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