Willkommen im User-Forum von mailbox.org
 

Mailserver Verschlüsselung

6715739 hat dies geteilt, 3 Jahren her
vorgeschlagen

Für die Domain mailbox.org habt ihr euren Webserver vorbildlich konfiguriert um ausschließlich moderne Verschlüsselung (sogar nur mit Forward Secrecy) anzubieten und die Verschlüsselung auf 4096 bit DH zu setzen (inklusive 4096bit Key im Zertifikat).


Leider gilt das noch nicht für die eigentlichen Mailserver, denn sowohl stmp als auch imap/pop server nutzen nur 2048 bit DH Keys. Das ist zwar nicht unsicher aber es würde die Sicherheit sicherlich erhöhen dies anzupassen und wäre außerdem konsequent. Außerdem wird teilweise noch DES Verschlüsselung angeboten.


Es wäre außerdem sinnvoll bei den ECDHE ciphern die keys ebenfalls zu erhöhen, da die momentanen Standartgrößen nur 3072 bit entsprechen und somit niedriger sind als der Zertifikatschlüssel. Die Sicherheit hängt von dem schwächstem Gleid ab.


Als Provider mit Fokus auf Sicherheit macht es daher durchaus Sinn ein wenig mehr als den Standart an Verschlüsselung zu bieten ;)

Kommentare (12)

Foto
1

Gibt es eine (seriöse) Quelle dafür, das 2048 Bit DH Keys nicht sicher sind und das 4096 Bit sicherer sind? Die aus meiner Sicht neuesten Information dazu habe ich im Heinlein Blog gelesen (Common 1024 Bit DH nach RFC 2409 sind unsicher). Wenn das Out-of-Date ist, würden mich die Quellen sehr interessieren.

Wenn 2048 Bit DH-Param unsicher sind, welche Quellen gibt es für die Behauptung, das 4096 Bit sicher sind? Warum nicht 8192 Bit oder 16384 Bit oder gleich 32768 Bit? Wäre technisch möglich.

Wenn es einfach nur Dein "Bauchgefühl" ist und es keinen Grund für die Annahme gibt, das die aktuell genutzten 2048 Bit DH Keys unsicher sind, dann sollte die Leute von Heinlein sich lieber um OTP und U2F kümmern, dass wurde hier schon mehrfach gewünscht und würde wirklich eine Verbesserung in der Sicherheit bringen.

"Außerdem wird teilweise noch DES Verschlüsselung angeboten:"

Das kann ich vielleicht aus eigener Erfahrung beantworten: Weil es eine Menge Kunden gibt, die Windows nutzen (und ältere Versionen von Windows Software). MS Outlook 2011 wurde bei mailbox.org von Heinlein bereits rausgeworfen wegen schlechter Crypto, aber man kann es sich als E-Mail Provider (der auch Business Kunden betreut) wahrscheinlich nicht leisten, bei dem Thema zu übertreiben.

Es wird übrigens nicht DES angeboten sondern 3DES (nur um korrekt zu bleiben). Andere E-Mail Provider wie Posteo.de bieten 3DES ohne Forward Secrecy (vollständiger Cipher: TLS_RSA_WITH_3DES_EDE_CBC_SHA) sogar noch auf dem Webserver an, um Kunden mit alter Software nicht zu verlieren. mailbox.org macht als einer der ersten Mailprovider einen Schnitt und akzeptiert 3DES nicht mehr im Webinterface.

Foto
1

Wo habe ich behauptet das 2048 bit DH unsicher seien?

Im Gegenteil: "Das ist zwar nicht unsicher..." habe ich sogar geschrieben.

"Warum nicht 8192 Bit oder 16384 Bit oder gleich 32768 Bit?"

Weil das mailbox.org Zertifikat einen 4096bit Schlüssel bietet und dieses nur dann sinnvoll ist wenn die gesamte Kette nicht schwächer als 4096 bit ist. 2048bit gilt ebenfalls als sicher, aber wenn man schon im Zertifikat und auf den Webserver überall 4096bit verwendet und den Service auch als sicheren Provider bewirbt, dann sollte das auch konsequent umgesetzt werden.

Die Erhöhung der DH Werte auf den Mailservern ist keine große Sache, da gibt es weder große Abhängigkeiten die zu testen wären noch dauert es sonst mehr als 2 Minuten.

Unterm Strich sind die 4096bit (die mailbox ja auch teilweise verwendet) gegenüber den 2048bit lediglich etwas Zukunftssicherer und bietet möglicherweise Schutz gegen noch unbekannte Angriffe, daher hat das schon seine Berechtigung (zumindest wenn Sicherheit im Fokus steht)

Was 3DES angeht, ist dieses auf den imap Server deaktiviert und auf den smtp (submission) Servern nicht. Daher kann Kompatibilität hier eigentlich keine Rolle spielen.

Foto
1

Die Erhöhung der DH-Parameter der Mailserver ist keine kleine Änderung, die wir schnell mal in 5min machen werden.


Jede kleine Verschärfung der SSL/TLS-Parameter der Mailserver führt dazu, dass einige (möglicherweise exotische) Clients sich nicht mehr wie gewohnt verbinden können. Außerdem kommunizieren unsere Mailserver mit tausenden anderen Mailservern, die teilweise noch alte Versionen vom MTA exim nutzen o.ä.


Wenn die neue Konfiguration nur in 99% der Fälle gut funktioniert, dann bedeutet es, dass tausende Nutzer Probleme haben und ihre Mails plötzlich nicht mehr versenden können.


Sie kennen sicher unser kleines Feature des TLS-Check. Wenn zu einem anderen Mailserver in der Vergangenheit eine verschlüsselte Verbindung möglich war und aufgrund einer Verschärfung der TLS-Einstellungen nicht mehr wie zuvor möglich ist, dann geht unser System zuerst einmal von SSL-Interception aus und blockiert die Zustellung von Mails zu diesem Provider erst einmal komplett. (Das soll nur ein Beispiel dafür sein, dass eine Verschärfung von TLS-Parametern durchaus Folgen nach sich ziehen kann.)


Wir müssen also jede kleine Änderung umfangreich testen und die möglichen Auswirkungen gegen den Gewinn an Sicherheit abwägen. Das kostet durchaus mehrere Tage.


Wie sie selbst sagen, sind 2048 Bit DH-Parameter derzeit als sicher einzustufen. Nach dem gegenwärtigen Stand der Forschung bedeutet eine Erhöhung kaum einen Gewinn an Sicherheit.


Gleichzeitig ist es möglich, dass einige Clients und ältere Mailserver dann kein DHE Key Exchange mehr nutzen können und statt dessen evtl. auf den veralteten RSA Key Exchange ausweichen. Es ist also nicht zwangsläufig so, dass eine Erhöhung auf 4096 Bit in allen Fällen eine Verbesserung bedeuten muss. Beim Wechsel von 1024 auf 2048 war es ähnlich, allerdings war dieser Wechsel absolut notwendig, da 1024 Bit DH-Parameter wirklich unsicher waren.


Wir als Mail-Provider müssen also neben der Sicherheit auch Fähigkeiten der möglichen Kommunikationspartner in Betracht ziehen und eine Abwägung treffen, die die Sicherheit garantiert und gleichzeitig möglichst vielen Kommunikationspartnern eine sichere Kommunikation ermöglicht. Notwendige Änderungen aufgrund neuer Erkenntnis der Kryptoanalyse werden wir natürlich mit hoher Priorität behandeln und umsetzen. Wir beobachten die Entwicklung auf diesem Gebiet aufmerksam.


Wenn Nutzer eine höhere Sicherheit anstreben, können sie die Anpassungen auch im Mail Client vornehmen. Für Thunderbird gibt es eine Anleitung im Privacy-Handbuch. Aber auch dieses Beispiel zeigt, dass man evtl. Nachteile in Kauf nehmen muss. Mit den dort vorgeschlagenen Einstellungen funktioniert das Update der Add-ons nicht mehr (falls Mozilla beim AMO noch nicht aufgerüstet hat).

Foto
1

Vielen Dank für die ausführliche Antwort.

Das die Änderung nicht ganz so einfach ist war mir nicht bewusst.


"Sie kennen sicher unser kleines Feature des TLS-Check."


Nein leider kenne ich das nicht. Gibt es vielleicht einen Link für weitere Informationen dazu? Auf die schnelle konnte ich dazu nichts finden.


Ich würde mir wünschen, dass vielleicht bei nächster Gelegenheit die Erhöhung der DH Parameter mal geprüft werden könnte um zu schauen ob es denn tatsächlich Probleme gibt. Mir sind mehrere Provider bekannt, die da bisher keine Probleme mit hatten (und viele Mailinglisten verwalten).

Aber ihr seit da sicher diejenigen mit mehr Erfahrung.


Mein Anliegen ist lediglich euch auf mögliche Verbesserungen hinzuweisen.

Foto
Foto
1

Währe es nicht sinnvoll DHE gegenüber ECDHE zumindest zu beforzugen?

DHE ist eine seit vielen Jahren untersuchtes Verfahren mit gefestigte Implementierungen während ECDHE in seiner momentan verbreiteten Form bzw. mit den momentan üblichen Kurven, höchst umstritten ist. Nicht nur sind die verwendeten elliptischen von der NSA geschaffen und enthalten geheime und unerklärte Parameter die eine Hintertür beinhalten könnte (wäre nicht das erste mal), auch ist die Implementierung erheblich schwerer und weniger getestet.


Für einen sicheren Mailprovider wäre es also durchaus gerechtfertigt auf diese Methode zu verzichten, oder zumindest in den Cipher Order Einstellungen nach DHE einzuordnen um Kompatibilitätsprobleme auszuschließen.

Momentan bevorzugen die Web und smtp Server von mailbox.org leider ECDHE. Eine Änderung der Preferred Cipher Order könnte hier abholfe geben ohne Kompatibilitätsprobleme zu schaffen.


Für weitere Informationen sei auch hieraus verwiesen: https://safecurves.cr.yp.to/

Foto
1

Ihr Vorschlag entspricht der neuesten Änderung der "Suite B Security Empfehlung" vom Januar 2016, was aber im Widerspruch zu den Empfehlungen der IETF (RFC 7525 vom Mai 2015) steht. Das zeigt, wie dynamisch die Entwicklung zur Zeit ist.


Wir haben für die kommende Woche einen Umbau der TLS-Security der Webserver von mailbox.org geplant. Die Mailserver kommen später dran. Dabei planen wir folgende Änderungen:


- ECDHE wird weiterhin bevorzugt, allerdings mit einer Safe Curve, die von unabhängigen Experten als sicher definiert wurden (evtl. Curve25519 von Bernstein o.ä. siehe Ihr Link)


- Da die meisten Clients (Mozilla Firefox, Google Chrome usw. ) die Safe Curves nicht unterstützen, werden sie automatisch DHE nutzen (hoffentlich).


Das wollen wir Anfang der Woche auf unseren Testsystemen probieren und dann gegen Ende der Woche auf den Webservern ausrollen, wenn es wie erwartet funktionieren sollte.


Die Mailserver kommen etwas später dran.

Foto
1

Hut ab, hätte nicht erwartet, dass ihr euch da so weit mit beschäftigt.


Kleiner Tipp dazu:


Das Experiment mit den alternativen Kurven hatten wir als Projekt in der Uni vor einer Weile schon mal ausprobiert (vor der Standartisierung).

Dabei hatten einige Mailclients bei ihnen unbekannten Kurven Probleme gemacht, statt auf alternative Methoden wie DH zurückzugreifen.

Vermutlich sind die Probleme inzwischen gefixt, aber eventuell wollt ihr zur Fehlervermeidung eure Cipher Order bei dem Mailserver auf DHE stellen. Bei den Webservern war das nicht wichtig, dort konnten alle bekannten Browser damit umgehen.

Foto
1

Ich habe mir gestern Nacht das Problem noch einmal von einer anderen Seite angeschaut. Neben dem Schlüsseltausch ist natürlich auch die darauf folgende Verschlüsselung wichtig.

Zu beachten ist:

- Sowohl die IETF als auch ENISA usw. empfehlen AES-GCM als symmetrischen Chipher in Kombination mit SHA256 Hashes zur Authentifizierung der Daten.

- CHACHA20_POLY1305 ist zweifellos auch empfehlenswert, ist aber nicht standardisiert und wird nur von Google Chrome unterstützt (ist also nur ein nice-to-have Feature).

- AES-CBC in Kombination mit SHA wird nicht mehr empfohlen. Im RFC 7525 vom Mai 2015 steht zu SHA: "SHOULD not be used"

- Bei den Elliptischen Kurven unterstützen die gängigen Browser und Mail Clients als gemeinsamen Nenner nur secp256r1 (aka NIST P-256) undsecp384r1 (aka NIST P-384), die bei SafeCurves als "NOT Safe" gelistet werden.

Das Problem ist:

- Alle Programme die die NSS-Lib verwenden, können sichere Cipher (AES-GCM + SHA256) nur in Kombination mit ECDHE verwenden und nicht in Kombination mit DHE.

- Google Chrome kann CHACHA20_POLY1305 auch nur in Kombination mit ECDHE verwenden und nicht in Kombination mit DHE.

Wenn man für ECDHE sichere Kurven verwendet und damit für Firefox, Thunderbind usw. DHE-Schlüsseltausch erzwingt, dann werden diese Clients gleichzeitig auf AES-CBC mit SHA wechseln. Das wäre nicht erfreulich.

Es gäbe damit also keinen Gewinn an Sicherheit sondern eine deutliche Verschlechterung.

Foto
1

Noch eine Ergänzung:

Alle gängigen Crypto-Implementierungen und alle Empfehlungen bevorzugen ECDHE vor DHE. Lediglich die letzte Aktualisierung der "Suite B Security Recommendations" der NSA vollzieht einen kleinen Schwenk und stellt die Mathematik von DHE mit ECDHE auf eine Stufe.

Wenn ich unserem Team und gegenüber und dem Chef gegenüber die entgegengesetzte Ansicht durchsetzen will, dann braucht man dafür gute Argumente, ein Bauchgefühl reicht dafür nicht.

Es gibt einige Ellipitsche Kurven, die wirklich gebrochen sind (z.B. die bei Bitcoin verwendeten Koblitz-Kurven). Die Random Kurven secp384r1 undsecp256r1 sind in der Herleitung der Parameter unsicher ("not safe" bei SafeCurves), aber nicht wirklich praktisch gebrochen. Sebst wenn die NSA einen Ansatzpunkt hat, dann erfordert das evtl. in der Umsetzung erhebliche Rechenleistung? Das ist eher "Bauchgefühl" und weniger stichhaltiges Argument.

Foto
1

Eine letzte Ergänzung:


Bei dem Traffic, den wir auf unseren Servern haben, spielt die Performance auch eine Rolle und kostet für uns richtig Geld. Wir haben vor kurzem gerade neue Hardware ausgerollt und wir wollen weiter wachsen.


Das bedeutet natürlich nicht, dass wir auf Kosten der Sicherheit sparen werden. Unser Ziel ist es, wirklich Sicherheit zu bieten. Wenn wir Rechenleistung für Crypto verpulvern wollen, dann brauchen wir aber Argumente, ein "Bauchgefühl" reicht nicht.


Ihre Forschungsergebnisse interessieren mich aus Sicht des Anwenders/Providers, falls sie noch nicht publiziert sind, werde ich mich per Mail direkt bei Ihnen melden. Danke für die Anregungen zum Nachdenken.

Foto
1

"Wenn man für ECDHE sichere Kurven verwendet und damit für Firefox,

Thunderbind usw. DHE-Schlüsseltausch erzwingt, dann werden diese Clients

gleichzeitig auf AES-CBC mit SHA wechseln. Das wäre nicht erfreulich."


Das ist korrekt, daher habe ich auch vorgeschlagen, DHE zu bevorzugen, statt auf die neuen Kurven zu setzen. Hier sehe ich zunächst die Browser Entwickler am Zuge bevor sich diese durchsetzen können.


Bei ECDHE wäre eine bereits erwähnte Alternative zumindest die Schlüsselstärke zu erhöhen und auf secp384r1 zu setzen um A) gegenüber den üblichen Schlüsselgrößen von secp256r1 einen Sicherheitsabstand zu haben falls mal ein neuer Angriff bekannt wird und B) die ebenfalls erwähnten 4096bit des Zertifikats auszunutzen.


Hinsichtlich Performance ist insbesondere der Webserver relevant, da hier in der Regel mehr (Crypto)Last erzeugt wird. Außerdem sind Mozilla Clients sowieso auf ECDHE angewiesen wegen AES-GCM und daher ist dies sowieso notwendig.


Eine optimale Konfiguration in der Cipher Order ist bereits auf den mailbox imap Servern vorhanden:


TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A

TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp384r1) - A

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp384r1) - A

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A

TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp384r1) - A

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp384r1) - A

TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A

TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A

...


Für Clients die DHE mit GCM bzw. SHA256 unterstützen funktionieren die ersten beiden Methoden und für Mozilla Clients wird weiterhin ECDHE verwendet.


Außerdem wird hier bereits secp384r1 verwendet, das einzige was noch optimiert werden könnte wäre die DH Parameter auf 4096bit zu erhöhen.


"Die Random Kurven secp384r1 undsecp256r1 sind in der Herleitung der

Parameter unsicher ("not safe" bei SafeCurves), aber nicht wirklich

praktisch gebrochen."


Diese Kurven sind (auch laut SafeCurves) nicht nur in ihrer Herleitung unsicher, sondern insbesondere hinsichtlich der Implementierung. Es gibt viele DInge zu beachten die diese Kurven unsicher machen, sollte die Implementierung diese nicht ausreichend prüfen. Daher erfordert die Umsetzung dieser Kurven erheblich komplexe Algorithmen die viel Spielraum für Angriffe und Sicherheitsprobleme lassen.


"Alle gängigen Crypto-Implementierungen und alle Empfehlungen bevorzugen

ECDHE vor DHE. Lediglich die letzte Aktualisierung der "Suite B Security

Recommendations" der NSA vollzieht einen kleinen Schwenk und stellt die

Mathematik von DHE mit ECDHE auf eine Stufe."


Dieser "Schwenk" hat einen durchaus Interessanten Hintergrund, den können wir gerne per Mail besprechen, das gehört hier aber wohl nicht unbedingt her.

Foto