Worldlex Wiki Le protocole S-HTTP ( Secure Hypertext Transfer Protocol ) est une alternative obsolète au protocole HTTPS pour le chiffrement des communications web sur Internet. Il a été développé par Eric Rescorla et Allan M. Schiffman chez Enterprise Integration Technologies en 1994 et publié en 1999 sous la référence RFC 2660. La domination de Netscape sur le marché des navigateurs a fait du HTTPS la méthode de facto pour sécuriser les communications web.
Comparaison avec HTTP sur TLS (HTTPS)
Le protocole S-HTTP chiffre uniquement les données de la page servie et les données soumises, telles que les champs POST, laissant inchangée l'initialisation du protocole. De ce fait, S-HTTP peut être utilisé simultanément avec HTTP (non sécurisé) sur le même port, car l'en-tête non chiffré détermine si le reste de la transmission est chiffré.
À l'inverse, HTTP sur TLS encapsule l'intégralité de la communication dans un protocole de sécurité de la couche transport (TLS ; anciennement SSL), de sorte que le chiffrement commence avant même l'envoi des données. Cela crée un problème de dépendance croisée (« la poule et l'œuf ») lié à l'hébergement virtuel, car il s'agit de déterminer quel nom DNS était destiné à la requête.
Cela signifie que les implémentations HTTPS sans prise en charge de l'indication du nom du serveur (SNI) nécessitent une adresse IP distincte par nom DNS, et toutes les implémentations HTTPS nécessitent un port distinct (généralement 443 contre le port standard 80 de HTTP) pour une utilisation non ambiguë du chiffrement (traité dans la plupart des navigateurs comme un schéma URI distinct , https:// ).
Comme indiqué dans la RFC 2817 , le protocole HTTP peut également être sécurisé en implémentant les en-têtes HTTP/1.1 Upgrade et en passant à TLS. L'exécution de HTTP sur TLS négocié de cette manière n'entraîne pas les mêmes conséquences que HTTPS en matière d'hébergement virtuel basé sur le nom (pas d'adresses IP, de ports ou d'espace URI supplémentaires). Cependant, peu d'implémentations prennent en charge cette méthode.
Dans S-HTTP, l'URL souhaitée n'est pas transmise en clair dans les en-têtes, mais laissée vide ; un autre ensemble d'en-têtes est présent dans la charge utile chiffrée. Dans HTTP sur TLS, tous les en-têtes sont inclus dans la charge utile chiffrée et l'application serveur n'a généralement pas la possibilité de se remettre correctement des erreurs fatales TLS (notamment « certificat client non approuvé » et « certificat client expiré »).