OS X Lion et le problème des certificats TLS/SSL

Anthony Nelzin-Santos |
skitchedLes certificats TLS/SSL sont indispensables à la communication sécurisée sur Internet : ils sont le garant de la confiance que vous pouvez accorder au site sur lequel vous allez vous connecter. Pierre angulaire de la sécurité sur Internet, ils sont aujourd'hui une cible de choix pour les pirates : obtenez-en un, et vous pourrez montrer patte blanche avec les plus mauvaises intentions du monde.

En mars dernier, un hacker iranien avait réussi à obtenir du fournisseur de certificats Comodo neuf certificats pour des domaines appartenant à Microsoft, Google, Mozilla ou Skype. Un hacker qui aurait réussi à détourner le système DNS d'un utilisateur dont l'OS ou le navigateur considère que le certificat contrefait est valide pourrait mener l'utilisateur a un site malicieux qui aurait non seulement l'apparence d'un site connu, mais se ferait techniquement passer pour lui (URL d'origine affichée dans le navigateur, connexion sécurisée, etc.).

Ce problème s'est à nouveau posé ces derniers jours : des hackers, à nouveau iraniens semble-t-il, ont réussi à obtenir des certificats valides sur l'ensemble des services de Google chez Diginotar. De quoi construire par exemple un faux Gmail se faisant complètement passer pour le vrai, et ainsi intercepter les communications des opposants au régime. Un véritable effet domino qui pose la question de la faiblesse — relative — du système TSL/SSL centralisé et basé uniquement sur la confiance envers un tiers : Diginotar (par le biais de sa maison-mère Vasco) et Comodo ont tout deux délégation de Verisign pour fournir des certificats numériques.

Google a rapidement réagi en révoquant 247 certificats de Diginotar. Chrome est capable de détecter le certificat usurpé, Mozilla explique comment le supprimer dans Firefox, et Microsoft a mis à jour Internet Explorer. Apple, elle, n'a pas réagi : il serait certes plutôt compliqué de mettre en œuvre une attaque man-in-the-middle avec DNS poisoning utilisant ces certificats sur OS X, mais la firme de Cupertino montre à nouveau sa réactivité très moyenne sur ces sujets.

DigiNotar%20Root%20CA

On peut révoquer le certificat SSL Diginotar dans le Trousseau d'accès : ouvrez le Trousseau d'accès, trouvez le certificat Diginotar, ouvrez-le, et choisissez Se fier > Lors de l'utilisation de ce certificat > Ne jamais approuver. Ce n'est cependant pas suffisant pour assurer la sécurité d'OS X : si un site utilise un certificat Extended Validation SSL Diginotar usurpé, OS X utilise une autre méthode de vérification, qui peut ignorer la révocation du « simple » certificat SSL.

Un problème qui n'a que peu d'applications pratiques, mais qu'Apple devra corriger. Et vite, tant qu'à faire.
Tags
avatar teo | 
[quote]il serait certes plutôt compliqué de mettre en œuvre [i]une attaque man-in-the-middle avec DNS poisoning[/i] utilisant ces certificats sur OS X, mais la firme de Cupertino montre à nouveau sa réactivité très moyenne sur ces sujets.[/quote] Quand vous évoquez certains termes techniques ou très techniques, serait-il possible de mettre un lien URL en renvoi vers un wiki maison ou vers wikipedia ? Il y a quelques années, si je me souviens bien, Benjamin avait commencé à travailler sur un wiki maison macgeneration. Qu'en est-il ?
avatar PierreBondurant | 
Est ce que la MAJ 6.0.1 de Firefox fixe ce problème ?
avatar marc_os | 
Question connexe aux développeurs : Est-ce que Xcode permet désormais de se connecter à un serveur Subversion via un certificat SSL ?
avatar tbassetto | 
@PierreBondurant : oui !
avatar albinoz | 
Le supprimer ne suffit t'il pas ?
avatar albinoz | 
Et sous Leopard et Snow Leopard ? C'est pareil ?
avatar TequilaPhone | 
Tout le monde à se certificat malware dans son trousseau ??
avatar Lecompas | 
[quote= PierreBondurant]Est ce que la MAJ 6.0.1 de Firefox [b]fixe[/b] ce problème ?[/quote]Rognutudju, cet anglicisme me file des boutons. Un problème est résolu, corrigé mais certainement pas [i]fixé[/i]
avatar mhausherr | 
[quote]Un véritable effet domino qui pose la question de la faiblesse — relative — du système TSL/SSL centralisé et basé uniquement sur la confiance envers un tiers :[/quote] Il s'agit de TLS/SSL et non TSL/SSL Effectivement c'est un vrai problème et qui se pose d'autant plus sur iPhone. Impossible de supprimer un certificat racine dans ce cas et l'attaque man in the middle est beaucoup plus simple à réaliser en se faisant passer pour un wifi public. Qui n'a jamais eu d'avertissement de certificat invalide sur m.gmail.com sur un hotspot d'un hotel par exemple?
avatar Taks75 | 
Ou alors, faudrait-il aussi ne pas se fier qu'au certificat mais également faire une requête à l'autorité à chaque connexion (lourd ceci dit).
avatar EBLIS | 
Comme quoi cette sécurité soit disant infaillible chez apple n'est qu'illusion. Aux rédacteurs Macg : serait-il possible de faire un bon article détaillé sur le pourquoi de cette idée de securité infaillible chez apple. Ce que je veux dire c'est faire un article nous expliquant les méthodes d'apple qui sont à vos yeux (ou réellement) efficaces contre les attaques (système, navigateur, hardware). Qu'en est-il aujourd'hui? Que faut-il attendre dans le futur en methode de sécurité et comparer le tout à windows ou linux. Faut-il , nous attendre à voir de plus en plus d'attaques sur macos. En gros démystifier ce fameux "y a pas de virus sous mac". Peut être que les lecteurs seraient intéressés. Merci d'avance.
avatar Switcher | 
@Eblis [i]Personne[/i] n'a jamais dit que sur le réseau, une plate-forme était plus épargnée qu'une autre sur ce type de problème. Et ceci n'est pas un virus, c'est presque plus pervers j'ai envie de dire… :/
avatar EBLIS | 
@Switcher Ma phrase "y a pas de virus sous mac" est une sorte de généralité car beaucoup de personnes néophytes ou ne sachant pas de quoi elle parlent vraiment appèllent toute attaque un virus.
avatar Romuald | 
@Anthony [quote]il serait certes plutôt compliqué de mettre en œuvre une attaque man-in-the-middle avec DNS poisoning utilisant ces certificats sur OS X[/quote] Ce qui est également compliqué, c'est de comprendre ce que ça veut dire quand on est utilisateur lambda...

CONNEXION UTILISATEUR