Wenn Sie sich schon einmal mit Cybersicherheit beschäftigt haben, kennen Sie wahrscheinlich die goldene Regel: „Immer HTTPS in der Produktion verwenden“. Sie gilt als Standard für sichere Webkommunikation, und das aus gutem Grund: HTTPS verschlüsselt Daten während der Übertragung. Anders ausgedrückt: HTTPS schützt sensible Informationen vor Abhören. Doch bei Public Key Infrastructure (PKI), insbesondere bei der Verwaltung von Zertifikatssperrungen, gilt diese Regel nicht immer. Bei Encryption Consulting nutzen wir unsere umfassende Erfahrung aus der Zusammenarbeit mit Fortune 500-Unternehmen, staatlichen Auftraggebern und Cloud-nativen Unternehmen, um robuste PKI-Systeme zu entwickeln. Eine Frage, die uns oft gestellt wird, lautet: „Sollten wir nicht HTTPS für unsere Widerrufsendpunkte, wie CRLs und OCSP?“
Die Antwort mag Sie überraschen: In diesen Fällen richtet HTTPS oft mehr Schaden als Nutzen an. Lassen Sie uns untersuchen, warum HTTP in PKI für Sperrendpunkte die bessere Wahl sein kann.
Widerrufsinformationen werden von der Zertifizierungsstelle digital signiert
Wenn ein Zertifikat widerrufen wird, beispielsweise aufgrund eines kompromittierten Schlüssels oder einer Richtlinienverletzung, Zertifizierungsstelle (CA) muss die vertrauenden Parteien benachrichtigen. Dies geschieht über zwei Hauptmethoden. Zertifikatsperrlisten (Certificate Revocation Lists, CRLs) sind signierte Dateien, die regelmäßig veröffentlicht werden und alle widerrufenen Zertifikate auflisten. Alternativ bietet das Online Certificate Status Protocol (OCSP) Echtzeit-Statusprüfungen für einzelne Zertifikate. Beide Methoden haben gemeinsam, dass die Zertifizierungsstelle sie kryptografisch signiert. Diese Signatur gewährleistet die Authentizität und Integrität der Daten, unabhängig davon, ob sie über HTTP, HTTPS oder sogar einen herkömmlichen USB-Stick übermittelt werden.
Wenn jemand versucht, eine CRL- oder OCSP-Antwort während der Übertragung zu manipulieren, schlägt die Validierungsprüfung der vertrauenden Partei fehl und die Daten werden sofort abgelehnt. Was bringt HTTPS in diesem Zusammenhang? In den meisten Fällen nicht viel.
Unerwartete Risiken von HTTPS in PKI
Sie fragen sich vielleicht, warum HTTPS angesichts seiner Sicherheitsvorteile nicht die Standardeinstellung ist. Die Antwort liegt in einem subtilen, aber kritischen Problem, das in RFC 5280, der Standard für X.509-Zertifikate und CRLs. Dieser Standard rät von der Verwendung von HTTPS für Zertifikatsverteilungspunkte (Certificate Distribution Points, CDPs) oder AIA-Felder (Authority Information Access, AIA) ab. Das Problem ist eine sogenannte zirkuläre Abhängigkeit in dem Szenario, in dem der CRL- oder OCSP-Endpunkt über HTTPS gehostet wird. Dieser HTTPS-Dienst benötigt ein Zertifikat, um Vertrauen aufzubauen. Um ein Zertifikat zu validieren, muss eine vertrauende Partei dessen Widerrufsstatus überprüfen.
Wenn der Widerrufsstatus jedoch auf demselben HTTPS-Endpunkt gehostet wird, geraten wir in eine Endlosschleife. RFC 5280 bezeichnet dies als „unbegrenzte Rekursion“ und stellt kein bloßes theoretisches Problem dar. Vielmehr kann es zu Validierungsfehlern in der Praxis führen, Vertrauensketten unterbrechen und Dienste stören.
Wir haben dieses Problem bei einem Kunden aus dem Bundesdienst beobachtet, der strenge Compliance-Anforderungen des US-Verteidigungsministeriums und der FedRAMP-Verordnung erfüllen musste. Die Sicherheitsrichtlinie sah die Verwendung von HTTPS für alle Endpunkte vor, einschließlich CRLs und OCSP Responder. Leider führte diese Konfiguration zu Zertifikatvalidierungsfehlern während TLS-Handshakes, was zu kaskadierenden Fehlern in ihren Firewalls und Diensten führte. So fatal kann diese zirkuläre Abhängigkeit sein. In diesem Fall wurde sie speziell durch die HTTPS-gehosteten Widerrufsendpunkte verursacht. Durch die Neugestaltung ihrer Infrastruktur zur Bereitstellung signierter CRLs und OCSP-Antworten über einfaches HTTP konnten wir die Rekursionsschleife beseitigen und die Funktionalität wiederherstellen, ohne die Sicherheit oder Compliance zu beeinträchtigen.
Auf unserer PKI-as-a-Service-Plattform verfolgen wir einen ähnlichen Ansatz und stellen Sperrdaten über HTTP mit eingebetteten Signaturen und strengen Caching-Kontrollen bereit. Dies vereinfacht die Validierung in Cloud-Umgebungen und verhindert ähnliche Fehler.
Wann HTTPS die richtige Wahl sein könnte
Es gibt Szenarien, in denen HTTPS für Sperrendpunkte sinnvoll sein kann, diese erfordern jedoch sorgfältige Planung und Überlegung. Wenn Sie beispielsweise Datenschutzbedenken haben und beispielsweise Metadatenlecks verhindern möchten, die offenlegen, welche Zertifikate geprüft werden, können Sie mit HTTPS OCSP-Anfragen und -Antworten verschlüsseln. HTTPS ist auch in streng kontrollierten Umgebungen mit fixierten Zertifikaten sinnvoll, da Sie so sicherstellen können, dass der Sperrstatus des HTTPS-Zertifikats über einen separaten, unabhängigen Pfad validiert wird. Eine weitere Möglichkeit ist die Out-of-Band-Validierung, um zirkuläre Abhängigkeiten gänzlich zu vermeiden. Diese Fälle sind jedoch die Ausnahme und erfordern eine sorgfältige Architektur, um neue Risiken zu vermeiden.
Eine intelligentere Alternative ist OCSP-Stapling
Wenn Sie Live-OCSP-Lookups vollständig umgehen möchten, gibt es eine bessere Option: OCSP-HeftenDieser Ansatz ermöglicht es dem Server, eine OCSP-Antwort abzurufen, zwischenzuspeichern und sie dann während des TLS-Handshakes an das Zertifikat anzuheften. Dadurch entfällt für Clients die Notwendigkeit, einen OCSP-Responder direkt abzufragen. Dies verbessert die Leistung durch Reduzierung externer Aufrufe, erhöht den Datenschutz durch serverseitige Speicherung der Validierungsdetails und erhöht die Ausfallsicherheit, falls der OCSP-Responder vorübergehend nicht verfügbar ist.
Wie Verschlüsselungsberatung PKI für Sie nutzbar macht
Bei Encryption Consulting sprechen wir nicht nur über Standards, wir entwickeln Systeme, die diese in die Praxis umsetzen. Egal, ob Sie Microsoft ADCS, die Nutzung von Cloud-basierten CAs wie AWS Private CA oder Azure Key Vault, die Verwendung von Open-Source-Lösungen wie EJBCA oder die Einführung unserer PKI-as-a-Service Plattform sorgen wir für die Sicherheit und Zuverlässigkeit Ihrer Widerrufsinfrastruktur. Wir entwickeln Systeme, die signierte Widerrufsdaten über HTTP bereitstellen, ohne die Validierung zu unterbrechen, implementieren hochverfügbare OCSP- und CRL-Responder und integrieren Widerrufsprüfungen in CI/CD-Pipelines und Zero-Trust-Umgebungen. Unsere CertSecure Manager Die Plattform automatisiert die Verwaltung des Zertifikatslebenszyklus und sorgt so für einen reibungslosen Ablauf Ihrer Abläufe. Vor allem helfen wir Ihnen, zirkuläre Vertrauensschleifen zu vermeiden, indem wir alle HTTPS-Endpunkte sorgfältig und unabhängig validieren.
Fazit
Bei PKI geht es bei der Sicherheit nicht nur um Verschlüsselung; es geht darum, sicherzustellen, dass Daten signiert, vertrauenswürdig und zugänglich sind, ohne die Vertrauenskette zu unterbrechen. HTTPS hat seine Berechtigung, aber für den Widerruf von Zertifikaten ist HTTP oft zuverlässiger. Bei Encryption Consulting entwickeln wir PKI Systeme, die ein Gleichgewicht zwischen Standards und realer Leistung herstellen und Ihnen dabei helfen, Fallstricke zu vermeiden, die die Betriebszeit oder die Konformität beeinträchtigen könnten.
Bereit für eine zukunftssichere PKI? Kontaktieren Sie unsere PKI-Experten unter info@encryptionconsulting.com oder besuchen Sie uns. https://www.encryptionconsulting.com um herauszufinden, wie wir Ihnen helfen können.
