RFC 2818 - HTTP Over TLS (HTTPS)

Status: Informationsdokument
Autor: E. Rescorla (RTFM, Inc.)
Datum: Mai 2000

Zusammenfassung (Abstract)

Dieses Memo beschreibt, wie TLS verwendet wird, um HTTP-Verbindungen über das Internet zu sichern. Die aktuelle Praxis besteht darin, HTTP über SSL (dem Vorgänger von TLS) zu schichten und gesicherten Verkehr von ungesichertem Verkehr durch die Verwendung eines anderen Server-Ports zu unterscheiden. Dieses Dokument dokumentiert diese Praxis unter Verwendung von TLS.

Bedeutung

RFC 2818 ist der Grundstein der Web-Sicherheit:

• 🔒 Definiert den grundlegenden Mechanismus von HTTPS
• 🌐 Grundlage der Sicherheit für alle modernen Websites
• 🔑 Zertifikatvalidierung und Identitätsverifizierung
• ⚡ Sichere Verbindungsaufbau und -beendigung

---

1. Introduction (Einführung)

HTTP [RFC2616] wurde ursprünglich im Klartext im Internet verwendet. Die zunehmende Verwendung von HTTP für sensible Anwendungen erforderte jedoch Sicherheitsmaßnahmen. SSL und sein Nachfolger TLS [RFC2246] wurden entwickelt, um kanalorientierte Sicherheit bereitzustellen. Dieses Dokument beschreibt, wie HTTP über TLS verwendet wird.

Kernkonzept

HTTPS = HTTP + TLS

┌────────────────────────────────────────┐
│         HTTP/1.1 Protocol              │
│    (Application Layer Protocol)        │
├────────────────────────────────────────┤
│         TLS/SSL Protocol               │
│      (Transport Layer Security)        │
├────────────────────────────────────────┤
│         TCP Protocol                   │
│    (Transmission Control Protocol)     │
└────────────────────────────────────────┘

1.1. Requirements Terminology (Anforderungsterminologie)

Die Schlüsselwörter „muss (MUST)", „darf nicht (MUST NOT)", „erforderlich (REQUIRED)", „sollte (SHOULD)", „sollte nicht (SHOULD NOT)" und „kann (MAY)", die in diesem Dokument erscheinen, sind wie in [RFC2119] beschrieben zu interpretieren.

---

2. HTTP Over TLS (HTTP über 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 →

2. 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

---

3. Endpoint Identification (Endpunkt-Identifizierung)

3.1. Server Identity (Server-Identität)

Kernanforderung: Clients müssen (MUST) die Server-Identität verifizieren, um Man-in-the-Middle-Angriffe zu verhindern.

Identitätsverifizierungsprozess

1. Client erhält Hostname aus URI
   z.B.: https://www.example.com

2. Server stellt Zertifikat im TLS-Handshake bereit

3. Client prüft, ob Hostname mit Zertifikatsidentität übereinstimmt

Priorität der Identitätsfelder

Priorität 1: subjectAltName (Alternativer Subjektname)

subjectAltName-Erweiterung im Zertifikat (dNSName-Typ):
dNSName: www.example.com
dNSName: api.example.com

← Dieses Feld muss (MUST) verwendet werden (falls vorhanden) →

Priorität 2: Common Name (Allgemeiner Name)

CN im Subject-Feld des Zertifikats:
CN=www.example.com

← Nur verwenden, wenn kein subjectAltName vorhanden →
← Veraltet, CAs sollten dNSName verwenden →

Übereinstimmungsregeln

1. Wildcard-Übereinstimmung:

Zertifikat: *.example.com
✅ Stimmt überein: foo.example.com
❌ Stimmt nicht überein: bar.foo.example.com

Zertifikat: f*.com
✅ Stimmt überein: foo.com
❌ Stimmt nicht überein: bar.com

2. IP-Adressen:

URI: https://192.168.1.1/
Zertifikat muss (MUST) enthalten: iPAddress subjectAltName
Wert muss (MUST) genau übereinstimmen: 192.168.1.1

3. Mehrere Identitäten:

Wenn Zertifikat mehrere dNSName enthält:
- www.example.com
- api.example.com
- *.app.example.com

← Übereinstimmung mit einem ist akzeptabel →

Verhalten bei fehlender Übereinstimmung

Benutzerorientierte Clients (Browser):

• ✅ Muss (MUST) Benutzer benachrichtigen
• ⚠️ Kann (MAY) Benutzer die Option zum Fortfahren geben
• Oder Verbindung beenden

Automatisierte Clients (API-Clients):

• ✅ Muss (MUST) Fehler in Audit-Log protokollieren
• ✅ Sollte (SHOULD) Verbindung beenden
• ⚠️ Kann (MAY) Konfigurationsoption zum Deaktivieren der Prüfung bereitstellen

Sicherheitswarnung

Nicht vertrauenswürdige URI-Quelle:

Angriffsszenario:
1. Benutzer klickt auf Link in HTTP-Seite
2. HTTP-Seite selbst ist nicht verschlüsselt
3. Man-in-the-Middle könnte URI ersetzt haben

Schutz:
Benutzer sollten Server-Zertifikat sorgfältig prüfen

3.2. Client Identity (Client-Identität)

Typischer Fall: Server hat keine externe Kenntnis der Client-Identität.

Wenn Server externe Kenntnis hat (von außerhalb von HTTP oder TLS):

• Sollte (SHOULD) Identität wie oben beschrieben prüfen

Client-Zertifikatauthentifizierung:

Häufige Szenarien:
- Interne Unternehmenssysteme
- API-Zugriffskontrolle
- Gegenseitiges TLS (mTLS)

Verifizierung:
- Zertifikatskette, die in geeigneter CA verwurzelt ist
- Optional: Spezifische Client-Identität verifizieren

---

Security Considerations (Sicherheitsüberlegungen)

Dieses gesamte Dokument behandelt Sicherheit.

Wichtige Sicherheitspunkte

1. Zertifikatvalidierung ist obligatorisch (Mandatory)

   • Clients müssen (MUST) Server-Zertifikate verifizieren
   • Verhindert Man-in-the-Middle-Angriffe

2. Ordnungsgemäße Verbindungsbeendigung (Proper Connection Closure)

   • TLS-Beendigungswarnungen verwenden
   • Erkennt Datenabschneidungsangriffe

3. Hostname-Verifizierung (Hostname Verification)

   • Verhindert Zertifikatsubstitutionsangriffe
   • subjectAltName gegenüber CN bevorzugen

4. Vorsicht bei nicht vertrauenswürdigen URIs (Beware Untrusted URIs)

   • Über HTTP erhaltene URIs können manipuliert sein
   • Benutzer sollten Zertifikate prüfen

---

Praktische Beispiele

Vollständige HTTPS-Verbindung

Client-Operationen:

1. URI analysieren: https://www.example.com/page.html
   → Hostname: www.example.com
   → Port: 443 (Standard)

2. TCP-Verbindung zu www.example.com:443

3. TLS-Handshake:
   ClientHello →
   ← ServerHello + Certificate
   Hostname im Zertifikat verifizieren
   ...Handshake abgeschlossen...

4. Verschlüsselte HTTP-Anfrage senden:
   GET /page.html HTTP/1.1
   Host: www.example.com

5. Verschlüsselte HTTP-Antwort empfangen:
   HTTP/1.1 200 OK
   Content-Length: 1234
   ...

6. Verbindung schließen:
   closure_alert senden
   TCP-Verbindung schließen

Zertifikatsverifizierungsbeispiel

# Python-Beispiel (konzeptionell)
import ssl
import socket

# SSL-Kontext erstellen
context = ssl.create_default_context()

# Zum Server verbinden
sock = socket.create_connection(('www.example.com', 443))
ssock = context.wrap_socket(sock, server_hostname='www.example.com')

# wrap_socket verifiziert automatisch:
# 1. Zertifikatskette ist gültig
# 2. Hostname stimmt überein
# 3. Zertifikat ist nicht abgelaufen

# Zertifikatsinformationen abrufen
cert = ssock.getpeercert()
print(f"Subject: {cert['subject']}")
print(f"Issuer: {cert['issuer']}")
print(f"SANs: {cert.get('subjectAltName', [])}")

Häufige Fehlerbehandlung

Fehler 1: Zertifikat-Hostname stimmt nicht überein
Certificate Hostname Mismatch
- Zertifikat: *.example.com
- Zugriff: www.different.com
→ Verbindung beenden oder Benutzer warnen

Fehler 2: Zertifikat abgelaufen
Certificate Expired
- Not After: 2023-12-31
- Aktuell: 2024-01-01
→ Verbindung ablehnen

Fehler 3: Selbstsigniertes Zertifikat
Self-Signed Certificate
- Nicht in vertrauenswürdiger CA-Liste
→ Benutzer warnen oder ablehnen

Fehler 4: Unvollständige Zertifikatskette
Incomplete Certificate Chain
- Zwischenzertifikat fehlt
→ Kann nicht verifizieren, Verbindung ablehnen

---

Beziehung zu modernen Standards

Nachfolger von RFC 2818

Obwohl RFC 2818 weiterhin gültig ist, gibt es aktualisierte Spezifikationen:

RFC	Titel	Beschreibung
RFC 2818	HTTP Over TLS	Dieses Dokument (2000)
RFC 5246	TLS 1.2	Aktualisiertes TLS-Protokoll
RFC 8446	TLS 1.3	Neuestes TLS-Protokoll
RFC 6125	Zertifikatvalidierung	Detailliertere Hostname-Verifizierung
RFC 7230-7235	HTTP/1.1	Aktualisierte HTTP-Spezifikationen
RFC 7540	HTTP/2	HTTP/2 läuft typischerweise über TLS

Updates moderner Praktiken

1. TLS-Versionen:

RFC 2818: SSL/TLS (1.0/1.1)
Modern: TLS 1.2+ (TLS 1.0/1.1 veraltet)

2. Zertifikatvalidierung:

RFC 2818: Grundregeln
RFC 6125: Detaillierte Spezifikationen

3. HSTS:

RFC 6797: HTTP Strict Transport Security
Zwingt Browser zur Verwendung von HTTPS

---

Schnellreferenz

HTTPS vs HTTP

Funktion	HTTP	HTTPS
Protokoll	http://	https://
Port	80	443
Verschlüsselung	❌ Klartext	✅ TLS-verschlüsselt
Integrität	❌ Kein Schutz	✅ MAC-Schutz
Authentifizierung	❌ Keine Server-Auth	✅ Zertifikat-Auth
Privatsphäre	❌ Kann abgehört werden	✅ Verschlüsselte Übertragung

TLS-Handshake-Übersicht

Client                           Server
  |                                |
  |--- ClientHello --------------->|
  |                                |
  |<-- ServerHello, Certificate ---|
  |<-- ServerHelloDone ------------|
  |                                |
  |--- ClientKeyExchange --------->|
  |--- ChangeCipherSpec ---------->|
  |--- Finished ------------------>|
  |                                |
  |<-- ChangeCipherSpec -----------|
  |<-- Finished -------------------|
  |                                |
  |=== Verschlüsselter Kanal =====|
  |                                |
  |--- Verschlüsselte HTTP-Anfrage->|
  |<-- Verschlüsselte HTTP-Antwort-|

Häufige Tools

# OpenSSL Zertifikat anzeigen
openssl s_client -connect www.example.com:443 -showcerts

# TLS-Version testen
openssl s_client -connect www.example.com:443 -tls1_2

# Zertifikatsdetails anzeigen
echo | openssl s_client -connect www.example.com:443 2>/dev/null | \
  openssl x509 -noout -text

# cURL HTTPS verwenden
curl -v https://www.example.com

---

Referenzen

Normative Referenzen

• [RFC 2119] - Schlüsselwörter zur Verwendung in RFCs zur Angabe von Anforderungsebenen
• [RFC 2246] - Das TLS-Protokoll
• [RFC 2459] - Internet X.509 Public Key Infrastructure Zertifikat- und CRL-Profil
• [RFC 2616] - Hypertext Transfer Protocol -- HTTP/1.1

Informative Referenzen

• [RFC 2817] - Upgrade auf TLS innerhalb von HTTP/1.1
• [RFC 5246] - Das Transport Layer Security (TLS) Protocol Version 1.2
• [RFC 6125] - Darstellung und Verifizierung domänenbasierter Anwendungsdienst-Identität
• [RFC 6797] - HTTP Strict Transport Security (HSTS)
• [RFC 7230-7235] - Hypertext Transfer Protocol (HTTP/1.1) Aktualisierte Spezifikationen
• [RFC 8446] - Das Transport Layer Security (TLS) Protocol Version 1.3

---

Glossar

Kernbegriffe

TLS (Transport Layer Security)

• Transport Layer Security-Protokoll, Nachfolger von SSL

SSL (Secure Sockets Layer)

• Vorgänger von TLS, jetzt veraltet

Certificate (Zertifikat)

• Digitales Dokument mit öffentlichem Schlüssel und Identitätsinformationen

CA (Certificate Authority / Zertifizierungsstelle)

• Zertifizierungsstelle, die vertrauenswürdige Zertifikate ausstellt

Closure Alert (Beendigungswarnung)

• TLS-Mechanismus für sichere Verbindungsbeendigung

Premature Close (Vorzeitige Beendigung)

• Unsachgemäße TLS-Verbindungsbeendigung

Man-in-the-Middle Attack (Man-in-the-Middle-Angriff)

• Angreifer fängt Kommunikation ab und modifiziert sie potenziell

subjectAltName (Alternativer Subjektname)

• Zertifikatserweiterung, die zusätzliche Hostnamen spezifiziert

Common Name (Allgemeiner Name)

• CN-Feld im Zertifikatsubjekt

---

Zurück: RFC-Dokumentliste

Verwandte RFCs:

• RFC 7231 - HTTP/1.1-Semantik
• RFC 3986 - URI Generische Syntax
• RFC 2119 - Schlüsselwörter