HSTS preload fuer BFH.science aktiv

[Daniel Baumann]

Hallo zusammen


Kurzfassung
===========

  * Wir haben Ende April HSTS preload fuer bfh.science und *alle*
    Subdomains (d.h. *.bfh.science) beantragt.

  * Mittlerweile haben alle Browser-Projekte/Hersteller in ihren
    aktuellen Versionen unseren Eintrag uebernommen, resp. wurden
    in der Zwischenzeit neue Browser-Releases veroeffentlicht welche
    unseren Eintrag enthalten.

  * Somit koennen (ohne manuelles Uebersteuern) keine unverschluesselten
    Web-Zugriffe auf alle Science DMZ (*.bfh.science) Systeme/Dienste
    mehr gemacht werden.

  * Wird explizit kein Protokoll in der Adresszeile des
    Browsers angegeben, wird vom Browser selbststaendig und automatisch
    https:// direkt gewaehlt, bevor der Webserver kontaktiert wird.

    (bei http:// machen unser Webserver natuerlich jeweils einen
    Redirect auf https://, so dass gar nie Inhalte ueber HTTP
    ausgeliefert werden.)

  * Damit leisten wir einen weiteren Beitrag fuer ein sichers, schnelles
    und modernes Web/Webdienste.


Hintergrund
===========

Im Folgenden fuer wen es interessiert (zur Vereinfachung mit Auslassung
von ein paar Implementierungs-Details fuer alle nicht-Informatiker unter
uns).. das Zusammenspiel zwischen HTTP und HTTPS in Bezug auf Browser.


1. HTTPS fuer sicheren Zugriff auf Webseiten
--------------------------------------------

Im Internet werden Webseiten ueber das HTTP Protokoll uebertragen. Dies
existiert in einer unterschluesselten (HTTP) und verschluesselten
(HTTPS) Variante:

  https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol
  https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol_Secure

Sollen sensitive Informationen (z.B. Passwoerter, Personendaten, etc.)
an oder von einer Webseite uebertragen werden, muss HTTPS verwendet
werden - sonst koennen Dritte mitlesen.

Ob eine Webseite via HTTPS benutzt wird, sieht man im Browser einerseits
an der URL (z.B. https://bfh.science statt http://bfh.science),
andererseits wird in der Adresszeile ein gruenes Schloss oder Balken
angezeigt.


2. HTTPS ist immer besser als HTTP
----------------------------------

Webseiten via HTTPS zu besuchen hat neben der bei sensitiven Daten
zwingend notwendigen Verschluesselung noch weitere Vorteile:

  * Privatsphaere: Da die gesamte Verbindung zwischen Browser und
    Webserver verschluesselt ist, koennen Dritte auch bei weniger
    sensitiven Inhalten diese z.B. fuer Marketingzwecken (oder
    Massenueberwachung) nicht oder kaum mehr auswerten (ja - Facebook-
    like Buttons und Cross-Site Tracking hebelt das wieder aus, ist
    aber auf ein "Content"-Problem im oberen Teil des Stacks/Layers).

  * Performance: Trotz Verschluesselung ist HTTPS auf Rechnern der
    letzten 10 Jahre wesentlich schneller als HTTP ohne Verschluesselung
    da bei HTTPS modernere Faehigkeiten bei den Browsern vorausgesetzt
    und genutzt werden koennen (Stichwort HTTP Pipelining und parallele
    Requests).

    -> vergl. z.B. http://www.httpvshttps.com

       HTTPS ist in obigem Beispiel in der Regel zwischen 4 und 8 mal
       schneller, je nach Browser/Betriebssystem/Einstellungen.

  * geringere Fehleranfaelligkeit: Da die Verbindungen End-to-End
    verschluesselt sind, koennen Dritte dazwischen die Verbindung nicht
    mehr untersuchen/manipulieren. Damit koennen Proxies und Firewalls
    bei Unternehmen oder Providern nicht mehr den Inhalt von Webseiten
    veraendern ("verbessern"), cachen oder (mind. weniger) die
    Verbindung stoeren.. was leider durchaus haeufig vorkommt.


3. HTTPS fuer alle
------------------

Browser und Internet-Unternehmen haben ab ca. 2012 angefangen, HTTPS
immer mehr zu bevorzugen/erzwingen (z.B. werden Eintraege von Seiten mit
https bei Suchmaschinen-Resultaten mit http bevorzugt resp. weiter oben
gelistet).

Leider war ein grosser Hinderungsgrund fuer eine grossflaechige HTTPS
Verbreitung, dass der auf dem Webserver verwendete kryptographische
Schluessel mit einem vorher im Browser schon importierten Schluessel
einer "Certificate Authority" signiert werden musste, ansonsten wurde
eine grosse Sicherheits-Warnung angezeigt.

Eine solche Signatur (umgangsprachlich meist "SSL Zertifikat" genannt)
musste man zu einem recht hohen Preis von einem der wenigen Unternehmen
kaufen, welche ihre Schluessel in den Browsern (gegen sehr hohe
Gebuehren) importieren liessen. Durch diese "Zertifikats-Mafia" wurden
nur wenige Webseiten (in der Regel nur von Unternehmen/Institutionen)
via HTTPS verfuegbar gemacht.

Ab Fruehling 2016 konnte durch das Letsencrypt Projekt kostenlose
Zertifikate automatisch bezogen werden. Dies hat HTTPS fuer die Massen
gebracht:

https://www.heise.de/security/meldung/Let-s-Encrypt-stellt-jetzt-mehr-als-die-Haelfte-aller-SSL-Zertifikate-aus-4029922.html


4. HTTP abschalten geht nicht
-----------------------------

In einer idealen Welt wuerden wir alle nur noch HTTPS verwenden.

Auf den ersten Blick mag es verlocken erscheinen, als
Browser-Projekt/Hersteller einfach http aufrufe durch https zu
ersetzen.. und falls dann auf https nichts antwortet, koennte man ja
immer noch einen Fallback auf http machen.

Leider geht das nicht.. HTTP (Port 80) und HTTPS (Port 443) sind
unterschiedliche Protokolle, d.h. es steht einem Sysadmin frei via HTTP
etwas komplett anderes als via HTTPS anzubieten - d.h.
http://bfh.science koennte eine ganz andere Webseite oder Dienst als
https://bfh.science sein. So war es eine Zeit lang nicht unueblich, dass
z.B. unter HTTPS der Login zum Backend zum Bearbeiten einer Seite war,
die tatsaechliche Seite aber "nur" ueber HTTP erreichbar war.

Die Browser koennen also den Nutzenden die "Entscheidung", welche der
beiden (moeglicherweise unterschiedlichen) Seiten sie besuchen wollen,
nicht abnehmen und den Sysadmins es nicht vorschreiben was sie wie
anbieten/betreiben sollen.

Ein paar, auch schon nur sanfte, Versuche in diese Richtung sind
klaeglich an der allgemeinen Traegheit der Webseiten-Betreibern und der
"Hilflosigkeit" der einfachen Nutzenden gescheitert, mit den
auftretenden Fehlern umgehen zu koennen (was meiner Meinung nach so auch
voellig richtig ist - die Nutzenden muessen das nicht wissen und sollen
sich darum auch nicht kuemmern muessen).


5. Problem des ersten Requests
------------------------------

In der Adresszeile tippen die Nutzenden in der Regel so wenig wie
moeglich, d.h. obwohl korrekterweise immer das Protokoll mit angegeben
werden muesste, schreiben die Leute "google.com" und nicht
"https://google.com" wenn sie diese Suchmaschine besuchen wollen.

Wenn der Sysadmin seine Webseite mit HTTPS ausliefern will, landen daher
trotzdem die ersten Verbindungsanfragen immer via HTTP beim Webserver.
Deshalb ist es ueblich, dass wenn man HTTPS einsetzt, ueber HTTP keine
Inhalte ausliefert sondern nur einen Rewrite auf HTTPS macht.

Soweit so gut.. koennte man meinen.

Neben dem unnoetigen HTTP->HTTPS Rewrite (welcher dazu noch langsam ist,
weil der Browser fuer den Protokoll-Wechsel auf HTTPS eine neue Session
aufbauen muss), kann es je nach Webseite sein dass dadurch schon einiges
an Informationen ungeschuetzt uebertragen werden. Deshalb ist es
zwingend, dass auch wenn der Nutzer das Protokoll nicht explizit angibt,
direkt auf HTTPS gesetzt werden kann.


6. HSTS to the rescue? think again!
-----------------------------------

Durch eine HTTP Header Einstellung beim Webserver kann mitgesendet
werden, dass alle folgenden Verbindungsanfragen immer ueber HTTPS
gemacht werden sollen, siehe:

  https://de.wikipedia.org/wiki/HTTP_Strict_Transport_Security

D.h. konkret:

  1. Nutzer besucht http://example.net

  2. der example.net Webserver macht einen Rewrite auf
     https://example.net

  3. der Browser des Nutzers wechselt auf https://example.net

  4. der Webserver liefert die Webseite ueber HTTPS aus,
     und schickt den HSTS (HTTP-Strict-Transport-Security)
     Header mit.

  5. Browser sieht den HSTS Header und merkt sich diesen.

     Dadurch werden, innerhalb einer vom Webserver-Betreiben
     festlegbaren Zeit (in der Regel 6 bis 12 Monate) alle
     Verbindungen auf http://example.net vom *Browser*
     (und nicht vom Webserver) *direkt* selbststaendig
     auf https://example.net umgeschrieben.

     D.h. ab dem Zeitpunkt, wo der Browser das erste mal den
     HSTS Header sieht, werden vom Browser keine weiteren
     HTTP Anfragen fuer example.net mehr an den Webserver
     geschickt.

Dies hat den Vorteil, dass der Webseiten-Betreiber nun sicherstellen
kann, dass alle Verbindungen ab dem 2. Request ausschliesslich ueber
HTTPS erfolgen.

Fuer den 1. Request hilft dies aber leider noch immer nichts, der
erfolgt nach wie vor initial per HTTP.


7. HSTS preload to the rescue!
------------------------------

Um auch den ersten Request schon direkt auf HTTPS zu erhalten, hat
Google eine oeffentliche Whitelist eingefuehrt, welche von allen
gaengigen Browsern gemeinsam benutzt wird.

Dabei wird jeder Request auf eine Domain zuerst gegen die Whitelist
geprueft - ist die Domain enthalten, wird immer HTTPS benutzt.

Damit ist der 1. Request abgedeckt.. und Freude herrscht :)

Wers bis soweit geschafft hat, weis dass jetzt sicher noch ein "aber"
folgen muss:

  * Bedingung fuer die Aufnahme in die Whitelist ist, dass die gesamte
    Domain inkl. Subdomains gewhitelistet werden kann (sonst wuerde die
    Whiteliste aus zig Millionen von einzelnen Eintraegen bestehen die
    dann immer alle geprueft werden muessten).

  * Ist eine Domain erstmal in der Whitelist, werden Dienste die nur
    per HTTP erreichbar sind, nicht mehr aufrufbar im Browser.

    Gibt es Probleme mit HTTPS (z.B. OCSP Server faellt aus, Zertifkat
    laeuft ab oder es werden generelle Fehler bei der kryptographischen
    Einstellungen gemacht), ist ein ensprechender Dienst nicht mehr
    nutzbar.

    D.h. die extra Sicherheit wird durch erhoehte Anforderungen an die
    Webserver was Konfiguration, Betrieb und Zuverlaessigkeit erkauft.
    Kann dies nicht gewaehrleistet werden, drohen massive
    Komplikationen/Ausfaelle/Unbenutzbarkeit.

  * Aufgrund der erhoehten Anforderungen werden Eintraege in die
    Whitelist nicht sofort uebernommen, sondern erst nach einer Frist
    von 6 bis 8 Wochen, bei welchem Google die Seite immer wieder auf
    Richtigkeit der HTTPS Einstellungen ueberprueft.

    Erst dann wird der Eintrag freigegeben und in den naechsten
    Versionen der gaengigen Browsern uebernommen.

  * Die gaengigen Browser enthalten jeweils beim Release des Browsers
    aktuelle Kopie der Whitelist, welche dann periodisch automatisch
    aktualisiert wird.

    D.h. Domains die einmal auf der Whitelist eingetragen wurden,
    koennen nicht mehr so einfach wieder von der Liste entfernt werden,
    weil je nach Browser/Browser-Version/Browser-Einstellungen die
    lokale "alte" Kopie weiterverwendet wird.


8. Zusammenfassung
------------------

HSTS preload loest das Problem des 1. Requests, ist aber nur fuer
Umgebungen geeignet, welche professionell genug sind die moeglichen
Fehlersituationen auszuschliessen.

Wir machen HSTS seit 2014 auf allen Linux Servern mit einem Webserver
und schauen auf rund 5 erfolgreiche und fehlerlose Jahre sicheren,
progressiven HTTPS-Betriebs an der BFH mit ueber 100 Webservern zurueck.

HSTS preload (zusammen mit einigen weiteren Merkmalen unseres
State-of-the-Art HTTPS Deployments) ist fuer moderne IT-Infrastrukturen aus
Sicherheitsgruenden ein Muss und wir freuen uns, dass wir diesen
Meilenstein nun fuer die Science DMZ umsetzen konnten.

Gruesse,
Daniel

-- 
Berner Fachhochschule / Bern University of Applied Sciences
Services / IT-Services
Daniel Baumann
Teamleiter Linux Services
___________________________________________________________
Dammweg 3, CH-3013 Bern
Telefon direkt +41 31 848 48 22
Telefon Servicedesk +41 31 848 48 48
daniel.baumann at bfh.ch
https://bfh.ch
https://bfh.science