HTTP-Early-Data-Header

Typ

Der Early-Data-Header ist ein HTTP-Request-Header, mit dem ein Intermediary anzeigt, dass der Request über TLS 1.3 0-RTT Early Data übertragen wurde.

Syntax

Der Header enthält einen festen Wert zur Kennzeichnung von 0-RTT-Übertragung.

http 
Early-Data: 1

Direktiven

Der Early-Data-Header verwendet einen einzelnen Wert:

value-1
Der Wert 1 zeigt an, dass der Request über TLS 1.3 0-RTT Early Data gesendet wurde. Kein anderer Wert ist definiert.
proxy-added
Der Header wird typischerweise von einem TLS-terminierenden Proxy oder Load Balancer hinzugefügt, nicht vom ursprünglichen Client.
replay-risk
Requests mit Early-Data sind potenziell replay-anfällig und sollten für nicht-idempotente Operationen abgelehnt werden.

Beispiele

API lehnt nicht-idempotente 0-RTT-Requests ab

Ein Proxy sendet einen POST-Request mit Early-Data-Kennzeichnung:

http 
POST /api/v1/orders HTTP/1.1
Host: api.example.com
Early-Data: 1
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

{
  "product_id": "SKU-12345",
  "quantity": 2
}

Die API lehnt den Request wegen Replay-Risiko ab:

http 
HTTP/1.1 425 Too Early
Content-Type: application/json

{
  "error": "too_early",
  "message": "Request sent via TLS 0-RTT Early Data. Retry without 0-RTT."
}

Client wiederholt Request ohne 0-RTT:

http 
POST /api/v1/orders HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

{
  "product_id": "SKU-12345",
  "quantity": 2
}

API erlaubt idempotente 0-RTT-Requests

Ein GET-Request wird mit Early-Data gesendet:

http 
GET /api/v1/products/12345 HTTP/1.1
Host: api.example.com
Early-Data: 1
Accept: application/json

Die API verarbeitet den Request normal da GET idempotent ist:

http 
HTTP/1.1 200 OK
Content-Type: application/json

{
  "product_id": "12345",
  "name": "Premium Widget",
  "price": 99.99
}

API verwendet Anti-Replay-Mechanismus für 0-RTT

Eine API implementiert Token-basierte Replay-Protection:

http 
POST /api/v1/payments HTTP/1.1
Host: api.example.com
Early-Data: 1
X-Request-Token: unique-token-abc123
Content-Type: application/json

{
  "amount": 99.99,
  "currency": "USD"
}

Server prüft Token auf Einmaligkeit:

http 
HTTP/1.1 200 OK
Content-Type: application/json

{
  "payment_id": "PAY-789",
  "status": "processed"
}

Bei wiederholtem Token:

http 
HTTP/1.1 409 Conflict
Content-Type: application/json

{
  "error": "duplicate_request",
  "message": "Request token already processed"
}

TLS-0-RTT-Early-Data-Flow

Der Ablauf der 0-RTT-Request-Verarbeitung mit Replay-Protection in APIs.

plantuml 
@startuml
actor Client
participant "TLS Proxy" as Proxy
participant "API Gateway" as Gateway
participant "API Service" as API

Client -> Proxy: TLS 1.3 ClientHello\nwith 0-RTT data\nPOST /api/v1/resource

Proxy -> Proxy: Accept 0-RTT data\n(before TLS handshake complete)

Proxy -> Gateway: POST /api/v1/resource\nEarly-Data: 1\n[request body]

Gateway -> Gateway: Detect Early-Data header\nCheck HTTP method

alt Non-idempotent method (POST, PUT, DELETE)
  Gateway --> Proxy: 425 Too Early\nReject replay-vulnerable request
  Proxy --> Client: 425 Too Early

  Client -> Proxy: Retry POST without 0-RTT\n(full TLS handshake)
  Proxy -> Gateway: POST /api/v1/resource\n(no Early-Data header)
  Gateway -> API: Process request
  API --> Gateway: 200 OK
  Gateway --> Proxy: 200 OK
  Proxy --> Client: 200 OK

else Idempotent method (GET, HEAD, OPTIONS)
  Gateway -> API: Process request\n(safe for replay)
  API --> Gateway: 200 OK
  Gateway --> Proxy: 200 OK
  Proxy --> Client: 200 OK
end

note right
0-RTT saves one round-trip
but requires careful replay
protection for state-changing
operations
end note
@enduml

Vorteile für die Systemarchitektur

  • Reduziert Latenz durch 0-RTT-Handshake bei TLS 1.3-Verbindungen
  • Verhindert Replay-Angriffe durch selektive Ablehnung nicht-idempotenter 0-RTT-Requests
  • Transparente Behandlung durch Load Balancer mit Early-Data-Header-Injection
  • Erlaubt sichere 0-RTT-Nutzung für GET-Requests ohne zusätzliche Mechanismen
  • Kombinierbar mit Request-Token-Systemen für erweiterte Replay-Protection

Spezifikation

Der Early-Data-Header ist in RFC 8470 (Using Early Data in HTTP) definiert.

Weitere Spezifikationen

Upgrade Header, Strict-Transport-Security Header