Häufigkeit von TLS Ciphern

Ich hatte etwas Zeit für eine kleine Analyse und wollte eigentlich mal nachsehen, ob noch jemand SSLv3 statt TLS für Verbindungen zu unseren Mailservern benutzt. Also habe ich die Logfiles der letzten 4 Wochen nach den Verbindungsparametern gefiltert. Folgende Studie kam dabei heraus:

gezähltCipher
1TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128
1TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256:
1TLSv1.2:ECDHE-RSA-AES128-SHA:128
3TLSv1:DHE-DSS-AES256-SHA:256
5TLSv1.2:DHE-RSA-AES128-SHA256:128
6TLSv1.1:ECDHE-RSA-AES128-SHA:128
6TLSv1.2:EDH-RSA-DES-CBC3-SHA:168
7TLSv1.2:AES128-GCM-SHA256:128
10TLSv1.2:DES-CBC3-SHA:168
11TLSv1.1:AES256-SHA:256
12TLSv1.1:DHE-RSA-AES256-SHA:256
13TLSv1.2:CAMELLIA256-SHA:256
24TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:
40TLSv1.2:DHE-RSA-AES256-SHA256:256
82TLSv1:EDH-RSA-DES-CBC3-SHA:168
83TLSv1:DHE-RSA-AES128-SHA:128
228TLSv1.2:ECDHE-RSA-AES128-SHA256:128
294TLSv1.2:AES256-SHA256:256
316TLSv1:DES-CBC3-SHA:168
386TLSv1:DHE-RSA-CAMELLIA256-SHA:256
455TLSv1.2:DHE-RSA-AES256-SHA:256
461TLSv1.2:AES128-SHA:128
606TLSv1.1:ECDHE-RSA-AES256-SHA:256
745TLSv1.2:AES256-SHA:256
760TLSv1.2:AES128-SHA256:128
2345TLSv1.2:DHE-RSA-AES128-SHA:128
2663TLSv1.2:ECDHE-RSA-AES256-SHA:256
3234TLSv1:AES128-SHA:128
9522TLSv1:DHE-RSA-AES256-SHA:256
9762TLSv1.2:AES256-GCM-SHA384:256
14110TLSv1:ECDHE-RSA-AES128-SHA:128
16894TLSv1.2:ECDHE-RSA-AES256-SHA384:256
18719TLSv1:AES256-SHA:256
36597TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
53900TLSv1:ECDHE-RSA-AES256-SHA:256
89330TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128
175139TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256

Grundlage der Studie sind 436.746 Emails, die unsere Server erreicht haben, also nicht, was gesendet wurde.

Was ich schonmal positiv finde, ist das Fehlen von SSL als Protokoll. Alle transportgesicherten Emails waren mit TLS gesichert. Leider konnten mich die eingesetzten/ausgehandelten Cipher nicht so beglücken z.b. TLSv1:AES256-SHA:256 . TLSv1 ist eigentlich SSLv3, nur leicht modifiziert und bereits erfolgreich gebrochen worden.

Um die Frage, die einigen Lesern auf der Zunge brennt: „Wieso lasst Ihr das zu?“ zu beantworten: Weil sonst keine Emails mehr bei den Kunden ankommen würden. Die Realität sieht nämlich leider so aus, daß die meisten Mailserver nicht auf Stand sind und es diesen Sendern auch egal ist. Die Senden zur Not auch ohne TLS. Heute erst bei der größten Film- und Fernseheproduktionfirma aus Hollywood erlebt.

Transportverschlüsselung wird also von vielen Firmen und Mailserverbetreiber immer noch als „egal, Hauptsache Mail kommt an“ abgetan und solange Ihr als Kunden nicht darauf besteht, daß der benutzte Mailserver A) TLS kann und B) den besten Cipher wählt der verfügbar ist, wird sich auch nichts ändern.

Unsere Server handeln den besten Cipher aus, der verfügbar ist. Versprochen 😉

interessant zu wissen wäre jetzt noch, welche Mailserver hinter den veralteten Ciphern stehen, nur kann ich damit leider nicht dienen.

1.108.500 KM Scheiße am Tag

Ein paar unschöne Wahrheiten über uns Menschen

Wenn 7,39 Milliarden Menschen am Tag eine, im Schnitt, ca. 15cm lange Wurst legen, ergibt das die stattliche Länge von 1.108.500 km . Wickelt man das 27,7x um die Erde, wäre der Scheißestreifen  55,4 cm breit. Täglich. Und das sind nur wir Menschen auf der Welt. Das nimmt eine Fläche von 22,17 km² am Tag ein, so daß es 16.110 Tage ( 44 Jahre ) dauert bis Deutschland komplett zugekackt ist.

Bei einem Erde-Mond Abstand von 384.400 km kann man diese Strecke also 2,88 mal füllen, ergo einmal hin und zurück und noch mal bis ins Mondorbit auslegen.

Im Jahr 2050 kommt die Weltbevölkerung auf 9,3 Milliarden Menschen und das wären 1.455.000 km Scheiße am Tag und damit wird der tägliche Streifen auf 72,75 cm anwachsen.

Wo kommen die Zahlen her ?

– Wikipedia zur Anzahl der Menschen auf der Welt
– eigene Studien zur Ermittlung der Durchschnittslänge von … 🙂

 

Abweichungen von Webstatistiken und WordPress

Ich glaube, die Jetpack-Wordpress-Statistik lügt uns Blogger an.

Dummerweise gibt es keine Infos auf den Jetpackseiten, was genau die da tracken, nur was sie nicht tracken, nämlich einen selbst.

Nun habe ich noch die guten alten Webalizerauswertungen durchgesehen und konnte für einzelne Beiträge teilweise den zehnfachen Zugriff feststellen.

Beispiel:

Der Beitrag „QMMP & MP3 & Fedora 24“ wurde laut Jetpackstats gestern 18x aufgerufen. Es gibt aber alleine gestern in den Webstats 352x Aufrüfe der Landingpageurl für diesen Artikel.

Bei genauerer Analyse der Aufrufer, stammen viele von Google. Lassen wir die weg, sind es noch 212 Anfragen.
Werfen wir alle doppelten IPs raus, bleiben noch 112 unique IPs übrig.

Das sind 500% mehr Zugriffe, als Jetpack dem Blog zugestehen will. Und das war nur eine von zwanzig Landingpages an dem Tag.

Warum zählt Jetpack das nicht, weiß das wer ?

Wie kommt man an diese Zahlen auf die schnelle ran ?

Zunächst mal braucht man einen Webserver z.b. einen Apache httpd und den passenden VirtualHost Eintrag um die Logfiles zu schreiben:

    ServerName bloggt-in-braunschweig.de
    ServerAlias *.bloggt-in-braunschweig.de
    ErrorLog logs/error_log
    CustomLog domlogs/bloggt-in-braunschweig.de combined

Weil son Tag erst richtig ausgewertet werden kann, wenn er vorbei ist, macht man das einen Tag später, weswegen auf einem normalen Webserver die Logfiles schon weggepackt wurden, damit sie wenig Platz benötigen. Da das am Tag +1 zum eigentlich Datum geschieht, sieht die Zeile auf meinem Fedora Server so aus :

zgrep „13/Jul/2016“  bloggt-in-braunschweig.de.20160714.gz | grep  „GET /2016/07/13/qmmp-mp3-fedora-24“ | grep -v „google“ | awk ‚{print $1;}‘ | sort -u | wc –lines

Damit Ihr Euch das vorstellen könnt, hier eine Beispiellogzeile:

5.35.243.228 – – [13/Jul/2016:20:40:35 +0200] „GET /2016/07/13/qmmp-mp3-fedora-24/ HTTP/1.1″ 200 40382 „-“ „Friendica ‚Lily of the valley‘ 3.4.3-2-1191; https://friend.sraega.org“

Die interessanten Teile, habe ich hervorgehoben.

Der Befehl ‚zgrep „13/Jul/2016“ ‚ filtert uns nur Einträge von dem Tag aus dem mit GZIP gepackten Logfile.
Mit ‚grep  „GET /2016/07/13/qmmp-mp3-fedora-24“‚ filtern wir auf die Landingpage, d.h. die Aufrufe des Artikels, die geschehen sind, als er Startbeitrag auf der Startseite war und diese aufgerufen wurde, werden so nicht mitgezählt.
Das „grep -v google“ wirft den Googleboot raus, ziemlich penetranter kleiner Kerl übrigens, der kommt schon fast im 5 Minuten Takt an der Landingpage vorbei um zu schauen, ob die sich geändert hat.
AWK sollte man als Admin kennen, hier wird es benutzt um nur die IP, die als erstes in der Logzeile steht, auszufiltern.
sort -u “ kickt die doppelten Einträge der IP raus.
wc –lines“ zählt dann die übrig gebliebenen Zeilen, also das Ergebnis.

Und das Ergebnis war 112x .

Jetzt fragt man sich, was WordPress da eigentlich statistisch erfaßt und ohne in den Code schauen zu wollen, würde ich sagen: kompletten Schrott 🙁

Bestenfalls kann man an dem Ergebnis ablesen, wie Trends einzelnen Blogbeiträge so liegen, aber das wars schon.

Am Beispiel vom SuperTuxKart Beitrag von heute: 22x laut WordPress, 134x laut Apachelogfile (-google und doppelten)  (bis zu diesem Artikel) also auch wieder Faktor 6 ( 500% mehr ) Abweichung.

D.h. ab sofort geht mir die Statistik am …… vorbei 😀

Update: ein Plugin soll das Problem lösen, indem es den Job übernimmt. Ich hab es mal aktiviert. Also nicht wundern wenn es die nächsten Tage noch wenig anzeigt.