Worknote: Google Chrome Update und eine Frage zur Sicherheit

Für einen der Server bei uns am Institut, der (nur) via HTTPS erreicht werden soll, habe ich über das Deutsche Forschungsnetz (DFN) ein Zertifikat beantragt und installiert. Während zum Beispiel der Firefox nun die HTTPS-Verbindung zu diesem Server anstandslos akzeptiert, meckert Googles Chrome diese Verbindung als »unsicher« an (angeblich wegen SHA-1). Schaut man genauer nach und läßt sich in Chrome alle Zertifikate der Kette bis hinauf zur Telekom anzeigen, wird aber jedes einzelne dieser Zertifikate als gültig eingeschätzt. Hat einer von Euch da draußen eine Erklärung für dieses (für mich zumindestens verwirrende) Verhalten?

Und wo ich gerade bei Chrome bin, soll nicht unerwähnt bleiben, daß Google mit dem Update auf die Version 52 (52.0.2743.82) seines Browsers auch wieder mehrere Sicherheitslücken geschlossen hat. Chrome aktualisiert sich üblicherweise (außer bei Linux) über die integrierte Update-Funktion, kann aber auch hier geladen werden. (Mein persönlicher CERT per Email.)

[Update]: Es hat tatsächlich etwas mit SHA-1 zu tun. Seit Januar 2016 erachtet Google Chrome die SHA-1-Verschlüsselung für unsicher. Unglücklicherweise scheint das DFN aber noch nicht in der Lage zu sein, eine komplette SHA-2-Zertifizierungskette bereitzustellen. Die Angelegenheit drängt, da ab 2017 auch der Firefox SHA-1 nicht mehr unterstützen will. Und wenn dann in naher Zukunft SHA-2 auch nicht mehr als sicher eingestuft wird, werden wir alle auf SHA-3 umrüsten müssen. Man hat ja auch sonst nichts zu tun.

Ich muß (mal wieder) Dave Winer Recht geben: HTTPS ist ein teures Sicherheitstheater und ein Angriff auf das freie Web. Denn wer nicht eine EDV-Abteilung und so etwas wie den DFN-Verein im Rücken hat, der kann sich das ganze augenwischende Sicherheitsbrimborium gar nicht leisten.

---

3 (Email-) Kommentare

---

Ich bin zwar kein Experte und kann nur eine Vermutung anstellen. Hast Du die CA-Chain mit eingebunden? Im Apache gibt es dafür einen extra Parameter, im Nginx musst Du die CA-Chain mit dem Zertifikat per cat zusammenführen. Ähnlich wie unter http://inqbus-hosting.de/support/dokumentation/docs/ca-chain-im-webserver-nginx-einbauen
Ich hatte so ein ähnliche Phänomen, als ich eine alte CA-Chain mit neuem Zertifikat verwendet hatte. Die Zertifikatskette sollte auch beim DFN downloadbar sein.

– Mirko O. (Kommentieren) (#)

---

Rechner nach draussen durchstellen (aus dem Internet erreichbar), und dann https://www.ssllabs.com/ssltest/ mit "Do not show the results on the boards". Nach Konfigurationänderungen noch das cache-löschen Hakerl setzen. Sobald du dir ein "A+" erarbeitet hast, kannst du den "Do not show the results on the boards" weglassen! ;)
Webserverkonfigurationshilfe leistet https://mozilla.github.io/server-side-tls/ssl-config-generator/

– Peter F. (Kommentieren) (#)

---

Auch wenn ich mich wiederhole: HTTPS ist sinnvoll und auch kein Sicherheitstheater. Das CA-System ist das Problem und es ist definitiv Sicherheitstheater, wenn Browser einfach einen öffentlichen Schlüssel akzeptieren, nur weil irgendeine CA ihn signiert hat (oder sogar selbstsignierte Schlüssel anmeckern!)
Klar ist es schön einfach auf Nutzerseite so wie es momentan läuft. Aber sinnvoll wäre es stattdessen, auf selbst-signierte Schlüssel zu setzen und einfache Möglichkeiten zu bieten, diese Schlüssel zu verifizieren. Warum kann mir meine Bank nicht ihren Schlüssel auf Papier als QR-Code schicken oder zum Mitnehmen auslegen? Statt dessen muss ich allen CA vertrauen dass sie ihren Job korrekt machen und auch nicht irgendwelchen Geheimdiensten oder sonst jemanden auf dem Leim gegangen sind…

– Ingo K. (Kommentieren) (#)

---

(Kommentieren)