BenBE's humble thoughts Thoughts the world doesn't need yet …

Nachdem in letzter Zeit mehrere Probleme mit SSL und TLS bekannt geworden sind und ich mich bereits mehrfach an die Konfiguration eines Workarounds gesetzt habe, gelang gestern der Durchbruch, das BEAST zu bezwingen.

Bevor ich jetzt tief in Details einsteige, der wahrscheinlich für die meisten mit GnuTLS wichtigste Teil:

GnuTLSPriorities SECURE256:-CIPHER-ALL:+COMP-DEFLATE:-MAC-ALL:!MD5:!ANON-DH:!3DES-CBC:-CAMELLIA-256-CBC:!CAMELLIA-128-CBC:-AES-256-CBC:!AES-128-CBC:+VERS-TLS1.2:+VERS-TLS1.1:+SHA384:+SHA256:+AES-256-GCM:+SHA1:+VERS-TLS1.0:+ARCFOUR-128:+CAMELLIA-256-CBC:+AES-256-CBC:%SERVER_PRECEDENCE

Das ist sicherlich noch nicht perfekt (insbesondere, weil er aus irgendeinem Grund noch RSA-KEX vor DHE-RSA priorisiert), aber zumindest gibt es schon mal eine Ausgangskonfiguration, mit der es prinzipiell funktioniert.

Also zur Erklärung der doch sehr kryptischen Zeile, deren Syntax in der Dokumentation zwar beschrieben ist – leider jedoch ohne Erwähnung ein paar sehr wichtiger Details. Daher war dann auch eine an anderer Stelle gefundene Beschreibung sehr hilfreich, auch wenn diese nicht wie gewünscht funktioniert hat.

Aber sie enthielt zwei wichtige Punkte, die entweder in der offiziellen Dokumentation fehlten oder meinem Blick geschickt entwichen sind.

• Durch Anhängen von %SERVER_PRECEDENCE kann man GnuTLS dazu bringen, die Reihenfolge von Ciphern basierend auf dem Priority-String serverseitig zu ermitteln.
• Durch Entfernen und Neueinfügen von Cipher-Gruppen kann man diese komplett umsortieren

Der erste Punkt war mir dabei zwar bereits über den Weg gelaufen, jedoch funktioniert dieser erst ab GnuTLS 3 – welches in Debian Veraltet und Debian Instabil leider nicht per Default installiert ist. Und auch wenn man etwas nachhilft, muss man mit GnuTLS noch etwas vorsichtig umgehen; mit etwas Conflict Resolution im Aptitude lässt sich ein System aber recht gut auf GnuTLS 3 ziehen.

Der Priority-String ist mit oben erwähnten zwei Punkten auch recht schnell erklärt:

1. SECURE256: Alle Cipher ab 256 Bit Keystrength aktivieren (Auch wenn SECURE256 ein Alias für SECURE192 ist und daher ab 192 Bit die Cipher aktiviert – aber Kryptographie ist selten Straight Forward)
2. -CIPHER-ALL: Alle Cipher deaktivieren
3. +COMP-DEFLATE: Kompression aktivieren
4. -MAC-ALL:!MD5: Alle MAC-Verfahren deaktivieren und insbesondere MD5 entgültig
5. !ANON-DH: Anonymes Diffie-Hellman KEX unterbinden (entgültig)
6. !3DES-CBC: Und Triple-DES wollen wir auch nicht mehr sehen
7. -CAMELLIA-256-CBC:!CAMELLIA-128-CBC:-AES-256-CBC:!AES-128-CBC: 128-Bit-Cipher entfernen und 256-Bit-Cipher vorübergehend deaktivieren
8. +VERS-TLS1.2:+VERS-TLS1.1: Protokoll-Support für TLS1.2 und TLS1.1 aktivieren
9. +SHA384:+SHA256:+AES-256-GCM: Cipher mit SHA384 und SHA256 als MAC erlauben und passende Varianten mit AES-256 mit GCM aktivieren
10. +SHA1: Dahinter die Varianten mit SHA1 als MAC einsortieren
11. +VERS-TLS1.0:+ARCFOUR-128: Das BEAST bekämpfen und einen für BEAST unanfälligen Cipher einsortieren (Und ja, RC4 [sic] hier verwenden zu müssen schmerzt!)
12. +CAMELLIA-256-CBC:+AES-256-CBC: Und noch einige CBC-Cipher, wobei CAMELLIA vor AES verwendet werden sollte
13. %SERVER_PRECEDENCE: Und zu guter Letzt sagen wir GnuTLS noch, dass die Reihenfolge (und nicht nur die Technik) wichtig ist.

Wer zusätzlich neben dem BEAST auch gegen Kriminalität vorgehen möchte, lässt in obigem Priority String einfach das Aktivieren der Deflate-Kompromitierung [sic] weg.

Jetzt fehlt nur noch, die Konfig auf allen VHosts einzuspielen, aber nachdem einmal die Konfig an sich steht, ist das gerade mal noch die Fingerübung.