La nouvelle vient d'apparaître qu'Apple, Cloudflare, Fastly et Mozilla ont collaboré pour améliorer le cryptage du mécanisme d'identification du nom de serveur de HTTPS lors de l'IETF 102 Hackathon, comme indiqué par un tweet de Nick Sullivan de Cloudflare. Le tweet a félicité l'équipe de mixage des quatre géants de la technologie en disant «travail formidable» et en partageant là-bas sous des liens vers les serveurs en activité sur esni.examp1e.net et cloudflare-esni.com .
Excellent travail au hackathon IETF 102 par l'équipe SNI cryptée composée de personnes de @Cloudflare @rapidement @mozilla et @Pomme . Il existe maintenant des implémentations dans BoringSSL, NSS et picotls.
Les serveurs de travail sont actifs à https://t.co/sLI9xLRjlK et https://t.co/AoC2SIlJ7N .
- Nick Sullivan (@grittygrease) 15 juillet 2018
L'IETF Hackathon est une plate-forme qui invite de jeunes développeurs et passionnés de technologie à se joindre à la tête pour rédiger des solutions pour les problèmes liés à la technologie auxquels l'utilisateur commun est confronté aujourd'hui. Les événements sont gratuits, ouverts à tous et encouragent le travail d'équipe plutôt que la compétition. Le Hackathon IETF de cette année a eu lieu à Montréaleet 15ede juillet. La réalisation la plus importante qui en ressort, semble-t-il, est le chiffrement de l'indication du nom du serveur (SNI) de Transport Layer Security (TLS), un problème qui a tourmenté les développeurs au cours de la dernière décennie, un problème auquel les membres d'Apple, Cloudflare, Fastly , et Mozilla a maintenant proposé une solution à.
Événement Hackathon de l'IETF. IETF
Il y a eu un glissement global clair du protocole HTTP (Hyper Text Transfer Protocol) vers l'indication de nom du serveur de sécurité de la couche de transport Hyper Text Transfer Protocol Secure (TLS SNI HTTPS) au cours de la dernière décennie et demie. le problème L’optimisation du système TLS SNI HTTPS est née de la capacité du pirate à utiliser SNI par rapport à son objectif de faire correspondre le transfert de données pour le décryptage ultérieur.
Avant le développement de SNI, il était difficile d'établir des connexions sécurisées à plusieurs serveurs virtuels en utilisant la même première négociation client. Lorsqu'une adresse IP interagissait avec un serveur, les deux échangeaient des «bonjour», le serveur envoyait ses certificats, l'ordinateur envoyait sa clé client, les deux échangeaient des commandes «ChangeCipherSpec», puis l'interaction était terminée lorsqu'une connexion était établie. Cela peut sembler facile comme cela vient d’être dit, mais le processus impliquait de multiples échanges et réponses qui ont facilement réussi à devenir assez problématiques à mesure que le nombre de serveurs avec lesquels communiquer augmentait. Si tous les sites utilisaient les mêmes certificats, cela n’était pas vraiment un problème, mais malheureusement, c’était rarement le cas. Lorsque plusieurs sites envoyaient divers certificats dans les deux sens, il était difficile pour le serveur de déterminer quel certificat l'ordinateur recherchait et dans le réseau complexe d'échanges, il devenait difficile d'identifier qui avait envoyé quoi et quand, mettant ainsi fin à toute l'activité. avec un message d'avertissement.
TLS SNI a ensuite été introduit en juin 2003 lors d'un sommet de l'IETF et le but qu'il a servi, en un sens, était de créer des étiquettes de nom pour les ordinateurs et les services impliqués dans le web d'échange. Cela a rendu le processus d'échange serveur-client bonjour beaucoup plus simple car le serveur a été capable de fournir les certificats exacts nécessaires et les deux ont pu avoir leur propre échange de conversation sans se demander qui a dit quoi. C’est un peu comme avoir des noms de contacts pour les chats et ne pas être confus quant à la provenance des messages, mais aussi pouvoir répondre à chaque requête de manière appropriée, en fournissant les bons documents à l’ordinateur qui en a besoin. Cette définition SNI est exactement ce qui a posé le plus gros problème avec cette méthode d'optimisation du processus d'échange.
La difficulté à laquelle de nombreuses entreprises ont été confrontées pour passer au HTTPS a été l'adaptation de nombreux certificats au format SNI avec des adresses IP individuelles pour exécuter les demandes pour chaque certificat. Ce que TLS a fait pour eux, c'est de simplifier la génération de certificats pour répondre à de telles demandes et ce que SNI a fait encore plus a été de supprimer le besoin d'adresses IP de certificat dédiées individualisées en lançant un système d'identification complet sur l'ensemble du réseau Internet. Ce qui est venu avec la mise à niveau du siècle était le fait qu'elle permettait aux pirates d'utiliser les «noms de contact» établis pour surveiller et observer le transfert de données et extraire les informations dont ils avaient besoin pour déchiffrer à un stade ultérieur.
Bien que TLS permette aux données d'être envoyées dans les deux sens dans un canal crypté, SNI garantissant qu'elles atteignent la bonne destination, ce dernier a également fourni des moyens aux pirates pour surveiller l'activité en ligne et la faire correspondre à sa source en suivant les requêtes DNS, les adresses IP et les flux de données. Bien que des politiques de codage SNI plus strictes aient été mises en œuvre en passant également les informations DNS via le canal TLS, une petite fenêtre reste pour que les pirates puissent l'utiliser comme moyen d'identification pour suivre l'information qu'ils aimeraient extraire et l'isoler pour décryptage. Les serveurs complexes qui traitent un trafic plus important de données cryptées TLS utilisent le SNI en texte brut pour envoyer la communication dans leurs serveurs et c'est ce qui permet aux pirates d'identifier plus facilement les canaux et les flux d'informations qu'ils souhaitent suivre. Une fois qu'un pirate informatique est en mesure d'extraire les informations SNI des données d'intérêt, il peut configurer une fausse relecture de la commande dans une connexion TLS séparée avec le serveur, en envoyant les informations SNI volées et en récupérant les informations qui y était associé. Il y a eu plusieurs tentatives pour résoudre ce problème de SNI dans le passé, mais la plupart sont allées à l'encontre du principe de simplicité sur lequel SNI fonctionne pour en faire une méthode d'identification pratique pour les serveurs.
De retour au sommet qui a d'abord travaillé à établir cette méthode, les participants de quatre géants de la technologie sont revenus à la conférence de Montréal pour développer un cryptage pour le TLS SNI car malgré la plus grande efficacité du système adjacent multi HTTPS, la sécurité reste une préoccupation juste autant qu'avant.
Pour dissimuler le SNI dans TLS, un «Service Caché» doit être conservé sous le spectacle d'un «Service de Fronting» que le pirate peut voir. Sans être en mesure d'observer directement le service caché, le pirate sera trompé par le déguisement de façade sous lequel il se cache en texte brut sans pouvoir identifier les paramètres des services secrets sous-jacents utilisés pour relayer les données cryptées. Au fur et à mesure que l'observateur suit la piste du service de façade, les données seront supprimées du canal observé lorsqu'elles sont redirigées vers son service caché prévu, auquel point le pirate aura perdu sa trace. Étant donné que le serveur sera également exposé au service de façade, au fur et à mesure que les données y parviennent, un deuxième signal SNI parallèle sera envoyé au service de façade pour rediriger les données vers le service caché et dans ce processus de changement de direction, le pirate va être perdu dans le Web du serveur. Ce mécanisme de double ticket est développé en un ticket combiné sous le même SNI. Lorsqu'un élément de données est envoyé au serveur, les données produisent un redirection SNI coopérant et les deux travaillent conjointement pour obtenir les données cryptées TLS là où elles doivent aller. Sans être en mesure de déchiffrer le service de façade aléatoire qui couvre les deux pistes SNI, le pirate informatique ne pourra pas suivre la trace des données, mais le serveur pourra toujours connecter les deux et décrypter le service caché comme emplacement ultime des données. Cela permet aux serveurs de continuer à utiliser SNI pour optimiser leur transfert de données dans le cryptage TLS tout en garantissant que les pirates ne peuvent pas profiter du mécanisme SNI.
