Blog GlobalSign

26 janv. 2018

Déchiffrement des flux SSL/TLS : ce qu’il faut savoir sur les racines et les AC émettrices

Le déchiffrement SSL/TLS (ou analyse SSL ou encore inspection des paquets en profondeur) est plus que jamais un sujet brûlant d'actualité dans le service informatique des entreprises. Je ne suis pas là pour vous dire si vous devriez y penser ou non. En tant qu’employé d’une autorité de certification (AC), j’ai un peu de mal avec ce concept car je crois vraiment aux principes de base du chiffrement. Mais de plus en plus d’entreprises y ont recours car le chiffrement n’offre pas la garantie d’un contenu sécurisé. Que vous recherchiez des informations sur le déchiffrement SSL ou que vous ayez déjà décidé de l’utiliser, vous devriez envisager de le faire de manière plus organisée et plus sécurisée.

C’est pour cette raison que je voulais vous parler d’un aspect particulier de l’implémentation du déchiffrement SSL qui échappe à beaucoup de monde. Je le sais parce que tout le monde est surpris de savoir qu’il est possible d’utiliser une AC émettrice privée et personnalisée pour créer des certificats de chiffrement et de déchiffrement.

En effet, plutôt que de dépendre de certificats d’AC auto-signés ou de certificats d’AC fournis avec les appareils de déchiffrement SSL, vous pouvez utiliser l’AC émettrice réservée d’une AC de confiance, telle que GlobalSign. Mais avant de nous concentrer sur ce point, rafraîchissons-nous un peu la mémoire sur le sujet en général.

Qu’est-ce que le déchiffrement SSL et à quoi ça sert ?

De plus en plus de sites web publiques adoptent le protocole HTTPS, ce qui permet de chiffrer les communications et les données échangées entre un serveur web et un client (l’utilisateur d’un navigateur web), ce qui représente plus de 60 % du trafic web selon SonicWall.

Bien que ce choix de tout chiffrer puisse sembler très judicieux car il permet de sécuriser les paiements par carte bancaire et les connexions en ligne, il existe, malheureusement, des individus néfastes qui ont commencé à cacher du code malveillant dans ce trafic chiffré. Cela signifie que les défenses habituelles des services informatiques, tels que les systèmes de prévention d’intrusions et la prévention de perte de données, sont contournées et le code malveillant atteint les machines des employés. Il vaut aussi la peine de mentionner que cette tendance à cacher du malware dans le trafic chiffré a augmenté de 72 % en l’espace d’un an seulement. Elle va probablement continuer à croître, en raison notamment de l’augmentation du nombre de fournisseurs SSL gratuits, tels que Let’s Encrypt, qui ont considérablement facilité l’acquisition de certificats à validation de domaine (DV) qui offrent très peu de garantie. C’est de plus en plus difficile de savoir si un site sécurisé est un site sans danger.

Le déchiffrement SSL aide à mitiger cette menace en se positionnant entre le client final (par exemple, vos employés qui naviguent sur le Web) et les serveurs web, en filtrant les codes malveillants. Il existe de nombreux appareils de déchiffrement sur le marché qui fonctionnent plus ou moins de la même manière. Lorsque du contenu HTTPS est échangé entre un client et un serveur web, le trafic passe à travers l’appareil qui le déchiffre et qui l’analyse pour repérer tout code malveillant.

Une fois l’analyse achevée, l’appareil crée une nouvelle session SSL avec le client final pour déchiffrer et rechiffrer le contenu. C’est sur ce point que je voudrais me concentrer, sur ces nouvelles sessions SSL et l’AC émettrice qui en sont à l’origine.

Comment fonctionne les processus de déchiffrement et de rechiffrement ?

Pour que l’appareil de déchiffrement SSL puisse déchiffrer et rechiffrer le contenu avant qu’il soit renvoyé aux utilisateurs finaux, il doit pouvoir émettre des certificats SSL à la demande. Cela signifie qu’un certificat d’AC (appelé parfois AC émettrice ou intermédiaire) doit être installé sur l’appareil.

Un autre facteur important à prendre en compte, c’est que pour que les navigateurs fassent confiance à ces certificats SSL émis à la demande (et ne pas afficher des messages d’alerte inquiétants, comme celui-ci-dessous, chaque fois qu’un employé visite un site qui a été rechiffré), la chaîne d’AC (ou hiérarchie) doit être ajoutée dans le magasin de confiance des navigateurs. Comme ces certificats ne sont pas émis depuis une AC de confiance publique, dans quel cas les racines et AC intermédiaires sont déjà intégrées, vous devrez distribuer manuellement les hiérarchies d’AC à tous les clients finaux.

Warning_message_for_self-signed_or_untrusted_roots_in_Chrome.png

Message d’alerte pour les racines auto-signées ou non-reconnues dans Chrome (source : BadSSL.com)

Pour les machines Windows, ce processus ne sera peut-être pas aussi compliqué car vous pouvez utiliser les fonctionnalités d’Active Directory et les stratégies de groupe, mais qu’en sera-t-il pour vos appareils mobiles, Mac ou Linux ? De façon générale, ce sera plus compliqué pour tout appareil qui n’utilise pas Windows.

Vous devrez également savoir si vous avez d’autres racines à conserver et à gérer dans votre entreprise, comme les racines auto-signées, les racines d’AC Microsoft ou les racines OpenSSL. Elles peuvent s’accumuler rapidement. Comment protégez-vous les clés privées ? Comment vous assurez-vous qu’aucune d’entre elles ne va expirer de manière impromptue ? Comment procédez-vous pour être sûr que vous utilisez la bonne racine pour chaque cas d’utilisation ?

Il existe une meilleure méthode : utilisez la racine privée et dédiée d’une AC externe

Si l’idée de devoir gérer plusieurs racines ou dépendre de certificats auto-signés ne vous semble pas alléchante, d’autres options s’offrent à vous. Vous pouvez choisir d’utiliser une AC externe à la place (veuillez noter que toutes les AC ne proposent pas ce service à l’inverse de GlobalSign). Vous vous demandez peut-être : « attends une seconde, je croyais qu’on ne pouvait pas utiliser des certificats de confiance publique pour les appareils de déchiffrement SSL ? ». Et vous avez raison. Dans ce cas, les certificats seraient émis depuis une AC émettrice privée enchaînée à l’AC racine privée, créée pour votre entreprise et qui serait gérée par GlobalSign.

	Example (simplified) architecture for dedicated customer roots.png

Exemple (simplifié) de l’architecture pour les racines dédiées du client

Alors, comment ce système règle-t-il les problèmes mentionnés plus haut ? Pour commencer, il peut minimiser le nombre de racines que vous devez gérer et distribuer. Avec cette option, vous pouvez choisir de n’avoir plus qu’une seule racine privée pour tous vos besoins PKI internes et d’y relier autant d’AC intermédiaires que vous le souhaitez. Le diagramme ci-dessus, par exemple, vous donne l’exemple d’une hiérarchie multi-tiers dans laquelle l’une des AC émettrices (ou AC intermédiaires si vous préférez) est utilisée pour les activités d’analyse et de déchiffrement SSL et l’autre AC émettrice est utilisée pour les machines internes (ordinateurs bureau et portables, serveurs, etc.).

Dans les cas d’utilisation pour les appareils SSL, l’AC émettrice doit être hébergée par le client (car elle doit être installée sur l’appareil lui-même) mais l’AC racine supérieure est hébergée par GlobalSign. Nous gérons la sécurisation et la protection de la clé privée et nous nous assurons de son renouvellement dans les temps. Cela signifie également que vous n’avez plus qu’à distribuer l’AC racine supérieure et tous les certificats émis depuis les AC qui y sont reliées seront également reconnus.

L'un des autres avantages de cette approche, c’est que si vous avez besoin de révoquer l’AC émettrice de votre appareil, nous créons une AC émettrice de rechange qui peut être reliée à votre racine privée originale et que vous pouvez utiliser immédiatement. Vous n’aurez besoin de distribuer aucune autre racine puisque celle-ci sera déjà enchaînée à l’AC racine de confiance.

Laissez-nous nous occuper de vos besoins PKI internes

Le cas d’utilisation pour le déchiffrement SSL est le dernier d’une tendance croissante dans laquelle on observe que de plus en plus d’entreprises dépendent d’une PKI interne ou privée. D’autres cas d’utilisation courants incluent les certificats pour l’authentification des utilisateurs ou des machines et les certificats SSL pour les serveurs internes et les configurations qui ne peuvent pas être sécurisés à l’aide d’un certificat de confiance publique selon les exigences du CA/B Forum.

Si vous pensez à utiliser une PKI interne pour ces mises en pratique ou pour d’autres, ou si vous gérez déjà votre propre PKI interne, sachez que vous pouvez en sous-traiter la gestion à une AC externe. Gérer les AC et les certificats approuvés, aussi bien publics que privés, c’est notre métier… laissez-nous nous en charger.

par Sid Desai

Partager ce blog

aeg-product-webinar-pic.jpg

Intégration Active Directory

La PKI au service d’une gestion automatisée des certificats
pour les grandes entreprises

Lire la fiche technique