Par ailleurs, et quoi qu'on pense de la moralité et de la légalité de la chose, de nombreux services informatiques ne permettent les connexions HTTP vers l'extérieur que dans la mesure où le logiciel maison anti-virus/anti-vers/anti-trojan/anti-exfiltration d'informations peut analyser tous les flux. Les connexions HTTPS sont donc redirigées vers un mandataire TLS qui :
- se connecte au vrai serveur HTTPS
- vérifie son certificat (enfin on espère)
- crée un certificat de toute pièce en recopiant le CN (Common Name) et les SAN (Server Alternative Name) présents dans le certificat du site, certificat appartenant au mandataire
- génère une signature de ce certificat à partir de la clé privée du mandataire;
- établit une connexion avec le client Web en présentant une chaine de certificats partant de la racine propre au mandataire, qui n'est pas une racine reconnue (en principe) (*)
- relaye la requête HTTP vers le serveur
- obtient la réponse du serveur, la vérifie, la transforme (p.ex. retirer tout ce qui est suspect, parfois enlever JS)
- renvoie la réponse au client
(*) Une sous officine administrative a voulu jouer à ça en utilisant une sous autorité de certification (sans restriction) issue de plusieurs niveaux de délégation à partir de la racine de confiance de l'ANSSI, ce qui est strictement interdit, et du coup couic la sous autorité et en plus restriction par Google : l'autorité de l'ANSSI ne peut plus servir que pour un domaine autre appartenant à la France, soit fr. re. (Réunion) .mq (Martinique) .gp (Guadeloupe), gf. (Guyane française), yt. (Mayotte) tf. (Terres Australes et Antarctiques) fc. (Nouvelle - Calédonie) pf. (Polynésie française) wf. (Wallis et Futuna) pm. (Saint-Pierre et Miquelon)
Et donc le client n'a qu'une connexion vers le mandataire et ne voit que son certificat. En général, le service de "sécurité informatique" de la boite impose qu'un certificat racine du mandataire soit installé dans le magasin des certificats de confiance de l'OS; sinon, il faudra faire une "exception de sécurité".
Les problèmes de sécurité que cela pose sont évidemment aussi nombreux qu'impossible à éliminer sans éliminer le mandataire.
Cela casse le fonctionnement des certificats "EV green", les certificats à validation étendue qui font afficher l'adresse en vert, puisque la racine du mandataire n'est pas une racine EV.
Cela peut aussi complètement bloquer le surf si le "certificate pinning" est actif sur le navigateur, qui refusera alors tout certificat dont la somme de contrôle n'a pas la bonne valeur, ou dont l'autorité intermédiaire ou racine n'a pas la bonne somme de contrôle (fixer la somme de contrôle de l'autorité au lieux de celle du certificat permet de gérer de façon fluide le renouvellement des certificats).
Par ailleurs, le fait d'intercepter la connexion casse complètement la sémantique de certaines fonctions de sécurité plus évoluées qui attachent des informations privilégiées à la session TLS et non aux témoins HTTP (HTTP cookies). De plus, les sites qui utilisent les certificats clients ne fonctionneront pas.
De nombreux "outils de sécurité" s'amusent aussi à ça sur le poste client afin de contrôler les contenus téléchargés. Ces outils font la même chose mais au niveau de la source et non au milieu. L'utilisateur peut éventuellement définir des "exceptions" qui sont les domaines "de confiance" ou ceux particulièrement sensibles.
Un outil installé à l'insu de l'utilisateur peut aussi faire une telle chose. De plus, la vérification du certificat du site n'est pas toujours aussi robuste que celle du navigateur, la vérification étant un processus relativement complexe qui tient compte de très nombreux éléments :
- vérification du nom de domaine (CN ou SAN, en tenant compte du joker *) qui n'est pas une "chaîne C" et peut contenir un NUL c'est à dire le caractère '\0'
- bon chaînage des certificats,
- les certificats intermédiaires sont des autorités,
- la racine est considérée comme de confiance,
- bonne date de validité de chaque élèment,
- consultation des listes de révocation,
- restrictions éventuelles (limite par domaine, limite par nombre d'autorités intermédiaires);
Les bugs dans la vérification des certificats constatés dans des produits largement utilisés sont nombreux. Les fonctions rarement utilisées sont des pièges (comme les restrictions au niveau des autorités intermédiaires).
Des dysfonctionnement majeurs ont concerné par le passé :
- vérification du nom de domaine
- vérification des autorités intermédiaires
mais aussi le fait de considérer un certificat considéré comme non valide comme valide, ou d'accepter une clé ne correspondant pas au certificat. Ces vulnérabilités constituaient des failles catastrophiques du type n'importe qui peut contrefaire n'importe quel nom de domaine. Elles sont touché le logiciel libre comme le propriétaire, et aussi bien MS, Apple, la FSF, Mozilla...
De plus, le fait d'avoir un intermédiaire imposé au milieu peut freiner les évolutions nécessaires du protocole de SSL 3 vers TLS 1.0, puis vers 1.2.
De façon générale, la conception d'un outil cryptographique demande des compétences qui dépassent largement celle du programmeur moyen (qui arrive tout juste à comprendre qu'on ne peut pas agglomérer au pif des commandes SQL et des données fournies par l'utilisateur).
Le fait que des failles catastrophiques puissent exister dans des outils de base largement utilisés, y compris des programmes opensource, montre à quel point la disponibilité du code source ne suffit pas, tellement ce code est subtil et pénible à lire.
IPv6