Die IETF hat Ende 2012 mit HTTP-Strict-Transport-Security (RFC 6797) einen neuen Internetstandard verabschiedet, der Useragents mitteilen soll, dass die Kommunikation mit einer Webseite nur über verschlüsselte und zertifizierte TLS-Verbindungen abgewickelt werden soll. Damit soll verhindert werden, dass der Benutzer beim ersten Verbindungsaufbau zur unverschlüsselten Version von einem Man-In-The-Middle attackiert werden kann, der die Weiterleitung zur verschlüsselten HTTPS-Version verhindert und somit die Verbindung manipulieren kann.
Der Benutzer tippt nämlich meistens nur den Hostnamen ohne Protokoll in die Adressleiste seines Browsers ein und ist somit über die erste unverschlüsselte Verbindung angreifbar. Wenn ein Webmaster den Useragents (also den Webbrowsern) mitteilen möchte, dass diese nur noch verschlüsselte und beglaubigte Verbindungen zur Webseite aufbauen sollen, dann setzt dieser im HTTP Response-Header der verschlüsselten Version den HSTS-Header mit einer Ablaufzeit, der dann vom Useragent des Besuchers zwischengespeichert wird.
strict-transport-security: max-age=15552000Wenn der Benutzer dann das nächste mal den Hostnamen ohne HTTPS-Protokoll in die Adressleiste seines Browser eingibt (oder einem Link auf einer Webseite folgt, der auf die unverschlüsselte Version zeigt) dann baut der Browser sofort eine verschlüsselte Verbindung zur Webseite auf, ohne erst via Plaintext-HTTP (als MITM manipulierbar) anzufragen und sich die Weiterleitung zur HTTPS-Version abzuholen (die ein aktiver Angreifer natürlich verhindern würde).
Wichtige Information zur Verwendung von HSTS
Beim Einsatz von HTTP-Strict-Transport-Security sollte man sich bewusst sein, dass man im schlimmsten Fall verhindert, dass Benutzer die Webseite erreichen können, wenn diese den HSTS-Header bereits in ihrem Browsercache haben und man als Webmaster (aus welchen Gründen auch immer) nicht mehr sicherstellen kann, dass die Webseite über ein (von einer vom Browser akzeptierten Zertifizierungsstelle beglaubigtes) Zertifikat verfügt. In so einem Fall können Benutzer solange nicht mehr auf die Seite zugreifen, bis die im HSTS-Header gesetzte Zeitspanne verstrichen ist.
Den Useragents ist es laut Spezifikation verboten, dem Benutzer eine Möglichkeit zu geben, die dann erscheinende Fehlermeldung zu ignorieren. Auch kann HSTS nicht verhindern, dass ein Man-In-The-Middle-Angriff auf die erste unverschlüsselte Verbindung erfolgreich ist, wenn die Webseite in der Vergangenheit kein einziges Mal über eine sichere Verbindung aufgerufen wurde, so dass der HSTS-Header gesetzt werden konnte.
Das alles ist aber kein Grund, um vor der Verwendung von Strict-Transport-Security zurückzuschrecken. Und um das Problem mit dem MITM-Angriff auf die erste unverschlüsselte Verbindung zu lösen, sollte man darüber nachdenken, sich auf die HSTS-Preload-Liste setzen zu lassen. Wenn schon, dann richtig! 😄
Den HSTS-Header im Apache setzen
Um den HSTS-Header in der Konfiguration eines Apache-VirtualHosts setzen zu können, wird das aktivierte Modul mod_headers benötigt. Danach kann man in Apache-Konfigurationen folgendermaßen den HSTS-Header setzen:
Header always set Strict-Transport-Security "max-age=15552000"