Veraltet: Seit Java 9 (2017) ist JCE Unlimited Strength standardmäßig aktiviert. Die hier beschriebene manuelle Installation der Policy Files ist bei aktuellen Java-Versionen nicht mehr nötig.
Möchte man unter seinem Java AES mit 256 Bit nutzen, muss man die JCE Unlimited Strength Jurisdiction Policy Files von Hand installieren.
Ja, man fühlt sich schnell einige Jahre zurück versetzt, als man noch aus den USA keine große Krypto exportieren durfte/darf. Daher war es ja lange nicht möglich große Krypto in Browsern einzusetzen. Das Java Thema ist sehr ähnlich!
Die Installation ist recht einfach.
Zuerst einmal die neuen Policy Files herunterladen (für Java 7):
Im heruntergeladenen ZIP-File finden sich zwei jar Dateien. Diese müssen nun gegen die…. na, sagen wir mal beschränkten, ausgewechselt werden. Auf einem Debian finden sich diese hier:
Nachdem beiden Dateien getauscht wurden, sind sie auch schon aktiv für jeden neuen Java Prozess. Ich will damit sagen, wenn es für den Openfire genutzt werden soll, diesen bitte einmal durchstarten.
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.
Habe ich ganz aktuell gesehen dass sich über die Webseite ssl-tools.net nun ebenfalls die DANE RECORDS testen lassen. Also einmal ob sie vorhanden sind und natürlich auch die Gültigkeit des RECORDS. Zu dem Thema bin ich ja bereits ein paar mal gefragt worden, da „einfache“ Test Tools noch rar waren. Was sich ja inzwischen endlich zu ändern scheint.
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).
Perfect Forward Secrecy (PFS) sorgt dafür, dass jede TLS-Verbindung einen eigenen temporären Schlüssel verwendet. Selbst wenn jemand den privaten Schlüssel des Servers in die Hände bekommt, kann er damit früher aufgezeichnete Verbindungen nicht entschlüsseln. Für E-Mail ist das besonders relevant, weil Mailverkehr gern auf Vorrat mitgeschnitten wird.
PFS bekommt man durch ECDHE- oder DHE-Schlüsselaustausch. Moderne OpenSSL-Versionen und aktuelle Postfix/Dovecot-Releases machen das Richtige von Haus aus. Trotzdem lohnt sich ein Blick auf die Konfiguration, um sicherzustellen, dass keine veralteten Protokolle oder Cipher-Suiten aktiv sind.
Postfix
Die relevanten Einstellungen in der main.cf:
# Eingehend (smtpd)
smtpd_tls_security_level = may
smtpd_tls_protocols = >=TLSv1.2
smtpd_tls_mandatory_protocols = >=TLSv1.2
smtpd_tls_mandatory_ciphers = medium
# Ausgehend (smtp)
smtp_tls_security_level = dane
smtp_tls_protocols = >=TLSv1.2
smtp_tls_mandatory_protocols = >=TLSv1.2
smtp_tls_mandatory_ciphers = medium
# Cipher-Präferenz beim Server
tls_preempt_cipherlist = yes
>=TLSv1.2 schaltet TLS 1.0 und 1.1 ab. tls_preempt_cipherlist = yes lässt den Server die Cipher-Reihenfolge bestimmen, nicht den Client. Postfix sortiert AEAD-Ciphers (GCM, CHACHA20) automatisch nach vorn, PFS-Ciphers haben Vorrang. Die medium-Stufe schließt alles unterhalb von 128-Bit-Verschlüsselung aus.
Für den ausgehenden Versand ist smtp_tls_security_level = dane die beste Wahl. Damit prüft Postfix TLSA-Records per DANE. Gibt es keinen TLSA-Record, fällt Postfix auf opportunistisches TLS zurück. Wer zusätzlich MTA-STS auswertet, deckt auch Server ohne DNSSEC ab.
Dovecot
In /usr/local/etc/dovecot/conf.d/10-ssl.conf (FreeBSD) bzw. /etc/dovecot/conf.d/10-ssl.conf (Linux):
ssl = required erzwingt TLS für alle Verbindungen. ssl_min_protocol = TLSv1.2 schließt alte Protokolle aus. ssl_prefer_server_ciphers = yes gibt dem Server die Kontrolle über die Cipher-Wahl. no_ticket deaktiviert TLS Session Tickets, die PFS untergraben können wenn der Ticket-Key kompromittiert wird.
Eine explizite Cipher-Liste ist bei aktuellem OpenSSL nicht nötig. Die Defaults bevorzugen ECDHE mit AEAD. Wer es trotzdem einschränken will:
ssl_cipher_list gilt für TLS 1.2, ssl_cipher_suites für TLS 1.3. Bei TLS 1.3 ist PFS immer aktiv, da gibt es keine Cipher-Suiten ohne Schlüsselaustausch mehr.
Testen
# Postfix (STARTTLS auf Port 25)
openssl s_client -starttls smtp -connect smtp.kernel-error.de:25 2>/dev/null | grep -E "Protocol|Cipher|Server Temp Key"
# Postfix (Implicit TLS auf Port 465)
openssl s_client -connect smtp.kernel-error.de:465 2>/dev/null | grep -E "Protocol|Cipher|Server Temp Key"
# Dovecot (STARTTLS auf Port 143)
openssl s_client -starttls imap -connect imap.kernel-error.de:143 2>/dev/null | grep -E "Protocol|Cipher|Server Temp Key"
# Dovecot (Implicit TLS auf Port 993)
openssl s_client -connect imap.kernel-error.de:993 2>/dev/null | grep -E "Protocol|Cipher|Server Temp Key"
Entscheidend ist die Zeile Server Temp Key. Steht dort X25519, ECDH P-256 oder DH 2048, ist PFS aktiv. Mit OpenSSL 3.5+ und entsprechender Konfiguration sieht man dort auch X25519MLKEM768 für Post-Quantum-Schlüsselaustausch.
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.
Wer eine strenge DMARC-Policy veröffentlicht und gleichzeitig Mailinglisten nutzt, wird früher oder später feststellen: Die eigenen Mails werden auf der Liste zugestellt, aber beim Empfänger abgelehnt. Das liegt nicht an einem Konfigurationsfehler, sondern an der Art wie Mailinglisten funktionieren.
Das Problem
DKIM signiert nicht nur den Body einer E-Mail, sondern auch bestimmte Header wie den Betreff. Mailinglisten-Manager wie Mailman verändern die Mail aber auf dem Weg zum Empfänger. Sie hängen einen Identifier an den Betreff ([liste-name]), fügen einen Footer mit Abmelde-Link an den Body an und setzen eigene Header. Jede dieser Änderungen bricht die DKIM-Signatur.
SPF schlägt ebenfalls fehl, weil die Mail jetzt vom Listserver kommt und nicht mehr vom Mailserver des ursprünglichen Absenders. Die IP des Listservers steht nicht im SPF-Record der Absender-Domain.
DMARC prüft ob mindestens DKIM oder SPF bestehen und das Alignment stimmt. Beides schlägt fehl. Bei einer Policy von p=reject wird die Mail vom empfangenden Server abgelehnt. Der Absender bekommt einen Bounce, der Empfänger sieht die Mail nie.
Workarounds der Listenbetreiber
Mailinglisten-Manager haben verschiedene Strategien entwickelt um das Problem zu umgehen:
From-Rewriting
Der Absender wird auf die Listenadresse umgeschrieben. DMARC-Alignment passt dann zur Listendomain. Nachteil: Man sieht nicht mehr wer die Mail geschrieben hat.
Subject-Tag weglassen
Kein [liste] im Betreff. Schont die DKIM-Signatur, aber der Betreff allein reicht nicht, die Signatur kann trotzdem brechen wenn der Body verändert wird.
Footer weglassen
Kein Abmelde-Link im Body. Schont DKIM, aber Listenbetreiber brauchen den Footer oft aus rechtlichen Gründen.
DKIM re-signing
Die Liste signiert die Mail neu mit ihrer eigenen Domain. Funktioniert, aber die originale Signatur des Absenders geht verloren.
Keiner dieser Workarounds ist sauber. Entweder geht Information verloren oder die Authentizität leidet.
ARC: Die eigentliche Lösung
Authenticated Received Chain (RFC 8617) wurde genau für dieses Problem entwickelt. Die Idee: Jeder Zwischenserver (wie ein Listserver) speichert die Authentifizierungsergebnisse der eingehenden Mail in einem ARC-Header und signiert diesen. Der empfangende Server kann dann die Kette zurückverfolgen und sehen, dass die Mail beim Eintritt in die Liste noch gültig war.
ARC-Authentication-Results enthält die Ergebnisse zum Zeitpunkt der Annahme. ARC-Message-Signature signiert die Nachricht in ihrem aktuellen Zustand. ARC-Seal signiert die gesamte ARC-Kette und verhindert Manipulation.
Der empfangende Mailserver prüft die ARC-Kette. Wenn er dem Listserver vertraut und die Kette gültig ist, kann er die Mail trotz gebrochener DKIM-Signatur zustellen. Gmail, Microsoft und Yahoo werten ARC bereits aus. rspamd unterstützt ARC-Validierung und ARC-Signing von Haus aus.
In der Praxis
Mailman 3 unterstützt ARC-Signing. Bei Mailman 2 lässt sich ARC über einen vorgeschalteten Milter nachrüsten. Wer rspamd als Milter einsetzt, kann ARC dort aktivieren und braucht keinen separaten Dienst.
Die Empfehlung für Listenbetreiber: ARC-Signing aktivieren und den Betreff nicht verändern (statt [liste] den List-Id-Header nutzen, den alle modernen Mailclients auswerten können). Für Absender mit p=reject: ARC reduziert das Problem erheblich, löst es aber nur wenn die Gegenseite ARC auch prüft. In der Übergangsphase hilft es, bekannte Listserver per DMARC-Whitelist von der Policy auszunehmen.
? 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*
