• [^] # Re: SSL et moi, on n'est pas amis, trop idiot pour ça.

    Posté par . En réponse au journal Attaque contre SSL/TLS. Évalué à 10.

    Tentative d'explication.
    Deja cette attaque ne passe pas le mecanisme de login applicatif du site, mais uniquement le tunnel SSL client.
    SSL Client refuse en effet le handshake si le certif n'est pas le bon.
    Mais derriere, faut quand meme se logger sur le site de la banque (en utilisant ledit tunnel ssl).

    Bref, passons.

    Le Mechant se met entre alice et banque.
    Il met ne place du dns poisonning et attend peinard en buvant des bieres qu'alice aille sur socgen.fr, ce qui la redigera vers la machine de Mechant.

    Mechant fait une copie parfaite de logitelnet et se contente pour l'instant de rediriger 1:1 ce qu'envoie alice a la banque.
    Il recoit d'un cote, rebalance de l'autre, sans se poser de question.

    A un moment, alice va sur une page qui requiert du SSL client. La Mechant va sortir de sa taniere.

    Il ne va pas rediriger tout de suite la requete d'alice vers la SG, mais plutot les faire preceder de qq requetes forgees, qui elles aussi requiert du SSL Client, style "vire 2 000 000 de dollars sur le compte 007" et les balancer a la SG.
    On a donc "requete http pour 1 millions de dollars sur mon compte", "requete pour 1 million sur le compte de maman" et "requete legitime d'alice", le tout bourre dans une seule requete HTTP (la legitime d'alice tant qu'a faire), apparement c'est valide.

    La sg recoit cette requete 3-en-1 pour du ssl client, elle va donc lancer le handshake SSL. Et comme elle doit bien traiter cette requetes un jour, elle la met de cote pour la traiter une fois le handshake fini.

    Mechant ne peut pas passer le handshake parce qu'il n'est pas alice et n'a pas son certif.
    Mais alice venant de faire une requete SSL Client, sa machine ne va donc pas s'etonner de recevoir en reponse un handshake (alice non plus d'ailleurs. Oui alice est tres geek et sait comment se passe un handshake ssl).
    Mechant se contente donc de retourner a Alice exactement ce que la banque lui demande dans le handshake.
    Donc echange de random, generation de cle symetrique chiffrees avec les cles publique de l'autre.
    A ce niveau, mechant est redevenu un routeur. Il fait suivre, et ne peut de toutes facons rien lire, parce que c'est chiffre avec des cles publique et n'a pas les cles privees correspondantes.
    A la fin du handshake, les 2 parties (alice et banque) ont leur cle symetrique, elles sont passees sous le nez de mechant qui ne peut pas les lire.

    Handshake fini, avec succes, banque reprend donc les 3 requetes qui ont initie le handshake, vire un million a mechant, un million a ma maman (oui, c'est moi le mechant dans l'histoire, et alice est une bonne salope, je tiens a le preciser) et ensuite traite la requete d'alice.

    Mechant recoit la reponse a ses requetes de virement, les drop (il ne peut pas les renvoyer a alice, elle ne les a pas faites). Il ne peut PAS les lire. Il n'a pas la cle.
    Mechant recoit la reponse a la requete d'alice et la renvoit.
    Bref, il reprend son boulot de routeur a forwarder strictement ce qu'il recoit.

    Au final:
    Tout marche tres bien, le protocole EST efficace.
    Le probleme ici est la possibilite de bourrer plusieurs requetes dans une seule.

    Ensuite, ca ne passe que la creation du tunnel SSL, j'ose esperer qu'une quelconque banque deployant du SSL client va AUSSI mettre une page de login.
    Dans ce cas les premieres requetes du mechant seront reboutee parce que pas encore logge, et par la suite il ne peut plus rien faire, donc il est baise.

    Bref, le monde ne va pas s'ecrouler demain.