ALPACA : une faiblesse de TLS permet de s'insérer dans des connexions HTTPS

ALPACA : une faiblesse de TLS permet de s’insérer dans des connexions HTTPS

ALPACA : une faiblesse de TLS permet de s'insérer dans des connexions HTTPS

Des chercheurs ont montré qu’il était possible de profiter d’une faiblesse de TLS quand il s’agit de protéger la connexion TCP.

En temps normal, visiter un site HTTPS provoque l’ouverture d’une connexion TLS après vérification que le certificat du site est valide. L’objectif est d’empêcher un tiers de s’insérer entre le client et le serveur, pour lire ou modifier les données en transit.

Les chercheurs ont prouvé que l’on pouvait déclencher une attaque de type MitM (homme du milieu) en réorientant le navigateur vers un serveur SMTP, IMAP, POP3, FTP ou un autre protocole de communication.

Il suffit pour cela que le nom de domaine du site corresponde à celui du serveur mail ou FTP. Si les conditions sont réunies, le certificat est considéré comme valide et les pirates se retrouvent en position de pouvoir envoyer par exemple un cookie déchiffré d’authentification ou de déclencher l’exécution d’un code arbitraire.

Selon les chercheurs – qui ont nommé cette attaque ALPACA (application layer protocols allowing cross-protocol attacks) – 14,4 millions de serveurs web se servent d’un nom de domaine compatible avec les identifiants cryptographiques d’un serveur mail ou FTP appartenant à la même structure. 

Sur cet ensemble, 114 000 sont considérés comme directement vulnérables à cette attaque car le serveur mail ou FTP utilise des versions de logiciels connues pour leurs failles. Les chercheurs ont même trois variantes de l’attaque (Upload, Download et Reflection). Dans tous les cas, le problème est le même : le trafic peut être réorienté car TLS ne protège ni l’adresse IP ni le port réseau.

Ils recommandent l’utilisation stricte de deux extensions de TLS : ALPN (application layer protocol negotiation) et SNI (server name indication). La première doit être utilisée en suivant toutes les recommandations d’implémentation, la seconde en la configurant pour fermer la connexion quand l’hôte cherché n’est pas trouvé.

Commentaires (11)


Petite question pour l’amateur que je suis : en gros, si on a un domaine en domaine.fr et que sur son serveur, on a auto-hébergé ses mails sur l’adresse [email protected], on est “éligible” à se faire hacker ?
J’imagine que les PME peuvent faire appel à une prestation interne/externe pour régler ça, mais pour les particuliers, existe-t-il des solutions simples à mettre en place ?



Merci !


Bon c’est une attaque man on middle donc il faut deja qu’une personne intercepte ton trafic bref c’est une attaque très ciblée.



Secundo, on parle des cookies de sessions du navigateur pouvant être récupérés pour le site en domaine.fr par exemple demandant une authentification.
Donc as tu deja un site du même nom que ton serveur de mail ?
Si oui utilises tu le même certificat pour le site web et le mail ?
Dans ce dernier cas, tu mets un certificat différent.


Merci pour vos retour, ça rassure. Non je n’ai pas de site web, mais on ne sait jamais, du coup l’idée de segmenter ses certificats est toujours un bon conseil, plutôt accessible pour un débutant comme moi.


A ce que je comprends pour que l’attaque soit fonctionnelle il faut que l’attaquant puisse faire du man in the middle ce qui est déjà une barrière très importante. De plus les attaques décrites sont plus des PoC qu’autre chose (et la plupart ne sont fonctionnelles que sur Internet Explorer).



Donc je ne pense pas qu’il y ai lieu de s’inquiéter outre mesure sur ce sujet.


En gros, la faille est intéressante pour les employeurs qui veulent espionner la navigation de leurs salariés ou pour des gouvernements…


Les employeurs n’ont pas pas besoin de ça, les “proxy transparents” sont fait pour ça.



(quote:1878933:prog-amateur)
si on a un domaine en domaine.fr et que sur son serveur, on a auto-hébergé ses mails sur l’adresse [email protected], on est “éligible” à se faire hacker ?




C’est le(s) domaine(s) supporté(s) par le serveur de courriel qui va(ont) compter. Comment se connecte-t-on lorsque l’on souhaite envoyer un courriel @domaine.fr ?
Pour le savoir, il faut connaître le(s) nom(s) de domaine utilisés sur le(s) serveur(s) pointé(s) par le champ MX du domaine domaine.fr, notamment ceux pour lesquels une sessions TLS est utilisable.



Si ce serveur de courriel accepte des connexions TLS avec un certificat pour domaine.fr, les conditions de l’attaque son réunies.


merci pour cette réponse détaillée



Cumbalero a dit:


Les employeurs n’ont pas pas besoin de ça, les “proxy transparents” sont fait pour ça.




Un proxy transparent ça reste une attaque Man-In-the-middle


Pas vraiment, car il faut avoir un accès à la machine de l’utilisateur pour placer le certificat du proxy.



Mihashi a dit:


Pas vraiment, car il faut avoir un accès à la machine de l’utilisateur pour placer le certificat du proxy.




Ces proxys fonctionnent en plaçant un certificat dans le magasin de l’utilisateur. Si tu refuses ce certificat, tu n’as pas accès ni à internet, ni aux autres ressources de l’entreprise telles que l’intranet.
Et tout le trafic est déchiffré et analysé.


Fermer