TLS

🔍 Contexte Publié sur GitHub par l’auteur Marc Rivero (alias @seifreed), CipherRun est un outil open source de scan TLS/SSL écrit en Rust, conçu pour l’analyse de sécurité des protocoles de chiffrement, la détection de vulnérabilités et la vérification de conformité. 🛠️ Fonctionnalités principales Couverture protocolaire : SSLv2 à TLS 1.3 avec analyse complète du handshake Tests de vulnérabilités : 18+ CVEs TLS majeurs (Heartbleed, ROBOT, POODLE, LOGJAM, etc.) Moteur de conformité : PCI-DSS, NIST, HIPAA, SOC 2, Mozilla, GDPR Fingerprinting : JA3, JA3S, JARM avec bases de signatures Analyse de certificats : validation de chaîne, révocation, détection EV Monitoring : surveillance 24/7 des certificats avec alertes CT Logs : streaming en temps réel des logs de transparence des certificats avec déduplication Bloom Base de données : support PostgreSQL/SQLite pour l’analytique et l’historique ⚙️ Architecture technique L’outil repose sur un moteur asynchrone basé sur Tokio, avec des sorties disponibles en Terminal, JSON, CSV, HTML et XML. Il supporte le protocole STARTTLS pour SMTP et IMAP. La qualité du code est assurée par des outils Rust (clippy, cargo audit, cargo fuzz, tarpaulin). ...

🔍 Contexte Publié le 16 juillet 2026 par l’équipe Red Team d’Okta sur sec.okta.com, cet article présente la découverte d’une vulnérabilité de type Denial of Service (DoS) dans OpenSSL, baptisée HollowByte. 🧩 Mécanisme technique La vulnérabilité exploite le comportement de la machine à états TLS lors du traitement du message ClientHello. Les versions vulnérables d’OpenSSL allouent un buffer de réception basé sur la taille déclarée dans l’en-tête du message (3 octets du header de 4 octets), sans validation préalable du payload : ...

📰 Source : BleepingComputer, publié le 17 juillet 2026, par Bill Toulas. L’advisory technique a été publié par l’équipe Red Team d’Okta en juin 2026. 🔍 Contexte Une vulnérabilité de type déni de service (DoS), nommée HollowByte, a été découverte dans la bibliothèque OpenSSL. Aucun identifiant CVE n’a été attribué ; l’équipe OpenSSL l’a traitée comme un « hardening fix » et a silencieusement intégré le correctif dans plusieurs versions. ...

🔍 Contexte Publié le 5 mai 2026 par BARGHEST sur leur blog, cet article constitue une divulgation coordonnée avec Google d’une vulnérabilité critique découverte dans le démon ADB (adbd) d’Android, identifiée sous CVE-2026-0073. 🐛 Vulnérabilité CVE-2026-0073 est un bypass d’authentification dans le chemin d’authentification ADB-over-TCP d’Android, plus précisément dans la fonction adbd_tls_verify_cert du fichier platform/packages/modules/adb/daemon/auth.cpp. La cause racine est une mauvaise utilisation de l’API EVP_PKEY_cmp de BoringSSL/OpenSSL : L’API retourne 1 (clés identiques), 0 (même type, clés différentes), -1 (types différents), -2 (opération non supportée) Le code vulnérable traite toute valeur non nulle comme un succès Un attaquant présentant un certificat TLS client avec une clé non-RSA (EC P-256 ou Ed25519) face à une clé stockée RSA provoque un retour de -1, interprété comme une authentification réussie if (EVP_PKEY_cmp(known_evp.get(), evp_pkey.get())) { verified = true; // -1 est truthy en C/C++ } ⚙️ Conditions d’exploitation Developer options activées ADB-over-TCP activé (Wireless debugging ou exposition du service adbd) Au moins une clé RSA précédemment appairée dans /data/misc/adb/adb_keys Accessibilité réseau au port TCP ADB (typiquement port 5555) 🔗 Chaîne d’exploitation L’exploitation nécessite trois étapes séquentielles : ...

🔬 Contexte Publié le 30 mars 2026 sur arXiv (cs.NI), cet article académique de Tushin Mallick, Ashish Kundu et Ramana Kompella constitue une étude de synthèse (survey) sur l’état de préparation post-quantique des protocoles réseau et de sécurité les plus répandus. ⚠️ Menace identifiée L’émergence de l’informatique quantique représente une menace structurelle pour les primitives cryptographiques à clé publique classiques, notamment : RSA Cryptographie sur courbes elliptiques (ECC) Ces primitives sont au cœur des mécanismes d’échange de clés et d’authentification de la majorité des protocoles réseau critiques. ...

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. ...

🌐 Contexte Publié le 3 mars 2026 sur le datatracker de l’IETF (https://datatracker.ietf.org/doc/rfc9849/), ce document constitue la RFC 9849, un standard de la catégorie Standards Track produit par le groupe de travail TLS de l’IETF. Les auteurs sont Eric Rescorla (Independent), Kazuho Oku (Fastly), Nick Sullivan (Cryptography Consulting LLC) et Christopher A. Wood (Apple). 🔐 Objet du standard La RFC 9849 spécifie le mécanisme TLS Encrypted Client Hello (ECH), une extension TLS permettant aux clients de chiffrer leur message ClientHello sous la clé publique du serveur. Ce mécanisme protège notamment : ...

📅 Source : Feisty Duck Cryptography & Security Newsletter, numéro 135, publié le 31 mars 2026. 🔐 Contexte général Cet article de newsletter spécialisée couvre plusieurs développements majeurs en cryptographie et PKI. Le sujet central est la refonte du Web PKI par Google via les Merkle Tree Certificates (MTCs), en réponse aux contraintes imposées par la cryptographie post-quantique (PQC) et les limites actuelles de Certificate Transparency (CT). 🌳 Merkle Tree Certificates : la refonte du Web PKI Google travaille depuis début 2023 sur une nouvelle architecture PKI. Fin 2025, ce travail a été transféré au groupe de travail IETF PLANTS, en collaboration avec Cloudflare. Les grandes étapes annoncées : ...

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. ...