Zum Hauptinhalt springen

RFC 2818 - HTTP Over TLS (HTTPS) - 3. Endpunkt-Identifizierung (Endpoint Identification)

3. Endpunkt-Identifizierung (Endpoint Identification)​

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