{"id":32603,"date":"2019-10-31T21:47:55","date_gmt":"2019-10-31T18:47:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/potentsialnye-ataki-na-https-i-kak-ot-nih-zashhititsya\/"},"modified":"2019-10-31T21:47:55","modified_gmt":"2019-10-31T18:47:55","slug":"potentsialnye-ataki-na-https-i-kak-ot-nih-zashhititsya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/potentsialnye-ataki-na-https-i-kak-ot-nih-zashhititsya","title":{"rendered":"Attaques potentielles sur HTTPS et comment s'en prot\u00e9ger","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La moiti\u00e9 des sites utilise HTTPS<\/a><\/noindex>, et leur nombre continue d'augmenter. Ce protocole r\u00e9duit le risque d'interception du trafic, mais n'exclut pas les tentatives d'attaques en tant que telles. Nous parlerons de certaines d'entre elles \u2014 POODLE, BEAST, DROWN et d'autres \u2014 et des m\u00e9thodes de protection dans notre article.<\/p>\n

\"Attaques <\/a><\/noindex><\/a><\/noindex>
\n\/ Flickr \/ Sven Graeme<\/a><\/noindex> \/ CC BY-SA<\/i><\/p>\n

POODLE<\/h2>\n

\nLa premi\u00e8re fois que l'attaque POODLE<\/a><\/noindex> a \u00e9t\u00e9 signal\u00e9e en 2014. La vuln\u00e9rabilit\u00e9 dans le protocole SSL 3.0 a \u00e9t\u00e9 d\u00e9couverte par l'expert en s\u00e9curit\u00e9 Bodo M\u00f6ller avec ses coll\u00e8gues de Google.<\/p>\n

Essentiellement, l'attaquant force le client \u00e0 se connecter via SSL 3.0, en simulant des coupures de communication. Ensuite, il recherche dans le trafic chiffr\u00e9 en CBC<\/a><\/noindex>-mode des messages sp\u00e9ciaux. Gr\u00e2ce \u00e0 une s\u00e9rie de requ\u00eates fausses, l'attaquant peut reconstruire le contenu des donn\u00e9es qui l'int\u00e9ressent, comme les cookies.<\/p>\n

SSL 3.0 est un protocole obsol\u00e8te. Cependant, la question de sa s\u00e9curit\u00e9 reste d'actualit\u00e9. Les clients l'utilisent pour \u00e9viter les probl\u00e8mes de compatibilit\u00e9 avec les serveurs. Selon certaines donn\u00e9es, pr\u00e8s de 7 % des 100 000 sites les plus populaires supportent encore SSL 3.0<\/a><\/noindex>. De plus existent<\/a><\/noindex> des modifications de POODLE, visant des TLS 1.0 et TLS 1.1 plus modernes. Cette ann\u00e9e, a introduit<\/a><\/noindex> de nouvelles attaques Zombie POODLE et GOLDENDOODLE, qui contournent la protection TLS 1.2 (elles sont toujours li\u00e9es au chiffrement CBC).<\/p>\n

Comment se prot\u00e9ger.<\/b> Dans le cas de l'original POODLE, il faut d\u00e9sactiver le support SSL 3.0. Cependant, cela pr\u00e9sente un risque de probl\u00e8mes de compatibilit\u00e9. Une solution alternative peut \u00eatre le m\u00e9canisme TLS_FALLBACK_SCSV \u2014 il garantit que les \u00e9changes de donn\u00e9es via SSL 3.0 ne se feront qu'avec de vieux syst\u00e8mes. Les attaquants ne pourront plus initier une r\u00e9trogradation du protocole. La protection contre Zombie POODLE et GOLDENDOODLE consiste \u00e0 d\u00e9sactiver le support CBC dans les applications bas\u00e9es sur TLS 1.2. La solution radicale consiste \u00e0 passer \u00e0 TLS 1.3 \u2014 dans la nouvelle version du protocole, le chiffrement CBC n'est pas utilis\u00e9. \u00c0 la place, des AES et ChaCha20 plus solides sont appliqu\u00e9s.<\/p>\n

BEAST<\/h2>\n

\nUne des toutes premi\u00e8res attaques contre SSL et TLS 1.0, d\u00e9couverte en 2011. Comme POODLE, BEAST utilise<\/a><\/noindex> Caract\u00e9ristiques du chiffrement CBC. Les attaquants injectent un agent JavaScript ou un applet Java sur la machine cliente, qui substitue les messages lors de la transmission des donn\u00e9es via TLS ou SSL. \u00c9tant donn\u00e9 que les attaquants connaissent le contenu des paquets \u00ab substitu\u00e9s \u00bb, ils peuvent utiliser ceux-ci pour d\u00e9chiffrer le vecteur d'initialisation et lire les autres messages au serveur, par exemple, les cookies pour l'authentification.<\/p>\n

\u00c0 ce jour, les vuln\u00e9rabilit\u00e9s BEAST continuent d'\u00eatre expos\u00e9es par divers outils r\u00e9seau<\/a><\/noindex>: serveurs proxy et applications prot\u00e9geant les passerelles Internet locales.<\/p>\n

Comment se prot\u00e9ger.<\/b> L'attaquant doit r\u00e9guli\u00e8rement envoyer des requ\u00eates pour d\u00e9chiffrer les donn\u00e9es. Dans VMware de lire les livres \u00ab<\/a><\/noindex> r\u00e9duisez la dur\u00e9e du SSLSessionCacheTimeout \u2014 de cinq minutes (recommandation par d\u00e9faut) \u00e0 30 secondes. Cette approche compliquera la mise en \u0153uvre des plans des attaquants, bien qu'elle ait un certain impact n\u00e9gatif sur les performances. De plus, il est important de comprendre qu'\u00e0 court terme, la vuln\u00e9rabilit\u00e9 BEAST pourrait dispara\u00eetre d'elle-m\u00eame \u2014 \u00e0 partir de 2020, les principaux navigateurs cessent<\/a><\/noindex> de prendre en charge TLS 1.0 et 1.1. De toute fa\u00e7on, moins de 1,5 % de tous les utilisateurs de navigateurs utilisent encore ces protocoles.<\/p>\n

DROWN<\/h2>\n

\nIl s'agit d'une attaque inter-protocole exploitant des erreurs dans l'impl\u00e9mentation de SSLv2 avec des cl\u00e9s RSA de 40 bits. L'attaquant \u00e9coute des centaines de connexions TLS de la cible et envoie des paquets sp\u00e9ciaux au serveur utilisant SSLv2 avec la m\u00eame cl\u00e9 priv\u00e9e. En utilisant l'attaque Bleichenbacher<\/a><\/noindex>, le hacker peut d\u00e9chiffrer l'une des quelque mille sessions TLS du client.<\/p>\n

DROWN a \u00e9t\u00e9 d\u00e9couvert pour la premi\u00e8re fois en 2016 \u2014 \u00e0 l'\u00e9poque, elle a affect\u00e9 un tiers des serveurs<\/a><\/noindex> dans le monde. \u00c0 ce jour, elle reste d'actualit\u00e9. Parmi les 150 000 sites les plus populaires, 2 % utilisent encore supportent<\/a><\/noindex> SSLv2 et des m\u00e9canismes de chiffrement vuln\u00e9rables.<\/p>\n

Comment se prot\u00e9ger.<\/b> Il est n\u00e9cessaire d'installer les correctifs propos\u00e9s par les d\u00e9veloppeurs de biblioth\u00e8ques cryptographiques d\u00e9sactivant le support de SSLv2. Par exemple, deux tels correctifs ont \u00e9t\u00e9 fournis pour OpenSSL (en 2016, ce furent les mises \u00e0 jour<\/a><\/noindex> 1.0.1s et 1.0.2g). Des mises \u00e0 jour et des instructions pour d\u00e9sactiver le protocole vuln\u00e9rable ont \u00e9galement \u00e9t\u00e9 publi\u00e9es sur Red Hat<\/a><\/noindex>, Apache<\/a><\/noindex>, Debian<\/a><\/noindex>.<\/p>\n

\u00ab La ressource peut \u00eatre vuln\u00e9rable \u00e0 DROWN si ses cl\u00e9s sont utilis\u00e9es par un serveur tiers avec SSLv2, par exemple un serveur de messagerie \u00bb, note le responsable du d\u00e9veloppement du fournisseur IaaS 1cloud.ru<\/a><\/noindex> Sergue\u00ef Belkin. \u2014 Cette situation se produit lorsque plusieurs serveurs utilisent un certificat SSL commun. Dans ce cas, il est n\u00e9cessaire de d\u00e9sactiver le support SSLv2 sur toutes les machines.<\/i><\/p><\/blockquote>\n

\nPour v\u00e9rifier si vous devez mettre \u00e0 jour votre syst\u00e8me, vous pouvez utiliser un outil sp\u00e9cialis\u00e9. outil<\/a><\/noindex> \u2014 il a \u00e9t\u00e9 d\u00e9velopp\u00e9 par des experts en cybers\u00e9curit\u00e9 qui ont d\u00e9couvert DROWN. Vous pouvez en savoir plus sur les recommandations li\u00e9es \u00e0 la protection contre ce type d'attaques dans un article sur le site OpenSSL.<\/a><\/noindex>.<\/p>\n

Heartbleed<\/h2>\n

\nL'une des plus grandes vuln\u00e9rabilit\u00e9s dans le logiciel \u2014 Heartbleed<\/a><\/noindex>. Elle a \u00e9t\u00e9 d\u00e9couverte en 2014 dans la biblioth\u00e8que OpenSSL. Au moment de l'annonce du bug, le nombre de sites web vuln\u00e9rables \u00e9tait estim\u00e9 \u00e0 un demi-million.<\/a><\/noindex> \u2014 c'est \u00e0 peu pr\u00e8s 17 % des ressources prot\u00e9g\u00e9es en ligne.<\/p>\n

L'attaque s'ex\u00e9cute via un petit module d'extension de TLS. Le protocole TLS exige que les donn\u00e9es soient transf\u00e9r\u00e9es de mani\u00e8re continue. En cas de longue p\u00e9riode d'inactivit\u00e9, la connexion est rompue et il faut la r\u00e9tablir. Pour faire face \u00e0 ce probl\u00e8me, les serveurs et les clients cr\u00e9ent artificiellement du \u00ab bruit \u00bb dans le canal (RFC 6520, p.5<\/a><\/noindex>), en transmettant un paquet de longueur al\u00e9atoire. S'il s'av\u00e9rait plus grand que le paquet, alors les versions vuln\u00e9rables d'OpenSSL lisaient la m\u00e9moire au-del\u00e0 du tampon allou\u00e9. Dans cette zone pouvaient se trouver toutes sortes de donn\u00e9es, y compris des cl\u00e9s de chiffrement secr\u00e8tes et des informations sur d'autres connexions.<\/p>\n

La vuln\u00e9rabilit\u00e9 \u00e9tait pr\u00e9sente dans toutes les versions de la biblioth\u00e8que entre 1.0.1 et 1.0.1f incluses, ainsi que dans un certain nombre de syst\u00e8mes d'exploitation \u2014 Ubuntu jusqu'\u00e0 12.04.4, CentOS au-del\u00e0 de 6.5, OpenBSD 5.3 et d'autres. Une liste compl\u00e8te est disponible sur le site d\u00e9di\u00e9 \u00e0 Heartbleed.<\/a><\/noindex>. Bien que des patches contre cette vuln\u00e9rabilit\u00e9 aient \u00e9t\u00e9 publi\u00e9s pratiquement imm\u00e9diatement apr\u00e8s sa d\u00e9couverte, le probl\u00e8me reste d'actualit\u00e9 encore aujourd'hui. D\u00e9j\u00e0 en 2017, pr\u00e8s de 200 000 sites<\/a><\/noindex>\u00e9taient encore vuln\u00e9rables \u00e0 Heartbleed.<\/p>\n

Comment se prot\u00e9ger.<\/b> Il faut mettre \u00e0 jour OpenSSL<\/a><\/noindex> vers la version 1.0.1g ou sup\u00e9rieure. Vous pouvez \u00e9galement d\u00e9sactiver manuellement les requ\u00eates Heartbeat \u00e0 l'aide de l'option DOPENSSL_NO_HEARTBEATS. Apr\u00e8s la mise \u00e0 jour, les experts en cybers\u00e9curit\u00e9 de lire les livres \u00ab<\/a><\/noindex> recommandent de renouveler les certificats SSL. Le remplacement est n\u00e9cessaire au cas o\u00f9 des donn\u00e9es sur les cl\u00e9s de chiffrement auraient fini par tomber entre les mains des hackers.<\/p>\n

Substitution de certificat<\/h2>\n

\nUn n\u0153ud contr\u00f4l\u00e9 est \u00e9tabli entre l'utilisateur et le serveur avec un certificat SSL l\u00e9gitime, interceptant activement le trafic. Ce n\u0153ud se fait passer pour un serveur l\u00e9gitime, pr\u00e9sentant un certificat valide, permettant ainsi de r\u00e9aliser une attaque MITM.<\/p>\n

Selon une \u00e9tude<\/a><\/noindex> Selon des \u00e9quipes de Mozilla, Google et d'un certain nombre d'universit\u00e9s, environ 11 % des connexions s\u00e9curis\u00e9es sur le r\u00e9seau sont \u00ab surveill\u00e9es \u00bb. Cela r\u00e9sulte de l'installation de certificats racine suspects sur les ordinateurs des utilisateurs.<\/p>\n

Comment se prot\u00e9ger.<\/b> Utiliser les services de fournisseurs SSL<\/a><\/noindex>. Vous pouvez v\u00e9rifier la \u00ab qualit\u00e9 \u00bb des certificats en utilisant le service la Transparence des Certificats<\/a><\/noindex> (CT). Les fournisseurs de services cloud peuvent \u00e9galement aider \u00e0 d\u00e9tecter les \u00ab \u00e9coutes \u00bb \u2014 aujourd'hui, certaines grandes entreprises proposent d\u00e9j\u00e0 des outils sp\u00e9cialis\u00e9s pour surveiller les connexions TLS.<\/p>\n

Une autre m\u00e9thode de protection sera le nouveau norme<\/a><\/noindex> ACME, qui automatise l'obtention de certificats SSL. Cela ajoutera \u00e9galement des m\u00e9canismes suppl\u00e9mentaires de v\u00e9rification du propri\u00e9taire du site. Vous pouvez en lire plus \u00e0 son sujet dans un de nos pr\u00e9c\u00e9dents articles<\/a><\/noindex>.<\/p>\n

\"Attaques
\n\/ Flickr \/ Yuri Samoilov<\/a><\/noindex> \/ CC BY<\/i><\/p>\n

Perspectives de HTTPS<\/h2>\n

\nMalgr\u00e9 un certain nombre de vuln\u00e9rabilit\u00e9s, les g\u00e9ants de l'IT et les experts en s\u00e9curit\u00e9 sont confiants dans l'avenir du protocole. Pour la promotion active de HTTPS, est<\/a><\/noindex> le cr\u00e9ateur du WWW, Tim Berners-Lee. Selon lui, avec le temps, le TLS deviendra plus s\u00e9curis\u00e9, ce qui augmentera consid\u00e9rablement la s\u00e9curit\u00e9 des connexions. Berners-Lee a m\u00eame sugg\u00e9r\u00e9 que \u00e0 l' avenir, des<\/a><\/noindex> certificats clients pour l'authentification des identit\u00e9s appara\u00eetront. Ils aideront \u00e0 am\u00e9liorer la protection des serveurs contre les attaquants.<\/p>\n

Le d\u00e9veloppement de la technologie SSL\/TLS est \u00e9galement pr\u00e9vu gr\u00e2ce \u00e0 l'apprentissage automatique \u2014 des algorithmes intelligents s'occuperont de la filtration du trafic malveillant. Dans les connexions HTTPS, les administrateurs n'ont pas la possibilit\u00e9 de conna\u00eetre le contenu des messages chiffr\u00e9s, y compris de d\u00e9tecter les requ\u00eates des logiciels malveillants. D\u00e9j\u00e0 aujourd'hui, les r\u00e9seaux neuronaux peuvent filtrer des paquets potentiellement dangereux avec une pr\u00e9cision de 90%. (diapositive 23 de la pr\u00e9sentation<\/a><\/noindex>).<\/p>\n

Conclusions<\/h2>\n

\nLes attaques contre HTTPS sont principalement li\u00e9es non pas \u00e0 des probl\u00e8mes dans le protocole lui-m\u00eame, mais au support de m\u00e9canismes de chiffrement obsol\u00e8tes. L'industrie IT commence progressivement \u00e0 se d\u00e9barrasser des protocoles de premi\u00e8re g\u00e9n\u00e9ration et propose de nouveaux outils pour rechercher des vuln\u00e9rabilit\u00e9s. \u00c0 l'avenir, ces outils deviendront de plus en plus intelligents.<\/p>\n

Liens suppl\u00e9mentaires sur le sujet :<\/h5>\n

<\/p>\n