Krypto-Algorithmen spezifizieren

Während des Verbindungsaufbaus handeln Client und Server einen Verschlüsselungsalgorithmus aus, mit dem beide arbeiten können. Doch nicht alle innerhalb von TLS beziehungsweise SSL verwendbaren Algorithmen sind heute noch sicher. Insbesondere das symmetrische Verschlüsselungsverfahren RC4 gilt in Fachkreisen als schwach und es besteht die Vermutung, dass amerikanische Geheimdienste bereits in der Lage sind, RC4 in Echtzeit zu knacken. Auch SSLv2 ist nicht mehr sicher. Außerdem sollte Perfect Forward Secrecy bevorzugt verwendet werden.

Bei Transportverschlüsselungen handelt es sich in der Praxis meist um TLS (früher SSL). Ein TLS-Zertifikat bestätigt dem Nutzer eines Webservices, dass er tatsächlich mit dem Besitzer der aufgerufenen Domain kommuniziert. (Bild: Fotolia / kittite)

Folgende Liste entspricht der Empfehlung „Configuration B“ von BetterCrypto und kann dort kopiert werden.

<VirtualHost *:443>
    # ...

    SSLProtocol All -SSLv2 -SSLv3 
    SSLHonorCipherOrder On 
    SSLCompression off 
    SSLCipherSuite 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA​+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA'
</VirtualHost>

Diese Konfiguration wird mit älteren Clients wie dem IE unter Windows XP nicht mehr funktionieren. Ist dies erforderlich, findet sich bei BetterCrypto ein Workaround. Unter Node.js lassen sich die empfohlenen Algorithmen analog vorgeben:

var https = require('https'); 
var fs = require('fs'); 
var constants = require('constants');

var options = {
    key:  fs.readFileSync('/etc/ssl-example.com/example.com.key'),
    cert: fs.readFileSync('/etc/ssl-example.com/example.com-combined.crt'),
    honorCipherOrder: true,
    ciphers: 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+'
      + 'aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!'
      + 'eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256'
      + '-SHA:CAMELLIA128-SHA:AES128-SHA',
    secureOptions: constants.SSL_OP_NO_SSLv2 | constants.SSL_OP_NO_SSLv3
};

Perfect Forward Secrecy ist hier erst ab Version 0.11 möglich, wobei Node.js wegen Heartbleed keinesfalls unter Version 0.10.27 beziehungsweise 0.11.13 verwendet werden sollte.

Testen mit dem Tool SSLScan

Der Aufruf der Webanwendung lässt sich nun über https://www.example.com testen. Gegebenenfalls muss in der Firewall zusätzlich noch Port 443 freigeschaltet werden. Je nach CA kann es einige Stunden dauern, bis das Zertifikat über das Online Certificate Status Protocol (OCSP) validiert werden kann. Nicht wundern: Bis das der Fall ist, liefert etwa die Standardkonfiguration des Firefox einen Fehler.

Steht der TLS-Server, kann man mit dem Tool SSLScan alle gängigen Verfahren testen und die Liste mit dem Befehl „grep“ filtern, um herauszufinden, welche vom Server akzeptiert werden.

$ sslscan example.com:443 | grep "Accepted"

Detailliertere Informationen zur TLS-Verbindung liefert OpenSSL.

$ openssl s_client -crlf -connect example.com:443

Fazit: Mit Transportverschlüsselung die Web-App sicherer machen

Eine Transportverschlüsselung für die eigenen Web-Applikationen umzusetzen ist kein Hexenwerk und gestaltet sich wesentlich weniger aufwändig als die Implementation einer deutlich komplizierteren Ende-zu-Ende-Verschlüsselung. Das Mehr an Sicherheit macht sich in einem Vertrauensgewinn bei den Nutzern bemerkbar. Wer alle genannten Details beim Einrichten des TLS-Zertifikats für den eigenen Server beherzigt, macht es zudem auch Angreifern wie Geheimdiensten und Co deutlich schwerer, Nutzerdaten abzugreifen und auszuwerten.