'Opportunistic' TLS-support

SchwarzeBeere

Moderator
Mitarbeiter
Moin zusammen,

wie schon unzählige Male in der Chatbox angesprochen wurde, starte ich jetzt auch mal offiziell die Diskussion, das Habo in Zukunft mit einer abgeschwächten Konfiguration von TLS auszustatten. Nach den in der Vergangenheit bekannt gewordenen Überwachungsmaßnahmen aus- und inländischer Geheimdienste wäre das nicht nur eine technische Spielerei, sondern vor allem ein politisches Statement, das auch von der IETF derzeit im Rahmen von Opportunistic Encryption und HTTP/2 diskutiert wird.

Mir ist durchaus bekannt, dass die WebPKI eine Reihe kritischer Design- (Revocation, Trust Management, ...) und Implementierungsprobleme (Heartbleed, ...) aufweist und damit gegen direkte vom Staat finanzierten Angriffe keine ausreichende Sicherheit bietet. Beim derzeitigen Stand der Entwicklung (diverse Notaries, Certificate Transparency, ...) muss man auch davon ausgehen, dass man schlicht noch einige Jahre für eine anständige Lösung brauchen wird. Viele Probleme könnte aber durch ein geeignetes Angreifermodell von vorne herein aus dem Scope ausgeschlossen werden. Als Angreifermodell schlage ich hierbei vor, dass man sich lediglich auf lauschende Angreifer konzentriert und weniger auf aktive Man-in-the-Middles, denen auch die Möglichkeit zur Verfügung steht, Pakete zu ändern, löschen oder im Namen des Clients/Servers zu verschicken. In dieses Angreifermodell fallen dann zum Beispiel:

- Abhörende Geheimdienste
- Diverse Produkte zum massenhaften Mitschneiden von Traffic, oft eingesetzt für Lawful Interception und aufgrund der hohen Anzahl an Connections nicht in der Lage, Zertifikate auszutauschen, ChangeCipherSuite-Pakete zu senden oder direkte Angriffe auf die Implementierung durchzuführen.
- Böse Geschwister/Mitbewohner/fürsorgliche Eltern mit geringer IT-Kenntnissen im heimischen WLAN
- Betreiber und Teilnehmer öffentlicher WLAN-APs
- ...

Die Umsetzung ist relativ simpel, denn TLS bringt hierfür schon die folgenden Cipher Suites mit:
RFC 5246 hat gesagt.:
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 };
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A };
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = { 0x00,0x6C };
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = { 0x00,0x6D };
Die Implementierung ist ebenfalls nicht schwer. So besitzen inzwischen alle Webserver eine Direktive wie SSLCipherSuites. Gleichzeitig entfallen einige Operation innerhalb des TLS Handshakes, was die Performance steigert, da lediglich ein DH Key Exchange erfolgen muss. Man hätte also die Möglichkeit zu verschlüsseln bei geringem zusätzlichem Overhead (weitere Infos auch z.B. hier) und ohne die Kosten eines TLS Zertifikats einer CA. Als Fallback könnte man darüber hinaus auch auf CACert-Zertifikate oder Let's Encrypt setzen und diese mittels DANE oder ähnlichen Mechanismen zusätzlich absichern. Diese Lösung ginge aber über das oben kurz genannte Angreifermodell hinaus. Zur Senkung der Betriebskosten könnte man natürlich weiterhin die Möglichkeit der unverschlüsselten Kommunikation anbieten, sodass TLS nur optional zum Einsatz kommen muss.

Damit ist das Thema nun endlich mal auf den Weg gebracht. Weitere Infos, auch zum Browser Support, gibts, wenn ich dazu gekommen, das auch mal selbst zu implementieren, was nun am Wochenende so weit sein sollte.

Viele Grüße,
SB

edit:
Ich habe das mal getestet, leider bislang ohne Erfolg:

Die host.conf unter nginx (der trotz ADH als einzig konfigurierter Cipher Suite Zertifikat und Key fordert...):
Code:
server {
        listen 443 ssl;
        ssl_certificate '/etc/nginx/sites-available/host.crt';
        ssl_certificate_key '/etc/nginx/sites-available/host.key';
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers ADH;
        ssl_dhparam /etc/ssl/certs/dhparam.pem;
       ...
}
Rückgabe im Firefox 35.0:
ssl_error_inappropriate_fallback_alert
sowie nach Aktivierung von SSLv3
ssl_error_no_cypher_overlap
Rückgabe in Chrome 40.0.2..
ERR_SSL_PROTOCOL_ERROR
Safari ist benutzerfreundlich und gibt nichtmal mehr nen Fehlercode aus, verweigert aber jede weitere Aktion.

Tjo.. damit hat sich das wohl erledigt fürs erste..
 
Zuletzt bearbeitet:
Oben