Mit den Tipps und Workshops im ADMIN-Magazin 03/2013 sichern Administratoren ihre Webserver und Netze gegen Angriffe ab: gegen Abhören sensibler Informationen, ... (mehr)

Was bedeutet das für die Apache-Konfiguration?

Im Apache-Webserver können wir die unterstützten TLS-Modi über die Optionen SSLProtocol und SSLCipherSuite einstellen. Eine Konfiguration, die nur mit TLS 1.2 arbeitet und nur GCM-Algorithmen mit Perfect Forward Secrecy aktiviert, ist in Listing 1 dargestellt. Die problematische Kompression wird deaktiviert.

Listing 1

Konfigurationsbeispiel

 

Eine im praktischen Betrieb eher realistische Einstellung ist in Listing 2 zu sehen. Alle Algorithmen mittlerer und niedriger Stärke werden abgeschaltet, ebenso Algorithmen, die keine Authentifizierung anbieten. Außerdem wird auch hier die inzwischen recht alte SSL-Version 3 deaktiviert. TLS Version 1.0 wird schon seit langem von allen Browsern unterstützt, eine Aktivierung der alten SSL-Versionen sollte daher nicht mehr notwendig sein.

Listing 2

Praxisgerechte Einstellung

 

Einschränkend muss noch gesagt werden, dass die Algorithmen, die einen Schlüsselaustausch mit elliptischen Kurven durchführen (durch ECDHE abgekürzt), erst seit Apache in der Version 2.4 unterstützt werden. Die wird bislang aber nur von wenigen Distributionen ausgeliefert. Doch die angegebenen Optionen funktionieren trotzdem, die nicht unterstützten Algorithmen werden dann einfach ignoriert.

Wer das Diffie-Hellman-Verfahren mit 1024 Bit vermeiden will, kann entweder einen experimentellen Patch aus dem Apache-Bugtracker nutzen [5] oder das Verfahren DHE-RSA-AES256-GCM-SHA384 aus der Konfiguration streichen und nur den Schlüsselaustausch über elliptische Kurven anbieten.

Die Abschaltung der verwundbaren Kompression ist in älteren Apache-Versionen nicht möglich. Sie wurde erst für die 2.2er-Serie in Version 2.2.24 eingeführt.

Damit die GCM-Algorithmen von TLS 1.2 funktionieren, wird eine OpenSSL-Version größer als 1.0.1 benötigt. Diese ist inzwischen bei den meisten Linux-Distributionen vorhanden.

Anschließend kann man die Seitenkonfiguration mit dem SSL-Test der Firma Qualys überprüfen. Der gibt zahlreiche Hinweise, falls etwas mit der Konfiguration nicht stimmt und vergibt Punkte für die Sicherheit der Konfigurationseinstellungen [6]. Zu warnen ist allerdings vor den dort vergebenen Empfehlungen bezüglich der BEAST-Attacke. Denn der Online-Test empfiehlt zumindest zu Redaktionsschluss hierfür noch die Bevorzugung der RC4-Algorithmen.

Unterm Strich

TLS ist in die Jahre gekommen. Die Technik, die gegenwärtig in Browsern und Webservern zum Einsatz kommt, würde so heute niemand mehr entwickeln. Die Attacken der jüngsten Zeit werfen darauf ein Schlaglicht. In der Praxis muss man sich dennoch nicht allzu viele Sorgen machen. Die Angriffe sind kompliziert und nur im Zusammenspiel mit Umständen möglich, die nur selten eintreffen. Die Sicherheit von Webanwendungen ist nach wie vor meist durch weit banalere Probleme gefährdet. Cross-Site-Scripting-Lücken oder SQL-Injection-Angriffe zum Beispiel, die mit der Kryptografie nichts zu tun haben, sind die weit größere Bedrohung und können auch durch die beste Verschlüsselung nicht verhindert werden.

Trotzdem sollte man die Sache nicht auf die leichte Schulter nehmen. Dass das mit Abstand wichtigste Kryptografieprotokoll der heutigen Zeit so lückenhaft daherkommt, ist zweifellos nicht gut. Und verbesserte Angriffsmethoden sind sehr wahrscheinlich lediglich eine Frage der Zeit.

Die Lösung der meisten der hier angesprochenen Probleme liegt längst vor: In einem fünf Jahre alten Standard mit dem Namen TLS Version 1.2, den keiner benutzt. Die Probleme, die TLS zu schaffen machen, sind lange bekannt. Hier zeigt sich eine der Schwierigkeiten der Entwicklung von sicheren Netztechnologien: Solange es keine praktischen Angriffe gibt, sehen viele Programmierer und Systemadministratoren keinen Anlass, auf neuere Standards umzusatteln und ihre Systeme zu aktualisieren. Sie warten lieber ab, bis man ihnen mit Brief und Siegel einen Angriff vorführt und ihre Systeme auch praktisch verwundbar sind. Vernünftig ist das nicht – aber leider weit verbreitet.

Der Autor

Hanno Böck ist freier Journalist und ehrenamtlicher Entwickler bei Gentoo Linux. Nebenher arbeitet er beim Webhosting-Unternehmen schokokeks.org mit, welches für den Betrieb seiner Dienste ausschließlich auf freie Software setzt.

Ähnliche Artikel

comments powered by Disqus
Mehr zum Thema

SSL-3.0-Lücke "POODLE" - testen und beheben

Zwar erfordert das Ausnutzen der jüngsten Sicherheitslücke im SSL-Protokoll einigen Aufwand, man sollte aber dennoch  SSL 3.0 am besten abschalten.

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019