In den letzten Tagen häufen sich die Meldungen über Google bezüglich verschlüsselter Webseiten. Zugegeben… Etwas überraschend für mich! So hat Google angekündigt künftig Webseiten, die verschlüsselt HTTPS ( also per SSL / TLS ) erreichbar sind. In seinem Ranking bei den Suchergebnissen zu bevorzugen. (HTTPS as a ranking signal)
Na da werden sich wohl einige CAs die Hände reiben und die SEOs wieder viel arbeiten haben. Hoffen wir mal das inzwischen alle Hoster SNI können, sonst wird diese Aktion sicher dem IPv4 Pool noch mal ordentlich etwas abziehen. BTW. Habe ich schon gesagt das es Zeit ist sich mit IPv6 zu beschäftigen?
Jetzt lese ich gerade das Google eine kleine Liste für seinen Browser Chrome führt. Eine Liste für HTTPS only Seiten. In genau diese Liste kann sich nun jeder mit seiner Webseite eintragen, der dafür gesorgt hat, dass seine Webseite nur per HTTPS zu erreichen ist. Dazu setzt Google auf HSTS (HTTP Strict Transport Security). Das Thema Stirct Transport Security habe ich ja bereits, unter anderem, vor einigen Wochen hier beschrieben: Apache und sichere SSL / TLS Verschlüsselung
Nun kann man sich also über diese Seite https://hstspreload.appspot.com/ in die Liste eintragen. Dabei erwartet Google zum Header max-age noch includeSubDomains und preload. Ist die Seite eingetragen bedankt sich Google und verweist als nächsten Schritt zur SSLlabs Testseite um ggf. vorhandene Probleme mit seiner SSL/TLS Konfiguration zu beheben.
Google tut dieses alles ganz sicher nicht aus Nächstenliebe, denn noch wird es die allgemeine Sicherheit, vor allem aber das Theme selbst, mehr in den Vordergrund ziehen. So wird sich vielleicht der eine oder andere „Entscheider“ nun doch mit einer positiven Rückmeldung zu dem Thema bei der IT melden!
Google lehnt hin und wieder E-Mails ab, die per IPv6 eingeliefert werden. Der Mailserver ist korrekt konfiguriert, SPF, DKIM, DMARC und DANE sind vorhanden, kein Eintrag auf irgendeiner Blacklist. Per IPv4 geht die gleiche Mail problemlos durch.
Die Fehlermeldung
550-5.7.1 Our system has detected that this message is likely
550-5.7.1 unsolicited mail. To reduce the amount of spam sent
550-5.7.1 to Gmail, this message has been blocked.
Der verlinkte Support-Artikel hilft nicht weiter. Alle Vorgaben sind erfüllt. Googles Antwort auf Nachfrage: „Warum genau eine E-Mail abgewiesen wird, können wir Ihnen leider nicht mitteilen.“ Das betrifft gmail.com, googlemail.com und jede bei Google gehostete Domain gleichermaßen.
Workaround: IPv4-only für Google
Da Google per IPv4 keine Probleme macht, lässt sich Postfix so konfigurieren, dass E-Mails an Google-Domains nur über IPv4 zugestellt werden. Das ist unnötig, ärgerlich und widerspricht dem Gedanken hinter IPv6. Aber es funktioniert.
In /etc/postfix/master.cf einen eigenen SMTP-Service anlegen, der nur IPv4 spricht:
smtp4 unix - - - - - smtp -o inet_protocols=ipv4
In /etc/postfix/main.cf die Transport Map aktivieren:
transport_maps = hash:/etc/postfix/transport
Die betroffenen Domains in /etc/postfix/transport eintragen:
googlemail.com smtp4:
gmail.com smtp4:
Anwenden und Postfix neu laden:
postmap /etc/postfix/transport
service postfix reload
E-Mails an Google-Domains gehen ab sofort nur noch über IPv4 raus. Wer weitere Domains pro Ziel steuern will, findet in Postfix TLS Policy Maps einen ähnlichen Ansatz.
Veraltet: StartSSL wurde 2017 von allen Browsern als nicht vertrauenswürdig eingestuft und ist nicht mehr verfügbar. Let’s Encrypt ist der kostenlose Standard für TLS-Zertifikate.
Etwas hilflos stand ich heute vor der Meldung von Openfire, welche mit mitteilte, dass mein Zertifikat von StartSSL nicht importiert werden konnte.
Über folgenden Weg habe ich es denn noch in meinen Openfire gießen können.
1. OpenFire beenden.
2. Das Root-Zertifikat von StartSSL sowie das Class1 Zertifikat für Server ist bereits im Java Truststore von Openfire enthalten. Da ich ein Class2 Zertifikat erstellt habe, muss ich das Intermedia Zertifikat noch aufnehmen. Sonst lässt sich ja kaum eine Kette bilden.
In meiner Installation liegt mein Openfire unter /etc/. Dort findet sich auch der Trust- sowie der Keystore. Die nächsten Schritte finden also am besten direkt dort statt. Damit ich am Ende direkt mein Zertifikat und das Intermediate Zertifikat in einem Rutsch importieren kann. Werfe ich direkt beide zusammen. Domain.tld.cert ist dabei der öffentliche Teil meines Zertifikates.
3. Das eigentliche Zertifikat muss ins pkcs12 Format konvertiert werden, domain.tld.key ist dabei der private Teil meines Zertifikates. Bei dieser Aktion muss ein Kennwort erstellt werden. Das Standardkennwort des Keystores ist: „changeit“. Ich nutze dieses hier ebenfalls.
Es gibt inzwischen viele Webtools die TLSA-Records prüfen. Aber wer es einmal von Hand gemacht hat, versteht was dabei passiert. Der Ablauf ist immer gleich: Zertifikat vom Server holen, Hash berechnen, mit dem DNS-Record vergleichen.
Zertifikat holen
Verbindung zum Mailserver aufbauen und das Zertifikat per STARTTLS abholen:
Welchen Hash man berechnen muss, hängt vom TLSA-Record ab. Die drei Felder im Record bestimmen das:
Usage
0 = CA, 1 = End-Entity (Kette muss gültig sein), 2 = Trust Anchor, 3 = End-Entity (keine Kettenprüfung)
Selector
0 = ganzes Zertifikat, 1 = nur Public Key (SPKI)
Matching Type
0 = exakter Vergleich, 1 = SHA-256, 2 = SHA-512
Am häufigsten sieht man 3 1 1 (End-Entity, nur Public Key, SHA-256) oder 3 0 1 (End-Entity, ganzes Zertifikat, SHA-256). Zuerst den TLSA-Record aus dem DNS holen um zu sehen was erwartet wird:
dig _25._tcp.smtp.kernel-error.de TLSA +short
Dann den passenden Hash berechnen. Bei Selector 0 (ganzes Zertifikat) und Matching Type 1 (SHA-256):
In der Ausgabe steht am Ende entweder Verified TLS connection established (DANE-Prüfung bestanden) oder eine Fehlermeldung mit dem konkreten Problem. Das Tool löst die MX-Records auf, holt den TLSA-Record, baut die TLS-Verbindung auf und vergleicht alles automatisch.
O-o nun mal im Ernst, mich wundert an der Geschichte eher dass dieses Viele überrascht. Schauen wir uns doch mal die durchschnittlichen Kennwörter der meistern Benutzer an. Die sind nicht wirklich gut und oft haben sie ebenfalls nur ein Kennwort für alle ihre Dienste. Natürlich haben sie ja per default nichts zu verbergen, also wird auf „Sicherheit“ nicht unbedingt Wert gelegt… Klar geht mir in diesen Fällen immer ein Schmunzeln über die Lippen. Denn man hat ja nichts zu verbergen und ist ja alles nicht SO schlimm. Nur wenn mein E-Mail Passwort von anderen geklaut wurde, ne da muss natürlich was passieren.
Ich lese und höre in den letzten Tagen immer das fiese, böse, Masken und Kapuzen tragende Hacker die E-Mail Accounts gehackt hätten. Viel eher werden wohl verseuchte Rechner die Kennwörter bei der Eingabe oder Übertragung eingesammelt und Kriminellen geschickt haben. Wenn ich mich so bei einigen Kunden umschaue sieht man schnell dass die großen drei Sicherheitslöcher Anwendungsprogramme (Java, Flash, PDF) meist in recht alten Versionen vorliegen. Die Microsoft Produkte selbst bekommen ja meist per WSUS oder direkt von Microsoft ihre Updates. Java, Flash oder der Acrobat Reader kümmern sich „selbst“ darum. Leider muss der Anwender für die Installation der Updates administrative Rechte auf dem Rechner haben. Sonst kann er die Installation kaum durchführen. Gut, es gibt auch hier Lösungen… Welche ich produktiv im Einsatz gesehen habe kann ich an einer Hand abzählen. Daher hängt es mal wieder vom Einsatz der hauseigenen IT ab. Das klappt mal gut, mal weniger gut. Gibt es keine eigene IT, sieht es schnell schlecht aus. Warum muss überhaupt jeder Anwender ins Internet und warum immer mit Flash, Java und PDF?!?!
Es lässt sich kaum ändern. Vor einiger Zeit hatten wir ja schon mal etwas ähnliches. Wie groß ist dann wohl die Dunkelziffer ? Beim letzten mal hat unser BSI nach langem überlegen die Idee eine Webseite zur Verfügung zu stellen auf welcher man seine E-Mail Adresse eingeben kann. Die Webseite war natürlich sofort tot und nicht erreichbar. Wer hätte schon damit rechnen können dass die eingeschüchterten Benutzer es wirklich probieren könnten? *kopfschüttel*
Man hat also seine E-Mail Adresse eingegeben und hat daraufhin die Info bekommen: Wenn deine E-Mail Konto geklaut wurde, dann bekommst du von uns eine GPG signierte E-Mail mit folgendem Betreff (Zufallszeichen). Nur wenn die E-Mail auch diesen Betreff hat ist sie von uns und du hast ein Problem!
Einmal mit Profis…. Nun nehmen wir das mal eben auseinander:
1. der GPG Schlüssel vom BSI ist auf der gleichen Webseite zu saugen und ist so vertrauenswürdig wie „der dicke Mann aus der Sparkassenwerbung“… 2. GPG ist toll nur wie viele der Anwender nutzen es wohl? 3. der Betreff, auf welchen es ankommt, wird bei einer GPG signierten E-Mail NICHT signiert. Er kann also wild geändert werden… 4. die E-Mail welche den Anwender darüber informiert das sein Account ggf. von anderen missbraucht wird, geht also an diesen Account. Der Missbrauchende müsste sie also nur ?löschen?.
Welcher Internetausdrucker hat sich dieses bitte überlegt?!?!?
Diese Kritikpunkte sind beim BSI angekommen und man könnte meinen, sie hätten es beim jetzt neuen Fall besser gemacht… Haben sie?
Natürlich nicht!!!
Zusätzlich wird man nun noch von seinem Provider informiert das sein Account „gefressen“ wurde und direkt gezwungen sein Kennwort zu ändern. Klappt natürlich nur bei den großen Providern. Ja OK, die meisten abgefischten Accounts liegen dort… Macht es denn noch nicht wirklich besser, oder?
Jetzt halten einige von den Pressemenschen wieder jedem dritten ihr Mikrofon unter die Nase… Dabei ergeben sich so Ideen wie: Es muss rechtliche Regelungen für so etwas geben. Zwei Wege Authentisierung usw. usw… Ob das wirklich alles so richtig ist?
Was bringt das alles wenn man Windows XP einsetzt, Java und Flash einem Sieb ähneln und die großen Provider dir beim Login erzählen das dein Adblocker die Sicherheit deines Browsers gefährdet? Dann sind wir schon bei E-Mail Made in Germany, richtig? Die Jungs hängen gerade an die große Glocke dass sie es 2014 geschafft haben TLS für ihre Verbindung einzuschalten und für die Anmeldung voraussetzten. 2014… Ich meine 2014… Das ist knapp 20 Jahre als. 2014. Die haben ihren Werbemastschweinen Kunden bis 2014 per Plaintext (also im Klartext) ein Login gestellt. Jeder hat durch bloßes hinschauen die Zugangsdaten abschreiben können. Die kommen dann mit „Sicherheit wiederherstellen“ und E-Mail Made in Germany und jetzt ist alles sicher?
Ach ich rege mich hier schon wieder auf…
Vielleicht sollte man aufhören seine Kunden auszuquetschen und mit Müll zu füttern. Hm, setzt natürlich voraus das die Kunden es wollen und vor allem mal von ihrem „kostenlos“ Ding wegkommen. Ach, ich höre nun auf, sonst habe ich für heute wieder schlechte Laune!
Unsichere Protokolle und Chiper aus Postfix, Dovecot und Apache2 sind schonmal weg!
Jetzt ist mein xmpp Jabber Server ejabberd dran… Auch hier müssen die Protokolle SSLv2 sowie SSLv3 weichen. Nur alles größer TLSv1 ist erlaubt…. Bei den Chipern fliegt alles raus das „böse“ ist… Zum Beispiel MD5, RC4 usw. usw… Natürlich werden auch die ECDHE Cipher suite aktiviert um Forward secrecy zu unterstützen.
Nachdem ich nun am Postfix hinsichtlich der SSL / TLS Sicherheit einige Einstellungen vorgenommen habe und sogar die nutzbare Cipher Suite eingeschränkt habe, da interessiert mich natürlich welche von den Clients genutzt werden. Daher fische ich für meinen Testzeitraum einfach mal per Regex (Regular expression) und egrep ein paar Infos aus dem Logfile und lege es hier zur Begutachtung hin.
So lässt sich nun gut verfolgen, welche Cipher, wie oft genutzt wird.
Begonnen habe ich mit dem Strict-Transport-Security Header. Sind diese gesetzt, und ein Client verbindet sich verschlüsselt (SSL / TLS) mit dem Webserver sagt ihm der Server: „Schön das du da bist. Ach ja, verbinde dich bitte die nächsten X Tage nur noch verschlüsselt mit mir, ok?“.
Normalerweise richten sich Webbrowser an diese „Bitte“ des Servers. Damit wird verhindert das ein Angreifer den Client überredet sich unverschlüsselt mit einem anderen Server zu unterhalten oder von der verschlüsselten Übertragung zur unverschlüsselten zu wechseln. Denn würde ein solcher Wechsel klappen, könnte der Angreifer ja ab dem Moment mitlesen!
Damit ich nun also die Strict-Transport-Security nutzen kann muss zuerst das Apache Modul headers aktiviert werden. Dieses erledige ich mit:
$ a2enmod headers
Fehlt nur noch eine weitere Zeile in der vhost Konfiguration:
Header always set Strict-Transport-Security "max-age=15552000"
max-age gibt einen Zeitwert in Sekunden vor. Dieser darf/sollte nicht kleiner als 180 Tage sein. 15552000 entspricht dabei genau 180 Tagen.
Damit wird also schon mal jeder Client für die kommenden 180 Tag versuchen verschlüsselt mit mir zu sprechen. Natürlich ist an dieser Stelle zu bedenken, wenn ich mich plötzlich dazu entscheiden sollte SSL/TLS nicht mehr anzubieten, werden es die Clients denn noch weiter so probieren. Also aufpassen….
Auf zu ssl crime attack… Dieser Angriff ist möglich wenn die SSLCompression aktiviert ist. Ich erweitere also meine Konfiguration des vhosts im Apache um folgende Zeile:
SSLCompression off
Um direkt die unsicheren und veralteten Protokolle zu deaktivieren folgt auf dem Fuße:
SSLProtocol +ALL -SSLv3 -SSLv2
Damit sich gleich alle an die Reihenfolge meiner zugelassenen Cipher Suite halten, gebe ich dieses noch einmal expliziet vor:
SSLHonorCipherOrder On
Fehlen nur noch die zu verwendenden Cipher Suites…. Dabei beginne ich mit den gewünschten Favoriten und gehe Stück für Stück weiter runter. Am Ende verbiete ich noch diese, welche ich auf keinen Fall nutzen will (alles vor dem ein Ausrufezeichen „!“ steht).
Veraltet: Die hier beschriebenen about:config-Einstellungen existieren in aktuellen Firefox-Versionen nicht mehr in dieser Form. Moderne Browser deaktivieren unsichere Protokolle und Cipher automatisch. Dieser Beitrag ist veraltet.
Nach der NSA „Geschichte“ sollte klar sein dass man mehr denn je darauf achten sollte eine möglichst sichere Verschlüsselung zu nutzen. Als Benutzer kann man leider nicht immer Einfluss auf die Gegenseite, den Server nehmen. Um denn noch etwas mehr steuern zu können, dass eine „sichere“ Verschlüsselung benutzt wird kann jeder etwas an seinem Client schrauben.
Warum? Nun ja….. Nehmen wir als Beispiel den Firefox Web Browser. Dieser unterstützt viele verschiedene Protokolle, diese noch in vielen verschiedenen Version und noch mehr Chiffrensammlungen. Die Gegenseite sollte ebenso mehrere Verfahren unterstützten. Der Hintergedanke dabei ist dass sich beide Seiten so auf ein Verfahren einigen können welches beide unterstützen. Wenn man also nun seinen Client nur Verfahren anbieten lässt, welche man als sicher erachtet… Tja, dann können sich beide nur auf ein sicheres Verfahren einigen. OK, wenn der Server nun nichts „sicheres“ anbietet, werden sie sich nicht einig werden. An dem Punkt muss man sich dann fragen ob man wirklich „unsicher“ mit der Gegenseite sprechen möchte oder nicht!
Es ist doch hin und wieder erschreckend, welche Seite nur ~schlechte~ Chipher anbieten. Hier ist wohl, wie so oft per IPv6, ein Weg zur Lösung… Nachfragen. Also den Betreibern einer solchen Seite die Frage stellen, warum geht das nicht?!?! Manche Antworten sind echt lustig.
Ich denke es gibt drei große Punkte an denen man ansetzten kann:
1. Sorgt dafür das der Browser nur noch als sicher bekannte Protokolle nutzt. 2. Wirft die als unsicher geltende RC4 Cipher Suite raus. 3. Sorgt dafür das selbst aufgezeichnete SSL/TLS Verbindungen in der Zukunft nicht so schnell gebrochen werden können, selbst wenn die Rechenleistung deutlich zunimmt.
Im Firefox lässt sich alles schnell und sehr einfach über die Seite: about:config einrichten.
B.t.w.: TLS (Transport Layer Security) ist der Nachfolger, die Weiterentwicklung von SSL (Secure Sockets Layer). Wir sprechen also besser nur von TLS, oder? Zurück zum Text…
1. TLS Version 1.0 als kleinstes unterstütztes Protokoll. Unter der about:config Seite in der Suche nach security.tls.version suchen. Hier den Wert security.tls.version.max auf 3 und den Wert security.tls.version.min auf 1 setzten.
2. RC4 Cipher Suite deaktivieren. Wieder über die Suche der about:config Seite nach rc4 suchen. Nun bei allen angezeigten Zeilen den Wert auf false setzten.
3. Perfect Forwad Secrecy (PFS) vorschreiben Erraten, about:config und die Suche benutzen. Gesucht wird security.ssl3…. Bei den Suchergebnissen nun alle Werte auf false setzten bei denen nicht ECDHE, DHE oder RC4 (wobei die RC4 „Jungs“ sollten ja bereits aus sein) in der Bezeichnung steht.
Ach ja…. Die Seite https://www.ausweisapp.bund.de/ kann spannenderweise nicht mehr aufgerufen werden, wenn man diese sicheren Einstellungen in seinem Browser vorschreibt. Lustig, hm?
U-P-D-A-T-E
Wem das alles etwas zu hart ist, der kann bei security.ssl3 den Wert: security.ssl3.rsa_aes_256_sha auf true lassen/setzten. Dieses würde sich zwar vielleicht mit steigender Rechenleistung entschlüsseln lassen. Ist aber aktuell noch recht sicher und wird von mehr Webseiten angeboten als nur auf Diffie Hellman zu setzten.
Es ist Zeit für ein neues Serverzertifikat. Im Standard sind dieses RSA Schlüssel mit einer Länge von 2048 Bit und SHA1 als Hash Algorithmus für Signaturen. Bei SHA1 bekommt man leider etwas Bauchschmerzen… 2048 Bit Keys sind nun ebenfalls nicht SO lang. Theoretisch noch „sicher“ aber wer will es schon darauf anlegen?
Nun wurde über Jahre an SSL / TLS Zertifikaten dieser Art festgehalten. Meist um kompatibel mit älteren Systemen zu sein. So können zum Beispiel die Betriebssysteme Windows XP sowie das darauf basierende Server Betriebssysteme von der Firma Microsoft, Windows Server 2003, nicht mit SHA2 umgehen.
Ich werde für die nächste Zertifikatsrunde auf 4096 Bit lange Schlüssel und SHA2 (SHA256) setzten. Selbst wenn ich damit einige Windows XP Benutzer abhängen werde!
Natürlich braucht man zusätzlich eine CA, welche mit X.509 Zertifikaten dieser Art umgehen kann. StartCOM / StartSSL kann dieses glücklicherweise. Ich erstelle die Zertifikate jeweils mit openSSL (Patch nicht vergessen!).
? Beim letzten mal hat unser BSI nach langem überlegen die Idee eine Webseite zur Verfügung zu stellen auf welcher man seine E-Mail Adresse eingeben kann. Die Webseite war natürlich sofort tot und nicht erreichbar. Wer hätte schon damit rechnen können dass die eingeschüchterten Benutzer es wirklich probieren könnten? *kopfschüttel*
