Le protocole de trans­mis­sion SSL (Secure Sockets Layer) et son suc­ces­seur TLS (Transport Layer Security) comptent parmi les com­po­sants les plus im­por­tants d’une présence Web sécurisée. En effet, ils chiffrent les données que les na­vi­ga­teurs et les serveurs échangent via HTTP avant qu’elles ne soient envoyées, même lors de la com­mu­ta­tion entre un HTTPS chiffré et une page non protégée. Ce procédé permet non seulement d’empêcher le transfert de données standard en texte clair, mais aussi d’envoyer un cookie configuré sous SSL avec une connexion non sécurisée. Les cer­ti­fi­cats utiles ga­ran­tis­sent l’au­then­ti­cité du nom d’hôte du serveur au client demandeur. Le protocole TLS offre donc une sécurité à plusieurs égards, ce qui rend son uti­li­sa­tion in­dis­pen­sable lors de la trans­mis­sion de données sensibles.

En général, TLS est l’un des pro­to­coles les plus sécurisés et a jusqu’à présent bien résisté contre les ten­ta­tives d’attaque. Cependant, dans certaines cir­cons­tances, des outils spéciaux (comme Sslstrip programmé à des fins de dé­mons­tra­tion) peuvent avoir accès au transfert de données avant le début du chif­fre­ment. Un tel accès externe non autorisé est appelé « Stripping SSL » :

Cer­ti­fi­cats SSL
Faites le choix de la sécurité
  • Sécurisez vos trans­ferts de données
  • Renforcez la confiance de vos clients
  • Améliorez votre po­si­tion­ne­ment sur Google

Qu’est-ce que le SSL Stripping ?

En 2002, le dé­ve­lop­peur Moxie Mar­lins­pike a programmé Sslsniff, un outil capable d’éliminer le chif­fre­ment SSL. Le logiciel proxy per­met­tait d’infiltrer les flux de données SSL et d’échanger le cer­ti­fi­cat serveur avec l’un de ses propres cer­ti­fi­cats. Avec son ap­pli­ca­tion, Mar­lins­pike a voulu souligner le point faible d’Internet Explorer, qui était au moment de la pu­bli­ca­tion de Sslsniff par­ti­cu­liè­re­ment vul­né­rable aux attaques de l’homme du milieu. Microsoft a été en mesure de combler la faille de sécurité, et d’autres clients connus sont main­te­nant largement protégés contre ce type d’attaque, à condition d’avoir la version actuelle et la bonne con­fi­gu­ra­tion.

Le programme Sslstrip a été présenté par Mar­lins­pike en 2009 dans le cadre de la con­fé­rence sur la sécurité Black Hat DC. Comme son précédent outil, Sslstrip est un proxy qui se po­si­tionne entre le client et le serveur et tente de con­tour­ner la cer­ti­fi­ca­tion des na­vi­ga­teurs. À cette fin, l’outil recherche spé­ci­fi­que­ment sur les sites Web délivrés par les serveurs Web, des liens et des re­di­rec­tions intégrés, qu’il redirige vers une page d’ouverture de session protégée par SSL, comme le lien suivant :

<a href="https://exemple.com/login.php">

Si le proxy trouve un tel lien, il le modifie en un lien HTTP équi­valent. L’uti­li­sa­teur envoie l’en­re­gis­tre­ment avec son na­vi­ga­teur au lieu des données or­di­naires pré­ten­du­ment chiffrées, en texte clair. Grâce à Sslstrip, le hackeur potentiel se po­si­tionne en tant que station in­ter­mé­diaire et peut ainsi fa­ci­le­ment lire et accéder à des in­for­ma­tions con­fi­den­tielles. Comme le SSL Stripping ne provoque pas de connexion invalide, aucun message d’aver­tis­se­ment n’apparait. En règle générale, l’uti­li­sa­teur ne remarque même pas que les données sont trans­mises sans chif­fre­ment.

Comment im­plé­men­ter un SSL strip ?

Peu importe si Sslstrip ou une autre ap­pli­ca­tion similaire est utilisée, la première chose né­ces­saire pour le hackeur est de basculer son proxy entre le na­vi­ga­teur et le serveur Web. Ce n’est que si le logiciel est capable d’in­ter­cep­ter ou de trans­mettre des flux de données qu’il a la pos­si­bi­lité d’insérer des URL modifiées par le SSL stripping. Les trois méthodes suivantes sont les plus cou­ram­ment utilisées pour la mise en œuvre :

  1. Entrée in­cor­recte du proxy dans les options du na­vi­ga­teur : si votre système est la cible de cy­ber­cri­mi­nels, ce n’est souvent pas l’ensemble de l’or­di­na­teur mais sim­ple­ment le na­vi­ga­teur qui est vé­ri­ta­ble­ment ciblé. Les pro­grammes mal­veil­lants s’assurent alors qu’un serveur proxy externe est au­to­ma­ti­que­ment saisi dans les pa­ra­mètres sans que l’uti­li­sa­teur ne s’en aperçoive.

  2. ARP ou NDP Spoofing : au sein d’un sous-réseau, un attaquant peut utiliser l’ ARP Spoofing (IPv4) ou le NDP Spoofing (IPv6) afin de mettre son proxy en jeu. Les deux pro­to­coles servent à résoudre les adresses IP en adresses ma­té­rielles cor­res­pon­dantes (également appelées adresses MAC). En utilisant les messages manipulés de ces pro­to­coles, le hackeur peut remplacer les adresses ma­té­rielles demandées par celles de son propre système, puis in­ter­cep­ter les paquets de données trans­mises.

  3. Mettre en place son propre hotspot : la troisième option est que le pé­ri­phé­rique sur lequel le serveur proxy est en cours d’exécution peut également agir comme un routeur. En tant que pas­se­relle standard com­pre­nant un serveur DHCP, elle peut ensuite attribuer des adresses IP aux uti­li­sa­teurs, par exemple, mais elle peut aussi lire et trans­fé­rer des paquets envoyés au-delà des limites du sous-réseau créé. Ceci fournit également la base parfaite pour le SSL stripping.

Dès que le proxy est po­si­tionné, l’attaquant n’a alors en principe pas besoin de faire grand-chose de plus pour le SSL strip : il doit juste exécuter l’outil, qui envoie des liens modifiés dans les si­tua­tions ap­pro­priées et en cas de succès délivre des in­for­ma­tions non chiffrées comme les données bancaires ou de con­nexions de l’uti­li­sa­teur.

En tant qu’uti­li­sa­teur, puis-je re­con­naitre le SSL Stripping ?

Le serveur et le na­vi­ga­teur n’ont pas la capacité de détecter un SSL strip. Les deux ap­pli­ca­tions supposent qu’elles com­mu­ni­quent avec le véritable par­te­naire contacté, de sorte qu’elles ne doutent pas de l’intégrité des données trans­mises. Pour les uti­li­sa­teurs, la situation est assez similaire, car à première vue, la visite du site semble se dérouler comme souhaité. Les pages ma­ni­pu­lées par SSL stripping ne sont re­con­nais­sables que dans quelques cas ex­cep­tion­nels sur la base de détails tech­niques ou de con­cep­tion. À moins d’une mise en page re­mar­qua­ble­ment pro­blé­ma­tique ou de retards im­por­tants lors du char­ge­ment de la page, il y très peu de signes indiquant que le chif­fre­ment SSL est absent.

Cependant, depuis un certain temps déjà, les lignes d’adresses des na­vi­ga­teurs apportent des conseils et in­for­ma­tions de dif­fé­rentes manières. Par exemple, pour marquer les pages Web avec une connexion sécurisée, la barre d’adresse dans les anciennes versions d’Internet Explorer de Microsoft était en­tiè­re­ment verte. D’autres na­vi­ga­teurs ne mettaient en évidence que le nom précédent de l’en­tre­prise, jusqu’à ce que ce type de sig­na­li­sa­tion, commun aux premiers appareils mobiles com­pa­tibles avec le Web, soit remplacé par les symboles actuels et courants que sont notamment le cadenas de sécurité. Mais même ces indices visuels ne ga­ran­tis­sent pas toujours le fait que le page visitée n’a pas été manipulée par des outils comme Sslstrip. Puisque un hackeur contrôle l’ensemble du transfert de données, il est alors tout à fait capable de délivrer un symbole similaire faisant office de favicon pour parfaire sa tromperie.

Quels sont les options de pro­tec­tion ?

La dif­fi­culté à détecter les pages ma­ni­pu­lées rend les attaques de SSL stripping dan­ge­reuses pour les uti­li­sa­teurs : les cer­ti­fi­cats de chif­fre­ment utilisés par tous les ex­ploi­tants de sites Web sérieux sont synonymes de sécurité et de fiabilité et éliminent les in­quié­tudes des visiteurs au niveau de la di­vul­ga­tion de données per­son­nelles. De plus, en principe, SSL offre aussi la pro­tec­tion né­ces­saire, car la pos­si­bi­lité de lire et d’in­ter­cep­ter des paquets de données ne résulte pas d’une faille de sécurité dans le protocole même, mais vient du fait que le chif­fre­ment même est empêché. Afin de se protéger des Ssl strip, chaque uti­li­sa­teur doit donc forcer l’éta­blis­se­ment de con­nexions chiffrées HTTPS, par exemple par les moyens suivants :

  1. Saisir L’URL ma­nuel­le­ment : une mesure qui est ex­trê­me­ment fas­ti­dieuse mais efficace consiste à saisir ma­nuel­le­ment l’URL HTTPS complète.
     
  2. Extension de na­vi­ga­teur : il existe plusieurs ex­ten­sions de na­vi­ga­teur qui peuvent aider à accéder aux versions chiffrées si elles existent. Par exemple, l’extension HTTPS Eve­ryw­here utilise des listes de domaines et de règles pour gérer tous les appels de page via des con­nexions HTTPS. Les versions pour Firefox, Firefox for Android, Chrome et Opera sont dis­po­nibles sur le site Internet de la Elec­tro­nic Frontier Foun­da­tion qui développe et maintient à jour l’extension avec le projet Tor.
     
  3. Sau­ve­gar­der les URL sûres comme favoris : si vous utilisez fré­quem­ment un service Web protégé par SSL (banque en ligne, service de Cloud etc.), vous pouvez ajouter la version HTTPS à vos favoris et ainsi toujours y accéder via ce signet. Une condition préalable est d’être certain de naviguer sur un réseau sécurisé lors de la mise en signet. Sinon, le risque est d’inclure une URL déjà manipulée dans votre liste de favoris.

En tant qu’opérateur d’un projet Web, vous pouvez aussi lutter ac­ti­ve­ment contre le SSL stripping. Par exemple, une étape de base consiste à activer le chif­fre­ment pour toutes les pages du site Internet et à forcer la re­di­rec­tion des con­nexions HTTP entrantes vers des pages sé­cu­ri­sées. De même que pour les cookies, si vous ne souhaitez pas renoncer aux données utiles pour l’analyse Web, vous devez vous assurer qu’ils ne sont pas renvoyés via des con­nexions HTTP non sé­cu­ri­sées. Pour cela, il vous suffit d’étiqueter les cookies avec l’attribut « Secure » en vous assurant que votre serveur ne reçoit que des in­for­ma­tions via HTTPS. Une autre mesure de sécurité est la norme IETF HSTS, décrite plus en détail dans la section suivante.

Comment HSTS contribue à lutter contre le SLL Stripping ?

Trois ans après que Mar­lins­pike avec son logiciel sslstrip ait attiré l’attention sur la vul­né­ra­bi­lité des sites Web certifiés SSL, l’IETF (Internet En­gi­nee­ring Task Force) a spécifié dans la RFC 6797 le mécanisme de sécurité HSTS (HTTP Strict Transport Security). Ceci permet aux serveurs Web d’informer les clients qui éta­blis­sent des con­nexions qu’ils accèdent au site Web ex­clu­si­ve­ment par le biais d’une connexion HTTPS pendant un certain temps. Pour cela, le serveur utilise le champ « Strict-Transport-Security » ainsi que la directive « max-age », qui spécifie la période de validité de l’ins­truc­tion en secondes, dans l’en-tête d’une réponse HTTP classique. Par exemple, pour rendre un domaine ac­ces­sible pendant un an ex­clu­si­ve­ment par connexion chiffrée, la réponse HTTP du serveur Web doit contenir la ligne suivante :

Strict-Transport-Security: max-age=31536000

A l’aide du paramètre « in­clu­de­Sub­Do­mains », la commande peut être étendue à tous les sous-domaines de la présence Web, de sorte que l’uti­li­sa­tion de SSL/TLS est ici forcée. Si un na­vi­ga­teur reçoit un message avec une ins­truc­tion « Strict-Transport-Security » du serveur Web contacté, toutes les requêtes non chiffrées seront au­to­ma­ti­que­ment con­ver­ties en requêtes chiffrées avec des con­nexions futures au domaine respectif. Si la sécurité de la connexion ne peut pas être garantie, alors un message d’erreur apparait et la page demandée n’est pas appelée.

HSTS est une solution per­ma­nente pour protéger un site Web et ses visiteurs contre les attaques avec SSL-Strip ou d’autres outils si­mi­laires. Cependant, comme nous l’avons déjà mentionné dans l’article, il existe toujours une toute première structure de connexion qui peut être manipulée avant que le mécanisme de sécurité ne puisse in­ter­ve­nir. Pour résoudre ce problème, Google a mis en place une liste de pré-char­ge­ment (Preload List) pour son na­vi­ga­teur Chrome, qui contient des projets Web ac­ces­sibles uni­que­ment via HTTPS. D’autres éditeurs de na­vi­ga­teurs ont adopté le principe et mis en œuvre des listes de pré-char­ge­ment HSTS basées sur la liste de Chrome. Pour ajouter votre site à la liste, vous pouvez soumettre une demande sur la page de projet de Google.

Remarque

afin de figurer dans la « Preload » liste, certaines con­di­tions préa­lables doivent être remplies : lo­gi­que­ment, vous devez pouvoir présenter un cer­ti­fi­cat valide et exécuter tous les sous-domaines via HTTPS. En outre, le champ HSTS dans les réponses du serveur Web au domaine principal doit être structuré comme suit:

La directive « max-age » doit être valide au minimum pendant 18 semaines (10886400 secondes).
La directive « in­clu­de­Sub­Do­mains » doit être spécifiée.
La directive « preload » doit aussi être définie.
S’il existe un paramètre de transfert, il doit aussi contenir l’en-tête HSTS.

Aller au menu principal