Die verborgenen Risiken der Zertifikatsperrung (CRL & OCSP)

Wenn ein privater TLS-Schlüssel durchgesickert oder kompromittiert ist, muss das Zertifikat vor Ablauf der Gültigkeit ungültig gemacht werden. Das kryptografische Ökosystem verlässt sich auf Zertifikatsperrlisten (CRL) und das Online Certificate Status Protocol (OCSP), um diese Ungültigkeit an Clients zu kommunizieren.

In verteilten Netzwerken ist es jedoch unglaublich schwierig, den globalen Zustand in Echtzeit aufrechtzuerhalten. Aus diesem Grund kommt es bei Sperrmechanismen häufig zu unsichtbaren Fehlern.

Wie die Sperrung zu funktionieren versucht

Eine CRL ist einfach eine große, gelegentlich aktualisierte Liste von Seriennummern, die eine CA gesperrt hat. Mit dem Wachstum des Internets wurde das Herunterladen riesiger Listen unhaltbar. OCSP wurde erfunden, um dies zu lösen, sodass Clients einen CA-Responder in Echtzeit abfragen können, um den Status zu prüfen.

Der Soft-Fail-Kompromiss

Die fatale Schwachstelle von OCSP ist Latenz und Zuverlässigkeit. Wenn ein Browser eine OCSP-Prüfung vor dem Laden verlangt und der Responder der CA offline oder durch eine Firewall blockiert ist, was passiert?

Wenn der Browser einen harten Fehler ausgibt (hard-fail), geht die Website wegen eines Drittanbieterausfalls offline. Um dies zu verhindern, implementierten Browser 'soft-fail'. Wenn der OCSP-Responder ein Timeout hat, nimmt der Browser an, das Zertifikat sei gültig.

Das bedeutet, ein Angreifer mit einem kompromittierten Zertifikat kann einfach die OCSP-Anfragen blockieren, einen Soft-Fail erzwingen und sich erfolgreich als Server ausgeben.

Verifizierung von OCSP Stapling

Die Lösung hierfür ist OCSP Stapling. Anstatt dass der Client die CA fragt, ruft Ihr Server asynchron eine signierte Antwort von der CA ab und 'heftet' (staples) sie an den TLS-Handshake.

Um zu prüfen, ob Ihr Server Antworten korrekt heftet, verwenden Sie OpenSSL:

openssl s_client -connect yourdomain.com:443 -status < /dev/null | grep -A 17 'OCSP response:'

Wenn 'OCSP response: no response sent' zurückgegeben wird, ist Ihr Stapling falsch konfiguriert, was die Validierungslast zurück auf Ihre Nutzer wirft.

Sicherstellung der Edge-Validierung

Das Verwalten von Stapling und das Bewerten von Vertrauensketten erfordert kontinuierliche externe Validierung. Heimdall Observer erzwingt systematisch eine tiefe TLS-Prüfung von mehreren Standpunkten aus, sodass Sie den Beweis erhalten, dass Ihre Endpunkte vertrauenswürdige Kryptografie bereitstellen.