SSL Cipher

    Sehr geehrtes Team,


    gerade ist mir etwas sehr kritisches aufgefallen.
    Ich habe ca. 10 Domains die über SSL auf meinem Server laufen.


    Hier musste ich feststellen, dass RC4 aktiviert ist.
    Es muss hier die Möglichkeit geben, dies zu deaktivieren, denn was bringt mir ein SSL Zertifikat, wenn man die Handshakes in Echtzeit decrypen kann?


    Stichwort:
    ALL:!ADH:!SSLv2:!EXPORT56:!EXPORT40:!RC4:!DES:+HIGH:+MEDIUM:+EXP


    Herzlichse Grüße


    Linde

    Sehr geehrter Herr Linde,


    welcher Algorithmus letztendlich zwischen Browser und Server verwendet wird, hängt davon ab, auf welchen "kleinsten gemeinsamen Nenner" sich Server und Client einigen können. Standardmäßig versuchen beide Seiten selbstverständlich die bestmögliche Verschlüsselung zu verwenden (und da zählt RC4 sicher nicht dazu). Nur bei Endgeräten, die sonst nichts Anderes (z.B. AES) unterstützen, findet ein Fallback auf RC4 statt.


    Wenn Sie alle Blockchiffren (DES, AES etc.) gemäß PCI ausschließen und gleichzeitig RC4 verbieten, bleiben bei SSLv3/TLS1.0 übrigens keine anderen Verschlüsselungsalgorithmen mehr übrig. ;)
    Erst ab TLS 1.2 stehen mit Elliptic Curves ausreichend starke Alternativen zur Verfügung; diese sind z.B. erst mit OpenSSL 1.0 (also ab Debian 7.0) verwendbar.


    Kurzum: lassen Sie sich durch die Medien nicht scheu machen. Es handelt sich hier definitiv nicht um ein "kritisches Problem", da ja nicht nur RC4 erlaubt ist.


    Mit freundlichen Grüßen


    -Klaus Keppler

    Hallo Herr Keppler,


    vielen Dank für Ihre schnelle Rückmeldung.
    Ich lasse mich nicht durch Medien verrückt machen, dennoch sehe ich das so, dass wenn eine Verschlüsselung in Echtzeit decrypted werden kann, dann bringt mir mein SSL Zertifikat nicht viel. (Mir ist bewusst, dass es beim Handshake zur "Entscheidung" der Verschlüsselungsmethode kommt und die naheliegenste gewählt wird. Selbst wenn nur ein Kunde von 1000 Kunden RC4 erwischt, habe ich "verloren")


    An dieser Stelle kommt dann die Frage auf:
    Wie soll ich mit "Übertragungssicherheit" und Sicherheit bezüglich der Kundendaten, die im Webinterface hinterlegt sind werben, wenn ich bestimme Chiffren nicht deaktivieren kann, die nachweislich nicht zur sicheren Nutzung ausgelegt sind?


    Daher auch der Einwand, dass solche Einstellungen Global und Webconfig basiert vornehmbar sein sollten.
    Ich gehe nicht davon aus, dass dies im Bereich des unmöglichen liegt und nur einiger kleiner Änderungen bedarf.


    Mit freundlichen Grüßen


    Nico Linde

    Dass RC4 in Echtzeit decodiert werden kann ist derzeit reine Spekulation (wobei dies durchaus im Bereich des Möglich liegt). Wer so etwas machen möchte, benötigt aber einen erheblichen Aufwand - mehr als beispielsweise bei einem BEAST-Angriff.


    Daher noch mal: wenn Sie alle (theoretisch) knackbaren Algorithmen deaktivieren (DES, 3DES, AES, RC4), dann bleibt für die meisten Besucher gar kein Verschlüsselungsalgoithmus mehr übrig.


    Wenn Sie die Chiffres dennoch manuell einschränken möchten, modifizieren Sie einfach die entsprechenden Vorgaben in /usr/lib/liveconfig/lua/apache.lua.


    Die von uns voreingestellten Werte bieten den besten Kompromiss aus Sicherheit und Kompatibilität. Gerade bei Online-Shops geht es mehr darum, nicht versehentlich 5 von 1000 Kunden aufgrund inkompatibler Chiffres zu verlieren als theoretisch von der NSA abgeschnüffelt zu werden.

    Zitat von kk

    Die von uns voreingestellten Werte bieten den besten Kompromiss aus Sicherheit und Kompatibilität. Gerade bei Online-Shops geht es mehr darum, nicht versehentlich 5 von 1000 Kunden aufgrund inkompatibler Chiffres zu verlieren als theoretisch von der NSA abgeschnüffelt zu werden.


    laut meinen Test mittels ssllabs.com und dem Firefox-Plugin Calomel unterstützt die aktuelle Konfiguration aber weder im kompatiblen noch im PCI-konformen Modus Perfect Forward Secrecy aka PFS durch Key Exchange mit DH oder ECDH - Betriebssystem Debian 7, Apache 2.2.22


    Ist geplant das in naher Zukunft anzupassen oder muss man selbst tätig werden?


    Beispielhaft ist meines Erachtens die SSLCipher-Konfiguration auf facebook.com und mail.google.com - um nur zwei große Beispiele zu nennen.


    Nachtrag:
    LiveConfig selbst nutzt ECDHE - wenn auch nicht mit TLS 1.2 / AES GCM - aber immerhin besser als das, was für Apache konfiguriert wird.

    Zitat von aziegler

    laut meinen Test mittels ssllabs.com und dem Firefox-Plugin Calomel unterstützt die aktuelle Konfiguration aber weder im kompatiblen noch im PCI-konformen Modus Perfect Forward Secrecy aka PFS durch Key Exchange mit DH oder ECDH - Betriebssystem Debian 7, Apache 2.2.22


    Welchen Cipher genau vermissen Sie?
    Der Befehl "openssl ciphers <Liste>" liefert eine vollständige Liste aller unterstützten Algorithmen; die Cipher-List die LiveConfig hierbei im Apache konfiguriert steht in /etc/apache2/sites-available/default".
    In der aktuellen Einstellung (!aNULL:!eNULL:!EXPORT:!ADH:!DES:!DSS:!LOW:!SSLv2:RC4-SHA:RC4-MD5:ALL) erhalte ich auch einen ganzen Schwung PFS-fähiger DH-Algorithmen.
    Ich tippe also mal darauf, dass in diesem Fall einfach keine DH-Parameter generiert wurden bzw. konfiguriert sind - das werden wir uns gleich noch mal genauer anschauen. (#131)


    Zitat

    Ist geplant das in naher Zukunft anzupassen oder muss man selbst tätig werden?


    Die o.g. Cipher-Liste ist "future-proof", da nur die unsicheren Ciphers deaktiviert werden. Der Rest ist Sache von OpenSSL und dem Client-Handshake.


    Zitat

    Beispielhaft ist meines Erachtens die SSLCipher-Konfiguration auf facebook.com und mail.google.com - um nur zwei große Beispiele zu nennen.


    Die verwenden leider kein LiveConfig zur Serverkonfiguration. ;)
    Ich kenne mich zufällig etwas mit der SSL-Konfiguration hinter den Google-Services aus - das ist alles andere als trivial (die machen u.a. SNI mit Fallback auf Multi-Domain-Zertifikate...).


    Zitat

    Nachtrag:
    LiveConfig selbst nutzt ECDHE - wenn auch nicht mit TLS 1.2 / AES GCM - aber immerhin besser als das, was für Apache konfiguriert wird.


    LC verwendet OpenSSL 1.0.1 und unterstützt somit auch TLS 1.2. In unserer internen Cipher-Konfiguration räumen wir ECDHE eine höhere Priorität ein als AES-GCM, Letzter wird aber auch unterstützt (mit ssllabs getestet).

    Zitat von kk


    Ich tippe also mal darauf, dass in diesem Fall einfach keine DH-Parameter generiert wurden bzw. konfiguriert sind - das werden wir uns gleich noch mal genauer anschauen. (#131)


    Daran wird es liegen, kann man das manuell anpassen oder würde LC das überschreiben?


    Zitat von kk

    Nachtrag: eine exzellente Beschreibung und aktuelle Cipher-Empfehlungen gibt's bei Mozilla:
    https://wiki.mozilla.org/Security/Server_Side_TLS


    Danke für diesen klasse Link! Die dortige Cipher-Liste funktionieren selbst unter Squeeze einwandfrei und bei modernem Client mit hoher "Sicherheit".

    Bei dem ganzen erneuern der Zertifikate ist mir aufgefallen das die Cipher Empfehlungen von Mozilla noch nicht in Liveconfig eingeflossen sind oder? Weil mir im Test gerade aufgefallen ist das "Forward Secrecy" fehlt. Und diverse Cipher werden ja auch schon unter Debian Wheezy unterstützt.


    Grüße
    Björn

    Ab v1.7.3-r2849 wird nun die empfohlene Liste von Mozilla's OpSec verwendet. Außerdem kann man künftig in einer custom.lua durch Ersetzen der Variable LC.liveconfig.DEFAULT_SSL_CIPHERS auch eine abweichende Cipher-Liste pflegen.
    Die v1.7.3-Preview dürfte in den nächsten 2-3 Tagen fertig sein.


    Viele Grüße


    -Klaus Keppler

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden