Passa al contenuto principale

RFC 2818 - HTTP Over TLS (HTTPS) - 3. Identificazione degli endpoint (Endpoint Identification)

3. Identificazione degli endpoint (Endpoint Identification)​

3.1. Server Identity (Identità del server)​

Requisito centrale: I client devono (MUST) verificare l'identità del server per prevenire attacchi man-in-the-middle.

Processo di verifica dell'identità​

1. Il client ottiene l'hostname dall'URI
ad es.: https://www.example.com

2. Il server fornisce il certificato nell'handshake TLS

3. Il client verifica se l'hostname corrisponde all'identità del certificato

Priorità dei campi di identità​

Priorità 1: subjectAltName (Nome alternativo del soggetto)

Estensione subjectAltName nel certificato (tipo dNSName):
dNSName: www.example.com
dNSName: api.example.com

← Questo campo deve (MUST) essere utilizzato (se presente) →

Priorità 2: Common Name (Nome comune)

CN nel campo Subject del certificato:
CN=www.example.com

← Utilizzare solo in assenza di subjectAltName →
← Deprecato, le CA dovrebbero utilizzare dNSName →

Regole di corrispondenza​

1. Corrispondenza con caratteri jolly:

Certificato: *.example.com
✅ Corrisponde: foo.example.com
❌ Non corrisponde: bar.foo.example.com

Certificato: f*.com
✅ Corrisponde: foo.com
❌ Non corrisponde: bar.com

2. Indirizzi IP:

URI: https://192.168.1.1/
Il certificato deve (MUST) contenere: iPAddress subjectAltName
Il valore deve (MUST) corrispondere esattamente: 192.168.1.1

3. Identità multiple:

Se il certificato contiene più dNSName:
- www.example.com
- api.example.com
- *.app.example.com

← La corrispondenza con uno di essi è accettabile →

Comportamento in caso di mancata corrispondenza​

Client orientati all'utente (browser):

  • ✅ Deve (MUST) notificare l'utente
  • ⚠️ Può (MAY) dare all'utente l'opzione di continuare
  • O terminare la connessione

Client automatizzati (client API):

  • ✅ Deve (MUST) registrare l'errore nel log di audit
  • ✅ Dovrebbe (SHOULD) terminare la connessione
  • ⚠️ Può (MAY) fornire un'opzione di configurazione per disabilitare il controllo

Avviso di sicurezza​

Fonte URI non affidabile:

Scenario di attacco:
1. L'utente clicca su un link in una pagina HTTP
2. La pagina HTTP stessa non è crittografata
3. Il man-in-the-middle potrebbe aver sostituito l'URI

Protezione:
Gli utenti dovrebbero esaminare attentamente il certificato del server

3.2. Client Identity (Identità del client)​

Caso tipico: Il server non ha conoscenza esterna dell'identità del client.

Se il server ha conoscenza esterna (da fuori HTTP o TLS):

  • Dovrebbe (SHOULD) verificare l'identità come descritto sopra

Autenticazione con certificato client:

Scenari comuni:
- Sistemi interni aziendali
- Controllo accesso API
- TLS mutuo (mTLS)

Verifica:
- Catena di certificati radicata in CA appropriata
- Opzionale: Verificare l'identità specifica del client