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

08.07.2013

Fighting the BEAST

Filed under: Server — Schlagwörter: , , , , , , , , , — BenBE @ 07:37:33

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.

Flattr this!

2 Comments »

  1. Ich denke wieso ein reine RSA-Keyexchange einem RSA-DH-Keyexchange vorgezogen wird ist recht einfach zu beantworten. Da du die Priorities der Keyexchange-Protokolle nicht änderst gilt der Default aus SECURE256. Leider lautet (wie in allen anderen SECURE*-Defaults):

    static const int kx_priority_secure[] = {
      /* The ciphersuites that offer forward secrecy take
       * precedence
       */
    #ifdef ENABLE_ECDHE
      GNUTLS_KX_ECDHE_ECDSA,
      GNUTLS_KX_ECDHE_RSA,
    #endif
      GNUTLS_KX_RSA,
      /* KX-RSA is now ahead of DHE-RSA and DHE-DSS due to the compatibility
       * issues the DHE ciphersuites have. That is, one cannot enforce a specific
       * security level without dropping the connection. 
       */
    #ifdef ENABLE_DHE
      GNUTLS_KX_DHE_RSA,
      GNUTLS_KX_DHE_DSS,
    #endif
      /* GNUTLS_KX_ANON_DH: Man-in-the-middle prone, don't add!
       */
      0
    };

    Wie man an dem Kommentar sieht wurde reines RSA also bewusst vorgezogen. Die Änderung erfolgte am 10. Feburar 2013 durch den Maintainer Nikos Mavrogiannopoulous. (https://gitorious.org/gnutls/gnutls/commit/eff2ae1606c7fea45dd1178de60b5cbf5c1012f9)

    Mehr Infos dazu habe ich gerade auch nicht.

    Kommentar von Matthias Wimmer — 14.07.2013 @ 13:34:05

  2. Nachtrag: Ich vermute, die geänderte Priorität geht auf dies hier zurück:
    http://lists.gnutls.org/pipermail/gnutls-devel/2013-February/006128.html

    Entsprechend wäre das etwas, das man auf einem Server problemlos anders sortieren kann, da die DH-Primzahl hier ja vom Server selbst vorgegeben wird.

    Kommentar von Matthias Wimmer — 14.07.2013 @ 13:46:22

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by WordPress