Netz - Rettung - Recht

HTTPS, also der per SSL/TLS gesicherte Zugriff auf Webseiten, hat sich in den letzten Jahren - nicht zuletzt durch die problem- und kostenlosen Zertifikate von Let’s Encrypt - stark verbreitet. War es noch vor fünf oder sechs Jahren eher der Ausnahmefall, dass Webseiten, die keinen Login erfordern, die Möglichkeit einer verschlüsselten Verbindung anbieten, ist HTTPS mittlerweile gefühlt der Normalfall geworden. Doch es gibt immer noch Ausnahmen (übrigens auch dort, wo ein Login erforderlich ist).

HSTS steht für HTTP Strict Transport Security und ist ein Standard, der unverschlüsselte Zugriffe auf solche Webseiten verhindern soll, die nur verschlüsselt angeboten werden.

Dem liegt folgendes Angriffsszenario zugrunde: Die Webseite www.example.com ist nur über HTTPS zugänglich. Der Angreifer “A” kann zwar Zugriffe des Benutzers “B” auf seinen eigenen Server umleiten, bspw. durch Manipulation des DNS, aber - wenn alles so läuft, wie es soll - kein Zertifikat für www.example.com erhalten. Was macht er? Er leitet alle Zugriffe auf https://www.example.com stattdessen auf http://www.example.com (ohne Verschlüsselung!) um, und schon gibt es für den Benutzer keine Fehlermeldungen mehr. Dass die Verbindung jetzt unverschlüsselt ist, sieht er vielleicht nicht ohne weiteres. Außerdem kann der Angreifer natürlich einfach ein - nicht vertrauenswürdiges, d.h. selbst signiertes - Zertifikat für www.example.com erzeugen. Das führt zwar zu einer Fehlermeldung, die der Nutzer aber ignorieren kann (“Sicherheits-Ausnahmeregel erstellen”). Auch das soll HSTS unterbinden.

Github hat am 22.02.2018 Änderungen an der HTTPS-und SSH-Konfiguration vorgenommen und ältere und weniger sichere Zugriffsmöglichkeiten deaktiviert. Das betrifft sowohl TLS 1.0 und TLS 1.1 als auch - für den SSH-Schlüsselaustauch - diffie-hellman-group1-sha1 und *diffie-hellman-group14-sha1. Wenn die verwendete Client-Software nicht mindestens TLS 1.2 bzw. einen anderen Schlüsselaustausch-Algorithmus beherrscht, muss man mithin aktiv werden.

Bis zum Umzug meines Blogs auf neue Hardware stammte das SSL-Zertifikat für das Blog von StartCom, einem Tochterunternehmen von WoSign (wobei der Erwerb offenbar verdeckt durch Hinterleute erfolgte). Die Konzernmutter fiel jedenfalls 2016 durch … unschöne Praktiken bei der Erstellung von Zertifikaten auf, mit der Folge, dass Apple, Google (Chrome) und Mozilla (Firefox) allen Zertifikaten der Mutter- wie der Tochterfirmen sukzessive das Vertrauen entzogen.

Wer seine Webseiten auf SSL umstellt, kennt das Problem: eingebundene Bilder, Grafiken, CSS- oder Javascript-Dateien werden hier und dort noch über HTTP aufgerufen, was entweder zu Warnmeldungen im Browser über Mixed Content führt (“Teile dieser Seite sind nicht sicher.”) - oder dazu, dass die “unsicher” eingebundenen Teile nicht nachgeladen werden, mit unschönen Aspekten, wenn Teil des CSS oder des Javascripts plötzlich fehlen.

Das Problem lässt sich natürlich mit einer Volltext-Suche (bspw. nach http:) angehen, aber gerade bei datenbankgestützten Webapplikationen (wie Blogs und CMS) mag der SSL-Check von Jitbit hilfreich sein, der kostenlos bis zu 200 Einzelseiten überprüft.

(Gefunden bei Leitmedium.)

Wie man mit Let’s Encrypt ganz einfach an SSL-Zertifikate kommt, hatte ich bereits vor mehr als einem Jahr geschildert - mittlerweile übrigens ganz einfach, denn in Debian stretch ist der Let’s Encrypt-Client (der jetzt certbot heißt) nativ dabei und bringt jetzt auch einen fertigen Cronjob mit.

Aber darum soll es heute gar nicht gehen, sondern vielmehr um die Frage, wie man Let’s Encrypt verwenden kann, wenn die entsprechende Webpräsenz mit einem einfachen Passwortschutz - der basic access authentication oder kurz Basic-Auth - versehen ist. Jeder kennt vermutlich das Popup, das nach Benutzerkennung und Passwort fragt; eine nicht sehr elegante, aber dafür mit praktisch keinem Aufwand verbundene Lösung, die zudem alle Dateien in allen Verzeichnissen der Präsenz schützt, nicht nur Scripts, sondern auch - bspw. - Bilder.

Eigentlich nutze ich mittlerweile ja Let’s Encrypt, wenn ich Zertifikate für den Betrieb einer Website benötige. Allerdings gibt es doch noch ein oder zwei Dienste, wo ich seit Ende 2015 auf StartCom setze - und die dortigen, kostenlosen Zertifikate laufen eben nach einem Jahr ab und standen daher jetzt zur Erneuerung an.

Vor einigen Monaten hatte ich über letsencrypt, die neue Zertifizierungsstelle für TLS-Zertifikate, berichtet und demletzt meine guten Erfahrungen damit dargestellt. Doch HTTP ist ja nicht das einzige Protokoll, das einer Absicherung bedarf. Wie sieht es mit TLS-Zertifikaten für Mail (SMTP und POP3 oder IMAP) und News (NNTP) oder noch andere Dienste aus?

Grundsätzlich ist das kein Problem: vorhandene Zertifikate mit dem (oder den) passenden Hostnamen müssen nur eingebunden werden.

Im April hatte ich über Let’s Encrypt berichtet, den Dienst, der angetreten ist, das Ausstellen und die Installation von Zertifikaten zu vereinfachen.

Der Betrieb lief seitdem gut und zuverlässig, und nachdem jetzt mehr als 90 Tage vergangen sind, kann ich auch berichten, dass die automatische Erneuerung der Zertifikate vor ihrem Ablauf gleichermaßen zuverlässig funktioniert; bemerkt habe ich sie nur durch die Benachrichtigungs-E-Mail meines Cronjobs. Ich bin also weiterhin sehr zufrieden.

Hat man dem eigenen Webserver erfolgreich SSL beigebracht und für ein valides Zertifikat gesorgt, bspw. mithilfe von Let’s Encrypt, finden sich in der Konfigurationsdatei (bei Debian: /etc/apache2/mods-available/ssl.conf) noch etliche Schrauben und Rädchen, an denen man drehen kann.

Bereits vergangene Woche berichtete ich von meinen Irrungen und Wirrungen des letzten Jahrzehnts mit SSL/TLS im Web. Erst Ende 2015 hatte ich mich aufgerafft, über StartCom für einige Domains Zertifikate erstellen zu lassen, und parallel die Berichterstattung über Let’s Encrypt verfolgt.

Der Workflow für die Erstellung und Pflege von HTTPS-Zertifikaten kann schnell komplex werden:

• Am Anfang steht die Erzeugung eines Schlüsselpaares, denn das spätere Zertifikat wird nur derjenige verwenden können, der auch den passenden privaten Schlüssel hat.
• Dann ist für jedes Zertifikat ein Certificate Signing Request (CSR) zu erstellen; das ist quasi die Roh-Form des späteren Zertifikats mit den notwendigen Informationen, die darin enthalten sein sollen.
• Dieser CSR muss dann von der Zertifierungsstelle (Certificate Authority, CA) digital signiert werden.
• Das so entstandene Zertifikat muss gespeichert und in die Webserver-Konfiguration eingebunden werden.
• Der ganze Ablauf ist nur zielführend, wenn die CA von den verbreiteten Browsern anerkannt ist, den von ihr signierten Zertifikaten also vertraut wird. Dafür wollen die meisten CAs Geld. Zudem müssen sie sich über einen mehr oder weniger aufwendigen Weg zumindest vergewissern, dass derjenige, der ein Zertifikat für einen bestimmten Hostnamen ausgestellt haben möchte, über diesen auch verfügen kann.
• Zertifikate werden in der Regel nur für einen begrenzten Zeitraum - meistens ein Jahr - ausgestellt. Danach müssen sie (rechtzeitig!) verlängert werden.

Let’s Encrypt ist angetreten, diese Abläufe weitestmöglich zu vereinfachen.

Datenströme im Netz zu verschlüsseln ist wichtig, aber auch zunehmend Allgemeingut. Telnet würde sicherlich niemand mehr zum Zugriff auf einen entfernten Rechner nutzen; stattdessen nimmt man SSH. Auch bei anderen Protokollen ist die Übertragung von Passworten im Klartext schon lange out: es fing an mit APOP für den Zugriff über POP3 und CRAM-MD5 für SMTP-Auth, und schon etliche Jahre nutze ich nur noch POP3S/IMAPS/SMTPS, also eine komplette Verschlüsselung des gesamten Datenstroms. So hat auch das auf SSH basierende SCP/SFTP schon lange FTP ersetzt, und nachdem sich mittlerweile auch NNTPS und der verschlüsselte Zugriff auf IRC-Server verbreitet haben, bleiben nur noch wenige Protokolle “offen”.

Selbstverständlich sollte auch - zumindest - die Übertragung von Passworten via HTTP gesichert werden, was die Einrichtung von HTTPS erfordert. Je mehr sich webbasierte Dienste und Apps verbreiten, desto wichtiger ist das. Es ist allerdings - leider - nicht ganz so einfach.