Archives du mot-clé SSL

Des vrais-faux certificats Google utilisés à la direction générale du Trésor

Via TheRegister et Silicon :

Voilà qui fait tache : Google a pris la main dans le sac la Direction Générale du Trésor de chez nous qui émettait des certificats signés par le Trésor et se faisaient passer pour le site de Google.

L’ANSSI a déclaré qu’il s’agissait d’une erreur humaine lié à la mauvaise configuration d’un WAF… Trop gros passera pas ? Pour d’autres c’est plutôt une tentative échouée de surveiller l’utilisation faite par les employés du Trésor des services de Google.

La confiance envers les certificats encore mise à mal

Via TheRegister :

Dernièrement on s’est habitué à voir des autorités de certification piratées, des grosses gaffes, des govs qui s’approprient des certificats etc.

Cette fois ça va encore plus loin : il n’y a pas eu de piratage mais un certificat valide a été donné à une entreprise fictive brésilienne se faisant appeler Buster Paper Comercial Ltda.
Ce certificat a ensuite été exploité pour signer des malwares (PDF piégé).

D’après l’autorité de certification qui a généré ce certificat, DigiCert, tout a été fait dans les règles de l’art.
Bref un certificat ça vaut plus rien !

Des certificats frauduleux créés pour Google.com

Encore un coup dur pour le système de certificats SSL/TLS actuel :

Google a détecté dans la journée du 24 décembre l’existence d’un certificat frauduleux pour les domaines *.google.com.
En effet ce certificat n’a pas été créé par Google mais est valide dans le sens où il a été créé par une sous-autorité de certification dépendant d’un CA considéré sûr jusqu’à présent.

A l’origine de ce merdier se trouve l’autorité de certification TURKTRUST. Elle aurait issue par erreur (d’après TURKTRUST) deux certificat d’autorité de certification au lieu de deux certificats simples pour le gouvernement turc (*.EGO.GOV.TR et e-islem.kktcmerkezbankasi.org).
Ces deux certificats ont ensuite permis de créer un certificat frauduleux pour *.google.com.

A l’heure actuelle très peu d’infos sont disponibles sur le sujet. On ne sait pas si c’est un coup du gov turc, si l’erreur de TURKTRUST n’est pas volontaire etc.
Les sous-certificats (*.EGO.GOV.TR et e-islem.kktcmerkezbankasi.org) font bien sûr être bannis par les différents navigateurs mais on ne sait pas si TURKTRUST aura une punition pour cette erreur…

L’article de KrebsOnSecurity, l’article de ZeroDay

Piratage de DigiNotar : le rapport final de Fox IT rendu

Le hack de DigiNotar par le « Comodo Hacker » remonte à fin aout 2011 (date des premières découvertes).

Mais le rapport final rendu par Fox IT sur l’analyse de ces intrusions est téléchargeable depuis peu.
On y découvre que le pirate avait bien plus d’accès que ce qui était imaginé précédemment et que son intrusion a duré environ 6 semaines.

Fox IT a fait un sacré boulot : le rapport PDF fait 100 pages.

Le code le plus dangereux au monde

Via HackerNews :

Sous ce titre alarmant se cache une étude menée par les Universités de Stanford et du Texas :
The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software

Le document PDF de 12 pages relève les erreurs d’utilisations de différentes librairies et API SSL qui rendent possibles les attaques MITM.
On découvre que même des librairies très utilisées comme CURL et OpenSSL sont souvent mal utilisées. Sans doute un must-read pour les développeurs qui ont à faire du SSL dans leur code.

CRIME exploite bien la compression

Dans cet article d’ArsTechnica vous saurez ce qu’il y a à savoir sur CRIME et vous pourrez même le voir à l’œuvre dans une vidéo.
La nouvelle information à prendre en compte c’est que au delà de la compression DEFLATE utilisée sous SSL/TLS, celà concerne aussi le protocole SPDY qui compresse les données.

L’article indique bien que ce type d’attaque est difficilement à la portée du « petit hacker » mais risque d’être exploité par des pays comme l’Iran.