HTTP-Expect-CT-Header

Typ

Der Expect-CT-Header ist ein HTTP-Response-Header, mit dem der Server Certificate Transparency-Requirements für TLS-Verbindungen durchsetzt und Zertifikatsmissbrauch erkennt.

Syntax

Der Header definiert Certificate Transparency-Policies mit optionaler Enforcement und Reporting.

http 
Expect-CT: max-age=86400, enforce
Expect-CT: max-age=86400, report-uri="https://api.example.com/ct-report"

Direktiven

Der Expect-CT-Header verwendet folgende Direktiven:

max-age
Zeitdauer in Sekunden, für die der Browser die CT-Policy speichern soll. Typische Werte: 86400 (1 Tag) bis 31536000 (1 Jahr).
enforce
Aktiviert Enforcement-Modus. Browser blockiert Verbindungen, wenn Zertifikat keine gültigen CT-Logs vorweist. Ohne enforce werden nur Violations reportet.
report-uri
URL für CT-Violation-Reports. Browser sendet JSON-Report an diese URL wenn CT-Requirements nicht erfüllt sind.

Beispiele

API aktiviert Expect-CT im Enforce-Modus

Eine API erzwingt Certificate Transparency für alle Verbindungen:

http 
GET /api/v1/secure/data HTTP/1.1
Host: api.example.com

Der Server antwortet mit Expect-CT-Policy:

http 
HTTP/1.1 200 OK
Expect-CT: max-age=86400, enforce
Strict-Transport-Security: max-age=31536000
Content-Type: application/json

{
  "data": "sensitive information",
  "security": "protected by CT enforcement"
}

Wenn Zertifikat keine CT-Logs hat, blockiert Browser die Verbindung.

API sammelt CT-Violations ohne Enforcement

Eine API testet CT-Compliance im Report-Only-Modus:

http 
GET /api/v1/public/info HTTP/1.1
Host: api.example.com

Der Server fordert CT-Reporting ohne Enforcement:

http 
HTTP/1.1 200 OK
Expect-CT: max-age=86400, report-uri="https://api.example.com/reports/ct"
Content-Type: application/json

{
  "message": "CT violations will be reported but not enforced"
}

Bei CT-Violation sendet Browser Report:

http 
POST /reports/ct HTTP/1.1
Host: api.example.com
Content-Type: application/expect-ct-report+json

{
  "expect-ct-report": {
    "date-time": "2025-10-01T10:25:00Z",
    "hostname": "api.example.com",
    "port": 443,
    "effective-expiration-date": "2025-10-02T10:25:00Z",
    "served-certificate-chain": ["..."],
    "validated-certificate-chain": ["..."]
  }
}

Kombinierte Expect-CT mit Enforcement und Reporting

Eine API nutzt beide Modi für maximale Sicherheit und Monitoring:

http 
GET /api/v1/payments HTTP/1.1
Host: payments.example.com
http 
HTTP/1.1 200 OK
Expect-CT: max-age=31536000, enforce, report-uri="https://security.example.com/ct-reports"
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Type: application/json

{
  "payment_methods": ["card", "bank_transfer"]
}

Certificate-Transparency-Enforcement-Flow

Der Ablauf der CT-Validierung und Enforcement für sichere API-Verbindungen.

plantuml 
@startuml
actor Browser
participant "API Server" as API
participant "CT Log Server" as CTLog
participant "Report Endpoint" as Report

Browser -> API: TLS Handshake\nRequest certificate

API --> Browser: Server certificate +\nSCT (Signed Certificate Timestamp)

Browser -> Browser: Parse Expect-CT header\nmax-age=86400, enforce

Browser -> CTLog: Verify SCT\nCheck CT log inclusion

alt Certificate in CT logs (valid SCT)
  CTLog --> Browser: SCT verified\nCertificate logged
  Browser -> API: Continue HTTPS connection\nGET /api/v1/resource
  API --> Browser: 200 OK\n[secure data]

else Certificate NOT in CT logs
  CTLog --> Browser: No valid CT logs found

  alt enforce=true
    Browser -> Browser: Block connection\nCT requirement not met
    Browser -x API: Connection blocked
    Browser -> Report: POST CT violation report
  else enforce=false (report-only)
    Browser -> API: Allow connection\n(non-compliant)
    API --> Browser: 200 OK
    Browser -> Report: POST CT violation report
  end
end

note right
CT enforcement prevents
MITM attacks using
fraudulent certificates
end note
@enduml

Vorteile für die Systemarchitektur

  • Verhindert Man-in-the-Middle-Angriffe durch gefälschte oder missbrauchte Zertifikate
  • Ermöglicht Detektion kompromittierter Certificate Authorities durch CT-Log-Monitoring
  • Report-Only-Modus erlaubt schrittweise Migration ohne Serviceunterbrechung
  • Kombinierbar mit HSTS für vollständige TLS-Sicherheit auf Transport-Ebene
  • Standardisierte Browser-basierte Enforcement ohne zusätzliche Client-Software

Spezifikation

Der Expect-CT-Header ist in RFC 9163 (Expect-CT Extension for HTTP) definiert.

Weitere Spezifikationen

Strict-Transport-Security Header, Content-Security-Policy Header