Résumé

  • Le RFC 2817 voulait lancer TLS après un échange HTTP/1.1 initial, sur le port 80. Le champ Host envoyé avant la négociation pouvait aider un serveur à choisir le certificat d'un hôte virtuel.
  • Le texte conservait deux espaces d'adresses, http et https, et constatait en 2000 le peu d'intérêt pour une solution de navigation courante qui remplacerait le port 443.

Deux portes accueillaient les visiteurs du Web. Le port 80 recevait HTTP en clair. Une adresse https conduisait vers le port 443, où TLS commençait avant la première requête HTTP. Multiplier ainsi les paires de ports pour les autres protocoles sécurisés agaçait déjà les responsables de l'IETF en décembre 1997. Leur réponse, publiée au printemps 2000, ressemblait à une idée de concierge pressé : poser une serrure sur la porte existante.

Le RFC 2817 de mai 2000 proposait un Upgrade vers TLS/1.0 sur la connexion HTTP/1.1 en cours. Le trafic ordinaire et le trafic chiffré auraient ainsi pu partager le port 80. Le projet répondait aussi au problème des sites virtuels. HTTP/1.1 indiquait le nom voulu dans Host, ce qui permettait à plusieurs sites de se partager une adresse IP. Avant cette requête, la négociation TLS usuelle ne fournissait pas au serveur le nom dont cette proposition avait besoin pour choisir son certificat. Le début en HTTP clair lui donnait ce renseignement avant l'entrée dans TLS.

Une requête initiale ne suffisait pourtant pas à sécuriser les suivantes. Le RFC 2616 définissait Upgrade comme un changement entre deux voisins immédiats de la chaîne HTTP. Un client pouvait proposer TLS avec les champs Upgrade et Connection: Upgrade. S'il acceptait une réponse non chiffrée, le serveur pouvait continuer normalement. Pour une opération dont la réponse en clair était inacceptable, le RFC 2817 prescrivait d'envoyer d'abord OPTIONS *. Cette requête préparatoire laissait la négociation se terminer avant que la véritable opération sensible quitte le client.

Un serveur disposé à changer répondait 101 Switching Protocols avec la pile ordonnée TLS/1.0, HTTP/1.1. Le basculement survenait après les en-têtes de la réponse, puis venait la négociation TLS; l'échange HTTP se poursuivait ensuite dans le canal sécurisé. Un autre code, 426 Upgrade Required, permettait au serveur d'indiquer que la ressource exigeait ce changement. Le client devait encore mener la procédure d'Upgrade. L'affiche sur la porte ne tournait pas elle-même la serrure.

Le détour par un proxy demandait une autre manœuvre. Comme Upgrade ne valait que pour un saut, un 101 émis par le proxy modifiait la liaison avec le client, tandis qu'un 101 de l'origine modifiait la liaison avec le proxy. Pour joindre l'origine par TLS, le RFC 2817 décrivait une connexion tunnel établie par CONNECT, même vers le port 80. Une réponse 2xx marquait l'ouverture du tunnel; le client pouvait ensuite négocier directement avec le serveur. La porte unique ne supprimait donc pas le couloir.

L'obstacle le plus solide tenait aux adresses elles-mêmes. Le RFC 2817 conservait la distinction entre http:// et https://. Son compagnon du même mois, RFC 2818, décrivait l'usage déjà installé : port 443 par défaut, message TLS ClientHello d'abord, requête HTTP ensuite, et schéma https pour identifier ce chemin. Choisir la même porte réseau pour deux modes de transport ne fusionnait pas les adresses que les lecteurs et les clients utilisaient.

Les auteurs du RFC 2817 ont consigné la réaction de leur époque avec franchise. Ils notaient que l'idée générale avait été bien accueillie, mais qu'une solution remplaçant 443 pour la navigation Web courante suscitait peu d'intérêt d'implémentation. Ils voyaient davantage d'utilité pour des applications nouvelles bâties sur HTTP, comme le protocole d'impression Internet. Cette observation est datée de 2000; elle suffit à mesurer l'écart entre un plan technique et une habitude déjà inscrite dans les liens.

Le projet avait une logique solide : économiser des ports parallèles, choisir un certificat après avoir lu Host, offrir au serveur un moyen explicite de demander TLS. Il devait aussi traverser un début en clair, une réponse d'acceptation, les tunnels des proxys et une frontière entre deux types d'URI. TLS pouvait se présenter au port 80; la porte 443 avait déjà son nom sur l'invitation.