TLS auf n-design.de

Anderenorts auf dieser Webseite heißt es:

Kryptografie
Sicherheitstechnologien werden immer komplexer und anspruchsvoller, um hier mit den aktuellen Entwicklungen Schritt zu halten, beraten wir Sie gerne, welche Technologie für Ihr Vorhaben die richtige ist. Unsere Mitarbeiter sind mit neusten Technologien bestens vertraut und bilden sich stets durch Schulungen und Lehrgänge auf diesem Gebiet weiter.

Wir werben – zu recht – mit unseren Kenntnissen im Bereich Kryptographie. Mit einem Produkt, wie dem Konnektor, mit dem regelmäßig Patientendaten verarbeitet werden, ist ein bewusster und professioneller Umgang mit Verschlüsselung unerlässlich, um diese Daten zu schützen. Lange galt für die Verschlüsselung der Webseite das Motto Der Schuster hat die schlechtesten Schuhe. Das widerspricht dem Trend, dass immer mehr Webseiten auf https umgestellt wird und nicht zu letzt dem eigenen Anspruch. Doch was ist dafür zu tun?

Vorbereitung

Welche Ressourcen werden aus dem Web geladen?

Moderne Webseiten laden oft Ressourcen (Grafiken, Skripte, Stylesheets, Schriften etc.) aus sehr unterschiedlichen Quellen nach. Hier sollte man sicherstellen, dass diese alle über https geladen werden. Hilfreiche Tools, um herauszufinden, was da passiert sind z.B.

  • Webbkoll | Webbkoll ist ein Webdienst, der den Abruf einer Internetseite im Browser simuliert. Dabei wird aufgezeichnet, welche sonstigen Dienste durch den Aufruf der Seite kontaktiert werden, ob die Verbindungen verschlüsselt sind und ob bestimmte Header in der HTTP-Antwort gesetzt sind. Dies alles erhält man dann in einem übersichtlichen Bericht.
  • uMatrix | Dieses Browser-AddOn für Chrome, Firefox und Opera stellt unterschiedliche Ressourcentypen und die zugehörigen Quellen auf einer Webseite in Form einer Matrix dar. Hinzu kommt die Möglichkeit, diese gezielt zu blockieren. Dadurch kann sich das Aussehen und Verhalten der betrachteten Webseite verändern.

Kein www-Präfix mehr

Unter einer Domain werden möglicherweise unterschiedliche Dienste (FTP, HTTP, SMTP usw.) angeboten. Die Präfixe dienen dazu, diese zu unterscheiden. Das www-Präfix hat sich für HTTP-Dienste eingebürgert, inzwischen kann man auch behaupten, dass dies der vorrangig genutzte Diensttyp ist.
Meiner Meinung nach ist es viel prägnanter, den eigenen Firmennamen ohne www garniert zu präsentieren. Die www-Variante kann und sollte man natürlich immer noch als Alias mitführen und auf die eigentliche Adresse weiterleiten – um alte Gewohnheiten abzufangen. In einer Apache-Webserverkonfiguration sieht das so aus:

<VirtualHost *>
    # ...
    ServerName n-design.de
    ServerAlias www.n-design.de
    # ...
</VirtualHost>

Das sieht hübscher aus, aber ist es für die Sicherheit der Seite wichtig? Tatsächlich ist es relevant, wenn man sich mit HTTP Strict Transport Security (HSTS) und deren Ausgestaltung im Detail auseinander setzt. Dazu aber später mehr.

Wenn man eine solche Umstellung vornimmt, sollte man auch in seinem Content Management System die Default-Adresse der Webseite anpassen, damit interne Links korrigiert werden. Dies gilt auch dann, wenn man TLS aktiviert hat, die Adresse muss dann von http auf https umgestellt werden.

TLS aktivieren

TLS steht für Transport Layer Security und ist hat die Nachfolge von SSL (Secure Socket Layer) angetreten. Beide Begriffe werden oft synonym verwendet. Durch dieses Verfahren wird eine Transportverschlüsselung auf eine Internetverbindung angewendet, d.h. die Verbindung zwischen zwei Rechnern ist verschlüsselt. Die Daten liegen vor und nach der Übertragung unverschlüsselt auf vor, ohne dass eine gesonderte Benutzerinteraktion nötig ist.

Als Zertifizierungsstelle verwenden wir Let’s Encrypt, diese geht auf u.a. auf eine Initiative von Mozilla und der EFF zurück. Let’s Encrypt stellt kostenlose Basiszertifikate (sog. Domain Validation) aus. Daneben werden Tools angeboten, die die Beantragung, Installation und Konfiguration der Zertifikate und TLS-Verbindungen weitgehend automatisiert. Dies mit dem Ziel, die Verschlüsselung von Internetverbindungen zu fördern und auszubauen.

Wie man TLS aktiviert hängt stark von der Serversoftware ab, die im Einsatz ist. In unserem Fall wird Apache HTTPD eingesetzt. Die Konfiguration und Aktivierung von TLS nimmt uns aber Let’s Encrypt ab.

Let’s Encrypt Client (Certbot) installieren

Einer dieser Clients ist der Certbot der von der EFF bereitgestellt wird. Auf der Certbot-Webseite kann man aus einer Liste Serversoftware und Betriebsystem auswählen und erhält die benötigte Anleitung für die eigene Installation.

Hier ist ein Beistpiel für einen Apache-Webserver auf der aktuellen Ubuntu-LTS Version (16.04 Xenial):

$ sudo apt update
$ sudo apt install software-properties-common
$ sudo add-apt-repository ppa:certbot/certbot
$ sudo apt update
$ sudo apt install python-certbot-apache

Zertifikat installieren und Apache auf TLS konfigurieren

$ sudo certbot --apache

Mehr ist in der Tat nicht zu tun. Es werden ein paar Fragen gestellt, die man beantwortet. Dann werden die Zertifikate anhand der vorliegenden Apache Konfiguration beantragt, geprüft und installiert. Nebenbei wird eine TLS-Konfiguration geschrieben, die die Zertifikate verwendet. Die Konfiguration ist so ausgelegt, dass sich auch noch sehr alte Clientsysteme verbinden können, moderne Systeme aber Verschlüsselung nach dem neusten Stand verwenden.

Zertifikatserneuerung einrichten

Da Let’s Encrypt-Zertifikate nur 90 Tage gültig sind, sollte regelmäßig ein Erneuerungsprozess durchgeführt werden. Zunächst mal ein Test:

$ sudo certbot renew --dry-run

Falls das klappt:

$ sudo crontab -e

und dort dann den Zertifikatsupdateprozess eintragen, etwa so:

15 3 * * * /usr/bin/certbot renew --quiet

Dann wird jede Nacht um 3:15 Uhr ein renew angestoßen. Wenn das Zertifikat weniger als 30 Tage gültig ist, wird es durch ein neues ersetzt.

Nachbereitung

Prüfung der geladenen Resourcen

Jetzt sollte man wieder, z.B. mit Webbkoll, überprüfen, ob alle verwendeten Resourcen per https geladen werden und ggf. Korrekturen durchführen. Die meisten Browser verbieten sogenannten Mixed-Content, also dass etwa unverschlüsselte Bilder oder Skripte in eine verschlüsselte Seite nachgeladen werden. Dies geschieht auch aus gutem Grund, ein Angreifer könnte durch manipulierte Inhalte, die über die ungeschützte Verbindung nicht weiter auffallen würden, dafür sorgen, dass sich das Verhalten und Aussehen der Seite so ändert, dass man ungewollt Informationen an den falschen Empfänger gibt.

Feintuning der TLS-Konfiguration

Wie vorhin schon erwähnt, ist die von Certbot erstellte Konfiguration recht weit gefasst. Sie unterstützt neben der aktuellen TLS Version 1.2 auch noch die Versionen 1.1 und 1.0. Dadurch können sich auch noch sehr alte Clientsystem mit der Webseite verbinden. Dennnoch ist die Konfiguration so gestaltet, dass moderne Systeme sich mit entsprechend sicheren Einstellungen verbinden.

Allerdings könnte man sich überlegen, ob man nicht alte Zöpfe abschneidet und eine strengere Konfiguration einsetzt, wenn man keine all zu alten Endgeräte unterstützen muss. Eine guter Ansatz ist die Mozilla TLS Dokumentation und der Mozilla Config Generator.

Jetzt bietet es sich ausserdem an, die eigene Konfiguration mit diversen Prüftools auf die Probe zu stellen:

Die ersten drei Tools analysieren allesamt die TLS-Konfiguration unter einer angegebenen Domain. Dabei geben SSLLabs ind High-Tech Bridge zusätzliche Informationen darüber, ob eine Verwundbarkeit für bestimmte Angriffsszenarien gefunden wird und prüfen noch einige zusätzliche Informationen rund um die Sicherheit einer Domain. Imirhil ist etwas sporadischer und bewertet vor allen Dingen die diversen eingesetzten Kryptoverfahren. Dabei ist es besonders streng. Ausserdem bietet es im Gegensatzt zu den anderen auch die Möglichkeit, andere Protokolle (ausser HTTPS) zu prüfen. Mozilla Observatory überprüft zunächst einmal nach den Mozilla TLS Richtlinien und bietet zusätzliche Informationen und Tipps zur weiteren Absicherung der eigenen Webseite an. Zusätzliche werden die anderen hier genannten Dienste auf Wunsch mit abgefragt.

Security-Header setzen

Die folgenden Header können zur Sicherheit der Webseite beitragen. Einige sind simpel anzuwenden, andere müssen verstanden werden und können Folgen für die Ereichbarkeit einer Webseite haben. Die eigene Header-Konfiguration kann man mit securityheaders.io überprüfen.

X-Frame-Options

Hiermit kann man steuern, ob Inhalte der eigenen Seite in einem Frame dargestellt werden dürfen und ggf. von wo dies erlaubt sein soll.

<VirtualHost *>
    # ...
    Header always set X-Frame-Options "SAMEORIGIN"
    # ...
</VirtualHost>

Dieser Wert erlaubt die Verwendung von Inhalten in Frames nur auf der eigenen Seite. Dadurch werden sogenannte Clickjacking-Angriffe verhindert, bei denen der Besuch einer Webseite vorgetäuscht wird.

X-Xss-Protection

Mit diesem Header wird der browserinterne Cross Site Scripting (XSS)-Schutz deaktiviert, aktiviert oder sogar verschärft:

<VirtualHost *>
    # ...
    Header always set X-Xss-Protection "1; mode=block"
    # ...
</VirtualHost>

Durch die 1 wird der Schutz aktiviert, durch mode=block wird das verhalten so verschärft, dass das kritische Script nicht bereinigt ausgeführt wird, sondern vollständig blockiert wird.

HTTP Strict-Transport-Security (HSTS)

Durch diesen Header werden sogenannte Downgrade-Angriffe verhindert, d.h. eine Zurückstufung auf eine unverschlüsselte Verbindung und ein anschließendes Laden einer fremden Seite. Durch den Header bekommt der Browser die Mitteilung, dass diese Seite nur per https aufzurufen ist. Dies merkt der Browser sich für die Anzahl an Sekunden, die unter max-age angegeben ist. Im folgenden Beispiel also 10 Minuten. Wann immer man versucht, n-design.de oder http://n-design.de aufzurufen, wird dies in dem Zeitraum in https://n-design.de umgesetzt. Natürlich verlängert sich die Frist entsprechend bei einem neuen Aufruf.

<VirtualHost *>
    # ...
    Header always set Strict-Transport-Security "max-age=600"
    # ...
</VirtualHost>

Der Zeitraum von 600 Sekunden, bzw. 10 Minuten ist eigentlich nur im Kontext eines Deployments von HSTS sinnvoll, wenn man zunächst ausprobieren möchte, ab alles noch funktioniert. Wenn man dann produktiv gehen möchte, sollte der Zeitraum auf ein Jahr oder mehr ausgedehnt werden.

Subdomains mit einschließen

Den Header kann man so erweitern, dass nicht nur die besuchte Domain, sondern auch alle dazu gehörenden Subdomains unter den selben Schutz fallen. Hier ist Aufmersamkeit geboten, denn nur wenn alle Subdomains korrekt per https erreicht werden können, sind sie danach noch erreichbar – denn unverschlüsselte http Verbindungen sind ab dann verboten.

<VirtualHost *>
    # ...
    Header always set Strict-Transport-Security "max-age=600; includeSubDomains"
    # ...
</VirtualHost>
HSTS vorab bekannt machen (preloading)

Man hat immer noch eine kleine Lücke für einen Angriff, nämlich den ersten Besuch einer Webseite, also bevor die Strict-Transport-Security Konfiguration bekannt ist. Hier kommt das Preloading ins Spiel. Fügt man dem Header noch das Schlüsselwort preload hinzu gibt man seine Bereitschaft bekannt, dass die Seite auf die Preloadingliste der Browserhersteller kommt. Ein Browser weiß dann ab Werk, dass eine Domain ausschließlich per https erreicht werden darf. Die Konfiguration sieht dann so aus, max-age wird dann auf 365 Tage gesetzt, was im Gegensatz zu 10 Minuten eher sinnvoll ist.

<VirtualHost *>
    # ...
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    # ...
</VirtualHost>

Weitere informationen findet man unter HSTS Preload, dort kann man auch die Eignung der eigenen Konfiguration für das Preloading testen und sich dann auch aktiv auf die Preloadingliste eintragen lassen. Insbesondere für umfangreichere Webpräsenzen ist es empfehlenswert, den dortigen Abschnitt Deployment Recommendations zu beherzigen, um sicherzustellen, dass alle Bereiche erreichbar bleiben.

Hier kommt auch nochmals der Verzicht auf das Domänen-Prefix zum Tragen. Auf die Preloadliste werden nur Top-Level-Domains eingetragen, die ihre Subdomains mit einschließen. Wenn man partout das www. behalten möchte, muss man allerdings auf die Weiterleitungen acht geben:
http://n-design.de -> https://www.n-design.de oder http://n-design.de -> http://www.n-design.de -> https://www.n-design.de funktioniert nicht, es muss
http://n-design.de -> https://n-design.de -> https://www.n-design.de sein. Grund ist, dass der Client die HSTS Header der Top-Level-Domain erhalten muss, um die Absicherung für alle Subdomains zu aktivieren.

Content-Security-Policy (CSP)

Die Content-Security-Policy kann sehr detailiert angeben, von wo eine Webseite welche Arten von Resourcen nachladen darf. Dies ist in jedem Fall sehr sinnvoll, um Nutzer der Seite vor Angriffen mit schädlichen Inhalten zu schützen und problematische Technologien zu beschränken. Problematisch können z.B. Frames sein, Inhalte anderer Webseiten innerhalb der eigenen Webseite anzeigen, insbesondere, wenn man hier keine Begrenzung für die erlaubten Quellen angibt. Ebenso sind Inline-JavaScripte problematisch und insbesondere die JavaScript-Methode eval(). Sie interpretiert einen beliebigen übergebenen Text als JavaScript und führt ihn aus.

Bevor man allerdings diesen Header anwendet, sollte man wissen, was auf der eigenen Seite eigentlich passiert. Hier hilft das Mozilla Laboratory AddOn für den Firefox: damit kann man die effektive CSP für eine Seite aufzeichnen und erhält Hinweise auf problematische Stellen.
Das AddOn kann ausserdem eine alternative CSP für eine Seite erzwingen, damit man die Auswirkungen von Änderungen überprüfen kann. Ebenso lässt sich eine CSP z.B. mit dem CSP Evaluator von Google analysieren.

Ein Wermutstropfen in diesem Zusammenhang ist, dass viele Designs für Webseiten umfangreich inline JavaScript verwenden und so die script-src: 'unsafe-inline' Direktive gesetzt werden muss, damit die Seite wie erwartet aussieht und sich entsprechend verhält. Ausser einem Redesign gibt es hier erst mal keine Lösung – bei einer Neukonzeption einer Seite ist darauf hin zu wirken, dass diese Technologie nicht mehr verwendet wird.

HTTP Public-Key-Pins (HPKP)

Dieses Verfahren ist die Holzhammer-Methode um sich gegen Man in the Middle-Angriffe zu wehren. Die Pins enthalten Hashwerte von öffentlichen Schlüsseln, von denen einer beim nächsten Besuch der Seite in der Zertifikatskette enthalten sein muss. Das Verfahren ist sehr mächtig aber leider nicht ganz unproblematisch. Wenn man keinen Zugriff mehr auf die entsprechenden Zertifikate hat (Datenverlusst, CA hat den Betrieb eingestellt, CA wurde kompromittiert etc.), besteht die Gefahr, dass die eigene Seite nicht mehr erreichbar ist, weil die Clients bei der Prüfung nicht die erwarteten (gepinnten) Public-Keys vorfinden. Man muss also sehr genau abwägen, ob das Verfahren für die eigene Webseite oder Anwendung sinnvoll ist. Wenn ein hoher Schutzbedarf besteht, unter Umständen schon, aber dann muss man sich sehr intensiv mit dem Thema beschäftigen und es verstehen. Zu den Problemen mit HPKP hat auch Scott Helme in I’m giving up on HPKP geschrieben.

<VirtualHost *>
    # ...
    Header always set Public-Key-Pins "pin-sha256='Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys='; pin-sha256='YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg='; pin-sha256='cnRbW6hKjLxCL6ZEYh/1oNdHs3QUj7HhhR8okYSpr2I='; max-age=2592000; includeSubDomains"
    # ...
</VirtualHost>

Die Statements max-age und includeSubDomains sind von ihrer Semantik wie bei HSTS.

X-Content-Type-Options

Manche Browser versuchen den Content-Type einer geladenen Resource zu erraten oder zu erschnüffeln statt auf den entsprechenden Header, den der Server gesendet hat zu hören. Dies kann im Zusammenhang mit sogenannten Drive By-Angriffen problematisch sein. Durch einen solchen Angriff soll der Browser dazu gebracht werden, automatisch Schadcode herunterzuladen und auszuführen.

<VirtualHost *>
    # ...
    Header always set X-Content-Type-Options "nosniff"
    # ...
</VirtualHost>

Einen Überblick über die zuvor genannten Header gibt auch der Blogbeitrag von Scott Helme: Hardening your HTTP response headers.

Referrer-Policy

Der Header Referrer-Policy weist den Browser an, wie mit Links umzugehen ist, die von unserer Seite auf eine fremde Seite führen. Je nach Wert, oder wenn er nicht gesetzt ist, erfährt die neu aufgerufene Seite dann, von wo sie aufgerufen wurde. Unter Umständen ist dies kritisch für die Privatsphäre von Besuchern. Daher verwenden wir folgende Konfiguration:

<VirtualHost *>
    # ...
    Header always set Referrer-Policy "no-referrer"
    # ...
</VirtualHost>

Scott Helme beschreibt diesen Header ausführlich in seinem Blog A new security header: Referrer Policy.

DNS-CAA Record setzen

Dies ist noch ein weiterer Kniff, den man anwenden kann, um mehr Sicherheit zu erlangen. Es ist das Gegenstück zu den Public-Key-Pins, nur nicht auf Clientseite, sondern auf Seite der Zertifikatsanbieter und weniger riskant.

Sofern der eigene Domain-Registrar dies unterstützt, kann man dort im Domain Name Service einen oder mehrere Certification Authority Authorization Records setzen. Die Idee ist, dass eine CA überprüft, ob sie per DNS-Record authorisiert wurde, Zertifikate für die entsprechende Domain auszustellen. Das Problem des Aussperrens besteht hier nicht, man kann bei Bedarf entsprechende Einträge hinzufügen und entfernen. Sie betreffen nur die Ausstellung von Zertifikaten, nicht die Prüfung derselben. Der CAA Record Helper hilft beim Anlegen der entsprechenden Records. Diese können dann in die eigenen DNS-Einträge kopiert werden.

Resümee

Es gibt einige Maßnahmen, die ergriffen werden können, um eine Webpräsenz sicherer zu machen. Glücklicherweise gibt es auch jede Menge Tools, die dies unterstützen. Insbesondere die einfache Bedienung des Certbot erleichtert die Bereitstellung von TLS auf dem eigenen Server. Zusammenfassend kann man sagen, dass wir weniger als zwei Stunden benötigten, diese Umstellung auf TLS abzuschließen. Das Schreiben dieses Beitrags kostete mehr Zeit.