CheckMyHTTPS a été développée suite aux constats suivants
Avant de transférer des flux chiffrés (HTTPS), un serveur web justifie son identité auprès de votre navigateur par l’envoi de son certificat de sécurité (sa carte d'identité) : Cf. phase 1 du schéma ci-dessous. Ce certificat a été préalablement validé (signé) par une autorité de certification reconnue par votre navigateur.
Pour fonctionner, les techniques d'interception de type "homme du milieu" (Man In The Middle - MITM) génèrent dynamiquement de faux certificats non validés par une autorité reconnue. Des scénarios existent néanmoins pour forcer votre navigateur à accepter ces faux certificats (3 d'entre eux vous sont présentés ci-après). CheckMyHTTPS permet de vérifier que le certificat que vous recevez est bien celui qui a été émis par le serveur auquel vous souhaitez vous connecter.
Scénario 1 - Un pirate
Les techniques d'interception malveillantes de flux chiffrés sont aujourd'hui matures et documentées. Ainsi, un pirate connecté sur le même réseau local que vous (filaire ou WIFI) peut exploiter ces techniques pour intercepter, analyser ou modifier vos flux sécurisés. Pour éviter que votre navigateur ne s'aperçoive que les certificats sont des faux, il va préalablement tenter de vous présenter des pages WEB vous incitant à installer son autorité de certification. Si son attaque fonctionne, CheckMyHTTPS détectera tout de même l'interception SSL/TLS et affichera un cadenas rouge. Pour mener son interception, le pirate doit être sur le même réseau local que vous ou il doit créer un réseau local que vous pensez être le vôtre. Cela peut être compliqué sur des réseaux domestiques ou d'entreprise correctement sécurisés. En revanche, sur les réseaux WIFI publics (points d'accès ouverts), le pirate possède un terrain de jeux infini...
Scénario 2 - Les équipements de cybersécurité
Plusieurs équipements de cybersécurité déployés par les directions informatiques (pare-feux, proxy, systèmes de prévention d'intrusion, etc.) intègrent des fonctionnalités leur permettant d’inspecter les flux chiffrés sortant sur Internet (HTTPS, POP3S, SMTPS, xxxxS).
Quand cette fonctionnalité est activée, tous les flux sécurisés sont déchiffrés pour être analysés par des modules de sécurité (antimalware, détection de fuite d'information, blocage de sites interdits, alertes, etc.). Dans le cadre du respect de la vie privée, cette fonctionnalité doit être connue des utilisateurs (via la signature d'une charte informatique par exemple).
Exemple avec un pare-feu FortiGate®
L'administrateur peut activer l'inspection SSL/TLS dans l'interface de configuration du pare-feu. Pour éviter que les navigateurs ne réagissent, le certificat du pare-feu aura été déployé au préalable sur les équipements des collaborateurs (de manière automatisé via une GPO par exemple).
Le pare-feu peut alors extraire les flux en clair pour les stocker ou les envoyer vers des modules d'analyse.
Dans l'exemple ci-dessous, le module "CheckMyHTTPS" du navigateur a détecté (cadenas rouge) que le certificat reçu par 'Microsoft-Outlook'® (forgé dynamiquement par le pare-feu) diffère de celui que le serveur de courrier a envoyé (login.live.com). C'est donc la preuve d'une interception SSL/TLS.
Scénario 3 - les logiciels de cyberprotection
Des logiciels de cyberprotection (antivirus, antimalwares, EDR, etc.) installés sur les PC/tablettes/GSM peuvent intercepter et déchiffrer les flux sécurisés SSL/TLS sortant de l'équipement. Les éditeurs de ces logiciels justifient ce comportement par le besoin de protection, même à l'intérieur des flux chiffrés. Pour éviter que les navigateurs ne réagissent à cette technique locale d'interception (MITM), ces logiciels ont ajouté leur autorité de certification dans les navigateurs au moment de leur installation.
Exemple avec Avast!®
Exemple avec Kaspersky®

