Quoi de 9 ?

A moins de ne pas lire de news sur Internet, ne pas regarder la TV et ne pas écouter la radio, vous n’avez pas pu passer à coté de la faille du bug de conception de DNS mise au yeux de tous en début de semaine.
Au cas où, la consultation de la page suivante vous éclairera : http://sid.rstack.org/blog/index.php/283-dns-dns-dns
Cette “faille” permet  de vous envoyer de fausses réponses à vos requêtes DNS encore plus facilement qu’avant (plus de chances de réussite).

Revenons 2 mois en arrière sur la faille OpenSSL de Debian (voir http://sid.rstack.org/blog/index.php/275-du-hasard-et-de-ses-consequences si vous n’êtes pas au courant).
Cette faille permet de trouver assez simplement la clé privée qui correspond à une clé publique générée avec un OpenSSL Debian Etch.

Vous voyez ou je veux en venir ? La combinaison des deux failles est détonnante puisqu’elle peut permettre de dérouter une connexion SSH/SSL/… vers votre serveur plutôt que celui que la personne cherche à atteindre. Si le serveur que la personne cherche à atteindre est sujet à la faille Debian alors vous pouvez vous faire passer pour le serveur cible.

Où comment faire un Man In the Middle d’une session “”sécurisé”” plus facilement que jamais

Cela fait quelque temps que je voulais tester une chose sur mon iPhone. La gestion du SSL par l’application email.

En effet j’utilise imaps pour consulter mes emails depuis mon iPhone et mon serveur email utilise un certificat SSL signé par une autorité de certification (CA) non reconnue par l’iPhone. Lors de l’ajout du compte l’iPhone il previent que le certificat n’est pas valide, propose de continuer ou d’annuler. Si on continue il ne dit plus rien.

Mon intérogation était assez simple, que se passe-t-il si le certificat SSL change sur le serveur ?

En effet, il est assez facile de se retrouver dans un cas de “man in the middle” avec un iPhone, tout particulièrement si on utilise des bornes Wifi ouvertes. Une personne malveillante pourrait alors intercepter la connexion SSL et faire en sorte que la terminaison SSL se termine chez lui (une sorte de proxy SSL). Mais dans ce cas le certificat ne serait plus le même. D’ou ma question : que fait l’iPhone dans ce cas ?

Et bien (très) bonne nouvelle, il dit de nouveau que le certificat n’est pas valide. On peut donc facilement s’apercevoir du problème.