OCSP-Stapling und Certificate Transparency

Certificate Revocation Lists (CRLs) sind von CAs veröffentlichte Dateien, in denen alle widerrufenen Zertifikate aufgeführt sind. CRLs haben mehrere Nachteile: Sie werden mit der Zeit groß, Clients müssen sie vollständig herunterladen, ihre Aktualität ist begrenzt, da sie nach einem Zeitplan veröffentlicht werden, und Browser haben bei fehlgeschlagener CRL-Abfrage historisch einen Soft-Fail durchgeführt, also Zertifikate akzeptiert. Dadurch war der Widerruf in der Praxis unzuverlässig.

Das Online Certificate Status Protocol (OCSP, RFC 6960) ermöglicht es Clients, den OCSP-Responder einer CA in Echtzeit nach dem Widerrufsstatus eines bestimmten Zertifikats abzufragen. Eine OCSP-Antwort gibt an, dass das Zertifikat "good", "revoked" oder "unknown" ist, und wird von der CA signiert. Das ist effizienter, als eine vollständige CRL herunterzuladen.

Standard-OCSP weist ein erhebliches Datenschutzproblem auf: Der Client muss den OCSP-Responder der CA mit der Seriennummer des zu prüfenden Zertifikats kontaktieren. Dadurch erfährt die CA oder ein Beobachter im Netzwerk, welche Websites die betreffende Person besucht und wann sie dies tut. So entsteht auf Ebene der Zertifizierungsstelle ein Überwachungsmechanismus, der die Privatsphäre der Nutzenden verletzt.

OCSP-Stapling (RFC 6066) löst das Datenschutzproblem, indem der Server die OCSP-Antwort vorab bei der CA abruft und zwischenspeichert. Während des TLS-Handshakes heftet der Server diese zwischengespeicherte Antwort an den Handshake an und übermittelt sie direkt an den Client. Der Client erhält einen aktuellen Widerrufsstatus, ohne die CA direkt zu kontaktieren.

Für die Konfiguration von OCSP-Stapling in Nginx benötigen Sie im Server-Block: "ssl_stapling on; ssl_stapling_verify on; resolver 8.8.8.8;". Der Block ssl_certificate_by_lua_block oder die Direktive ssl_trusted_certificate stellt die Kette für die Verifizierung bereit. Für Apache benötigen Sie "SSLUseStapling on" im VirtualHost. Beide Server speichern die Antwort zwischen und aktualisieren sie vor ihrem Ablauf.

Die OCSP-Must-Staple-X.509-Erweiterung (RFC 7633) teilt Browsern mit, dass der Server dieses Zertifikats immer eine OCSP-Antwort stapeln wird. Wenn ein Browser eine Verbindung zum Server herstellt und keine angeheftete Antwort erhält, weist er die Verbindung zurück. Dadurch wird verhindert, dass ein Angreifer mit einem widerrufenen Zertifikat OCSP-Antworten blockiert und so ein Soft-Fail-Verhalten erzwingt.

Certificate Transparency (CT) ist ein System, bei dem alle öffentlich vertrauenswürdigen CAs verpflichtet sind, jedes von ihnen ausgestellte Zertifikat vor dessen Auslieferung in öffentlich prüfbaren, ausschließlich erweiterbaren Logs zu protokollieren. Diese Logs ermöglichen es Domaininhabern, Forschenden und Überwachungsdiensten, für jede Domain falsch ausgestellte oder betrügerisch erlangte Zertifikate zu erkennen.

Wenn eine CA ein Zertifikat an ein CT-Log übermittelt, gibt das Log einen Signed Certificate Timestamp (SCT) zurück. Der SCT ist ein kryptografisch signiertes Versprechen, dass das Zertifikat protokolliert wurde. SCTs werden in das Zertifikat eingebettet, über eine TLS-Erweiterung übertragen oder in der OCSP-Antwort angeheftet. Chrome verlangt für das Vertrauen mindestens zwei SCTs.

Google Chrome verlangt seit April 2018 Certificate Transparency für alle öffentlich vertrauenswürdigen TLS-Zertifikate. Zertifikate ohne gültige SCTs werden von Chrome mit einem Zertifikatsfehler abgewiesen. Diese Anforderung erzwingt faktisch die CT-Protokollierung durch alle wichtigen CAs, da eine CA, deren Zertifikate von Chrome abgewiesen werden, nicht als öffentliche CA tätig sein kann.

CT-Logs ermöglichen es jeder Person, Zertifikate für die eigene Domain zu überwachen. Dienste wie crt.sh und Facebooks CT Monitor ermöglichen Domaininhabern, alle CT-Logs nach Zertifikaten zu durchsuchen, deren Subject- oder SAN-Felder die eigene Domain enthalten. Eine unbefugte Zertifikatsausstellung, etwa durch eine kompromittierte CA oder mittels BGP-Hijacking, wird innerhalb weniger Stunden erkennbar.

CT-Logs werden von mehreren unabhängigen Organisationen betrieben, darunter Google (Argon, Xenon), Cloudflare (Nimbus), DigiCert, Sectigo und andere. Mehrere Log-Betreiber verhindern, dass eine einzelne Instanz ein protokolliertes Zertifikat unterdrücken kann. Browser verlangen SCTs von Logs, die auf ihrer genehmigten Liste stehen, und stellen so die Qualität der vertrauenswürdigen Logs sicher.

Welches Problem löst OCSP-Stapling im Vergleich zu Standard-OCSP?

CRLs sind groß und veraltet; OCSP liefert den Widerrufsstatus in Echtzeit, gibt dabei aber Browserdaten an CAs preis. OCSP-Stapling übermittelt den vorab abgerufenen Widerrufsstatus während des TLS-Handshakes und schützt so die Privatsphäre. OCSP Must-Staple verhindert die Umgehung durch einen Soft-Fail. Certificate Transparency protokolliert alle ausgestellten Zertifikate und ermöglicht mithilfe von SCTs, falsch ausgestellte Zertifikate zu erkennen. Chrome verlangt CT seit 2018.