Aller au contenu principal

RFC 2818 - HTTP Over TLS (HTTPS)

Statut : Document informatif
Auteur : E. Rescorla (RTFM, Inc.)
Date : Mai 2000

Résumé (Abstract)​

Ce mémo décrit comment utiliser TLS pour sécuriser les connexions HTTP sur Internet. La pratique actuelle consiste à superposer HTTP sur SSL (le prédécesseur de TLS), en distinguant le trafic sécurisé du trafic non sécurisé par l'utilisation d'un port serveur différent. Ce document documente cette pratique en utilisant TLS.

Importance​

RFC 2818 est la pierre angulaire de la sécurité Web :

  • 🔒 Définit le mécanisme de base de HTTPS
  • 🌐 Fondement de la sécurité pour tous les sites Web modernes
  • 🔑 Validation des certificats et vérification d'identité
  • ⚡ Établissement et fermeture de connexion sécurisée

1. Introduction​

HTTP [RFC2616] était à l'origine utilisé en clair sur Internet. Cependant, l'utilisation accrue de HTTP pour des applications sensibles a nécessité des mesures de sécurité. SSL, et son successeur TLS [RFC2246] ont été conçus pour fournir une sécurité orientée canal. Ce document décrit comment utiliser HTTP sur TLS.

Concept central​

HTTPS = HTTP + TLS

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

1.1. Terminologie des exigences (Requirements Terminology)​

Les mots-clés « doit (MUST) », « ne doit pas (MUST NOT) », « requis (REQUIRED) », « devrait (SHOULD) », « ne devrait pas (SHOULD NOT) » et « peut (MAY) » qui apparaissent dans ce document doivent être interprétés comme décrit dans [RFC2119].

2. HTTP Over TLS (HTTP sur TLS)​

Principe central​

Conceptuellement très simple : HTTP/TLS est très simple. Utilisez simplement HTTP sur TLS précisément comme vous utiliseriez HTTP sur TCP.

2.1. Connection Initiation (Initiation de connexion)​

Processus :

1. Client → Serveur : Établir une connexion TCP (port 443)
2. Client → Serveur : Envoyer TLS ClientHello
3. ↔ Processus de négociation TLS ↔
4. Après la négociation : Le client peut initier la première requête HTTP

Exigences :

  • ✅ Le client HTTP doit (MUST) agir en tant que client TLS
  • ✅ Se connecter au port approprié (par défaut 443)
  • ✅ Envoyer TLS ClientHello pour commencer la négociation
  • ✅ Toutes les données HTTP doivent (MUST) être envoyées en tant que « données d'application » TLS

Exemple de flux :

Client :
1. Connexion TCP à www.example.com:443
2. Envoyer ClientHello

Serveur :
3. Répondre ServerHello + Certificat
4. ServerHelloDone

Client :
5. ClientKeyExchange
6. ChangeCipherSpec
7. Finished

Serveur :
8. ChangeCipherSpec
9. Finished

← Négociation TLS terminée →

Client :
10. Envoyer une requête HTTP chiffrée :
    GET / HTTP/1.1
    Host: www.example.com

2.2. Connection Closure (Fermeture de connexion)​

TLS fournit une facilité pour la fermeture sécurisée de connexion.

Closure Alert (Alerte de fermeture)​

Définitions :

  • Fermeture valide (Valid Closure) : Alerte de fermeture correcte reçue
  • Fermeture incomplète (Incomplete Close) : Fermer la connexion immédiatement après l'envoi de l'alerte de fermeture
  • Fermeture prématurée (Premature Close) : Connexion fermée sans recevoir d'alerte de fermeture

Exigences :

  • ✅ Les implémentations doivent (MUST) initier un échange d'alertes de fermeture avant de fermer une connexion
  • ⚠️ Les implémentations peuvent (MAY) fermer la connexion après l'envoi de l'alerte de fermeture (sans attendre)
  • ❌ Les connexions avec fermeture prématurée ne doivent pas (MUST NOT) réutiliser la session

2.2.1. Client Behavior (Comportement du client)​

Problème : HTTP utilise la fermeture de connexion pour signaler la fin des données du serveur.

Le client doit (MUST) :

  • ✅ Traiter toute fermeture prématurée comme une erreur
  • ✅ Traiter les données reçues comme potentiellement tronquées
  • ✅ Envoyer une alerte de fermeture avant de fermer la connexion

Cas particuliers :

  1. Réponse sans Content-Length :
HTTP/1.1 200 OK
Content-Type: text/html
[La fermeture de connexion indique la fin]

← La fermeture prématurée ne peut pas distinguer le serveur de l'attaquant →
  1. Content-Length présent mais pas entièrement lu :
HTTP/1.1 200 OK
Content-Length: 1000
[Seulement 500 octets reçus avant la fermeture]

← Impossible de déterminer si c'est une erreur serveur ou une attaque →

Exception : Si les données reçues correspondent à Content-Length, devrait (SHOULD) être traité comme complet.

Exemple client :

✅ Fermeture normale :
Client : Envoyer closure_alert
Attendre closure_alert du serveur
Fermer la connexion

⚡ Fermeture rapide :
Client : Envoyer closure_alert
Fermer la connexion immédiatement (ne pas attendre)
← Cela génère une fermeture incomplète côté serveur →

2.2.2. Server Behavior (Comportement du serveur)​

Exigence RFC 2616 : Les serveurs doivent (MUST) se rétablir gracieusement de la fermeture du client.

Le serveur devrait (SHOULD) :

  • ✅ Être préparé à recevoir une fermeture incomplète du client
  • ✅ Être disposé à reprendre les sessions TLS fermées de cette manière
  • ✅ Tenter d'échanger des alertes de fermeture avec le client
  • ⚡ Peut (MAY) fermer la connexion après l'envoi de l'alerte de fermeture

Note d'implémentation :

HTTP sans connexions persistantes :
- Le serveur signale la fin des données en fermant la connexion
- Mais le client peut avoir déjà envoyé l'alerte de fermeture et déconnecté

2.3. Port Number (Numéro de port)​

Port par défaut : 443

Justification :

Le serveur HTTP attend : Request-Line (par exemple, GET / HTTP/1.1)
Le serveur TLS attend : ClientHello

← Impossible de distinguer sur le même port →

Solution : Utiliser des ports différents
- HTTP : 80
- HTTPS : 443

Exemples :

# HTTP (texte clair)
curl http://www.example.com:80/

# HTTPS (chiffré)
curl https://www.example.com:443/

2.4. URI Format (Format d'URI)​

Identificateur de protocole : https:// (au lieu de http://)

Exemples :

https://www.example.com/~smith/home.html
https://api.example.com:8443/v1/users
https://192.168.1.1/admin

Composants d'URI :

https://www.example.com:443/path?query#fragment
  ↑         ↑              ↑     ↑     ↑     ↑
scheme    host           port  path  query fragment

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

3.1. Server Identity (Identité du serveur)​

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

Processus de vérification d'identité​

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é​

Priorité 1 : subjectAltName (Nom alternatif du sujet)

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

← Ce champ doit (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​

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 (MUST) contenir : iPAddress subjectAltName
La valeur doit (MUST) 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​

Clients orientés utilisateur (navigateurs) :

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

Clients automatisés (clients API) :

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

Avertissement de sécurité​

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. Client Identity (Identité du client)​

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 (SHOULD) 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

Security Considerations (Considérations de sécurité)​

Ce document entier concerne la sécurité.

Points de sécurité clés​

  1. La validation des certificats est obligatoire (Mandatory)

    • Les clients doivent (MUST) vérifier les certificats du serveur
    • Prévient les attaques de l'homme du milieu

  2. Fermeture de connexion appropriée (Proper Connection Closure)

    • Utiliser les alertes de fermeture TLS
    • Détecte les attaques de troncature de données

  3. Vérification du nom d'hôte (Hostname Verification)

    • Prévient les attaques de substitution de certificat
    • Préférer subjectAltName à CN

  4. Méfiez-vous des URI non fiables (Beware Untrusted URIs)

    • Les URI obtenus via HTTP peuvent être altérés
    • Les utilisateurs devraient examiner les certificats

Exemples pratiques​

Connexion HTTPS complète​

Opérations du client :

1. Analyser l'URI : https://www.example.com/page.html
   → Nom d'hôte : www.example.com
   → Port : 443 (par défaut)

2. Connexion TCP à www.example.com:443

3. Négociation TLS :
   ClientHello →
   ← ServerHello + Certificate
   Vérifier le nom d'hôte dans le certificat
   ...négociation terminée...

4. Envoyer une requête HTTP chiffrée :
   GET /page.html HTTP/1.1
   Host: www.example.com

5. Recevoir une réponse HTTP chiffrée :
   HTTP/1.1 200 OK
   Content-Length: 1234
   ...

6. Fermer la connexion :
   Envoyer closure_alert
   Fermer la connexion TCP

Exemple de vérification de certificat​

# Exemple Python (conceptuel)
import ssl
import socket

# Créer un contexte SSL
context = ssl.create_default_context()

# Se connecter au serveur
sock = socket.create_connection(('www.example.com', 443))
ssock = context.wrap_socket(sock, server_hostname='www.example.com')

# wrap_socket vérifie automatiquement :
# 1. La chaîne de certificats est valide
# 2. Le nom d'hôte correspond
# 3. Le certificat n'est pas expiré

# Obtenir les informations du certificat
cert = ssock.getpeercert()
print(f"Subject: {cert['subject']}")
print(f"Issuer: {cert['issuer']}")
print(f"SANs: {cert.get('subjectAltName', [])}")

Gestion des erreurs courantes​

Erreur 1 : Non-correspondance du nom d'hôte du certificat
Certificate Hostname Mismatch
- Certificat : *.example.com
- Accès : www.different.com
→ Terminer la connexion ou avertir l'utilisateur

Erreur 2 : Certificat expiré
Certificate Expired
- Not After : 2023-12-31
- Actuel : 2024-01-01
→ Refuser la connexion

Erreur 3 : Certificat auto-signé
Self-Signed Certificate
- Pas dans la liste des CA de confiance
→ Avertir l'utilisateur ou refuser

Erreur 4 : Chaîne de certificats incomplète
Incomplete Certificate Chain
- Certificat intermédiaire manquant
→ Impossible de vérifier, refuser la connexion

Relation avec les normes modernes​

Successeurs de RFC 2818​

Bien que RFC 2818 reste valide, il existe des spécifications mises à jour :

RFCTitreDescription
RFC 2818HTTP Over TLSCe document (2000)
RFC 5246TLS 1.2Protocole TLS mis à jour
RFC 8446TLS 1.3Dernier protocole TLS
RFC 6125Validation des certificatsVérification détaillée du nom d'hôte
RFC 7230-7235HTTP/1.1Spécifications HTTP mises à jour
RFC 7540HTTP/2HTTP/2 fonctionne généralement sur TLS

Mises à jour des pratiques modernes​

  1. Versions TLS :
RFC 2818 : SSL/TLS (1.0/1.1)
Moderne : TLS 1.2+ (TLS 1.0/1.1 déprécié)
  1. Validation des certificats :
RFC 2818 : Règles de base
RFC 6125 : Spécifications détaillées
  1. HSTS :
RFC 6797 : HTTP Strict Transport Security
Force les navigateurs à utiliser HTTPS

Référence rapide​

HTTPS vs HTTP​

FonctionnalitéHTTPHTTPS
Protocolehttp://https://
Port80443
Chiffrement❌ Texte clair✅ Chiffré TLS
Intégrité❌ Aucune protection✅ Protection MAC
Authentification❌ Pas d'auth serveur✅ Auth par certificat
Confidentialité❌ Peut être intercepté✅ Transmission chiffrée

Aperçu de la négociation TLS​

Client                           Serveur
  |                                |
  |--- ClientHello --------------->|
  |                                |
  |<-- ServerHello, Certificate ---|
  |<-- ServerHelloDone ------------|
  |                                |
  |--- ClientKeyExchange --------->|
  |--- ChangeCipherSpec ---------->|
  |--- Finished ------------------>|
  |                                |
  |<-- ChangeCipherSpec -----------|
  |<-- Finished -------------------|
  |                                |
  |=== Canal chiffré établi ======|
  |                                |
  |--- Requête HTTP chiffrée ----->|
  |<-- Réponse HTTP chiffrée ------|

Outils courants​

# OpenSSL afficher le certificat
openssl s_client -connect www.example.com:443 -showcerts

# Tester la version TLS
openssl s_client -connect www.example.com:443 -tls1_2

# Afficher les détails du certificat
echo | openssl s_client -connect www.example.com:443 2>/dev/null | \
  openssl x509 -noout -text

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

Références​

Références normatives​

  • [RFC 2119] - Mots-clés à utiliser dans les RFC pour indiquer les niveaux d'exigence
  • [RFC 2246] - Le protocole TLS
  • [RFC 2459] - Infrastructure à clé publique Internet X.509 Profil de certificat et CRL
  • [RFC 2616] - Protocole de transfert hypertexte -- HTTP/1.1

Références informatives​

  • [RFC 2817] - Mise à niveau vers TLS dans HTTP/1.1
  • [RFC 5246] - Le protocole Transport Layer Security (TLS) Version 1.2
  • [RFC 6125] - Représentation et vérification de l'identité de service d'application basée sur le domaine
  • [RFC 6797] - HTTP Strict Transport Security (HSTS)
  • [RFC 7230-7235] - Protocole de transfert hypertexte (HTTP/1.1) Spécifications mises à jour
  • [RFC 8446] - Le protocole Transport Layer Security (TLS) Version 1.3

Glossaire​

Termes centraux​

TLS (Transport Layer Security)

  • Protocole de sécurité de la couche transport, successeur de SSL

SSL (Secure Sockets Layer)

  • Prédécesseur de TLS, maintenant déprécié

Certificate (Certificat)

  • Document numérique contenant une clé publique et des informations d'identité

CA (Certificate Authority / Autorité de certification)

  • Autorité de certification qui émet des certificats de confiance

Closure Alert (Alerte de fermeture)

  • Mécanisme TLS pour la fermeture sécurisée de connexion

Premature Close (Fermeture prématurée)

  • Fermeture inappropriée de connexion TLS

Man-in-the-Middle Attack (Attaque de l'homme du milieu)

  • L'attaquant intercepte et potentiellement modifie la communication

subjectAltName (Nom alternatif du sujet)

  • Extension de certificat spécifiant des noms d'hôte supplémentaires

Common Name (Nom commun)

  • Champ CN dans le sujet du certificat

Retour : Liste des documents RFC

RFC connexes :

Dernière mise à jour le