Verschlüsselung von SNI: Wie einer der großen Internet-Bugs behoben wurde

Cloudflare wurde am 27. September 2010 gestartet. Seitdem betrachten wir den 27. September als unseren Geburtstag. Am kommenden Donnerstag werden wir 8 Jahre alt.

Seit unserem ersten Geburtstag nutzen wir diese Gelegenheit, neue Produkte oder Dienste zu präsentieren. Im Laufe der Jahre kamen wir zu dem Schluss, dass wir zur Feier unseres Geburtstages nicht Produkte auf den Markt bringen sollten, mit denen wir Geld verdienen können, sondern vielmehr unsere Benutzer und das Internet im Allgemeinen mit etwas beschenken sollten. Meine Mitbegründerin Michelle hat gestern in einem großartigen Blogbeitrag über diese Tradition geschrieben.

Für mich persönlich war einer meiner stolzesten Momente bei Cloudflare, als wir anlässlich unseres Geburtstags 2014 die HTTPS-Unterstützung für alle unsere Benutzer kostenlos machten. Damals nannten uns die Leute verrückt – wortwörtlich und wiederholt. Ehrlich gesagt, hatten wir auch intern einige Diskussionen darüber geführt, ob wir verrückt sind, denn Verschlüsselung war der Hauptgrund dafür, dass Menschen von einem kostenlosen Konto auf ein Bezahlkonto umgestiegen sind.

Aber es war der richtige Weg. Die Tatsache, dass Verschlüsselung nicht von Anfang an in das Web integriert war, war unserer Meinung nach ein Fehler. Heute, fast genau vier Jahre später, ist das Web zu fast 80 % verschlüsselt, dank der Vorreiterrolle von großartigen Projekten wie Let's Encrypt, der Browserteams von Google, Apple, Microsoft und Mozilla und der Tatsache, dass immer mehr Hosting- und SaaS-Anbieter kostenlose Unterstützung für HTTPS bieten. Ich bin stolz darauf, dass wir eine führende Rolle bei der Entwicklung dieses Trends gespielt haben.

Heute ist ein weiterer Tag, auf den ich zurückblickend stolz sein möchte, denn heute werden wir hoffentlich einen neuen Trend starten, der das verschlüsselte Web noch privater und sicherer macht. Um das zu verstehen, müssen Sie zunächst verstehen, warum das verschlüsselte Web, wie es heute existiert, immer noch einen großen Teil Ihres Browserverlaufs durchsickern lässt.

Wenn Sie eine Website über HTTPS besuchen, erwarten Sie, dass niemand, der die Verbindung zwischen Ihnen und Ihrem Ziel belauscht, sehen kann, was Sie tun. Und bis zu einem gewissen Grad stimmt das auch. Wenn Sie die Website Ihrer Bank besuchen, sorgt HTTPS dafür, dass die an die Website gesendeten oder von ihr erhaltenen Inhalte (z. B. Ihr Benutzername und Passwort oder der Saldo Ihres Bankkontos) nicht an Ihren ISP oder andere Personen, die Ihre Netzwerkverbindung überwachen, weitergegeben werden.

Während die Inhalte, die an eine HTTPS-Seite gesendet oder von ihr empfangen werden, geschützt sind, kann die Tatsache, dass Sie die Seite besucht haben, auf verschiedene Weise leicht nachverfolgt werden. Eine Möglichkeit dafür war traditionell über DNS. DNS-Abfragen sind standardmäßig unverschlüsselt, sodass Ihr ISP oder jemand anderes sehen kann, wo Sie online unterwegs sind. Aus diesem Grund haben wir im vergangenen April 1.1.1.1 gestartet – einen kostenlosen (und wahnsinnig schnellen) öffentlichen DNS-Resolver mit Unterstützung für DNS-over-TLS und DNS-over-HTTPS.

1.1.1.1 war ein großer Erfolg und wir konnten den Prozentsatz der DNS-Abfragen, die über eine verschlüsselte Verbindung gesendet werden, deutlich erhöhen. Kritiker haben jedoch zu Recht darauf hingewiesen, dass die Identität der von Ihnen besuchten Seiten immer noch durch andere Schwachstellen nachverfolgt werden kann. Die problematischste davon ist die sogenannte Server Name Indication-Erweiterung (SNI).

Grundsätzlich ist SNI da, damit Sie mehrere verschlüsselte Websites unter einer einzigen IP-Adresse hosten können. Frühe Browser enthielten die SNI-Erweiterung nicht. Wenn damals eine Anfrage zum Aufbau einer HTTPS-Verbindung gestellt wurde, hatte der Webserver nicht viele Informationen und konnte nur ein einziges SSL-Zertifikat pro IP-Adresse, an der der Webserver lauschte, zurückgeben.

Eine Lösung für dieses Problem war die Erstellung von Zertifikaten mit mehreren Alternativnamen (Subject Alternative Names – SANs). Diese Zertifikate verschlüsseln den Traffic für mehrere Domains, die alle auf derselben IP gehostet werden können. So behandelt Cloudflare HTTPS-Zugriffe von älteren Browsern, die kein SNI unterstützen. Wir beschränken diese Funktion jedoch auf unsere zahlenden Kunden, und das aus dem gleichen Grund, warum SANs keine gute Lösung sind: Sie sind ein Hack, schwierig zu verwalten und können die Performance bremsen, wenn sie zu viele Domains umfassen.

SNI war als Lösung besser skalierbar. Eine gute Analogie dafür ist meiner Ansicht nach ein Briefumschlag. Der Inhalt im Umschlag ist geschützt und für den Postboten nicht sichtbar. Außerhalb des Umschlags befindet sich jedoch die Anschrift mit Straße und Hausnummer, dank der der Postbote den Umschlag in das richtige Gebäude bringt. Im Internet entspricht die IP-Adresse eines Webservers Straße und Hausnummer.

Wenn man jedoch in einem Mehrfamilienhaus wohnt, reichen Straße und Hausnummer allein nicht aus, um den Umschlag an den richtigen Empfänger zu bringen. Als Ergänzung zur Anschrift gibt man eine Wohnungsnummer oder den Namen des Empfängers an. Das ist das Äquivalent zu SNI. Wenn ein Webserver mehrere Domains hostet, stellt SNI sicher, dass die Anfrage an die richtige Website weitergeleitet wird, sodass das richtige SSL-Zertifikat zurückgegeben werden kann, um alle Inhalte verschlüsseln und entschlüsseln zu können.

Die Spezifikation für SNI wurde 2003 von der IETF eingeführt, in den Folgejahren stellten Browser die Unterstützung bereit. Damals schien es ein akzeptabler Kompromiss zu sein. Der überwiegende Teil des Internetverkehrs war unverschlüsselt. Das Hinzufügen einer TLS-Erweiterung, mit der Verschlüsselung einfacher unterstützt werden kann, schien ein großartiger Schritt zu sein, auch wenn diese Erweiterung selbst nicht verschlüsselt war.

Aber heute macht HTTPS fast 80 % des gesamten Web-Traffics aus. Dass SNI jede von Ihnen online aufgerufene Website an Ihren ISP und jeden anderen weitergibt, der die Verbindung belauscht, zu einem eklatanten Datenschutzloch geworden. Wenn man weiß, welche Websites Sie besuchen, kann man sich ein sehr genaues Bild davon verschaffen, wer Sie sind. Das führt zu Datenschutz- und Sicherheitsrisiken.

In den Vereinigten Staaten gab es nach den FCC-Vorschriften, die kurz vor dem Ende der Obama-Regierungszeit verabschiedet wurden, kurzzeitig Beschränkungen für ISPs beim Sammeln von Daten zum Surfverhalten ihrer Kunden. Die ISPs betrieben jedoch erfolgreich Lobbyarbeit im Kongress, und im April 2017 unterzeichnete Präsident Trump eine Kongressresolution zur Aufhebung dieser Schutzmaßnahmen. Mit der zunehmenden Übernahme von Medien- und Ad-Targeting-Unternehmen durch ISPs erhalten diese die Möglichkeit, die durch ihre Leitungen fließenden Daten zu analysieren. Für diese Unternehmen ist das ein zunehmend attraktives Geschäft, für uns alle stellt es jedoch eine zunehmend beunruhigende Bedrohung der Privatsphäre dar.

Am 3. Mai, etwa einen Monat nach dem Start von 1.1.1.1, las ich einen Bericht über unseren neuen Dienst. Während der Artikel die Tatsache lobte, dass 1.1.1.1 zum Schutz der Privatsphäre beiträgt, kam er etwas nihilistisch zu dem Schluss, dass das alles vergeblich sei, weil ISPs uns immer noch ausspionieren konnten, indem sie SNI überwachten. Frustriert schrieb ich schnell eine E-Mail an einige Cloudflare-Entwickler und das Senior-Team von Mozilla, mit dem wir an einem Projekt zur Verschlüsselung des DNS arbeiteten. Ich schloss meine E-Mail mit:

Meine einfache Anforderungsspezifikation: Wenn Firefox sich mit einer Cloudflare-IP verbindet, dann geben wir ihm einen öffentlichen Schlüssel, mit dem er den SNI-Eintrag verschlüsseln können, bevor er ihn an uns sendet. Wie lässt sich das auf andere Anbieter ausdehnen? Keine Ahnung, aber irgendwo müssen wir anfangen. Grober Konsens und lauffähiger Code, oder?

Es stellte sich heraus, dass sich die Sache etwas komplexer verhielt. Heute bin ich jedoch stolz darauf, Ihnen mitteilen zu können, dass Encrypted SNI (ESNI) im gesamten Netzwerk von Cloudflare live ist. Wir erwarten, dass im Laufe dieser Woche Mozillas Firefox in seiner Nightly-Version als erster Browser das neue Protokoll unterstützen wird. In den kommenden Monaten ist geplant, dass es zum Mainstream wird. Und es ist nicht nur Mozilla. Es gibt großes Interesse von allen wichtigen Browseranbietern und ich bin zuversichtlich, dass jeder von ihnen im Laufe der Zeit ESNI unterstützen wird.

Wir sind zwar die ersten, die ESNI unterstützen, aber wir haben es nicht allein entwickelt. Wir haben an ESNI gemeinsam mit großartigen Teams von Apple, Fastly, Mozilla und anderen aus der Branche gearbeitet, die sich wie wir um den Datenschutz im Internet sorgen. Cloudflare ist zwar das erste Content-Netzwerk, das ESNI unterstützt, aber es handelt sich nicht um ein proprietäres Protokoll. Es wird als IETF-Entwurf-RFC daran gearbeitet und wir hoffen, dass andere uns helfen werden, den Entwurf zu formalisieren und den Standard umzusetzen. Wenn Sie neugierig auf die technischen Details hinter ESNI sind, können Sie mehr aus dem großartigen Blogbeitrag erfahren, den mein Kollege Alessandro Ghedini gerade veröffentlicht hat. Und wenn die Browserunterstützung Ende dieser Woche beginnt, können Sie es mit unserem praktischen ESNI-Testwerkzeug testen.

Vor vier Jahren war ich stolz darauf, dass wir zu einem Trend beigetragen haben, der dazu geführt hat, dass heute fast das gesamte Web verschlüsselt wird. Ich hoffe, dass wir heute wieder zu einem Trend beitragen – diesmal, um das verschlüsselte Web noch privater und noch sicherer zu machen.

Abonnieren Sie den Blog und Sie erhalten tägliche Updates zu allen unseren Mitteilungen der Geburtstagswoche.