L’acronyme HTTPS désigne l’encapsulation du protocole HTTP au travers du protocole SSL. A ce titre, il bénéficie de la solidité du protocole SSL mais présente l’inconvénient inhérent au protocole SSL et qui oblige à chiffrer l’intégralité des données de la page Web.

S-HTTP (Secure HTTP) est un procédé de sécurisation des transactions HTTP reposant sur une amélioration du protocole HTTP mise au point en 1994 par l'EIT (Enterprise Integration Technologies). Il permet de fournir une sécurisation des échanges lors de transactions de commerce électronique en cryptant les messages afin de garantir aux clients la confidentialité des données échangées. Une implémentation de S-HTTP a été développée par la société Terisa Systems afin d'inclure une sécurisation au niveau des serveurs web et des navigateurs.

Contrairement à SSL qui travaille au niveau de la couche de transport, S-HTTP procure une sécurité basée sur des messages au-dessus du protocole HTTP, en marquant individuellement les documents HTML à l'aide de « certificats ». Ainsi, alors que SSL est indépendant de l'application utilisée et chiffre l'intégralité de la communication, S-HTTP est très fortement lié au protocole HTTP et chiffre individuellement chaque message.
Le format S-HTTP est basé sur la syntaxe CMS (Cryptographic Message Syntax) décrite dans la RFC 2630. CMS est une variante du format PKCS#7 utilisé dans le protocole S/MIME (cf. paragraphe ‎7.2.6 - ). Un message S-HTTP ressemble à un message standard HTTP mais le corps du message est écrit au format CMS.

Les messages S-HTTP sont basés sur trois composantes:

Ainsi, pour déchiffrer un message S-HTTP, le destinataire du message analyse les en-têtes du message afin de déterminer le type de méthode qui a été utilisé pour chiffrer le message. Puis, grâce à ses préférences cryptographiques actuelles et précédentes, ainsi que des préférences cryptographiques précédentes de l'expéditeur, il est capable de déchiffrer le message.

CMS est un protocole fournissant des mécanismes d’encryption et de signature de données. Chaque message CMS possède un type décrivant le mécanisme cryptographique utilisé pour chiffrer les données. Le protocole CMS définit six types de messages :

un message signé contient des données accompagnées d’une ou de plusieurs signatures du contenu. Les implémentations techniques de ce type de message effectuent un hachage du contenu signé par la clé publique de l’émetteur. Ce type de message peut inclure les certificats permettant la vérification des signatures utilisées ainsi que l’adresse de la CRL permettant de vérifier la validité des dits certificats.

un message chiffré contient des données chiffrées. Les données peuvent être chiffrées à l’aide d’une clé pré partagée ou via un mécanisme clé publique/clé privée.

A l’inverse du protocole HTTPS, le protocole S-HTTP utilise le même port de communication que le protocole HTTP. De manière à identifier une page S-HTTP, deux balises HTML particulières nommées « Secure » (identifiant le protocole S-HTTP) et « Content-Privacy-Domain » (identifiant l’utilisation du protocole CMS) sont présentes dans les entêtes de pages HTML.

Il est reconnu qu’en général plus les mécanismes offrant de la sécurité sont proches du niveau applicatif, plus ceux-ci permettent une flexibilité et une efficience importante. Cette flexibilité s’accompagne par contre d’une complexité en général plus importante. Ainsi bien que le protocole S-HTTP présente une adaptation au protocole HTTP beaucoup plus importante, les mécanismes mis en œuvre dans le cadre de ce protocole sont considérablement plus compliqués à mettre en œuvre.

La différence la plus significative entre les deux protocoles réside dans le fait que le protocole S-HTTP est beaucoup plus flexible que le protocole HTTPS. En effet, chaque ressource protégée par les mécanismes S-HTTP peuvent en théorie bénéficier de procédures de chiffrement adaptées à la nature des informations véhiculées. En pratique cette flexibilité est rarement nécessaire et l’adoption de mécanismes basés sur un couple clé privée/clé publique est souvent de mise. Il est à noter cependant que le protocole HTTPS n’offre aucune possibilité de segmentation des moyens de chiffrement au regard des données transportées.

Les mécanismes de non répudiation mis en œuvre dans le cadre d’une implémentation du protocole S-HTTP ne peuvent être retrouvés dans une implémentation du protocole HTTPS. En effet, rien ne permet de prouver qu’une requête ou une réponse ont bien été faites par l’émetteur au sein d’une liaison chiffrée via le protocole SSL. A l’inverse, une page S-HTTP contient la signature de l’intégralité du message et il est très facile coté client ou serveur de requérir une trame signée de confirmation.

Il est relativement difficile de mettre en place des serveurs Web virtuels protégés par HTTPS. En effet, le nom du serveur contenu dans le certificat présenté lors de la session SSL changeant en fonction du serveur Web virtuel contacté, la mise en place d’hôtes virtuels protégés par HTTPS est possible quoique délicate. La même mise en place de serveurs Web virtuels protégés par S-HTTP ne présente aucune difficulté, les certificats étant contenus dans les pages examinées.

En terme techniques, le protocole S-HTTP présente une flexibilité et une intégration au protocole HTTP beaucoup plus importante que le protocole HTTPS. Le fait que le protocole S-HTTP soit plus délicat à implémenter que le protocole HTTPS fait que ce dernier est le leader incontesté du marché.