Die Zwickmühle beim Betreiben von verschlüsselten Netzdiensten aus Betreibersicht

Angesichts der Schwachstellen rund um bestimmte Verschlüsselungsarten (Poodle und Logjam waren die bekanntesten in letzter Zeit) hat man es als Betreiber schwer, die „optimale“ Konfiguration für Netzdienste zu finden, die verschlüsselte Kommunikation anbieten. Auf der einen Seite möchte man nach Möglichkeit Benutzer mit älteren Geräten, die noch nicht die neuesten Verfahren implementiert haben, nicht völlig von der Nutzung ausschließen, auf der anderen Seite gelten bestimmte Verfahren inzwischen als so unsicher, dass man diese als Serverbetreiber auf gar keinen Fall mehr anbieten möchte, um Nutzer nicht in trügerischer Sicherheit zu wägen.

Das gilt insbesondere dann, wenn als Szenario droht, dass ein Angreifer sich in die Verbindung zwischen Server und Client einklinken kann und dann dafür sorgt, dass die beiden eigentlichen Kommunikationspartner sich auf eine Primitiv-Verschlüsselung einlassen, weil der Angreifer vortäuscht, der jeweils andere Partner würde keine starke Verschlüsselung unterstützen („Downgrade-Attack“). In einem solchen Fall braucht der Angreifer dann nur noch die Primitiv-Verschlüsselung zu knacken anstelle der starken Verschlüsselung, die die beiden Kommpunikationspartner im Normalfall untereinander vereinbart hätten.

Webserver und andere Dienste

Weiter verkompliziert wird die Lage dadurch, dass Angriffsszenarien bei verschiedenen Netzdiensten unterschiedlich zu beurteilen sind. So sind Angriffe, die darauf beruhen, dass einer der Kommunikationspartner unfreiwillig dazu gebracht werden kann, häufig Datenpakete mit annähernd gleichem Inhalt zu senden, bei Webseiten bis zu einem gewissen Grad realistisch. Schafft es der Angreifer, das Opfer auf eine Webseite unter seiner Kontrolle zu locken, so sind automatisierte Datenabrufe durch eingebetteten Skriptcode denkbar, ohne dass es direkt auffällt. Bei anderen Diensten, beispielsweise E-Mail mit einem Mailclient, gibt es hingegen kein ernstzunehmendes Szenario, wie ein Angreifer von außerhalb den Computer des Opfers automatisiert dazu bringen kann, selbständig mit gewisser Regelmäßigkeit gleichartige Datenpakete zu verschicken. Das ist umso mehr eine Besonderheit des Webs gegenüber anderen Netzdiensten, weil das Angriffsziel „Session-Cookie“ auch nur im WWW-Bereich wirklich existiert.

Alte Software überall

Als wäre dieses Spannungsfeld nicht schon vertrackt genug, kann als weitere Schwierigkeitsstufe noch dazukommen, dass man nicht nur bei den fremden Kommunikationspartnern nicht die neuesten Verschlüsselungsverfahren voraussetzen kann, sondern dass man auch als Anbieter nicht all das nutzen kann, was theoretisch verfügbar ist. So steht am RRZK für den Betrieb von Webservern i.d.R. als Betriebsystem Red Hat Enterprise Linux 6 (RHEL6) zur Verfügung. Dieses bringt aber nicht die jeweils neuesten Programmversionen mit, sondern im Regelfall diejenigen Versionen, die bei Erscheinen des Betriebssystems aktuell waren, jedoch natürlich um in der Zwischenzeit bekanntgewordene Sicherheitslücken bereinigt.

Für RHEL6 bedeutet das ganz konkret, dass nur die Funktionen von openssl 1.0.1 zur Verfügung stehen (anstelle von openssl 1.0.2) sowie der Apache-Webserver aus der 2.2er Versionslinie (anstatt 2.4). Damit sind einige der Empfehlungen für Serverbereiter, wie Sie beispielsweise von den Entdeckern des Logjam-Problems gegeben werden, nicht umsetzbar. Das Definieren individueller sog. Diffie-Hellman-Parameter etwa ist erst mit den neuesten Versionen des Apache-Webservers (ab 2.4.8) möglich.

Empfehlung für Apache 2.2 unter RHEL6

Um nun unter RHEL6 einen Apache-Webserver zu betreiben, der Webseiten ausschließlich verschlüsselt (per https) ausliefert, und das unter den gegebenen Umständen mit einem als möglichst sicher geltenden Kompromiss, kann man folgende Einstellungen in der allgemeinen Apache-Konfiguration verwenden:

SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite HIGH:MEDIUM:!ADH:!MD5:!RC4
SSLHonorCipherOrder on

Das ist zunächst einmal wenig spektakulär und kaum anders als das, was von den Logjam-Entdeckern empfohlen wird. In der Praxis läuft es darauf hinaus, dass die hier vorgeschlagene Konfiguration keine Präferenz für AES-128-Verschlüsselung enthält, so dass von den meisten heutigen Clients eine AES-256-Verschlüsselung verwendet werden wird. Ob man in dem gegebenen Kontext (Abruf von Webseiten) nun AES-128 oder AES-256 den Vorzug geben sollte ist für mich nicht zu beurteilen und wird in der Praxis wohl auch kaum eine Rolle spielen. Die theoretische Angreifbarkeit von AES-256 gegenüber AES-128 (hier ein alter und bekannter Blogartikel von Bruce Schneider dazu) bezieht sich auf mögliche Related-Key-Angriffe und ist in dieser Frage von untergeordneter Bedeutung.

Lässt man die oben genannte Einstellung SSLHonorCipherOrder hingegen auf dem Standardwert off, statt sie wie empfohlen auf on zu setzen, so ändert sich in der Praxis bei den meisten Browsern wenig. Durch das Setzen von SSLHonorCipherOrder on sorgt man de facto nur dafür, dass Benutzer mancher Versionen des Internet Explorers unter Windows 7 zu ihrem Glück gezwungen werden und auch bei ihnen eine Verbindung mit Forward Secrecy aufgebaut wird. Auf die Belange von Nutzern, die auch heute noch die extrem veraltete und per se unsichere Kombination von Internet Explorer 6 und Windows XP einsetzen, wird hier keine Rücksicht mehr genommen. Diese früher nicht ganz kleine Gruppe an Webseitenbesuchern machte in der Vergangenheit viele faule Kompromisse notwendig.

Dem Browser den Weg zur Verschlüsselung weisen

Legt man Wert darauf, in dem beliebten SSL-Servertest von Qualys besonders gut abzuschneiden, ist SSLHonorCipherOrder on unbedingt notwendig. Jedoch reicht das Setzen dieser und der anderen allgemeinen Verschlüsselungseinstellungen nicht aus. Für ein gutes Testergebnis muss man auch dafür sorgen, dass Besucher ausschließlich verschlüsselt mit dem Server kommunizieren. Solange unverschlüsselte Kommunikation im Web der Normalfall ist, sind dazu noch ein paar weitere Anstrengungen in der Apache-Konfiguration notwendig.

Webseitenbesucher, die – aus welchem Grund auch immer – eine unverschlüsselte Verbindung zum Server aufbauen möchten, müssen also von diesem Vorhaben abgehalten werden. Verwendet man dazu virtuelle Hosts in der Apache-Konfiguration, so kann man die Besucher, die keine Verschlüsselung verwenden, per

<VirtualHost *:80>
  RedirectMatch permanent (.*) https://meinhostname.uni-koeln.de$1
</VirtualHost>

umlenken. Für Named Virtual Hosts wäre hier natürlich noch eine weitergehende Konfiguration nötig. Gezeigt werden soll anhand dieses Konfigurationsschnipsels eigentlich nur, dass man die Besucher am besten mit einer dauerhaften Umleitung (permanent) auf die verschlüsselte Version der Website lenkt.

https und nur https, in guten wie in schlechten Zeiten

Als Kür sendet man dann noch die Information an die Browser der Webseitenbesucher, es in Zukunft gar nicht erst über eine unverschlüsselte Verbindung zu probieren, sondern ausschließlich per https mit dem Server zu kommunizieren:

<VirtualHost *:443>
  # hier stehen normalerweise Einstellungen wie ServerName, DocumentRoot etc.
  
  # vvv Einschalten von HSTS aka HTTP Strict Transport Security, RFC 6797
  Header always set Strict-Transport-Security: max-age=31536000
  # ^^^ Strict Transport Security, funktioniert mit Apache 2.2.15
</VirtualHost>

In diesem Beispiel wird der abrufende Browser instruiert, dass die Information, mit diesem Server nur verschlüsselt zu kommunizieren, ca. ein Jahr lang (31536000 Sekunden) gültig ist. Dies kann man zum Glück auch schon mit dem bei RHEL6 mitgelieferten Webserver Apache 2.2.15 so einstellen.

Mit den auf diese Weise optimierten Einstellungen erhält der Webserver dann von dem erwähnten SSL-Test die Bestnote A+ attestiert, vorausgesetzt die übrigen Einstellungen (zum Zertifikat und der Kette der Zwischenzertifizierungsstellen etc.) sind ebenfalls in Ordnung. Diese Einstellungen sind aber nicht spezifisch für RHEL6, daher soll hier darauf nicht weiter eingegangen werden.