HSTS – Was es ist, wie es funktioniert und wie man es in Apache einrichtet

HSTS steht für HTTP Strict Transport Security und ist ein HTTP-Header bei dem der Webserver dem anfragenden Browser mitteilt, das alle Verbindungen nur ueber SSL/TLS aufgebaut werden sollen.
HSTS soll „Man-in-the-middle“ Attacken abwehren oder erschweren. Das Angriffsszenario besteht darin, dass Nutzer in der Regel nie

https

in den Webbrowser eingeben, sondern immer nur

example.net

Die Weiterleitung von http:// zu https:// macht der Webserver. Das sieht dann zum Beispiel so aus:
ohne_hsts

Man kann sehen, dass die erste GET Anfrage mit einem HTTP 302 Weitergeleitet wird und die zweite dann ein 200 OK zurueck liefert. Der Webserver ist in diesem Fall so konfiguriert, das alles was per HTTP reinkommt, automatisch auf HTTPS umgeleitet wird:

<VirtualHost *:80>
        ServerAdmin webmaster@jan-von.de
        ServerName mail.jan-von.de
        DocumentRoot /var/www/empty
 
        RewriteEngine on
        RewriteCond %{HTTP:X-Forwarded-Proto} !https
        RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
 
        CustomLog /var/log/apache2/mail.jan-von.de-access.log combined
</VirtualHost>

Genau hier liegt auch das Problem. Man kann sich in einem fremden Netz befinden, zum Beispiel einem unbekannten oeffentichen WLAN, dort kann die HTTP Anfrage abgefangen und der HTTPS Aufruf auf einen alternativen Server weitergeleitet werden.

Hier kommt HSTS ins Spiel. Der Server teilt dem Webbrowser mit, dass er sich bitte fuer eine bestimmte Zeit (zum Beispiel ein Jahr) daran erinnern soll, das diese Webseite nur noch ueber HTTPS aufgerufen werden soll.

In Apache muss dafuer das Headers-Modul aktiviert sein:

a2enmod headers

und anschliessend fuegt man in den HTTPS vhost die folgende Zeile ein:

Header always set Strict-Transport-Security "max-age=31556926"

Der Parameter max-age wird in Sekunden gesetzt. 31556926 Sekunden sind 365 Tage. Ein weiterer Parameter den man optional noch mit Komma Semikolon separiert dahinter haengen kann ist includeSubDomains. Dafuer muss aber sichergestellt sein, dass auch alle Subdomains per HTTPS erreichbar sind.
Weiter muss man aufpassen, dass die entsprechenden vhosts auch die angegebene Zeit, also zum Beispiel ein Jahr lang per HTTPS erreichbar sind, ansonsten kann es zu Fehlermeldungen kommen.

Wenn man dann HSTS aktiviert hat und eine Webseite aufruft die es unterstuetzt, dann kann man schoen sehen, wie der Browser gleich HTTPS nimmt und gar nicht erst HTTP probiert.

mit_hsts

Weiteres zu dem Thema z.B. unter:

HowTo: Disable weak RC4 cipher in Firefox, Chromium, Google-Chrome & Internet Explorer

In Firefox kann man das visuell in der Konfiguration machen. Dafuer in der Adresszeile about:config eingeben, bestaetigen, nach rc4 suchen und alle Werte deaktivieren:

Bildschirmfoto vom 2013-11-13 06:34:46

In Chromium und Google-Chrome ist das schon umstaendlicher. Da muessen die zu deaktivierenden Ciphers als Blacklist-Parameter beim Starten uebergeben werden:

chromium-browser --cipher-suite-blacklist=0x0001,0x0002,0x0004,0x0005,0x0017,0x0018,0xc002,0xc007,0xc00c,0xc011,0xc016,0xff80,0xff81,0xff82,0xff83

Die Verfuegbaren Hexcodes gibt es leider nur im Quelltext.

Um RC4 Verbindungen aus Windows heraus, und dadurch auch beim Internet Explorer zu unterbinden muessen die folgenden Registry Werte gesetzt sein:

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 128/128]
    "Enabled"=dword:00000000
 [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 40/128]
    "Enabled"=dword:00000000
 [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 56/128]
    "Enabled"=dword:00000000

Weitere Informationen dazu unter „Security Advisory 2868725: Recommendation to disable RC4

Die vom Browser unterstuetzten Cipher Suites werden einem angezeigt, wenn man die folgende Webseite aufruft:

Mehr Sicherheit fuer die eigenen Daten – Komfort mit Firefox Sync + Masterpasswort

Dieses ist der vierte Teil einer Serie von Blogeintraegen, die sich als Reaktion auf die NSA Affaere um den Kontext Sicherheit fuer die eigenen Daten und Verschluesselung drehen.

Links zu den ersten drei Artikeln befinden sich am Ende des Blogposts. Im diesem vierten Teil moechte ich auf das Thema Komfort im Webbrowser eingehen und dabei auf meinen frueheren Artikel zum selbst gehosteten Firefox Sync verweisen.

Es gibt eine ganze Menge an Webbrowsern dort draussen, das sind zum Beispiel Google Chrome, Apple Safari, Microsoft Internet Explorer oder halt auch Mozilla Firefox. Ich bevorzuge den letzten weil er erstens OpenSource ist, zweitens gut unter Linux laeuft und drittens mich nicht versucht in irgendwelche Services zu zwingen. Ich nehme dabei bewusst in Kauf, dass die Performance der JavaScript Engine nicht so gut ist, wie zum Beispiel verglichen mit der von Google Chrome. Auf Annehmlichkeiten wie synchronisierte Lesezeichen oder Chronik moechte ich aber dennoch nicht verzichten. Ich persoenlich synchronisiere damit Daten zwischen drei Geraeten, davon ein Mobiltelefon.

Aus diesem Grund habe ich bereits vor laengerer Zeit mir einen selbst gehosteten Firefox Sync Server installiert. Dort ist alles in meiner Hand, auf meinen Servern, ich kann verschluesseln, und meine Passwoerter schwirren wenn ueberhaupt dann gesichert durchs Netz.

Im Prinzip ist bei mir alles noch genauso, wie ich es in der Anleitung damals beschrieben habe. Der einzige Unterschied ist der Apache vHost, der nun ueber SSL geht:

<VirtualHost *:443>
        ServerName ffsync.example.org
        ServerAdmin webmaster@example.org
        DocumentRoot /opt/ffsync/server-full
 
        SSLEngine on
        SSLCertificateFile /path/to/ffsync.example.org.crt
        SSLCertificateKeyFile /path/to/example.org.key
 
                Order deny,allow
                Allow from all
 
        WSGIProcessGroup ffsync
        WSGIDaemonProcess ffsync user=ffsync group=ffsync processes=2 threads=25
        WSGIPassAuthorization On
        WSGIScriptAlias / /opt/ffsync/server-full/sync.wsgi
 
        CustomLog /var/log/apache2/ffsync_access.log combined
        ErrorLog /var/log/apache2/ffsync_error.log
</VirtualHost>

Weiter habe ich in der etc/sync.conf die URL des fallback node auf https:// abgeaendert.

Ganz wichtig dabei ist natuerlich: WENN Passwoerter im Webbrowser abgespeichert werden, DANN MUSS ein Masterpasswort gesetzt sein. Das gilt fuer Mozilla Firefox genauso wie fuer Mozilla Thunderbird. Wenn KEIN Masterpasswort gesetzt ist, kann JEDER der Zugriff auf den laufenden Webbrowser oder das laufende Thunderbird hat mit fuenf Klicks ALLE gespeicherten Passwoerter einsehen. Diese fuenf Klicks sind:

  1. Firefox
  2. Einstellungen
  3. Sicherheit
  4. Gespeicherte Passwoerter
  5. Passwoerter anzeigen

An der gleichen Stelle kann man uebrigens auch das Masterpasswort setzen. In Thunderbird ist es auch Einstellungen -> Sicherheit -> Passwoerter…

Vorherige Blogposts:

  • Der erste Teil war fuer mich das Aufraeumen, einen Ueberblick zu bekommen sowie Strukturen zu schaffen, auf denen ich aufbauen kann.
  • Der zweite Teil bestand darin einen Ort zu schaffen, in dem ich Keys und Passwoerter sicher aufbewahren und gleichzeitig alles in ein vernuenftiges Backup schieben kann.
  • Der dritte Teil bezog sich auf das erzeugen von Zertifikaten und Einrichten von verschluesselten Verbindungen zu Apache vHosts.