On assiste aujourd’hui à la généralisation du trafic internet sécurisé via le protocole HTTPS (HyperText Transfer Protocol Secure ou « protocole de transfert hypertexte sécurisé ») qui représente désormais plus de 80% des flux web en France et qui attendra probablement les 90% dès 2020. Cette progression répond à une tendance de fond de sécurisation des échanges de données. Elle répond également à l’impulsion de Google qui favorise le référencement naturel des sites internet en HTTPS dans son moteur de recherche et pénalise ceux qui ne le sont pas.
Cette transformation se vérifie d’ailleurs à tous les niveaux puisque la quasi-totalité des navigateurs web considèrent désormais l’accès à un site HTTP non chiffré comme dangereux et préviennent l’utilisateur par des alertes explicites.
Pour autant, l’explosion du trafic internet sécurisé ne simplifie pas la tâche du filtrage HTTPS pour les DSI et RSSI qui font face à un véritable casse-tête technique avec le déchiffrement SSL/TLS et juridique puisque l’entreprise n’est pas autorisée à déchiffrer tous les flux (dans le domaine bancaire ou de la santé par exemple…). En effet, l’analyse des flux échangés entre le réseau interne de l’entreprise et l’extérieur est vital en matière de sécurité web et de protection des systèmes d’information. Quelles sont donc les recommandations pour prendre en compte cette nouvelle exigence liée au HTTPS ?
Le protocole HTTPS vient compléter le protocole historique HTTP avec une couche de sécurité supplémentaire qui permet d’échanger des informations sécurisées sur un réseau TCP/IP. Cette couche supplémentaire correspond au protocole TLS (Transport Layer Security) qui est une version plus récente et surtout plus sécurisée du protocole SSL (Secure Socket Layer) plus connu.
Lorsque les flux HTTP sont encapsulés dans le protocole TLS, cela garantit à la fois la confidentialité et l’intégrité des communications depuis le serveur jusqu’aux postes clients connectés tout en assurant leur authentification. Toutes les parties prenantes ont ainsi la certitude que l’on ne pourra pas truquer les informations échangées : le site web que l’on consulte est bien celui que l’on s’attend à voir et les internautes peuvent en toute tranquillité fournir leur numéro de carte bancaire et/ou renseigner des informations personnelles.
Dans un contexte de prolifération des cyber menaces, il est évident que la généralisation des connexions sécurisées sur le web est une tendance de fond positive, tant dans la sphère privée que pour les entreprises. Mais les spécialistes de la sécurité informatique ne s’y trompent pas : si les flux sont chiffrés, ils peuvent évidemment présenter des risques cachés ! En effet, les hackers peuvent tenter d’y dissimuler leurs malwares et certaines URL en HTTPS peuvent bien évidemment être malveillantes. C’est pour cela qu’il est désormais indispensable d’enrichir ses dispositifs traditionnels de sécurité pour déchiffrer ces flux et vérifier qu’il n’y ait pas de menaces à l’intérieur…
Pour faire face à ces risques cachés et aider les organisations à protéger leur système d’information, l’ANSSI a établi des recommandations. Malgré tout, le protocoleTLS apportant une sécurité et une confidentialité des échanges, « casser » cette protection n’est pas forcément simple techniquement ni dénué d’obligations légales à respecter…
Evidemment, la liste blanche qui n’autorise la navigation que vers les URL reconnues et préalablement qualifiées, serait un excellent moyen de se protéger d’éventuelles menaces mais elle n’est pas forcément applicable dans tous les secteurs d’activité. Il est donc parfois nécessaire de déchiffrer…
Pour garantir une communication sécurisée, le mécanisme utilisé dans le cadre d’un échange HTTPS repose sur une authentification à l’aide d’un certificat associé au site web que le navigateur du poste client va vérifier, ainsi que sur l’échange de clés publique et privée. La clé publique (accessible à tous) est utilisée pour chiffrer les données tandis que seule la clé privée permet de les déchiffrer.
Pour pouvoir intercepter cette communication sécurisée, la passerelle de sécurité web doit recourir à la technique du MITM ou « Man in the middle » en validant le certificat elle-même et en établissant une connexion où elle se fait passer en quelque sorte pour l’utilisateur. La passerelle de sécurité web va donc reformer la communication grâce au jeu des certificats sans pour autant briser la chaîne de sécurité : l’utilisateur continue à accéder au site web de manière sécurisée mais la passerelle peut vérifier la nature des contenus échangés. Pour cela, elle doit intégrer un pack de déchiffrement HTTPS (SSL) comme nous le proposons chez Olfeo.
L’objectif est évidemment de bloquer une éventuelle menace le plus tôt possible, avant qu’elle n’atteigne le poste de l’utilisateur final qui est de plus en plus la cible des cybercriminels. Il est d’ailleurs essentiel de développer une meilleure culture de la sécurité auprès des utilisateurs finaux et faire changer les comportements.
Le filtrage HTTPS et le déchiffrement SSL posent évidemment des problématiques d’optimisation technique, de droits et d’obligations. La première exigence est évidemment de garantir le plus haut niveau de sécurité et de confidentialité autour de la passerelle de sécurité web qui va traiter des données normalement chiffrées et donc potentiellement confidentielles.
Ensuite, le déchiffrement SSL est consommateur de ressources machines ; la bonne pratique est donc de mettre en place des exceptions en ce qui concerne certains flux comme ceux des logiciels métiers autorisés par exemple. Ceci afin de concentrer ses efforts de déchiffrement sur d’autres natures de trafic comme YouTube, les réseaux sociaux, l’utilisation d’un webmail, etc.
En effet, le déchiffrement de ces flux est parfois indispensable au regard des obligations qui pèsent sur l’entreprise en matière de conformité légale et culturelle du surf internet : des vidéos YouTube peuvent proposer des tutoriaux pour fabriquer des grenades artisanales ou donner accès à des images très violentes et ce type de navigation ne peut être accepté dans l’entreprise. Par contre En revanche, il est également interdit de déchiffrer des flux liés à la navigation sur certains sites web comme par exemple lorsqu’un utilisateur va consulter le site de sa banque, de son assureur ou accède au portail AMELI puisque des données personnelles peuvent alors être échangées…
Les exigences de conformité légale en matière de déchiffrement SSL sont donc cruciales et sont exprimées dans la note technique de l’ANSSI. Il faut donc vous assurer que votre proxy est conforme et respecte bien ces obligations comme nous le faisons chez Olfeo.
Enfin, pour que votre stratégie de filtrage HTTPS soit réellement efficace, il ne faut pas se tromper d’outils et ne pas faire reposer le déchiffrement SSL uniquement sur l’UTM (Unified Threat Management) et/ou le Firewall. En effet, on sait aujourd’hui que le déchiffrement SSL sur un Firewall peut représenter une perte de performance allant jusqu’à 74% (NSS Labs, John W. Pirc, Significant SSL performance loss leaves much room for improvement), il est donc indispensable d’ajouter un Proxy autonome à votre Firewall.
