Sichere SSL-Verbindung mit Apache oder Nginx, ohne Poodle

Teuflischer Pudel bei https://www.poodletest.com/ - Achtung: Diese Website prüft die Verletzlichkeit des Browsers, nicht des Servers!
Teuflischer Pudel bei https://www.poodletest.com/ – Achtung: Diese Website prüft die Verletzlichkeit des Browsers, nicht des Servers!

Mit SSL lässt sich die Internet-Kommunikation hoffentlich abhörsicher verschlüsseln. Wie man sich dafür selbst ein Zertifikat erzeugt – per Zertifizierungsstelle oder selbst signiert – stand im letzten Beitrag. Diesmal geht es darum, einen Webserver SSL-fähig zu machen und ihm sodann das Zertifikat samt Schlüssel zur Verfügung zu stellen, so dass eine sichere Kommunikation über HTTPS möglich ist. Dabei soll der Server auch gleich noch vor dem sogenannten POODLE-Angriff geschützt werden. All dies wird am Beispiel des weit verbreiteten Webserver-Schwergewichts Apache vorgeführt und dann auch noch einmal mit dem wendigen Russen Nginx durchgespielt.

Mit POODLE (Padding Oracle On Downgraded Legacy Encryption) ist kein tollwütiger Kläffer gemeint, sondern ein Angriff, bei dem böse Menschen in der Kommunikation zwischen Client und Server den Rückfall auf den veralteten, unsicheren SSL-Protokollstandard 3.0 (oder älter) erzwingen; auf diese Weise können sie dann die verschlüsselte Verbindung knacken. Damit ein solcher Fallback nicht passieren kann, sollte ein Webserver-Administrator SSL 3.0 ganz einfach deaktivieren. Der Preis dafür ist, dass alte Clients, etwa der Internet Explorer 6, der keine neueren SSL/TLS-Protokolle beherrscht, ausgesperrt werden. Andererseits: Wer immer noch den IE6 nutzt, ist selbst schuld.

Und damit zur Konfiguration eines POODLE-losen Virtual Hosts auf dem Apache-Server für die Subdomain secure.example.com:

<VirtualHost *:443>
        DocumentRoot /var/www/example
        ServerName secure.example.com
        DirectoryIndex index.shtml index.php index.html index.htm
        SSLEngine On
        SSLCertificateFile /etc/ssl/localcerts/example.com.crt
        SSLCertificateKeyFile /etc/ssl/localcerts/private.key
        SSLProtocol All -SSLv2 -SSLv3
</VirtualHost>

Gegenüber einem gewöhnlichen Virtual Host, der über Port 80 unverschlüsselte HTTP-Verbindungen bedient, lauscht dieser hier auf Port 443, dem Standard-Port für SSL. Mit SSLEngine on wird die Verschlüsselung eingeschaltet. Mit SSLCertificateFile und SSLCertificateKeyFile werden dem Server das Zertifikat und der private Schlüssel, mit dem es signiert wurde, bekannt gemacht. Und schließlich dringen wir noch zu Pudels Kern vor, der bekanntlich ein teuflischer ist: Mit der SSLProtocol-Direktive werden zunächst alle verfügbaren Protokolle erlaubt, sodann aber explizit SSL 3 und vorsichtshalber auch noch SSL 2 (obwohl es im aktuellen Apache-Entwicklungszweig 2.4 ohnehin nicht mehr unterstützt wird) verboten.

Um wirksam zu werden, muss die Konfiguration schließlich noch eingelesen werden. Unter Debian zum Beispiel mit:

$ /etc/init.d/apache2 reload

Für den Webserver Nginx würde die Beispiel-Konfiguration so aussehen:

server {
        listen 443 ssl
        root /usr/share/nginx/html/example;server_name secure.example.com;
        index index.shtml index.php index.html index.htm;
        ssl_certificate /etc/ssl/localcerts/example.com.crt
        ssl_certificate_key /etc/ssl/localcerts/private.key
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
}

Als Schutz vor dem POODLE-Angriff empfiehlt das Nginx-Blog, sämtliche Vorkommnisse von SSLv3 in den Konfigurationsdateien zu löschen. Schließlich wird die Nginx-Konfiguration neu eingelesen mit:

$ /etc/init.d/nginx reload

Egal ob der Webserver nun Apache oder Nginx heißt: Nutzt man diese Konfigurations-Beispiele als Skelett für die eigene Website, sollte eine SSL-Verbindung aufgebaut werden, sobald man mit dem Browser https://secure.example.com ansteuert. Ist das Zertifikat selbst signiert, wird der Browser natürlich beim ersten Mal meckern. Man sollte dann sicherheitshalber den Fingerprint des Zertifikats vergleichen und eine Ausnahme hinzufügen.

Schreibe einen Kommentar