Aller au contenu principal

RFC 2818 - HTTP sur TLS (HTTPS) - 2. HTTP sur TLS (HTTP Over TLS)

2. HTTP sur TLS (HTTP Over TLS)​

Principe central (Core Principle)​

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. Initiation de connexion (Connection Initiation)​

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 agit 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 MUST être envoyées en tant que « application data » TLS

Exemple de flux :

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

Serveur :
3. Répondre ServerHello + Certificate
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. Fermeture de connexion (Connection Closure)​

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

Alerte de fermeture (Closure Alert)​

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 MUST initier un échange d'alertes de fermeture avant de fermer une connexion
  • ⚠️ Les implémentations MAY fermer la connexion après l'envoi de l'alerte de fermeture (sans attendre)
  • ❌ Les connexions avec fermeture prématurée MUST NOT réutiliser la session

2.2.1. Comportement du client (Client Behavior)​

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

Le client 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, elles devraient être traitées comme complètes.

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. Comportement du serveur (Server Behavior)​

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

Le serveur 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
  • ⚡ 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. Numéro de port (Port Number)​

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. Format d'URI (URI Format)​

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