Zum Hauptinhalt springen

RFC 2818 - HTTP Over TLS (HTTPS) - 2. HTTP über TLS (HTTP Over TLS)

2. HTTP über TLS (HTTP Over TLS)​

Kernprinzip​

Konzeptionell sehr einfach: HTTP/TLS ist sehr einfach. Verwenden Sie HTTP über TLS genau so, wie Sie HTTP über TCP verwenden würden.

2.1. Connection Initiation (Verbindungsaufbau)​

Prozess:

1. Client → Server: TCP-Verbindung aufbauen (Port 443)
2. Client → Server: TLS ClientHello senden
3. ↔ TLS-Handshake-Prozess ↔
4. Nach Handshake-Abschluss: Client kann erste HTTP-Anfrage initiieren

Anforderungen:

  • ✅ HTTP-Client muss (MUST) als TLS-Client agieren
  • ✅ Verbindung zum entsprechenden Port herstellen (Standard 443)
  • ✅ TLS ClientHello senden, um Handshake zu beginnen
  • ✅ Alle HTTP-Daten müssen (MUST) als TLS-„Anwendungsdaten" gesendet werden

Beispiel-Ablauf:

Client:
1. TCP-Verbindung zu www.example.com:443
2. ClientHello senden

Server:
3. ServerHello + Zertifikat antworten
4. ServerHelloDone

Client:
5. ClientKeyExchange
6. ChangeCipherSpec
7. Finished

Server:
8. ChangeCipherSpec
9. Finished

← TLS-Handshake abgeschlossen →

Client:
10. Verschlüsselte HTTP-Anfrage senden:
    GET / HTTP/1.1
    Host: www.example.com

2.2. Connection Closure (Verbindungsbeendigung)​

TLS bietet eine Funktion für sichere Verbindungsbeendigung.

Closure Alert (Beendigungswarnung)​

Definitionen:

  • Gültige Beendigung (Valid Closure): Korrekte Beendigungswarnung empfangen
  • Unvollständige Beendigung (Incomplete Close): Verbindung sofort nach Senden der Beendigungswarnung schließen
  • Vorzeitige Beendigung (Premature Close): Verbindung ohne Empfang einer Beendigungswarnung geschlossen

Anforderungen:

  • ✅ Implementierungen müssen (MUST) einen Austausch von Beendigungswarnungen initiieren, bevor sie eine Verbindung schließen
  • ⚠️ Implementierungen können (MAY) die Verbindung nach dem Senden der Beendigungswarnung schließen (ohne zu warten)
  • ❌ Verbindungen mit vorzeitiger Beendigung dürfen nicht (MUST NOT) die Sitzung wiederverwenden

2.2.1. Client Behavior (Client-Verhalten)​

Problem: HTTP verwendet Verbindungsbeendigung, um das Ende der Serverdaten zu signalisieren.

Der Client muss (MUST):

  • ✅ Jede vorzeitige Beendigung als Fehler behandeln
  • ✅ Empfangene Daten als möglicherweise abgeschnitten behandeln
  • ✅ Beendigungswarnung senden, bevor die Verbindung geschlossen wird

Besondere Fälle:

  1. Antwort ohne Content-Length:
HTTP/1.1 200 OK
Content-Type: text/html
[Verbindungsschluss zeigt Ende an]

← Vorzeitige Beendigung kann nicht zwischen Server und Angreifer unterscheiden →
  1. Content-Length vorhanden, aber nicht vollständig gelesen:
HTTP/1.1 200 OK
Content-Length: 1000
[Nur 500 Bytes vor Beendigung empfangen]

← Kann nicht feststellen, ob Serverfehler oder Angriff →

Ausnahme: Wenn empfangene Daten mit Content-Length übereinstimmen, sollte (SHOULD) als abgeschlossen behandelt werden.

Client-Beispiel:

✅ Normale Beendigung:
Client: closure_alert senden
Auf closure_alert des Servers warten
Verbindung schließen

⚡ Schnelle Beendigung:
Client: closure_alert senden
Verbindung sofort schließen (nicht warten)
← Dies erzeugt eine unvollständige Beendigung auf der Serverseite →

2.2.2. Server Behavior (Server-Verhalten)​

RFC 2616-Anforderung: Server müssen (MUST) sich von Client-Beendigung ordnungsgemäß erholen.

Der Server sollte (SHOULD):

  • ✅ Bereit sein, eine unvollständige Beendigung vom Client zu empfangen
  • ✅ Bereit sein, auf diese Weise geschlossene TLS-Sitzungen wieder aufzunehmen
  • ✅ Versuchen, Beendigungswarnungen mit dem Client auszutauschen
  • ⚡ Kann (MAY) die Verbindung nach dem Senden der Beendigungswarnung schließen

Implementierungshinweis:

HTTP ohne persistente Verbindungen:
- Server signalisiert das Datenende durch Schließen der Verbindung
- Aber Client hat möglicherweise bereits die Beendigungswarnung gesendet und getrennt

2.3. Port Number (Portnummer)​

Standard-Port: 443

Begründung:

HTTP-Server erwartet: Request-Line (z.B. GET / HTTP/1.1)
TLS-Server erwartet: ClientHello

← Kann auf demselben Port nicht unterschieden werden →

Lösung: Verschiedene Ports verwenden
- HTTP: 80
- HTTPS: 443

Beispiele:

# HTTP (Klartext)
curl http://www.example.com:80/

# HTTPS (verschlüsselt)
curl https://www.example.com:443/

2.4. URI Format (URI-Format)​

Protokollidentifikator: https:// (anstelle von http://)

Beispiele:

https://www.example.com/~smith/home.html
https://api.example.com:8443/v1/users
https://192.168.1.1/admin

URI-Komponenten:

https://www.example.com:443/path?query#fragment
  ↑         ↑              ↑     ↑     ↑     ↑
scheme    host           port  path  query fragment