6 questions à se poser avant de choisir une solution de protection SSL
This post is also available in:
Anglais 
Allemand 
Italien 
Portugais - du Brésil 
Espagnol 
Russe
Aujourd’hui, 99 % du trafic Internet est chiffré. La récente réglementation RGPD oblige les entreprises à utiliser le protocole HTTPS, les communications chiffrées devenant ainsi la méthode par défaut. Si le chiffrement du trafic est important pour préserver la sécurité et la vie privée des utilisateurs, il ouvre également la porte à une nouvelle génération d’attaques DDoS agressives qui peuvent mobiliser jusqu’à 15 fois plus de ressources sur le serveur de destination que sur l’hôte demandeur.
La détection du trafic malveillant dans le trafic chiffré est une tâche délicate. Cela revient à trouver une aiguille dans une botte de foin. Voilà pourquoi cette méthode est avantageuse pour les attaquants : elle soumet les infrastructures des réseaux et des applications ciblés à une forte pression.
En définitive, il n’existe aucune solution universelle pour la protection SSL. Chaque entreprise a ses propres priorités, ses propres besoins métier, sa sensibilité et ses besoins particuliers en matière de protection de la vie privée. Toutefois, certaines questions essentielles doivent être prises en compte lors de la sélection d’une solution de protection SSL la meilleure possible.
1. Avez-vous accès au certificat SSL ?
Certaines entreprises ne peuvent pas accéder au certificat. Cela peut être dû à des restrictions en matière de réglementation ou de confidentialité, à des problèmes d’architecture de réseau et de sécurité ou à des modèles de sécurité en tant que service (SaaS). Dans le cas d’un fournisseur de services de sécurité managés (MSSP) ou de services de nettoyage, le certificat du client final peut ne pas être disponible.
D’autres entreprises disposant d’un accès au certificat SSL peuvent déchiffrer le trafic SSL et obtenir une visibilité sur ce trafic.
2. Si le certificat est accessible, à quel niveau le trafic doit-il être déchiffré ?
L’accès au certificat est une chose, il faut ensuite considérer la topologie du réseau et la sécurité souhaitée.
Dans certaines topologies de réseau, le déchiffrement du trafic SSL est effectué à proximité des serveurs. Dans certains déploiements, il est préférable de déchiffrer le trafic plus tôt et d’éliminer les menaces à un stade précoce. Lorsque le déchiffrement est effectué à proximité du serveur, la protection repose généralement sur des solutions de protection applicative. Dans ce cas, il faut envisager des risques supplémentaires tels que les attaques DDoS, qu’il est préférable de bloquer plus tôt dans le réseau.
3. Si le certificat est accessible, quand le trafic doit-il être déchiffré ?
Le déchiffrement continu de la totalité du trafic SSL permet une visibilité totale, au prix d’une charge de calcul et d’une latence. Certaines entreprises ne peuvent se permettre une latence supplémentaire, ce qui signifie que le déchiffrement constant de toutes les sessions n’est pas envisageable. Ces entreprises préféreront une solution de sécurité qui ne déchiffre que dans certaines conditions, ou qui déchiffre une partie des sessions seulement, ou qui ne déchiffre pas du tout. Un déchiffrement limité du trafic SSL permet d’assurer la sécurité SSL tout en équilibrant la latence et l’expérience des utilisateurs légitimes.
[Sur le même thème : Détecter et bloquer les inondations HTTPS… sans clés de déchiffrement]
4. Si le certificat est accessible, quelle partie de la session faut-il déchiffrer ?
De même, pour déterminer à quel moment appliquer le déchiffrement, il peut être utile de choisir le niveau de déchiffrement. Le déchiffrement d’une partie seulement de la session SSL plutôt que de toute la session présente une grande valeur en termes de protection contre des attaques spécifiques. Tout comme la flexibilité relative au moment du déchiffrement des sessions SSL, le niveau de déchiffrement permet aux entreprises de trouver un équilibre entre les niveaux de sécurité souhaités et une expérience utilisateur optimisée.
5. Vos services sont-ils trop sensibles à la latence ?
Un déchiffrement de l’ensemble du trafic SSL offre une visibilité totale mais implique une charge de calcul importante, ce qui augmente la latence du service. Certaines entreprises et certains services ne peuvent pas se permettre la latence supplémentaire du déchiffrement SSL. Ces entreprises préféreront une solution SSL ne nécessitant aucun déchiffrement ou un déchiffrement minimal, réservé à certaines conditions et à une partie seulement des sessions.
6. Vos services utilisent-ils des réseaux de diffusion de contenu (CDN) ?
Un CDN achemine le trafic pour le compte de l’entreprise. En cas d’utilisation d’un CDN, l’adresse IP réelle ne peut se trouver qu’à l’intérieur des en-têtes HTTP chiffrés. Il n’y a donc aucun moyen de connaître le véritable client sans déchiffrer tout le trafic SSL. En présence de CDN, la solution de sécurité doit déchiffrer les sessions SSL complètes, identifier le véritable client dans les en-têtes HTTP et appliquer des mesures de sécurité ciblées.
Considérations importantes
Selon le rapport DDoS de Radware pour le deuxième trimestre 2021, les attaques Web chiffrées représentent 20 % du volume total des événements malveillants signalés au cours du trimestre. Une chose est sûre, les solutions classiques n’offrent pas les protections adéquates. Les solutions basées sur le réseau, telles que les détecteurs NetFlow, ne perçoivent pas le trafic SSL, ce qui rend le réseau dans lequel elles fonctionnent vulnérable aux attaques chiffrées.
Si vous utilisez un réseau de diffusion de contenu (CDN), celui-ci achemine le trafic pour le compte de l’entreprise. L’adresse IP réelle ne peut se trouver qu’à l’intérieur des en-têtes HTTP chiffrés. Il n’y a donc aucun moyen de connaître le véritable client sans déchiffrer tout le trafic SSL.
D’autres solutions imposent de déchiffrer intégralement les paquets HTTPS, ce qui porte atteinte à la vie privée des utilisateurs, ajoute de la latence et nécessite un processus lourd de gestion des clés.
