TLS

Source : GitGuardian (blog), en collaboration avec Google — résultats présentés à Real World Crypto (RWC) 2026 à Taipei. L’étude analyse à l’échelle d’Internet l’impact réel des fuites de clés privées en reliant des clés exposées publiquement aux certificats TLS via Certificate Transparency (CT). • Portée et risque 🔐: Depuis 2021, environ 1 M de clés privées uniques ont été détectées sur GitHub et DockerHub. En s’appuyant sur l’infrastructure CT de Google, les chercheurs ont associé >40 000 clés à 140 000 certificats TLS. Au septembre 2025, 2 622 certificats restaient valides, dont >900 protégeant des Fortune 500, des établissements de santé et des agences gouvernementales. Les fuites de clés TLS permettent l’usurpation de sites, l’interception/manipulation de données et potentiellement la décryption de communications passées si la PFS n’était pas généralisée. ...

Source : billet de blog de Yannik Marchand. Contexte : analyse de l’implémentation TLS du sysmodule « ssl » de la Nintendo Switch (librairie NSS) et découverte d’un défaut de vérification permettant l’interception de trafic 🔒. Résumé technique : la vérification des certificats dans le callback SslAuthCertCb comporte un cas spécial pour les certificats importés via nn::ssl::Context::ImportServerPki. Lorsque le certificat reçu figure dans la liste « de confiance » du contexte, la signature n’est pas validée par NSS. La fonction CertificateStore::IsTrusted ne compare que le Subject Key Identifier (SKID) — une valeur contrôlable par un attaquant — au lieu de vérifier la chaîne et la signature. En forgeant un certificat auto-signé avec le même SKID qu’un certificat importé, un attaquant peut réussir une attaque de type man-in-the-middle (MITM) et usurper un serveur. ...

L’article publié par gbhackers.com le 10 juillet 2025, met en lumière une nouvelle attaque de type man-in-the-middle nommée “Opossum”, capable de compromettre les communications sécurisées. Opossum cible une large gamme de protocoles d’application couramment utilisés, tels que HTTP, FTP, POP3, SMTP, LMTP et NNTP, qui prennent en charge le TLS “implicite” sur des ports dédiés et le TLS “opportuniste” via des mécanismes de mise à niveau. En exploitant des différences subtiles d’implémentation entre ces deux modes, un attaquant peut provoquer une désynchronisation entre le client et le serveur, compromettant ainsi les garanties d’intégrité du TLS et manipulant les données vues par le client. ...

SSL.com pourrait délivrer un certificat TLS de confiance pour le nom de domaine d’une adresse e-mail du demandeur, même si ce dernier n’a pas établi le contrôle administratif de ce domaine.