Archives du mot-clé SSL

testssl.sh : tester la sécurité d’un serveur HTTPS (et autres protocoles derrière TLS/SSL)

Via ISC SANS :

Une nouvelle version de testssl.sh, un script permettant de déterminer quelle est le niveau de sécurité du chiffrement utilisé sur un site, est disponible.
Ce script permet aussi de tester d’autres protocoles que HTTPS, regarde les différents algos utilisables (ex: RC4) et vérifie si le serveur a été patché contre CRIME, POODLE, BEAST, Heartbleed et compagnie.

Symantec a vendu de faux certificats Google (sans le savoir)

Via V3 :

Thawte, une entreprise de vente de certificats TLS filiale de Symantec a eu la mauvaise surprise de découvrir que certains employés ont vendu de vrais-faux certificats pour des domaines de Google.

Les employés auraient agit par manque de sérieux (n’ont pas suivi les règles de sécurité pour s’assurer de l’identité de l’acheteur, etc) et non par malveillance. Dans tous les cas il y a maintenant des postes à pourvoir chez Thawte.

C’est Google qui a découvert (via Certificate Transparency log) les faux certificats et pris contact avec Symantec pour régler le problème.

Komodia : la boîte derrière le scandale Superfish

Superfish est le adware créé par Komodia qui installe de faux certificats sur une machine dans le but d’intercepter (pour surveillance et/ou modification) le trafic encrypté.

Découvert sur les PCs Lenovo, la présence de cet adware a fait beaucoup de bruit en particulier parce que le certificat utilisé par Komodia était facilement cassable permettant ainsi à n’importe qui de déchiffrer le trafic SSL/TLS émit par un poste infecté.

Dans un article, Journal du Net a fait un bon résumé de cette histoire.

Microsoft / Comodo : double-team, double FAIL

Voici une nouvelle bien chantante 🙂

Un finlandais qui disposait d’un simple compte email sur le Microsoft Live finlandais (live.fi) s’est demandé s’il pouvait enregistrer une adresse paraissant comme étant du staff Crosoft et en faire quelque chose d’intéressant.

Comme Live.com permet, comme d’autres messageries connues, d’enregistrer des alias il en a profité pour obtenir l’adresse hostmaster@live.fi.

La suite ? Il a envoyé un email à Comodo pour demander un certificat SSL/TLS valide estampillé Microsoft et il l’a obtenu… sans que son identité ne soit vérifiée.

FREAK : Windows et IE sont vulnérables

Aïe, aïe, aïeSChannel (Secure Channel), le service fournissant des fonctions de cryptographie sous Windows, est vulnérable à FREAK quelque soit la version du système.

Cela veut dire que si vous utilisez IE sous un Windows récent (ou pas, du moment que SChannel est utilisé) sur PC, smartphone ou autre alors vous êtes vulnérables.
Et comme IE n’est sans doute pas le seul soft utilisant SChannel sous Windows, ça promet…

FREAK : encore une faille SSL/TLS

Via FreakAttack, WebSense, NEXTINpact :

Et oui ! Encore une vulnérabilité dans SSL/TLS, ou devrais-je plutôt dire dans les implémentations OpenSSL et SecureTransport (Apple) de ces protocoles.

Lors de l’établissement d’une connexion SSL entre un serveur et un client une négociation a lieu afin de se mettre d’accord sur une « cypher suite », c’est à dire les différents moyens cryptographiques qui seront utilisés dans la suite de la communication.
Bien sûr les deux parties font en sorte de choisir les paramètres les plus sûrs pour échapper aux grandes oreilles.

Mais… certaines implémentations ont conservés une relique des lois cryptographiques américaines datant des années 90 car ces derniers refusaient que les algos créés chez eux soit utilisés par l’ennemi d’autres pays avec des tailles de clés difficiles à casser.

Bien sûr on pensait être débarrassés de tout cela mais il s’avère que dans certaines situations un attaquant en position d’homme du milieu puisse forcer un downgrade du chiffrement vers la suite EXPORT_RSA qui utilise une clé RSA de 512 bits.
Pour cela il faut que le serveur cible supporte EXPORT_RSA et que le client soit vulnérable (c’est à dire qu’il va accepter bêtement une clé RSA de 512 alors qu’il avait demandé plus solide).
Si une telle situation se vérifie alors il faut relativement peu de moyens (7 heures et demi et 104 dollars pour des serveurs EC2) pour factoriser une clé RSA de 512 bits.

Comme les serveurs web (ou autre) sont faignants ils ne prennent même pas la peine de régénérer une clé RSA à chaque nouvelle communication, ce qui fait qu’une fois une clé cassée vous pouvez la réutiliser tant que le serveur n’a pas été redémarré !

L’attaque est bien réelle et il est alors possible d’intercepter et modifier les communications à destination de www.nsa.gov si le client est vulnérable (le site de la NSA est sur un serveur Akamai qui sont vulnérables mais corrigés sous peu).

Plus d’infos sur la faille chez Cryptography Engineering.
Et pour tout savoir de SSL/TLS (y compris les précédentes attaques), rendez-vous sur StackExchange.

OpenSSL a colmaté la faille en janvier. Apple doit toujours faire un fix. Les matériels plus anciens ou laissant moins de libertés sur les updates (Android & co) sont plus vulnérables.