Skip to main content

Web Security Part 1: OCSP

Web Applikationen sind aus unserem Alltag nicht mehr wegzudenken und ersetzen native Applikationen in allen Bereichen der Wirtschaft aber auch in der privaten Anwendung. Keine App oder Social Network funktioniert heute noch ohne diese Technologien. Auch die Angriffsfläche, die Web Applikationen Angreifern bieten, sind sehr umfangreich und teilweise sehr einfach ausnutzbar.

Dennoch fällt es nach wie vor vielen Unternehmen schwer, die Auswirkungen und Risiken, welche durch Schwachstellen und fehlender Abwehrmassnahmen in Webapplikationen bestehen, korrekt einzuschätzen.

Aus diesem Grund werden wir in den nächsten Monaten mit der Blog-Serie: Web Security auf einige Themen zu Web Application Security eingehen.

OCSP & OCSP Stapling

OCSP steht für «Online Certificate Status Protocol» und wird von Certificate Authorities (CA) verwendet, um den Wiederruf ausgestellter x509 Zertifikate zu überwachen. Dabei können Clients wie z.B. Betriebssysteme, Applikationen oder Browser per OCSP Protokoll den Status eines Zertifikates bei einem Validierungsdienst abfragen. OCSP löst die bereits in die Jahre gekommenen CRL (Certificate Revocation Lists) ab und bietet einige Vorteile.

Wie funktioniert OCSP?

Wenn eine SSL/TLS geschützte Verbindung zu einem Webserver aufgebaut wird, liefert der Webserver als erstes das Webserver x509 Zertifikat an den Client oder Browser aus. In diesem Zertifikat ist eine CRL oder ein OCSP Responder (oder beides) in den Zertifikatseigenschaften hinterlegt. Wenn der Client darauf konfiguriert ist, bevorzugt er die Validieren des Zertifikates per OCSP Protokoll. Daraufhin kontaktiert der Client den OCSP Responder mit der Angabe der Seriennummer des Zertifikates und verlangt dessen Überprüfung. Der OCSP Responder prüft das Zertifikat entweder direkt in der CA Datenbank oder in einer CRL Liste und gibt dem Client entweder den Status Good (Nicht revoziert) oder revoked (revoziert).

Vor- und Nachteile von OCSP und CRLs

Zertifikats- Sperrlisten werden nur in grösseren Zeitlichen Abständen erstellt und veröffentlicht und sind damit nicht immer aktuell. OCSP Abfragen werden zumeist pro Zertifikat ausgestellt und können dadurch sekundengenaue Antworten liefern. OCSP kann auch gefälschte Zertifikate von gültigen Zertifikaten unterscheiden und erkennen, sofern der OCSP Responder von der CA darauf konfiguriert wurde.

Beim Einsatz von Sperrlisten, sogenannten Certificate Revocation Lists (CRL) werden alle revozierten Zertifikate anhand der Seriennummer in dieser Liste aufgeführt. Dies führt zu relativ grossen CRL Dateien, welche auf jedem Client heruntergeladen werden. Dies macht die Anwendung vor allem für IoT Geräte und andere Geräten mit limitiertem Speicher ineffizient und langsam, denn es muss bei jeder Abfrage die gesamte Datei geprüft werden.

Ein weiterer Nachteil von OCSP ist, dass der Client bei jedem Aufruf einer Seite von einem Webserver eine Anfrage an eine dritte Partei ausführt, den Zertifikatsaussteller (CA). Dies verlangsamt nicht nur den Aufruf der Webseite sondern ist auch Datenschutztechnisch bedenklich, da dem Aussteller mitgeteilt wird, welches Zertifikat und damit welche Webseite abgefragt wird.

Um dies zu verhindern, wurde mit RFC6066 (https://tools.ietf.org/html/rfc6066) OCSP Stapling eingeführt.

OCSP Request

Im folgenden OCSP Request sehen wir die Anfrage an die CA per ermitteltem OCSP Protokoll. Im Request sieht man Angaben zum abgefragten Zertifikat und die Nonce Erweiterung, welche wir später erklären.

OCSP Response

Im folgenden OCSP Response sehen wir die Antwort der CA mit dem Zertifikatsstatus: good. Dies bedeutet das Zertifikat wurde nicht zurückgezogen (revoked) aber keinen Hinweis auf den Nonce.

Was ist OCSP Stapling?

Bei OCSP ist der Client (Browser Agent) dafür Verantwortlich, den Zertifikats Status bei der CA abzufragen. Diese Abfragen können sowohl eine Verzögerung beim Aufruf mit sich ziehen, als auch eine Privacy Verletzung darstellen, da durch diese Abfrage der CA Anbieter in der Lage ist, die Webseiten Aufrufe mit zu protokollieren. Daher wurde die alternative Variante des OCSP Stapling eingeführt.

Beim initiieren des TLS Handshakes mit dem Webserver kann dieser in der Antwort die OCSP Validation Message mit dem Zertifikat mitsenden. Damit kann die Anfrage vom Client schneller abgeschlossen werden. Der Webserver agiert als eine Art Proxy für die OCSP Abfrage.

Dabei stellt der Webserver oder Reverse Proxy die OCSP Anfrage an den OCSP Responder und Cached die Antwort entsprechend den Einstellungen nach und beschleunigt damit die Antworten an den Client weiter.

Wie kann man den OCSP Status prüfen?

Das Prüfen des OCSP Status ist realtiv einfach durchzuführen. Für die Abfrage einer korrekten OCSP Stapling Funktion werden einige weitere Schritte notwendig. Wir verwenden in unseren Beispielen das Linux Tool openssl, die Kommandos könnten z.B. aber auch mit curl ausgeführt werden.

OCSP Stapling Traffic Capture

In diesem Traffic Capture sieht man, dass bei OCSP Stapling keine separate OCSP Verbindung zum OCSP Responder aufgebaut wird, sondern dass die Antwort des Zertifikatsstatus in die TLS Bestätigung des Webservers implementiert ist.

Schritt 1

Zuerst muss das Server Zertifikat vom Webserver abgefragt werden

openssl s_client -connect clue.ch:443 < /dev/null 2>&1 |  sed -n ‹/—–BEGIN/,/—–END/p› > certificate.pem
Schritt 2

Da SSL Zertifikate in der Regel nie von der Root CA direkt signiert werden, sondern von einer Sub-CA, fragen wir die vollständige Zertifikatskette ab.

Das erste Zertifikat in der Kette ist das Server Zertifikat, wir entfernen es aus der Datei chain.crt

openssl s_client -showcerts -connect clue.ch:443 < /dev/null 2>&1 |  sed -n ‹/—–BEGIN/,/—–END/p› > chain.crt
Schritt 3

Nun lesen wir den zuständigen OCSP Responder für das Server Zertifikat aus.

openssl x509 -noout -ocsp_uri -in certificate.pem

http://ocsp.sectigo.com
Schritt 4

Wir haben nun das Server Zertifikat, die Zertifikatskette und den zuständigen OCSP Responder ermittelt. Nun kann eine Anfrage an den Service durchgeführt werden

Die Angabe des Host Headers ist speziell für neuere OCSP Responder erforderlich, da diese nicht per HTTP 1.0 Protokoll funktionieren.

openssl s_client -connect clue.ch:443 < /dev/null 2>&1 |  sed -n ‹/—–BEGIN/,/—–END/p› > certificate.pem
Schritt 5

Nun können wir das Ergebnis validieren. Der Zertifikatsstatus kann good oder revoked sein.

OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: 430BD20E4F137A1A6C918F24E5DA7E324D4733C8
          Issuer Key Hash: 8D8C5EC454AD8AE177E99BF99B05E1B8018D61E1
          Serial Number: 9C0E54F3A3DF8731F82F8237A5A3F878
    Request Extensions:
        OCSP Nonce: 
            04101518B5072B8762A2FC7EC37D7CDB32BD
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: 8D8C5EC454AD8AE177E99BF99B05E1B8018D61E1
    Produced At: Feb 19 01:45:49 2021 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 430BD20E4F137A1A6C918F24E5DA7E324D4733C8
      Issuer Key Hash: 8D8C5EC454AD8AE177E99BF99B05E1B8018D61E1
      Serial Number: 9C0E54F3A3DF8731F82F8237A5A3F878
    Cert Status: good
    This Update: Feb 19 01:45:49 2021 GMT
    Next Update: Feb 26 01:45:49 2021 GMT
Schritt 6

Nun konnten wir validieren, dass das Zertifikat für OCSP konfiguriert ist und die Abfrage des OCSP Status bei der CA erfolgreich durchgeführt werden konnte. In diesem Schritt werden wir den OCSP Stapling Prozess durch den Webserver abfragen.

openssl s_client -connect cdn.clue.ch:443 -servername cdn.clue.ch -tls1_2 -tlsextdebug -status

 

OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: 8D8C5EC454AD8AE177E99BF99B05E1B8018D61E1
    Produced At: Feb 19 01:45:49 2021 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 430BD20E4F137A1A6C918F24E5DA7E324D4733C8
      Issuer Key Hash: 8D8C5EC454AD8AE177E99BF99B05E1B8018D61E1
      Serial Number: 9C0E54F3A3DF8731F82F8237A5A3F878
    Cert Status: good
    This Update: Feb 19 01:45:49 2021 GMT
    Next Update: Feb 26 01:45:49 2021 GMT

Mögliche Fehlerursachen

Nonce

Möglicherweise erhalten wir in unserer Antwort einen Fehler: WARNING: no nonce in response

Die Warnung weist darauf hin, dass unser Openssl Befehl einen nonce als Schutz gegen Replay Attacken mitgegeben hat, der Server diesen in seiner Antwort aber nicht bestätigt hat. Dies passiert in der Regel weil Certificate Authorities aus Performance Gründen die Antwort Zeiten für OCSP Anfragen so kurz wie möglich halten möchten.

In dem Fall, dass die nonce Protection nicht korrekt von der CA beantwortet wird, kann per Openssl die Anfrage ohne nonce mit dem -no_nonce switch ausgeführt werden.

openssl ocsp -no_nonce -issuer chain.crt -cert certificate.pem -text -url http://ocsp.sectigo.com -header «HOST» «ocsp.sectigo.com»

OCSP Antwort abgelaufen

Des öfteren sieht man bei der Überprüfung der OCSP Konfiguration den Status OCPS Stapling ok, aber zusätzlich auch Fehlermeldungen wie «OCSP Response Expired». Dies weist darauf hin, dass OCSP Stapling konfiguriert ist, der Webserver oder Reverse Proxy aber den aktuellen Status nicht von der CA abfragen kann. Gründe hierfür könnte eine eingeschränkte Netzwerkkommunikation, eine Störung beim OCSP Responder oder auch ein fehlendes Vertrauensverhältniss zur CA anhand der x509 Zertifikatskette sein.

Vertrauensverhältnis OCSP Responder

Die Abfrage des OCSP Services erfolgt per HTTP Protokoll. Dennoch wird eine signierte Antwort als OCSP zurückgegeben. Dabei verwenden manche CA’s die selbe Zertifikatskette um den OCSP Responder zu signieren, andere verwenden aber eine separate Zertifikatskette, wie z.B. die GoDaddy CA.

OCSP Response von Sectigo (Comodo)
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: 8D8C5EC454AD8AE177E99BF99B05E1B8018D61E1
Produced At: Feb 20 23:45:48 2021 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 430BD20E4F137A1A6C918F24E5DA7E324D4733C8
Issuer Key Hash: 8D8C5EC454AD8AE177E99BF99B05E1B8018D61E1
Serial Number: 9C0E54F3A3DF8731F82F8237A5A3F878
Cert Status: good
This Update: Feb 20 23:45:48 2021 GMT
Next Update: Feb 27 23:45:48 2021 GMT
OCSP Response von GoDaddy
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: C = US, ST = Arizona, L = Scottsdale, O = GoDaddy Inc., CN = Go Daddy Validation Authority – G2
Produced At: Feb 19 20:14:48 2021 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: B6080D5F6C6B76EB13E438A5F8660BA85233344E
Issuer Key Hash: 40C2BD278ECC348330A233D7FB6CB3F0B42C80CE
Serial Number: 98AD27047908DD8B
Cert Status: good
This Update: Feb 19 20:14:48 2021 GMT
Next Update: Feb 21 08:14:48 2021 GMT

Dabei kann es vorkommen, dass beim Einsatz von OCSP Stapling der Webserver oder Reverse Proxy, welche in diesem Fall die Anfrage an den eigentlichen OCSP Responder der CA, stellvertretend für den Client durchführt, die Antwort des Responders nicht validieren kann.

In diesem Fall muss die Vertrauensstellung zur OCSP Validation hergestellt werden. Dazu wird das validierende Zertifikat oder die Zertifikatskette in die Liste der zu vertrauenden Aussteller hinzugefügt.

Der Fehler zeigt sich z.B. durch diese Fehlermeldung in der Anfrage

error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:ocsp_vfy.c:138:Verify error:unable to get local issuer certificate

Weitere Hilfsmittel

Es stehen sehr viele online tools und CLI Tools for die Analyse und Troubleshooting von OCSP und weiteren Web Security Mechanismen zur Verfügung.

Speziell für die Analyse von OCSP Konfigurationen helfen folgende Seiten weiter.

SSL Labs, ein SSL/TLS Online Test
https://ssllabs.com

CRT.ch, eine Suchmaschine für x509 Zertifikate
https://crt.sh

Web Application Firewalls

Web Application Firewalls agieren als Reverse Proxy und stehen damit zwischen dem Applications-Nutzer und dem Webserver. Die Web Application Firewall (WAF) bietet Schutzmechanismen, so dass böswillige Anfragen an den Webserver bereits blockiert werden, bevor diese überhaupt beim Webserver ankommen. Die WAF bietet aber nicht nur diese auf Layer 7 bezogenen Security Mechanismen sondern erleichtert auch eine saubere Konfiguration von SSL/TLS Zertifikaten und Protokollen, wozu auch eine OCSP Stapling Konfiguration zählt.

Managed Application Protection

Clue Application Protection vereint den Betrieb einer Web Application Firewall mit der komplexen Absicherung Ihrer Webapplikation. Hier geht es zum Service.

Haben Sie noch Fragen?

Sie setzen in ihrem Unternehmen Web-Applikationen wie z.B. Webshops, Kundenportale, Remote Access Portale, oder andere kritische Applikationen ein und möchten diese schützen und um deren Sicherheitslevel Bescheid wissen? Sprechen Sie uns auf ein Application Security Assessment und den Application Protection Service an. Gerne beraten wir Sie im Bereich Application Security Assessment und Application Protection Service und zeigen Ihnen eine auf Ihre Anforderungen angepasste und sichere Umsetzung auf.

    This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

    This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

    Latest Articles

    CLUE und Next Industries fördern Industrie 4.0 durch Praxiszirkel

    26 August 2024

    Stabilität: Clues QA-Prozess im CrowdStrike-Vorfall

    22 Juli 2024

    Area 41 Challenge – Ein Innovativer Ansatz von Clue

    2 Juli 2024