Aller au contenu principal

RFC 2818 - HTTP sur TLS (HTTPS) - 3. Identification des points d'extrémité (Endpoint Identification)

3. Identification des points d'extrémité (Endpoint Identification)​

3.1. Identité du serveur (Server Identity)​

Exigence centrale : Les clients MUST vérifier l'identité du serveur pour prévenir les attaques de l'homme du milieu (man-in-the-middle).

Processus de vérification d'identité (Identity Verification Process)​

1. Le client obtient le nom d'hôte de l'URI
   par exemple : https://www.example.com

2. Le serveur fournit un certificat lors de la négociation TLS

3. Le client vérifie si le nom d'hôte correspond à l'identité du certificat

Priorité des champs d'identité (Identity Field Priority)​

Priorité 1 : subjectAltName (Nom alternatif du sujet)

Extension subjectAltName dans le certificat (type dNSName) :
dNSName: www.example.com
dNSName: api.example.com

← Ce champ MUST être utilisé (s'il est présent) →

Priorité 2 : Common Name (Nom commun)

CN dans le champ Subject du certificat :
CN=www.example.com

← Utiliser uniquement en l'absence de subjectAltName →
← Déprécié, les CA devraient utiliser dNSName →

Règles de correspondance (Matching Rules)​

1. Correspondance avec caractères génériques :

Certificat : *.example.com
✅ Correspond : foo.example.com
❌ Ne correspond pas : bar.foo.example.com

Certificat : f*.com
✅ Correspond : foo.com
❌ Ne correspond pas : bar.com

2. Adresses IP :

URI : https://192.168.1.1/
Le certificat doit contenir : iPAddress subjectAltName
La valeur doit correspondre exactement : 192.168.1.1

3. Identités multiples :

Si le certificat contient plusieurs dNSName :
- www.example.com
- api.example.com
- *.app.example.com

← La correspondance avec l'un d'eux est acceptable →

Comportement en cas de non-correspondance (Behavior When No Match)​

Clients orientés utilisateur (navigateurs) :

  • ✅ MUST notifier l'utilisateur
  • ⚠️ MAY donner à l'utilisateur l'option de continuer
  • Ou terminer la connexion

Clients automatisés (clients API) :

  • ✅ MUST enregistrer l'erreur dans un journal d'audit
  • ✅ SHOULD terminer la connexion
  • ⚠️ MAY fournir une option de configuration pour désactiver la vérification

Avertissement de sécurité (Security Warning)​

Source d'URI non fiable :

Scénario d'attaque :
1. L'utilisateur clique sur un lien dans une page HTTP
2. La page HTTP elle-même n'est pas chiffrée
3. L'homme du milieu peut avoir remplacé l'URI

Protection :
Les utilisateurs devraient examiner attentivement le certificat du serveur

3.2. Identité du client (Client Identity)​

Cas typique : Le serveur n'a pas de connaissance externe de l'identité du client.

Si le serveur a une connaissance externe (en dehors de HTTP ou TLS) :

  • Devrait vérifier l'identité comme décrit ci-dessus

Authentification par certificat client :

Scénarios courants :
- Systèmes internes d'entreprise
- Contrôle d'accès aux API
- TLS mutuel (mTLS)

Vérification :
- Chaîne de certificats ancrée dans une CA appropriée
- Optionnel : Vérifier l'identité spécifique du client