HTTP Status 425 - Too Early

Der HTTP-Status-Code 425 Too Early signalisiert, dass Server einen Request ablehnt, der über TLS 1.3 Early Data (0-RTT) gesendet wurde. Server will Replay-Attack-Risk vermeiden bei non-idempotent Requests. Client muss Request nach vollständigem TLS-Handshake wiederholen. Security-Feature für TLS 1.3-Optimization.

Typ

Response-Status-Code

Syntax

Der Status Code wird zurückgegeben bei abgelehnten TLS Early Data Requests.

http
HTTP/1.1 425 Too Early

Direktiven

Der 425 Too Early Status Code wird bei TLS 1.3 Early Data Rejection verwendet.

TLS 1.3 0-RTT Rejection
Server lehnt Request ab der über TLS Early Data gesendet wurde. 0-RTT-Data ermöglicht schnellere Connection-Resume aber ist vulnerable gegen Replay-Attacks. Server acceptiert nur Requests nach Full-Handshake.
Replay Attack Prevention
TLS Early Data kann von Attacker replayed werden. Server returned 425 für non-idempotent Requests (POST, DELETE) die über Early Data gesendet wurden. Schützt vor unintended Duplicate-Operations.
Retry After Handshake
Client sollte Request automatisch über vollständig established TLS-Connection wiederholen. Nach Full-Handshake ist Connection gegen Replay-Attacks geschützt.

Beispiele

Nachfolgend finden Sie praktische Anwendungsbeispiele für Status 425.

Beispiel 1 POST Request Rejected in Early Data

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

{"product_id": 42, "quantity": 2}

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

{
  "error": "early_data_rejected",
  "message": "Non-idempotent requests not accepted in TLS Early Data",
  "details": "Request will be replayed after TLS handshake completes",
  "retry": "Automatic retry on full TLS connection"
}

Beispiel 2 Payment Request Replay Protection

http
POST /api/payments HTTP/1.1
Host: secure.example.com
Content-Type: application/json
Early-Data: 1
Authorization: Bearer token123

{"amount": 100, "currency": "USD", "card": "****1234"}

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

{
  "status": 425,
  "error": "too_early",
  "message": "Payment requests cannot be processed in TLS Early Data",
  "reason": "Protection against replay attacks",
  "action": "Retry after TLS handshake completion"
}

Beispiel 3 State-Changing DELETE Rejection

http
DELETE /api/accounts/42 HTTP/1.1
Host: api.example.com
Early-Data: 1
Authorization: Bearer token123

HTTP/1.1 425 Too Early
Content-Type: text/plain

Error: Account deletion cannot be processed in TLS Early Data.
This operation is not idempotent and could be subject to replay attacks.
Please retry after TLS handshake completes.

TLS 1.3 Early Data Rejection Flow

425 Too Early bei TLS 1.3 0-RTT Replay-Attack-Prevention

Vorteile für die Systemarchitektur

  • Replay Attack Protection: 425 verhindert dass non-idempotent Operations über TLS Early Data durchgeführt werden. Schützt vor Duplicate-Payments, Double-Submits, unintended Deletions durch replayed 0-RTT-Data.
  • Performance Optimization with Safety: Server kann TLS 1.3 0-RTT für idempotent GET-Requests nutzen (Performance-Benefit) aber non-idempotent Requests ablehnen (Security-Benefit). Best of both worlds.
  • Transparent Client Handling: Modern HTTP-Clients können 425-Response automatisch handeln durch Request-Retry nach Full-Handshake. User merkt Security-Protection nicht, nur leichte Latency für non-idempotent Operations.

Spezifikation

RFC 8470, Section 3 – Using Early Data in HTTP https://www.rfc-editor.org/rfc/rfc8470.html#section-3

Weitere Spezifikationen

Early-Data Header, Strict-Transport-Security Header