Big Brother oder: Wie ich lernte, Verschlüsselung zu lieben

Big Brother oder

Wie ich lernte, Verschlüsselung zu lieben

Veit Hailperin
von Veit Hailperin
Lesezeit: 8 Minuten

Immer und immer wieder wird abgehört. Immer und immer wieder hört man von Angriffen auf Verschlüsselung, und dann auch nach ein Zertifikatsdebakel nach dem anderen.

Zertifiziert sicher

Aber nur weil Angriffe auf Verschlüsselung und deren Umsysteme passieren, heisst es nicht, dass die Lösung so schwierig ist, wie sie manchmal scheint – verschlüsseln und korrekt konfigurieren ist alles was nötig ist. Die Hauptherausforderung ist das fehlende Wissen, was es zu tun gilt und nicht in eines der vielen möglichen Konfigurationsfettnäpfchen zu tappen. Dabei helfen diverse Webseiten, die versuchen, das Wissen darüber zu verbreiten. Ich verzichte darauf, zu erklären, warum Verschlüsselung wichtig ist. Wer dies liest, ist vermutlich über diesen Status hinaus.

Die Cipher und Protokolle

Die Cipher sind die grösste Quelle für Fehlkonfiguration. Kryptographisch schwache Cipher, zu kurze Cipher, zu kleine Diffie-Hellman Groups, veraltete, unsichere Protokolle und die Liste geht weiter. Glücklicherweise ist bekannt, dass dies häufig falsch gemacht wird und so gibt es gleich zwei gute Webseiten, die Administratoren, egal ob privat oder geschäftlich, helfen.

Zum einen gibt es Cipherli.st, welche gute Konfigurationen und Erklärungen dazu gibt. Die unterstützten Produkte sind Apache, nginx, Lighthttpd, Postfix, Exim, Zarafa, und viele mehr.

Wer seine eigene Konfiguration testen möchte, zumindest die von Web Servern, welche Zugang zum Web haben, empfiehlt sich Ivan Ristic’s SSL Labs. Diese Plattform liefert eine schnelle und gute Übersicht über die aktuelle Situation, der TLS/SSL Konfiguration.

Wer besser verstehen möchte wieso was wie zu konfigurieren ist, liest am besten Michael Schneiders Artikel Transport Layer Security richtig konfigurieren.

Verkehr weiterleiten nach 443

Oft sind Webseiten in verschlüsselter und unverschlüsselter Version vorhanden. Ein Benutzer muss ein bisschen Glück gehabt haben, und einmal auf die verschlüsselte Version zugegriffen haben, um zu realisieren, dass es sie gibt. Hat der Benutzer dann noch die HTTPS Everywhere-Extension installiert, so greift der Browser in Zukunft auf die verschlüsselte Variante zu. Als Serverbetreiber sollte man den Benutzer darin allerdings unterstützen und eine Weiterleitung von der unverschlüsselten Version auf die verschlüsselte Variante automatisch durchführen. Damit ist die Schwierigkeitsstufe für Angreifer schon etwas erhöht.

Es gibt allerdings ein weiteres Problem. Jedes Mal, wenn der Benutzer die Webseite besucht, wird – davon ausgehend, dass die meisten Benutzer kein HTTPS Everywhere haben und http in die URL eingeben – diese Weiterleitung ausgeführt. Ein Angreifer kann also jedes Mal erneut einen Man-in-the-Middle Angriff am Anfang durchführen und SSL entfernen. Dieser Angriff ist als SSL-Strip-Attack bekannt. Zu dessen Verhinderung kann ein Browser seitens Server instruiert werden, von nun an immer per HTTPS zuzugreifen. Dies geschieht mit dem Strict-Transport-Security Header.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Dabei steht max-age für die Gültigkeit des Headers in Sekunden. Grob gesagt gilt: Je länger desto besser. includeSubDomains und preload sind Optionen. includeSubDomains sorgt dafür, dass auch bei Subdomains grundsätzlich nur per HTTPS auf die Seite zugegriffen wird. preload sorgt dafür, dass man sich auf der Preloadliste Google Chromes aufnehmen lassen kann. Ist eine Domain eingetragen, so greift der Browser von Anfang an nur per HTTPS auf die Domain zu. Die Liste wird auch von Firefox, Safari, Internet Explorer 11 und Microsoft Edge verwendet.

Das Zertifikat

Eines der Argumente, die man gegen verschlüsselte Kommunikation hört, ist, dass es Geld kostet sich ein Zertifikat zu leisten. Insbesondere von Non-Profit-Organisationen hört man dies. Es ist noch frisch, aber es gibt inzwischen eine Certificate Authority (CA), die kostenlos ist und im Gegensatz zu CAcert auch von allen wichtigen Browsern akzeptiert wird. Die Certificate Authority heisst Let’s Encrypt. Sie bringt eine freie, automatisierte CA, welche von einer Gruppe von Enthusiasten betrieben wird. Andere Certificate Authorities sind bereits am Nachziehen und stellen Zertifikate kostenlos aus. Einige Fehler mit Wildcard-Zertifikaten und Extended Validation können mit Let’s Encrypt nicht gemacht werden, da diese Dinge nicht unterstützt werden. Das Gleiche gilt für MD5- und SHA-1-signierte Zertifikate. Auch wird standardmässig eine Minimallänge von 2048 bit verwendet, und 4096 bit ist möglich. Durch das mitgelieferte Skript wird darauf geachtet, dass die Zertifikate auch nicht auslaufen sondern in kurzen Abständen erneuert werden.

Zusammen mit den Schmetterlingen abgeheftet

Wer ein sauberes Zertifikat und eine gute Cipher- und Protokollkonfiguration hat, ist einen wesentlichen Schritt weiter gegenüber unverschlüsselter Kommunikation. Es gibt aber eine weitere Sache zu beachten: Solange das Zertifikat von einer gültigen CA für die Webseite ausgestellt sind, ist es für einen Benutzer nicht möglich, zu unterscheiden, ob jemand diese unerlaubterweise, wie im Fall von Google und Symantec, ausgestellt hat oder ob das Zertifikat tatsächlich gültig ist. Die Lösung hierfür ist der neue HTTP Response Header Public-Key-Pinning. Die einzige Art, diesen sinnvoll zu umgehen, ist während des allerersten Handshakes. Anschliessend bindet/heftet (english: to pin) der Browser die kryptographische Identität des Server an die URL und speichert diese lokal ab. Sollte ein Angreifer versuchen, einen Man-in-the-Middle Angriff durchzuführen, selbst mit einem gültigen Rogue-Zertifikat, so erkennt der Browser dies.

Public-Key-Pins: max-age=5184000; pin-sha256="base64-kodierter-SPKI-Fingerprints" [; includeSubdomains][; report-uri="URI"]

Zusätzlich kann man die Option includeSubdomains setzen. Diese setzt dann den Header und die SPKI, analog zum Strict-Transport-Security Header, auch für die Subdomains durch. Das RFC definiert auch eine Option, die Fehler oder potentielle Angriffe direkt meldet. Dies geschieht über die Option report-uri=URI.

Weiterführende Notizen zu Public-Key-Pinning finden sich auf der Entwicklerseite Mozillas.

Über den Autor

Veit Hailperin

Veit Hailperin arbeitet seit 2010 im Bereich der Informationssicherheit. Seine Forschung konzentriert sich auf Network und Application Layer Security sowie auf den Schutz der Privatsphäre. Die Resultate präsentiert er an Konferenzen.

Links

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

×
Konkrete Kritik an CVSSv4

Konkrete Kritik an CVSSv4

Marc Ruef

Das neue NIST Cybersecurity Framework

Das neue NIST Cybersecurity Framework

Tomaso Vasella

Angriffsmöglichkeiten gegen Generative AI

Angriffsmöglichkeiten gegen Generative AI

Andrea Hauser

iOS Mobile Application Testing

iOS Mobile Application Testing

Ian Boschung

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv