Viele von euch kennen vielleicht die Seite SSLLabs.com, bei der sich die Einstellungen bezüglich TLS testen lassen. Wer wissen möchte, wie gut die Daten auf einer verschlüsselten Webseite geschützt sind, kann den Namen eingeben und SSLabs führt dann verschiedene Tests durch. Nach Beendigung gibt die Seite eine Einschätzung aus.
Nun ist TLS nicht die einzige Baustelle, was die Sicherheit im Web betrifft. Es gibt zahlreiche Schwachstellen, die ausgenutzt werden. Für einige dieser Schwachstellen wurden neue HTTP-Header eingeführt.
So gibt es beispielsweise einen, der dem Browser auffordert, die Seite ausschließlich über HTTPS aufzusuchen (HSTS). Die meisten aktuellen Browser unterstützen den Header. Daneben gibt es Header, die Schutz vor so genanntem Cross-Site-Scripting (XSS) bieten sollen sowie weitere mehr.
Die Seite securityheaders.io hat es sich zum Ziel gemacht, die Header der Webseiten zu testen und ein ähnliches Rating wie SSLLabs auszugeben. Auch hier erhaltet ihr einen schnellen Überblick über die Sicherungsmaßnahmen. Allerdings habe ich Einstellungen gefunden, wo das Rating aus meiner Sicht nicht gerechtfertigt ist. Die Seite hatte HSTS gesetzt und erhielt trotzdem nur ein sehr schlechtes Rating. Laut Aussage der Entwickler sind die aber dabei, das zu ändern. Testet die Seite doch mal aus!
Meine Seite hat derzeit folgendes Rating:
Wie ihr seht, fehlt derzeit CSP und das Key Pinning. Bei letzterem lässt sich aus meiner Sicht viel falsch machen. Da will ich erstmal noch ein paar Gedanken reinstecken, bevor ich den setze. Und CSP muss ich testen, inwieweit das mit dem Blog Probleme gibt. Wenn das passiert ist, steht einem A+ nichts mehr im Wege.
Die Anonymisierungssoftware Tor bietet neben vielen nützlichen Anwendungen auch Risiken in sich. In der Vergangenheit haben diverse Leute versucht, Passwörter anderer Nutzer auszulesen oder sonst an geheime Informationen zu kommen. Heute stieß ich beim Surfen auf einen Exit-Knoten, der falsche SSL-Zertifikate präsentiert. Damit ließe sich die sonst geschützte Kommunikation von dritter Seite mitlesen, ohne das man selbst etwas davon merkt. Der Knoten trägt den Namen JustANode
mit der IP-Adresse 89.138.155.193 und läuft unter Windows XP. Offensichtlich läuft dort das Finjan Secure Web Gateway, welches sich für Active Real-Time Content Inspection rühmt. Ich hoffe, der Knoten bekommt schnellstens ein BadExit-Flag. Das schützt andere Tor-Nutzer davor, diesen zufällig zu nutzen.
Wenn du selbst mal in den Genuss kommen willst, kannst du folgendes probieren. Allerdings solltest du wissen, was du tust und auf keinen Fall schützenswerte Daten über die Leitung schicken!
- Stelle sicher, dass Tor installiert ist und funktioniert (eventuell hilft das Tor-Browser-Paket).
- Wähle eine SSL-Seite (https://torproject.org oder https://www.ccc.de sind zwei Möglichkeiten.)
- Gib in die Adresszeile des Browsers die URl gefolgt von .JustANode.exit ein: https://www.example.com.JustANode.exit/.
- Wirf einen genauen Blick auf das präsentierte Zertifikat.
Das Beispiel zeigt mal wieder, dass man beim Surfen im Web immer die Augen und das Gehirn offen halten sollte.
Vor vielen Jahren berichtete ich über Banken, die sicheres Login (SSL) abschalten. Sebastian twitterte über Truecrypt, die den Aufruf von https://truecrypt.org auf die HTTP-Seite umleiten. Gerade TrueCrypt als Anbieter von Sicherheitslösungen (Verschlüsselung der Festplatte) ist da ein schlechtes Beispiel. Einige weitere Beispiele nannte Sebastian in einer weiteren Nachricht. Ich habe das mal auf der Seite BadHTTPS gesammelt. Wenn euch weitere Beispiele einfallen, so hinterlasst entweder hier einen Kommentar oder schreibt es direkt auf die obige Wikiseite. Es wäre sehr interessant, weitere Beispiele zu kennen. Solch eine Sammlung liess sich in einem weiteren Schritt nutzen, um die betreffenden Firmen anzusprechen und auf eine Verbesserung der Situation hinzuwirken.
Heute haben 38 Akademiker und Forscher einen offenen Brief (HTML-Version)an den CEO von Google, Eric Schmdit, geschrieben. So fordern auf sechs Seiten (plus zwei Seiten Fußnoten) die Standardnutzung von HTTPS und somit adäquate Sicherheit und den Schutz der Privatsphäre für die Nutzer.
Aus der Zusammenfassung:
Google already uses industry-standard Hypertext Transfer Protocol Secure (HTTPS) encryption technology to protect customers’ login information. However, encryption is not enabled by default to protect other information transmitted by users of Google Mail, Docs or Calendar. As a result, Google customers who compose email, documents, spreadsheets, presentations and calendar plans from a public connection (such as open wireless networks in coffee shops, libraries, and schools) face a very real risk of data theft and snooping, even by unsophisticated attackers. Tools to steal information are widely available on the Internet.
Google supports HTTPS encryption for the entire Gmail, Docs or Calendar session. However, this is disabled by default, and the configuration option controlling this security mechanism is not easy to discover. Few users know the risks they face when logging into Google’s Web applications from an unsecured network, and Google’s existing efforts are little help.
Support for HTTPS is built into every Web browser and is widely used in the finance and health industries to protect consumers’ sensitive information. Google even uses HTTPS encryption, enabled by default, to protect customers using Google Voice, Health, AdSense and Adwords. Google should now extend this degree of protection to users of Gmail, Docs and Calendar.
Rather than forcing its customers to “opt-in” to adequate security, Google should make security and privacy the default.