In Anlehnung an HTTP Shaming haben wir einmal die Top 20 der Internetangebote in Deutschland mit dem Test von Qualsys SSL Labs durchgetestet, die Ergebnisse sind gemischt. Die detaillierte Tabelle findet ihr am Ende des Artikels (Update: Unser Leser Christoph hat das Ganze auch mal für Parteien gemacht, was wir ergänzt haben. Tolle Idee! Schlussfolgerungen, wie man daraus die Bedeutung des Themas Datenschutz ableiten kann, überlassen wir euch).
Vorher ein kurzer Rück- beziehungsweise Überblick, worum es bei TLS-gesicherten https-Verbindungen geht und was dabei passiert.
Durch https-Verbindungen wird nicht, wie oft verwechselt, die Webseite verschlüsselt, sondern die Daten, die zwischen dem Server, auf dem die Webseite liegt, und dem Browser des Betrachters ausgetauscht werden. Also im Zweifel auch alle Passwörter, Suchwörter und persönliche Daten die der Nutzer in Formulare eingibt und versendet. Das ist besonders da kritisch, wo Zugangsdaten betroffen sind. In WLANs ist es so für jeden möglich, diese im Klartext zu lesen, wenn er nur mitschneidet, was an Datenpaketen durch die Luft fliegt.
Neben der Verschlüsselung stellt das TLS-Protokoll zusätzlich sicher, dass man mit dem richtigen Server redet und nicht mit einem „man in the middle“ – einem Angreifer, der vorgibt, der gewünschte Gesprächspartner zu sein und sich so auch eigentlich verschlüsselte Daten zugänglich macht, da sie fälschlicherweise passend für ihn verschlüsselt werden. Der Nutzer merkt davon nichts, denn der Angreifer leitet den Datenverkehr einfach weiter, nachdem er ihn abgegriffen hat.
Eine Sicherung der Kommunikation, die das vermeidet, funktioniert folgendermaßen:
- Der Browser verbindet sich mit einem Server, der TLS unterstützt und verlangt, dass dieser sich identifiziert.
- Der Server schickt eine Kopie seines Zertifikats, das auch den öffentlichen Schlüssel des Servers enthält.
- Der Browser überprüft, ob der Zertifikatsaussteller in einer Liste vertrauenswürdiger Zertifikatsaussteller ist, das Zertifikat noch gültig und nicht widerrufen ist und dass der Name mit dem der Webseite übereinstimmt.
- Wenn alle Voraussetzungen erfüllt sind, erstellt der Browser einen Sitzungsschlüssel und sendet ihn, verschlüsselt mit dem öffentlichen Schlüssel des Servers, an diesen.
- Der Server entschlüsselt den Sitzungsschlüssel und sendet eine verschlüsselte Bestätigung, um die Sitzung zu starten.
Acht der 20 Seiten, die wir getestet haben, unterstützen TLS-verschlüsselte Verbindungen, aber bei den wenigsten sind die Einstellungen ideal.
So nutzen die meisten Zertifikate noch SHA1. SHA1 gilt bereits seit 2005 als potentiell unsicher, nachdem ein Angriff veröffentlicht wurde, der den Aufwand zum Auffinden von Kollisionen stark reduziert hat und für Hochleistungsrechner möglich machen würde. Das BSI empfahl, SHA1 ab 2010 nicht mehr für die Zertifikatserstellung zu verwenden, hat es aber bis Anfang 2014 noch selbst verwendet.
Viele unterstützen auch noch RC4, eine Stromchiffre für die Verschlüsselung, die spätestens seit 2013 als gebrochen gilt.
Mit Perfect Forward Secrecy sieht es in den meisten Fällen schlecht aus. Sie würde verhindern, dass Kommunikation rückwirkend entschlüsselt werden kann, wenn zu einem Zeitpunkt der Langzeit-Schlüssel bekannt oder gebrochen wird. Dazu werden für die einzelnen Verbindungssitzungen temporäre Schlüssel ausgehandelt, die nach selbiger weggeworfen werden. Ein erfolgreicher Angreifer könnte demnach nur die aktuelle Kommunikation im Klartext lesen – im Ernstfall eine bedeutende Schadensbegrenzung.
Im August hat Google angekündigt, dass die Unterstützung von https-Verbindungen ein Ranking-Kriterium bei Suchergebnissen werden wird, wenn auch vorerst nur ein schwaches. Es gibt also neben Sicherheit weitere Anreize, endlich umzustellen.
Auch wir haben Nachholbedarf und nur ein A- bekommen. Aber wir arbeiten dran.
Eine kurze Erklärung zum Ranking (detaillierte Methodik). Die Bestnote ist A, die schlechteste F. Der schlimmste Fall wäre natürlich, dass gar keine https-Verbindungen unterstützt werden, dann gibt es auch kein Ranking.
Es gibt ein Punktesystem, nach dem die Noten vergeben werden, aber natürlich auch KO-Kriterien. Wenn ein Zertifikat nicht gültig ist, bringt es nachvollziehbarer Weise wenig, wenn es SHA2 nutzt. In die Wertung gehen die Unterstützung geeigneter Protokolle (30 %), die Sicherung des Schlüsselaustauschs (30 %) und die Stärke der Chiffre zur Verschlüsselung (40 %) mit ein.
Top 20 Internetangebote
| Domain | Bewertung | Anmerkungen | TLS obligatorisch? |
|---|---|---|---|
| t-online.de | A- | Zertifikat nutzt noch SHA1, RC4 wird noch unterstützt, keine PFS | nein |
| ebay.de | B | Zertifikat nutzt noch SHA1, keine PFS, keine Unterstützung von TLS 1.2, kein Secure Negotiation | nein |
| gutefrage.net | B | Zertifikat nutzt noch SHA1, keine PFS, keine Unterstützung von TLS 1.2 | nein |
| bild.de | keine TLS-Unterstützung | nein | |
| web.de | A | nein | |
| chip.de | keine TLS-Unterstützung | nein | |
| focus.de | A- | Zertifikat nutzt noch SHA1, RC4 wird noch unterstützt, keine PFS | nein |
| spiegel.de | keine TLS-Unterstützung | nein | |
| computerbild.de | A- | Zertifikat nutzt noch SHA1, RC4 wird noch unterstützt, keine PFS | nein |
| gmx.de | A | Zertifikat nutzt noch SHA1 | nein |
| chefkoch.de | A- | Zertifikat nutzt noch SHA1, RC4 wird noch unterstützt, keine PFS | nein |
| yahoo.de | A- | Zertifikat nutzt noch SHA1, keine PFS, einer der Server unterstützt jedoch keine https-Verbindungen | ja |
| welt.de | keine TLS-Unterstützung | nein | |
| telefonbuch.de | keine TLS-Unterstützung | nein | |
| dasoertliche.de | keine TLS-Unterstützung | nein | |
| wetter.com | keine TLS-Unterstützung | nein | |
| rtl.de | A- | Zertifikat nutzt noch SHA1, RC4 wird noch unterstützt, keine PFS | nein |
| sueddeutsche.de | A- | Zertifikat nutzt noch SHA1, RC4 wird noch unterstützt, keine PFS | nein |
| mobile.de | A- | Zertifikat nutzt noch SHA1, RC4 wird noch unterstützt, keine PFS | nein |
| meinestadt.de | keine TLS-Unterstützung | nein |
Partei-Webseiten
| Domain | Bewertung | Anmerkungen | TLS obligatorisch? |
|---|---|---|---|
| piratenpartei.de | A | Zertifikat nutzt noch SHA1 | ja |
| gruene.de | A | nein | |
| alternativefuer.de | A- | Unterstützt keine PFS | nein |
| die-linke.de | A- | Zertifikat nutzt noch SHA1, keine PFS | nein |
| cdu.de | B | Zertifikat nutzt noch SHA1, keine PFS, keine Unterstützung von TLS 1.2 | nein |
| spd.de | F | Unterstützt SSL 2 und unsichere Chiffren, Zertifikat nutzt noch SHA1, keine PFS, keine Unterstützung von TLS 1.2 | nein |
| fdp.de | keine TLS-Unterstützung | nein |
Man sollte wenigstens hinzufügen, dass die Idee der kommerziellen CAs als gebrochen gesehen werden muss.
TLS basiert auf X.509, und das hat in der Standard-Ausführung einen Designfehler: gelingt es einem Angreifer, auch nur eine der vertrauten CAs zu übernehmen, so kann er beliebig Schlüssel ausstellen, denen alle vertrauen – auch welche im Beispiel HTTPS für Webseiten, die eigentlich mit einer anderen CA arbeiten.
Wer wissen will, welchen CAs sein Browser vertraut, kann das bei eigentlich allen nachschauen; bei Firefox ist’s in den Einstellungen Erweitert und Zertifikate. Klickt man dort “Zertifikate anzeigen”, so sieht man das Ausmass des Problems: beginnend mit “Türktrust” über das “China Internet Network Information Center” bis zu in den USA gehostete (und dadurch mit Patriot Act Section 215 zu zwingende) CAs ist auch alles vertreten, was nach Schlapphüten stinkt.
HTTPS könnte in modernen Varianten als sicher gelten – jedoch nicht so, wie es nun eben einmal in der Praxis vorkommt. Projekte wie CAcert http://www.cacert.org/ zeigen, dass es auch besser ginge. Was wir jedoch praktisch vorfinden, ist der Design-Teil der X.509-Katastrophe. Der Implementierungsteil dieser Katastrophe betrifft übrigens nicht nur OpenSSL – man schaue sich z.B. einmal den Backtrack von GnuTLS an.
Ein Nachtrag: http://pep-project.org verzichtet bewusst auf die kommerzielle Variante von HTTPS. Wer dennoch per TLS verbinden möchte, dem steht https://cacert.pep-project.org zur Verfügung.
Wir haben bewusst darauf verzichtet, HTTPS auf derselben Domain anzugeben, sondern eine Subdomain gewählt, damit das Benutzer tun können, die wissen, dass sie das CAcert Root-Zertifikat in den Browser laden müssen, damit der beim Zugriff nicht meckert, und damit wir allen anderen keine Sicherheit vor den Überwachern vorgaukeln, wo in Wirklichkeit keine ist.
Aktuelles Beispiel dafür, dürfte die Ausstellung von „falschen“ google-Zertifikaten durch indische CAs gewesen sein: http://www.heise.de/security/meldung/Indien-stellte-falsche-Google-Zertifikate-aus-2252544.html. Betraf aber wohl glücklicherweise nur die IE-Nutzer, Firefox listet diese CAs wohl gar nicht.
Auch wenn ich den Ansatz von CAcert noch nicht ganz verstanden habe, klingt es sehr interessant. Allerdings liesse sich hier gleich wieder monieren, dass CAcert in Australien gegründet wurde und z.B. auch spenden nur in Form von AU$ möglich sind – also mehr oder weniger starke Verflechtung mit einem Five Eyes Staat aufweist. Ich will kein Schelm sein, der böses denkt, aber manchmal hat man nur noch das Gefühl mit dem Rücken an allen 4 Wänden gleichzeitig zu stehen.
Jedes Bisschen Sicherheit hilft, je weniger Leute es aushebeln können desdo besser.
Man kann ja später mit DNSSEC/DANE noch eins draufsetzen aber dazu müssten die Webseiten mal anfangen.
Ich würde noch Heise, Gamestar, Golem , PCGames mit draufsetzen, denn diese PC-Affinen Seiten sollten erst recht komplett verschlüsseln, nicht nur die Logins.
Das sind die TOP 20 Seiten in Deutschland? Oh Mann, das es so schlimm ist, hätte ich jetzt nicht erwartet. Warum musstet ihr mich so mit der Realität konfrontieren?
Zumindest laut der „Arbeitsgemeinschaft Onlineforschung AGOF“, gemessen an den „gemeinsamen Nutzerzahlen einer Marke, bzw. eines Vermarkters auf stationären und mobilen Geräten“.
Schöner Test!
Ich habe das ganze mal mit den Internetseiten der derzeit populärsten deutschen Parteien gemacht:
(von gut nach schlecht)
1) Piratenpartei | piratenpartei.de | *A*
2) Bündnis 90/ Die Grünen | gruene.de | *A*
3) Alternative für Deutschland | alternativefuer.de | *A-*
4) Die Linke | die-linke.de | *A-*
5) CDU | cdu.de | *B*
6) SPD | spd.de | *F*
7) FDP | fdp.de | *No secure protocols supported*
Das spiegelt teilweise die Wichtigkeit von Netzpolitik innerhalb der einzelnen Parteien wider.
Großartige Idee! Ich nehm das mal in den Artikel auf :)
An welcher Stelle spiegelt dieses Ranking die Netzpolitik wieder? Während sich die AfD die Netzpolitik im Wahlprogramm weitestgehend schenkt, zählte die FDP zuletzt zu den Parteien, die sich stets gegen Netzsperren und für Netzneutralität, Datenschutz etc. ausgesprochen haben. Die Grünen halte ich auch nicht für die Vorreiter der Netzpolitik…
Beachte „teilweise“.
Natürlich sagt die Tabelle nicht viel über die Netzpolitik der Parteien aus.
Aber wenn man von anderen mehr Datenschutz erwartet, sollte man bei sich selber anfangen und als Vorbild dienen.
Anders gesagt: Wer mit dem Zeigefinger auf andere zeigt, zeigt mit 3 Fingern auf sich selber!
Die AfD meinte ich sicher nicht mit „teilweise“.
Was man ergänzen sollte: A ist nicht die höchste Wertung des Tests, die haben inzwischen A+ eingeführt. Dafür muss man SSL-only einsetzen und HSTS aktivieren. Macht offenbar von den erwähnten Seiten niemand.
Warum habt ihr die FPD getestet? Die gibts doch gar nicht mehr lol.
P.S. Die kack AfD und NPD fehlt. Von mir erhält die AfD und NPD schon mal die Note 88. Bitte braun hinterlegen, falls es so übernommen wird. Ansonsten, hier die Ergebnisse:
https://www.ssllabs.com/ssltest/analyze.html?d=alternativefuer.de (A-, kein PFS)
https://www.ssllabs.com/ssltest/analyze.html?d=npd.de (F, kein SSL/TLS)