Nun also auch Mozilla und Google: nachdem Apple bereits vor einiger Zeit vorangegangen ist, die Gültigkeitsdauer der HTTPS-Zertifikate zu begrenzen, ziehen jetzt Mozilla und Google nach. Diese generelle Diskussion ist schon seit einiger Zeit auf Thema im CA Browser Forum, dort stieß es bis zuletzt noch auf Widerstand seitens der CAs.
Konkret ist die Änderung: ab 01.09.2020 werden Zertifikate abgelehnt, deren Gültigkeitsdauer 398 Tage überschreitet. Bei Chromium ist die bisherige maximale Gültigkeitsdauer 825 Tage (ab 2018-03-01).
Als Argument für diese Verschärfung wird das als kaputte bezeichnete Widerrufsverfahren, implementiert durch CRLs und OCSP, aufgeführt.
Meinung
Während vor 10 Jahren Google gerade auf Default-HTTPS umstellte und die Wikpedia noch lediglich über https://secure.wikimedia.org/wikipedia/de/ HTTPS-Verschlüsselung bereitstellte, sieht das heute mittlerweile fundamental anders aus.
Mit Let's Encrypt ist auch das Kostenargument widerlegt worden, sodass es TLS-Zertifikate für die HTTPS-Verbindungen mittlerweile selbst als Beigabe bei Hostern oder CDNs gibt. Bereits bei Let's Encrypt war ich allerdings verwundert, warum die Zertifikate nur 90 Tage laufen. Automatisierung, so hieß es, löst das Problem.
Hieraus lässt sich der Trend erkennen, dass Zertifikate von Goldstaub, der teuer und aufwändig gekauft werden musste, zu Allerweltsgut werden. Und zwar durch kürzere Laufzeiten und die Reduktion auf das Wesentliche: eine Transportverschlüsselung zu einem Server mit einem DNS-Namen. Vielleicht werden wir irgendwann die Laufzeit von 1 Tag haben, so wie mir das bereits beim elektronischen Personalauweis bei den Berechtigungszertifikaten über den Weg gelaufen ist. (aber dort ist die Zielsetzung sicherlich auch anders, zudem weiß ich nicht, wie da der aktuelle Stand ist)
Schnell wechselnde Zertifikate sind nicht nur ein administrativer Aufwand (der sicherlich bei Automatisierung nur einmalig ist), sondern verbauen den Weg fürs praktikable Fingerprinting („hier der Fingerprint von meinem Cert, wenn der nicht mehr stimmt, dann stimmt vielleicht was nicht... ruf mich dann mal an“). Aber das wurde ja in der Implementierung durch Key Pinning mit HPKP schon länger abgekündigt. Von Extended Validation-Certs (bringen die noch optisch was?) ganz zu schweigen. Glückt einem Angreifer also ein DNS Spoofing-Angriff, so hat dieser leichteres Spiel, da die trivialen Warnmöglichkeiten wie das angesprochene Key Pinning nicht mehr Standard sind und Sperrlisten von den Browserherstellern gar nicht mehr als Weg betrachtet werden.
Es geht also zukünftig weniger um die Vorstellung eines Schutzes einer Verbindung zu einem Server mit einem DNS-Domainnamen einer Person/Organisation XYZ, sondern lediglich um das Wesentliche eines DV-Zertifikats: den Schutz einer Verbindung zu einem Server mit einem DNS-Domainnamen.
Aber ich drifte wohl zu sehr in die Intranet-Welt ab. Die soll das eh nicht so betreffen, da laut Apple eigens hinzugefügte CAs nicht von den neuen Regeln erfasst sein sollen. In Chrome ist das scheinbar ebenfalls so, jedenfalls, wenn dieses is_issued_by_known_root sich auf Public CAs bezieht (konnte das bisher auf die Schnelle nicht genau nachvollziehen, wurde aber in Kommentaren so angedeutet).
Ich kann beide Seiten verstehen. Bleibt die Frage, ob maximale Anforderungen auch die maximale Sicherheit mit sich bringt.
Jörg