Archives par mot-clé : https

Abuser le HTTPS des sites Internet

Deux chercheurs en sécurité informatique découvrent une méthode pour abuser les sites Internet en mode sécurisé (https).

Deux informaticiens Belges viennent d’alerter Google, Microsoft et les participants de la Black Hat conférence d’un problème découvert permettant de piéger les sites Internet et leur mode sécurisé, le HTTPS. Pour Tom Van Goethem et Mathy Vanhoef, deux étudiants de l’université de Leuven, la technique exploitée est baptisée HTTP Encrypted Information can be Stolen Through TCP-Windows (HEIST).

L’idée malveillante est d’intercepter les données transmisses, passant par les protocoles de sécurité tels que SSL ou TLS. Bilan, le HTTPS (connexion sécurisé) ne sert plus à rien si l’interception du trafic est orchestré, dans la foulée, par un fichier JavaScript caché sur une page web dédiée, ou exploitée à cet effet. Une publicité diffusée par une régie extérieure, qui elle n’est pas sécurisée, peut permettre cette infiltration.

La présentation des deux doctorants en informatique est disponible ICI. Pour vous protéger de ce genre d’indiscrétion, désactivez les ‘third-party cookies’ dans les paramètres de votre navigateur. Je vais être clair, pas pratique, cela va perturber le bon fonctionnement des sites en HTTPS. Mais en attendant une correction des géants de l’Internet, pas d’autres solutions.

Ne confondons plus confidentialité avec sécurité

Depuis début octobre 2015, Twitter a décidé de chiffrer les échanges de messages privés entre ses utilisateurs, en expliquant que cela augmente la sécurité. A chaque fois qu’un géant de l’Internet, Google en tête, passe en trafic SSL, le message est « c’est pour améliorer la sécurité ». Mais l’utilisation de flux chiffrés est-elle un véritable vecteur d’amélioration de la sécurité des systèmes d’informations ?

N’est-ce pas plutôt, et comme l’indique l’ANSSI dans son document Recommandation de Sécurité concernant l’analyse des flux HTTPS « Une technologie conçue pour protéger en confidentialité et en intégrité les communications de bout en bout ».

La confidentialité consiste dans « le fait de s’assurer que l’information n’est seulement accessible qu’à ceux dont l’accès est autorisé » selon la définition de l’Organisation Internationale de Normalisation (ISO). La sécurité, elle, correspond à l’absence de menaces, ou à la mise en place de stratégie et d’outils pour réduire très significativement ces menaces.

Le chiffrement du trafic rend pratiquement impossible l’interception des échanges par une personne non autorisée et améliore de ce fait la confidentialité. Et ce de bout en bout, entre le site Internet et l’ordinateur ou le terminal mobile. Mais si le site web est infecté, alors les codes malicieux qui vont transiter sur le réseau ne pourront plus être détecté par les systèmes de sécurité de l’entreprise déployés dans l’infrastructure. En voulant améliorer la confidentialité, le développement des trafics chiffrés ouvre en fait une brèche béante de sécurité

L’Arcep vient d’annoncer qu’à la mi-2015, la part de trafic chiffré vue par les FAI en France représenterait près de 50% contre 5% en 2012. De ce fait, et sur la moitié des trafics internet, la sécurité de l’entreprise ne pourra reposer que sur les capacités d’analyse et de détection déployées après le tunnel chiffré. C’est-à-dire sur le périphérique. Dans la grande majorité des cas, il s’agit d’un simple agent d’antivirus, ce qui est loin d’être suffisant vu la complexité des menaces actuelles. Les pirates l’ont bien compris, et on estime que 80% des attaques complexes utilisent désormais les connections chiffrées pour pénétrer le système informatique des entreprises.

Cela crée une situation paradoxale pour les employés, qui demandent, et à juste titre, à la fois la confidentialité des échanges, la sécurisation des informations sensibles et la protection contre les attaques de type Ransomware. Ne confondons pas confidentialité et sécurité… ça n’est pas la même chose. Ces deux besoins fondamentaux peuvent paraître antinomiques, mais il est désormais possible, avec des solutions de Sécurisation des Flux chiffrés (Encrypted Trafic Management) de faire quelles se complètent pour renforcer la sécurité du système d’information. (Par Dominique Loiselet, Directeur
Général de Blue Coat France.)

Les Risques Cachés de l’Explosion du Trafic HTTPS

Si vous n’êtes pas préparé à une forte augmentation du trafic HTTPS, votre réseau est menacé !

Paradoxal, non ? HTTPS, après tout, est une bonne chose. Comme tout le monde le sait, HTTPS est la version sécurisée du Hypertext Transfer Protocol (HTTP), qui utilise le protocole SSL/TLS pour crypter et protéger le trafic web. Si vous souhaitez privatiser n’importe quelle action en ligne — qu’il s’agisse de l’achat de nouvelles chaussures ou du paiement d’une facture— HTTPS est ce qui protège vos communications des regards mal intentionnés.

Les professionnels de la sécurité ont toujours encouragé l’utilisation d’HTTPS par les applications web. Il semble que leurs vœux aient été exhaussés. Comme le confirme l’ouvrage The Cost of “S” in HTTPS, 50% des flux sur le web sont aujourd’hui sécurisés. En fait, beaucoup des plus grands sites web ont adopté HTTPS comme leur protocole par défaut, dont Google, Facebook et YouTube. Mieux encore, les fournisseurs de navigateurs tels que Google ont même commencé à considérer toutes les pages non HTTPS comme non sécurisées, un nouveau pas vers la standardisation par défaut d’HTTPS.

De nombreux facteurs contribuent à cette ruée vers HTTPS, dont le principal est probablement « l’effet Snowden. » Certes, les spécialistes ont toujours compris la facilité avec laquelle nos conversations sur Internet peuvent être interceptées, mais les documents secrets dévoilés par Edward Snowden n’ont pas seulement permis au grand public d’identifier le risque du ‘man-in-the-middle’ (MitM), mais ont prouvé que les gouvernements y ont participé activement depuis des années. Maintenant que nous savons que quelqu’un nous regarde, nous prenons la protection de nos conversations beaucoup plus sérieusement.

Au sens large, cet accroissement du trafic HTTPS est une bonne chose. Toutefois, sous la surface il dissimule deux écueils qui peuvent sérieusement affecter votre sécurité, si vous n’y êtes pas préparé. Spécifiquement,

1.      Les méchants utilisent aussi HTTPS,
2.      La sécurisation de ce trafic entraîne de nouvelles contraintes en matière de performances.

Les avantages que vous retirez d’HTTPS profitent également aux hackers. Les pirates veulent dissimuler leurs communications, qu’il s’agisse de leurs téléchargements de malware ou des canaux de commande et de contrôle (C&C) que leur malware utilise pour communiquer avec eux. HTTPS fournit un mécanisme très efficace pour faire précisément cela. Les méchants ont compris que HTTPS est typiquement un « trou noir » pour vos outils de sécurité réseau, et ont donc commencé à l’utiliser pour leurs activités malveillantes, afin de les masquer.

C’est la raison pour laquelle il est plus important que jamais de commencer à sécuriser HTTPS. Vous avez besoin de solutions de sécurité capables de “voir” à l’intérieur des communications HTTPS, et d’y appliquer les scans traditionnels de sécurité (IPS, antivirus, etc.).

Heureusement, il existe une solution à ce problème. De nombreuses solutions de sécurité réseau actuelles, telles que de nouvelles versions de boîtiers UTM, des firewalls de nouvelle génération (NGFW), et d’autres proxies de sécurité, disposent de passerelles sur la couche applicative ou de capacités d’inspection DPI pour HTTPS. En gros, ils effectuent une attaque MitM « amicale » sur HTTPS afin de le décrypter de façon temporaire et de mettre en œuvre les scans de sécurité. Le boîtier ré encrypte ensuite le trafic pour le délivrer au réseau. Ces outils nécessitent que vos clients acceptent un certificat numérique, afin de maintenir la confidentialité de la connexion HTTPS. En bref, ils vous permettent de potentiellement détecter des activités malicieuses dans un trafic normalement indéchiffrable, sans remettre en cause la vie privée de vos utilisateurs.

Toutefois, sécuriser le trafic HTTPS met en lumière et exacerbe le second problème – les contraintes d’HTTPS en matière de performances. En termes simples, encrypter quelque chose consomme des ressources de traitement et accroît le volume du trafic. Si vous désirez savoir dans quelle proportion, il vous suffit de consulter l’ouvrage que j’ai cité précédemment. En gros, les conséquences ne sont pas négligeables, mais nous disposons généralement des ressources processeur et réseau pour les gérer… Ceci, avant d’y ajouter les solutions de sécurité dont j’ai parlé plus haut.

Comme je l’ai mentionné précédemment, des solutions de sécurité peuvent maintenant décrypter le trafic HTTPS. Toutefois, ce décryptage double le temps de traitement d’HTTPS, le boîtier de sécurité devant décrypter puis ré encrypter avant de délivrer le trafic. De plus, dans l’environnement actuel riche de menaces, vous souhaiterez que plusieurs couches de sécurité (par exemple IPS, antivirus, détection C&C) contrôlent votre trafic HTTPS. Si vous avez mis en place un contrôle de sécurité séparé pour chaque couche, chacune d’entre elles nécessite un traitement, ce qui ralentit singulièrement le trafic. Si 50% du trafic Internet est en protocole HTTPS, cela représente un vrai goulet d’étranglement.

La solution ? Utiliser des contrôles de sécurité tout en un conçus pour traiter la charge HTTPS. Un des avantages des nouveaux boîtiers UTM et des firewalls de nouvelle génération est que leurs couches de sécurité sont toutes appliquées en un seul point. Ceci veut dire qu’ils n’ont à décrypter HTTPS qu’une seule fois. Cependant, si votre sécurité dépend à ce point d’un seul boîtier, mieux vaut être sûr qu’il sera capable de supporter la charge. Beaucoup de boîtiers UTM ou Next Generation Firewalls mettent en avant leurs performances firewall, qui ne tiennent pas compte des autres contrôles de sécurité et de l’inspection des paquets HTTPS. Il est donc très important d’examiner la performance du boîtier lorsque tous les contrôles de sécurité sont activés, et spécialement l’inspection des paquets HTTPS. Ce n’est qu’une fois cette vérification faite que vous saurez si votre boîtier sera capable ou non de traiter, et de sécuriser, l’explosion des flux HTTPS.

Pour résumer, l’usage accru du protocole HTTPS est une très bonne chose pour la sécurité du web. Toutefois, vous devez vous assurer que vos solutions de sécurité en place sont capables réellement d’identifier les menaces à l’intérieur d’HTTPS, et qu’elles peuvent supporter l’accroissement de la charge HTTPS induit par l’effet Snowden. (Par Pierre Poggy, Country Manager Watchguard France / TechDirt)

Inquiétude pour des clients de LaPoste.net

Le site Internet de LaPoste.net propose un service webmail efficace. Sauf que les identifiants de connexions ne sont pas sécurisés. Plusieurs lecteurs de Data Security Breach nous ont annoncé être inquiets du système d’identification du site LaPoste.net. Les connexions « chiffrées » au webmail Laposte.net n’existent pas. Sur la page d’accueil du site http://www.laposte.net, il est possible de se connecter à « Ma boîte aux lettres » LaPoste.net. « Je suis extrêmement surpris que l’on puisse saisir son identifiant et son mot de passe alors que la connexion n’est pas chiffrée et sécurisée en https avec un certificat SSL » indique à la rédaction Vincent. Effectivement, cela signifie tout simplement que les identifiants et les mots de passe transitent en clair sur le réseau Internet entre l’ordinateur de l’utilisateur et les serveurs de La Poste. Une personne mal intentionnée pourrait aisément, et avec quelques outils spécialisés, comme en sniffant les trames Ethernet avec Wireshark, récupérer les informations privées au moment de la connexion. Autant dire qu’un utilisateur passant par une connexion wifi gratuite dans un aéroport, un restaurant (MacDo…), un café (Starbucks…) met tout simplement son webmail en danger. Plusieurs lecteurs ont envoyé un courriel à La Poste. Des services tels que Google ou encore Outlook (live.com) proposent des connexions en https et un certificat SSL.

Alors sécurisé ou pas ?

Ce qui compte est la sécurisation https de l’url qui se trouve dans le formulaire de login. Si celle ci est en https, aucun souci, même si la page qui héberge ce formulaire n’est pas https. Donc, pas d’inquiétude le login de la poste est sécurisé, et les identifiants ne sont pas transmis en clair. « Une fois de plus le petit logo vert partout n’est pas un garant de la sécurité d’un site » rajoute Seb, un lecteur. Il faut admettre, cependant, qu’un peu plus de visibilité ne nuirait pas à la bonne compréhension, et à rassurer les utilisateurs. La dynamique équipe sécurité de La Poste nous a répondu à ce sujet. Il faut tout d’abord différencier le portail laposte.net sur lequel est disponible le webmail et l’authentification au webmail qui ne fonctionnent pas avec les mêmes restrictions d’accès et de sécurité. « Pour accéder à leurs mails XXXX@laposte.net,  nos clients doivent impérativement passer par une phase d’authentification (échange des login/mot de passe) qui est biensur  cryptée en Https » confirme à Data Security Breach l’équipe sécurité de La Poste. Voilà qui devrait définitivement rassurer les utilisateurs.