Perfect Forward Secrecy (PFS) in der JPBerlin

Die NSA-Diskussionen haben aufgerüttelt: Was eigentlich schon seit über einem Jahrzehnt klar war und wovor wenige Rufern in der Wüste (ungehört) gewarnt haben, ist ins Bewußtsein gerückt: Geheimdienste hören im großen Stil, teilweise flächendeckend, Internet Traffic ab. Nur das tatsächliche Ausmaß hat letztenendes überrascht.

Vielen Unternehmen und ISPs ist in den letzten Wochen ins Bewußtsein gerückt, daß Datenverschlüsselung über SSL/TLS überhaupt nötig wird — nicht wenige auch große Provider haben selbst das bislang nicht genutzt.

Andererseits hat sich in der Wahrnehmung ebenso festgesetzt, daß eine schlechte Verschlüsselung nicht ausreicht und es mit „irgendeinem“ SSL/TLS nicht getan ist. Viel mehr noch: Solange damit zu rechnen ist, daß Unternehmen und große ISPs mit den Geheimdiensten kooperieren und ggf. auch Zugriff auf Schlüssel ermöglichen, oder solange damit zu rechnen ist, daß Geheimdienste auf anderem Weg Kenntnis der benutzten Schlüssel erlangen können, ist auch ein Schutz gegen eine nachträgliche Entschlüsselung nötig. Ein heute (unentschlüsselbar) aufgezeichneter Netzwerkverkehr soll nicht in einigen Monaten oder Jahren nachträglich noch entschlüsselt werden können.

Die Lösung dieses Problems heißt „Perfect Forward Secrecy“ (PFS). Darüber hat es in den letzten Wochen viel Wirbel gegeben. Zeitschriften haben darüber berichtet, Provider haben begonnen, hektisch (endlich!) SSL/TLS und auch PFS einzurichten.

Die JPBerlin bietet seit jeher konsequent alle Dienste auch stets verschlüsselt per SSL/TLS an. Und „seit jeher“ heißt bei uns: Seit über 15 Jahren. Und natürlich sind unsere Maildienste auch alle bereits über Perfect Forward Secrecy (PFS) abgesichert — für den derzeit bestmöglichen Abhörschutz.

So funktioniert Perfect Forward Secrecy (PFS)

Perfect Forward Secrecy (PFS) basiert auf der Idee, daß Client und Server ihre Kommunikation über einen zusätzlichen temporären Schlüssel absichern, der wechselt. Da der Verbindungsaufbau so gestrickt ist, daß der Schlüssel selbst gar nicht ausgetauscht werden muß, kann der jeweils benutzte Sitzungsschlüssel selbst auch nicht aufgezeichnet werden. Eine nachträgliche Entschlüsselung einer früher aufgezeichneten Session ist auch dann nicht mehr möglich, wenn ein Dritter nachtäglich in den Besitz des SSL/TLS-Verschlüssels des Servers gelangt.

2 Kommentare

Peer Heinlein

2013-09-06 13:04:02

Maildienste nutzen die Protokolle SMTP, POP3, IMAP und Managesieve. Auf diesen Protokollen bieten wir (EC)DHE-Ciphers an und damit PFS. Der zitierte Test von ssllabs.com testet eine WEBseite, keine Maildienste. Unsere Webseite ist noch nicht auf PFS umgestellt, weil verschiedene Browser (namentlich IE) hier umfangreiche Schwierigkeiten machen und das nicht-trivial ist, will man alte Browser nicht aussperren. Wir arbeiten daran. Unsere Aussage bezog sich auf die Maildienste und ist richtig. peer@booster:~> openssl s_client -starttls smtp -connect mx1.jpberlin.de:25 Cipher : ECDHE-RSA-AES256-GCM-SHA384 peer@booster:~> openssl s_client -starttls imap -connect imap.jpberlin.de:143 Cipher : DHE-RSA-AES256-SHA Wir haben in unserem Blog erklärt, wie man PFS einrichtet und was es damit auf sich hat: http://www.heinlein-support.de/blog/security/perfect-forward-secrecy-pfs-fur-postfix-und-dovecot/

Sicherheit?

2013-09-06 12:53:31

Ihr nutzt mit kein Perfect Forward Secrecy! https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fwww.jpberlin.de Die aussage " Und natürlich sind unsere Maildienste auch alle bereits über Perfect Forward Secrecy (PFS) abgesichert " ist also eine dreiste Lüge.