Zum Hauptinhalt springen

8. Zertifikatsstatus-Anfrage

Die Überprüfung des Sperrstatus eines Zertifikats kann erfordern, dass der Client eine dritte Partei wie eine Zertifizierungsstelle (CA) oder einen Online Certificate Status Protocol (OCSP) Responder kontaktiert. Für Clients mit Bandbreitenbeschränkungen kann dies erhebliche Kosten verursachen. Die "status_request"-Erweiterung ermöglicht es Clients, den TLS-Server zu bitten, den Zertifikatsstatus im Namen des Clients zu erhalten.

8.1. Hello-Nachrichten​

Clients, die den Zertifikatsstatus anfordern, MÜSSEN eine Erweiterung vom Typ "status_request" in das (erweiterte) Client-Hello aufnehmen. Das Feld "extension_data" dieser Erweiterung enthält "CertificateStatusRequest", wobei:

struct {
    CertificateStatusType status_type;
    select (status_type) {
        case ocsp: OCSPStatusRequest;
    } request;
} CertificateStatusRequest;

enum { ocsp(1), (255) } CertificateStatusType;

struct {
    ResponderID responder_id_list<0..2^16-1>;
    Extensions request_extensions;
} OCSPStatusRequest;

opaque ResponderID<1..2^16-1>;
opaque Extensions<0..2^16-1>;

Im OCSPStatusRequest sind die Felder "responder_id_list" und "request_extensions" DER-kodierte [X690] Strukturen eines ResponderID bzw. Extensions, wie in [RFC2560] definiert. "Extensions" wird aus [RFC5280] importiert. Eine DER-kodierte "ResponderID" mit der Länge Null bedeutet, dass der Responder durch das betreffende Zertifikat impliziert wird. "Extensions" mit der Länge Null bedeutet, dass es keine Erweiterungen gibt.

Sowohl "ResponderID" als auch "Extensions" sind DER-kodierte Strukturen im oben definierten OCSPStatusRequest-Feld. Zur Verdeutlichung hier ein Beispiel einer DER-Kodierung für eine ResponderID:

ResponderID ::= CHOICE {
   byName               [1] Name,
   byKey                [2] KeyHash }

KeyHash ::= OCTET STRING -- SHA-1 Hash des öffentlichen Schlüssels des Responders
                          -- (d.h. der SHA-1 Hash des Werts der
                          -- BIT STRING subjectPublicKey [ohne
                          -- Tag, Länge und Anzahl ungenutzter
                          -- Bits] im Zertifikat des Responders)

Die DER-Kodierung der ResponderID wird dann in einem opaken Vektor im Feld responder_id_list platziert.

Server, die eine "status_request"-Client-Hello-Erweiterung erhalten, KÖNNEN eine entsprechende "status_request"-Server-Hello-Erweiterung zurückgeben, wenn der Server wählt, den Zertifikatsstatus im Handshake zurückzugeben. Wenn ein Server eine "status_request"-Erweiterung im Server-Hello zurückgibt, dann MUSS der Server eine Erweiterung vom Typ "status_request" mit einem leeren "extension_data"-Element eingefügt haben. Der Server hat mehrere Möglichkeiten, die Zertifikatsstatusinformationen zurückzugeben:

  • Er kann den Zertifikatsstatus anfordern und ihn in der (erweiterten) CertificateStatus-Nachricht zurückgeben, wie in Abschnitt 8.2 beschrieben.

  • Er kann wählen, den Zertifikatsstatus nicht anzufordern und keine "status_request"-Erweiterung in das Server-Hello aufzunehmen.

  • Er kann wählen, den Zertifikatsstatus nicht anzufordern, selbst wenn er die "status_request"-Erweiterung in das Server-Hello aufgenommen hat. In diesem Fall gibt der Server keine (erweiterte) CertificateStatus-Nachricht zurück.

Für den Fall, dass der Server wählt, den Zertifikatsstatus nicht im Handshake zurückzugeben, KANN der Client wählen, den Zertifikatsstatus direkt von einem externen OCSP-Responder anzufordern.

8.2. Zertifikatsstatus​

Der Server KANN eine "CertificateStatus"-Nachricht im TLS-Handshake zurückgeben, wenn der Client einen Zertifikatsstatus angefordert hat, indem er eine "status_request"-Erweiterung in das Client-Hello aufgenommen hat. Wenn der Server wählt, eine CertificateStatus zu senden, MUSS diese Nachricht unmittelbar nach der Certificate-Nachricht gesendet werden (und vor jeder ServerKeyExchange- oder CertificateRequest-Nachricht, falls zutreffend).

Die Struktur der CertificateStatus-Nachricht ist:

struct {
    CertificateStatusType status_type;
    select (status_type) {
        case ocsp: OCSPResponse;
    } response;
} CertificateStatus;

opaque OCSPResponse<1..2^24-1>;

Eine "OCSPResponse" enthält eine vollständige DER-kodierte OCSPResponse-Struktur (wie in [RFC2560] definiert). Nur eine OCSP-Antwort KANN gesendet werden.

Die "CertificateStatus" MUSS eine OCSP-Antwort mit einem OCSPResponseStatus-Wert von "successful" (0) enthalten.

Der Server MUSS die "CertificateStatus"-Nachricht senden, wenn:

  • Er eine gültige "status_request"-Erweiterung im Client-Hello erhält und wählt, die Anfrage zu erfüllen, UND
  • Er eine gültige OCSP-Antwort für sein Zertifikat erhält.

Wenn keine gültige OCSP-Antwort verfügbar ist, SOLLTE der Server die "CertificateStatus"-Nachricht NICHT senden.

Der Client, der einen Zertifikatsstatus anfordert, MUSS die OCSP-Antwort überprüfen, wenn er eine erhält. Wenn die OCSP-Antwort nicht zufriedenstellend ist, KANN der Client entscheiden, den Handshake abzubrechen. Die Überlegungen, die der Client verwendet, um zu bestimmen, ob die OCSP-Antwort zufriedenstellend ist, liegen außerhalb des Umfangs dieses Dokuments. Der Client DARF NICHT eine fehlende OCSP-Antwort (d.h., dass der Server keine CertificateStatus-Nachricht gesendet hat) als Versagen der Statusanfrage behandeln und SOLLTE den Handshake in diesem Fall normal fortsetzen.

8.3. Implikationen für das Zwischenspeichern von OCSP-Antworten​

Server, die diese Erweiterung implementieren, SOLLTEN OCSP-Antworten für die Zertifikate zwischenspeichern, die sie verwenden. Der Server SOLLTE auch regelmäßig (vor Ablauf von thisUpdate oder nextUpdate) neue OCSP-Antworten erhalten, um die Aktualität der Statusinformationen zu erhalten.

Server KÖNNEN einen Cache von aggregierten OCSP-Antworten pflegen, um mehrere Zertifikate effizient zu verwalten. In diesem Fall muss der Server sicherstellen, dass die OCSP-Antworten aktuell sind und zum Serverzertifikat passen.

Ein Server, der nicht rechtzeitig eine OCSP-Antwort erhalten oder aktualisieren kann, KANN eine abgelaufene OCSP-Antwort weiterhin verwenden, bis eine neue Antwort verfügbar ist. Er SOLLTE jedoch versuchen, so bald wie möglich eine neue OCSP-Antwort zu erhalten.

8.4. Sicherheitsüberlegungen zur Zertifikatsstatus-Anfrage​

Die "status_request"-Erweiterung ermöglicht es einem Client, den Server zu bitten, während des TLS-Handshakes Zertifikatsstatusinformationen (normalerweise über OCSP) bereitzustellen. Dies hat wichtige Sicherheitsimplikationen:

Sicherheitsvorteile:

  • Verbesserte Privatsphäre: Der Client muss nicht direkt einen OCSP-Responder kontaktieren, was verhindert, dass der OCSP-Responder die Aktivitäten des Clients verfolgt.

  • Leistung: Reduziert die Verbindungslatenz, indem ein zusätzlicher Roundtrip zu einem externen OCSP-Responder vermieden wird.

  • Zuverlässigkeit: Der Server kann OCSP-Antworten zwischenspeichern, wodurch der Dienst zuverlässiger wird, selbst wenn der OCSP-Responder vorübergehend nicht verfügbar ist.

Sicherheitsrisiken:

  • Aktualität der OCSP-Antworten: Der Server kann veraltete OCSP-Antworten bereitstellen. Clients müssen die Felder thisUpdate und nextUpdate in der OCSP-Antwort überprüfen.

  • Gefälschte OCSP-Antworten: Ein kompromittierter Server könnte gefälschte OCSP-Antworten bereitstellen. Clients MÜSSEN die Signatur der OCSP-Antwort überprüfen.

  • Denial-of-Service-Angriffe: Ein Server könnte absichtlich keine OCSP-Antwort für ein gesperrtes Zertifikat bereitstellen. Clients SOLLTEN eine Fallback-Richtlinie haben (z. B. direkte Kontaktaufnahme mit dem OCSP-Responder oder Ablehnung der Verbindung).

  • Server-Privatsphäre: Der Server offenbart die Identität des OCSP-Responders, den er verwendet, was Informationen über die Server-Infrastruktur preisgeben könnte.

Clients, die diese Erweiterung implementieren, MÜSSEN eine vollständige Validierung der OCSP-Antwort durchführen, einschließlich der Überprüfung der Signatur, der Überprüfung, dass der Responder autorisiert ist, und der Überprüfung, dass die Antwort gemäß der Client-Richtlinie aktuell ist.

Letztes Update am