Original-URL des Artikels: https://www.golem.de/news/netzverschluesselung-mythen-ueber-https-1412-111188.html    Veröffentlicht: 16.12.2014 09:00    Kurz-URL: https://glm.io/111188

Netzverschlüsselung

Mythen über HTTPS

Google will HTTP zum unsicheren Protokoll degradieren, der Trend geht zum verschlüsselten Netz. Daran gibt es auch Kritik, doch die beruht oft auf Missverständnissen.

Der Trend im Netz geht klar in Richtung HTTPS. Große Webseiten wie Facebook, Twitter oder Google sind längst nur noch verschlüsselt erreichbar. Vor allem Google treibt die Verschlüsselung des Netzverkehrs voran. Der Suchmaschinenriese bevorzugt HTTPS-Seiten inzwischen beim Indizieren. Langfristig soll der Chrome-Browser vor HTTP-Verbindungen ohne TLS warnen.

Während Google für seine Schritte von Kryptographen und IT-Sicherheitsexperten viel Lob erhält, gibt es auch Kritik. Die basiert aber häufig auf falschen Vorstellungen davon, wie HTTPS eigentlich funktioniert.

Mythos: HTTPS-Verschlüsselung für reine Inhalte ist nutzlos

Weit verbreitet ist die Annahme, dass HTTPS nur bei Webseiten mit Logins oder jenen, bei denen sensible Daten übertragen werden, etwas bringt. Wozu etwa ein Blog verschlüsselt übertragen, wenn die Inhalte sowieso jeder lesen darf?

HTTPS gewährleistet jedoch mehr als nur die Verschlüsselung von Inhalten. Eine abgesicherte Verbindung garantiert neben der Vertraulichkeit auch die Echtheit der übertragenen Daten. Anders ausgedrückt: Es wird gewährleistet, dass beim Nutzer auch wirklich das ankommt, was der Server abgeschickt hat. Dass Inhalte auf dem Übertragungsweg manipuliert werden, kommt häufig vor und führt zu realen Problemen.

Sehr aufschlussreich ist ein Eintrag auf der Webseite Stackoverflow: Der Fragende schreibt von einem WLAN in Cafés, deren Betreiber die Idee hatte, die Werbung auf den übertragenen Webseiten durch eigene Werbung zu ersetzen. Der US-Provider Comcast hat Ähnliches bereits in die Praxis umgesetzt und fremde Webseiten mit eigener Javascript-Werbung versehen. Schlagzeilen machte kürzlich auch der US-Provider Verizon, weil er ungefragt Cookies in übertragene Webseiten einbaute. Damit überwacht Verizon die Surfgewohnheiten seiner Kunden.

Ebenfalls denkbar ist natürlich, dass Angreifer unverschlüsselte Datenübertragung nutzen, um Malware in Webseiten einzufügen. Das könnte beispielsweise in offenen WLANs passieren oder auch bei Tor-Exit-Nodes. Dazu kommen harmlosere aber dennoch möglicherweise unerwünschte Manipulationen, etwa wenn Anbieter mobiler Netzzugänge Bilder zusätzlich komprimieren oder übertragene HTML-Daten optimieren.

Derartige Manipulationen von Daten auf dem Übertragungsweg sind nur möglich, weil gewöhnliche Verbindungen im Netz die Echtheit der übertragenen Daten nicht gewährleisten. Durch HTTPS weiß der Nutzer, dass die Daten, die er empfängt, auch wirklich vom angegebenen Server stammen.

Mythos: Zertifikate sind zu teuer

Vielfach wird eingewandt, dass die weitere Verbreitung von HTTPS nur dem Geschäft der Zertifizierungsstellen diene. Doch anders als noch vor einigen Jahren sind entsprechende Zertifikate heute sehr günstig zu bekommen. Die israelische Firma StartSSL, deren Zertifikat seit langem von allen Browsern akzeptiert wird, bietet sogar kostenlose Zertifikate. Im nächsten Jahr soll zudem die von Mozilla, der EFF und anderen getragene Zertifizierungsstelle Let's encrypt ihren Betrieb aufnehmen, die das Ziel hat, Zertifikate kostenlos und möglichst einfach auszustellen.

Bezahlen muss man heute für Zertifikate nur noch, wenn man Wildcard-Zertifikate oder Extended-Validation-Zertifikate nutzen möchte. Wildcard-Zertifikate gelten für mehrere Subdomains (etwa *.example.com), bei EV-Zertifikaten wird nicht nur der Besitz der Domain, sondern auch der Inhaber überprüft, und im Browser wird etwa der Firmenname in einer grünen Leiste angezeigt. Für einfache Webseiten reichen kostenlose Zertifikate völlig aus.



Mythos: HTTPS ist viel zu langsam

In den meisten Fällen sind die kryptographischen Operationen von HTTPS in Sachen Performance nahezu vernachlässigbar. Laut einer älteren Aussage von Google-Entwickler Adam Langley musste Google keinerlei zusätzliche Hardware anschaffen, um den Betrieb von Gmail vollständig auf HTTPS umzustellen.

Praktisch irrelevant für die Performance ist die symmetrische Verschlüsselung. Geringe Performancekosten hat man bei den asymmetrischen Operationen, also bei der Verifikation von Signaturen und beim Schlüsselaustausch. Doch auch die bewegt sich nur im Millisekundenbereich. Das einzige wirkliche Performanceproblem von HTTPS sind zusätzliche Round-Trips beim Verbindungsaufbau. Doch die sind kein grundsätzliches Problem, sie treten nur bei nicht optimalen Serverkonfigurationen auf.

Ilya Grigorik, bei Google als Experte für Webperformance angestellt, betreibt eine Webseite mit dem Namen istlsfastyet.com, auf der er erläutert, welche Performanceprobleme bei TLS-Verbindungen auftreten können und wie man diese vermeidet. So sollten Serverbetreiber etwa die Funktion OCSP-Stapling anschalten und gewährleisten, dass die Browser die Funktion TLS False Start einsetzen können. Wenn man HTTPS in Kombination mit SPDY oder HTTP/2 einsetzt, kann man sogar in Sachen Performance gewinnen.

Google-Entwickler Chris Palmer argumentiert, dass HTTPS zwar sehr geringe Kosten in Sachen Performance hat, aber die wenigsten Webseiten reizen bislang andere Möglichkeiten der Optimierung voll aus. Dazu gehören etwa die komprimierte Übertragung von HTML, CSS und Javascript, die Optimierung von Bildern und vieles mehr. Insofern ist es in den meisten Fällen so, dass man durch einfache Optimierungen an anderer Stelle die Verluste durch HTTPS kompensieren kann.

Mythos: Bei HTTPS benötigt man eine eigene IP für jeden Domainnamen

Ursprünglich wurde HTTPS so entwickelt, dass der Server das Zertifikat übertragen hatte, bevor er wusste, auf welchen Domainnamen sich eine Verbindung bezieht. Das führte dazu, dass man mit HTTPS keine virtuellen Hosts einsetzen konnte und für jeden Hostnamen eine eigene IP benötigte. Doch diese Zeiten sind längst vorbei.

2003 wurde die TLS-Erweiterung Server Name Indication (SNI) definiert. Mit SNI ist es möglich, beliebig viele HTTPS-Webseiten mit eigenen Zertifikaten auf einer einzigen IP zu hosten. Das wird heute auch von allen Browsern unterstützt. Selbst mit älteren Browsern sind Probleme extrem selten. Der Internet Explorer 7 unter Windows Vista unterstützte bereits SNI, Firefox kann das Protokoll seit Version 2.0. Die einzigen Browser, die Probleme mit SNI haben, sind der Internet Explorer unter Windows XP und der interne Browser von alten Android-2-Systemen.



Mythos: Die Zertifizierungsstellen geben alle privaten Schlüssel an Geheimdienste weiter

Einige Zertifizierungsstellen bieten eine Funktion an, bei der die Zertifizierungsstelle den privaten Schlüssel für ein HTTPS-Zertifikat erstellt. Diese Funktion ist umstritten, insbesondere StartSSL steht dafür immer wieder in der Kritik.

Allerdings: Kein Kunde wird zur Nutzung dieser Funktion gezwungen, auch wenn dies immer wieder fälschlicherweise behauptet wird. Jeder Nutzer hat die Möglichkeit, selbst einen privaten Schlüssel und ein sogenanntes CSR (Certificate signing request) zu erstellen und dieses von der Zertifizierungsstelle signieren zu lassen. Dann kann man sich auch sicher sein, dass der private Schlüssel nicht in fremde Hände gelangt.

Mythos: Es ist wichtig, dass ich das Zertifikat bei einer vertrauenswürdigen Zertifizierungsstelle erhalte

Aus Sicherheitsgründen ist es völlig egal, von welcher Zertifizierungsstelle man sein Zertifikat erhält. Manche Webseitenbetreiber haben in der Vergangenheit damit geworben, dass sie Zertifikate von einem europäischen Anbieter erwerben, weil sie US-Anbietern nicht trauen. Solche Aussagen zeigen nur, dass die Personen offenbar nicht wissen, wie das Zertifikatssystem funktioniert.

Im Browser sind in der Regel alle Zertifizierungsstellen gleichberechtigt (es gibt wenige Ausnahmen). Wer sein Zertifikat von einer besonders vertrauenswürdigen Zertifizierungsstelle erhält, kann weiterhin von einer der vielen anderen angegriffen werden.

Mythos: Das System der Zertifizierungsstellen ist korrupt, daher ist HTTPS nutzlos

Zunächst einmal ist es richtig, dass es viel bereichtigte Kritik an der Arbeit der Zertifizierungsstellen gibt. Viele wurden in der Vergangenheit gehackt, und es wurden Zertifikate durch unauthorisierte Dritte ausgestellt. Dafür stehen beispielsweise die Namen Comodo, Türktrust und Diginotar. Das grundsätzliche Problem des ganzen Systems ist, dass eine einzige kompromittierte Zertifizierungsstelle ausreicht, um jede beliebige Webseite anzugreifen. Viele Zertifizierungsstellen befinden sich in den USA und sind vermutlich verpflichtet, der NSA bei Bedarf zu helfen.

Daraus zu schließen, dass HTTPS komplett nutzlos ist, würde jedoch weit über das Ziel hinausschießen. Selbst wenn die NSA in der Lage wäre, alle HTTPS-Verbindungen anzugreifen, würde die Technologie Nutzer immer noch in vielen Szenarien schützen. Denn auch wenn Zertifizierungsstellen von Geheimdiensten kompromittiert werden können: Für einfache Kriminelle, die beispielsweise Zugangsdaten zu Mailaccounts mitlesen wollen, um sie für Spamangriffe zu missbrauchen, ist dies vermutlich eine nicht zu überwindende Hürde.

Viel wichtiger ist aber folgendes: In Folge der diversen Skandale um Zertifizierungsstellen wurden inzwischen Technologien entwickelt, die die Nutzung kompromittierter Zertifikate zwar nicht in allen Fällen ausschließen, aber doch enorm erschweren. Dazu gehört die Funktion HTTP Public Key Pinning (HPKP), mit der ein Seitenbetreiber bestimmte Keys im Browser des Nutzers für einen definierten Zeitraum festlegen kann. Das System Certificate Transparency sorgt außerdem dafür, dass es erschwert wird, die Fälschung von Zertifikaten zu vertuschen. Diese werden von Log-Servern in einem kryptographisch abgesicherten Log gespeichert.

Alternative DANE

Oftmals wird das DANE-Protokoll als mögliche Alternative zum System der Zertifizierungsstellen ins Gespräch gebracht. DANE sichert die Echtheit von Zertifikaten über DNS-Einträge ab, die wiederum mit DNSSEC signiert sind. Doch bei DANE gibt es noch sehr viele Fragezeichen. Zunächst einmal ist es so, dass DNSSEC seit vielen Jahren propagiert wird, aber praktisch eingesetzt wird es nahezu überhaupt nicht.

Viele Fragen beim praktischen Einsatz von DANE sind zudem völlig ungeklärt. Die Verifikation der DNSSEC-Signaturen wird von einem DNS-Resolver durchgeführt. Doch DNS-Resolver werden bisher in aller Regel nur von Providern betrieben und nicht von Nutzern. Die Abfrage der DNS-Resolver findet weiterhin ungeschützt statt.

Damit DANE sinnvoll funktioniert, müssten Nutzer eigene DNS-Server betreiben. Wie das passieren soll, ist bislang völlig unklar. Man könnte versuchen, alle Hersteller von Betriebssystemen dazu zu bringen, standardmäßig DNS-Server zu installieren, die die DNSSEC-Prüfung übernehmen. Doch das erscheint kaum realistisch. Eine Alternative wäre, dass Webbrowser einen eigenen DNS-Resolver betreiben. Es gibt einige Browserplugins, die so arbeiten. Im Moment arbeitet aber kein großer Browserhersteller daran, eine solche Funktion zu integrieren.

Zudem: Auch bei DNSSEC stellt sich die Frage, wem man hier eigentlich vertraut. Zwar ist es sicher ein Fortschritt, statt Hunderten Zertifizierungsstellen nur noch einer Stelle, beispielsweise der DeNIC, zu vertrauen. Aber auch hier sind natürlich Interventionen von Geheimdiensten nicht auszuschließen, und Systeme wie Key Pinning oder Certificate Transparency wären weiterhin sinnvoll.

Möglicherweise wird DANE irgendwann etwas zur Absicherung von HTTPS-Verbindungen beitragen, aber dafür muss noch viel passieren. Im Moment ist es zumindest bei HTTPS-Verbindungen nahezu nutzlos. Realistischerweise hat DANE eher dort eine Zukunft, wo bisher Zertifikate überhaupt nicht geprüft werden, beispielsweise bei SMTP-Verbindungen zwischen Servern.

Die wirklichen Gründe: Inhalte von Drittanbietern

Natürlich werden wir oft gefragt, warum die Webseite von Golem.de noch nicht über HTTPS erreichbar ist. Das hat einen simplen Grund: Golem.de ist auf Werbung und andere Daten von Drittanbietern angewiesen, und die stehen oft nicht verschlüsselt zur Verfügung. Das ist auch der Grund, weshalb vor allem Nachrichtenwebseiten bisher selten über HTTPS erreichbar sind. Wir arbeiten aber intensiv daran, Golem.de in Zukunft verschlüsselt anbieten zu können.

Für Webseitenbetreiber, die ihre Webseiten bei Shared-Hosting-Anbietern betreiben, kommt ein weiteres Problem hinzu: Längst nicht alle Anbieter erlauben es ihren Kunden, eigene Zertifikate für Webseiten einzutragen. In manchen Fällen werden dafür auch horrende Extragebühren erhoben. Doch hier kann man wohl optimistisch in die Zukunft blicken: Nach der Ankündigung der Chrome-Entwickler, HTTP zum unsicheren Protokoll zu degradieren, können sich das Webhoster vermutlich in Zukunft nicht mehr erlauben.

Fazit: Die Zukunft ist verschlüsselt

Man kann Google für vieles kritisieren, aber in Sachen IT-Sicherheit macht das Unternehmen zur Zeit vieles richtig. Der Druck in Richtung HTTPS ist gut für die Sicherheit im Netz, die Nachteile sind überschaubar und oft durch den Einsatz moderner Technologien zu lösen.

Vielfach wird beklagt, dass die NSA-Affäre bislang kaum Konsequenzen nach sich gezogen hat. Auf der politischen Ebene ist das sicher richtig, aber in Sachen Netzsicherheit und Verschlüsselung tut sich einiges. HTTPS wird zum Standard - und das ist auch gut so.  (hab)


Verwandte Artikel:
ROBOT-Angriff: Arbeitsagentur nutzt uralte Cisco-Geräte   
(09.03.2018, https://glm.io/133258 )
Trustico/Digicert: Chaos um 23.000 Zertifikate und private Schlüssel   
(01.03.2018, https://glm.io/133077 )
Cisco: Kritische Lücke im VPN ermöglicht DoS-Angriffe auf Switches   
(30.01.2018, https://glm.io/132470 )
LLVM 6.0: Clang bekommt Maßnahme gegen Spectre-Angriff   
(09.03.2018, https://glm.io/133241 )
Urheberrecht: Bär lehnt Leistungsschutzrecht strikt ab   
(10.03.2018, https://glm.io/133260 )

© 1997–2019 Golem.de, https://www.golem.de/