Ce n'est pas ce point que je critique. Je ne parle pas de la validation du certificat mais de la session TLS elle même.
Ca s'appelle du SSL Pinning. Le client refuse de continuer si le certificat présenté par le serveur n'est pas le meme que celui present cote client. En clair: a moins d'avoir la cle privee du certificat, ton homme de le milieu il va être dur.
Encore une fois, ce n'est pas du tout de cela dont je parle.
Rappels sur l'établissement d'une session TLS :
ClientHello: Le client envoie la liste des algo supportés ;
ServerHello: Le serveur choisit une version du protocole TLS et quelle "CipherSuite" sera utilisée. Ceci indique entre autre la méthode utilisée pour échanger la clé qui sera utilisée par la suite ;
Certificate: Le serveur envoie son certificat ;
ServerKeyExchange (optionnel suivant les méthodes) et ClientKeyExchange : Échange de clés pour établir le secret utilisé pour chiffrer le contenu de la session ;
ServerHelloDone: Fin du handshake.
L'élément qui pose problème ici est que l'échange d'information (Key Exchange) pour établir la clé de chiffrement se fait avec très peu d'entropie du côté client vu que le client pollen est exécuté très tôt au démarrage du système, avant que les autres services ne se lancent.
Si l'on prend l'exemple de l'algorithme d'échange de clé Diffie-Hellman, et en considérant que le secret généré aléatoirement par le client n'est pas si aléatoire que cela, alors il est très facile pour un attaquant de déterminer le secret partagé obtenu à la fin de l'échange à partir des informations envoyées par le serveur. Il n'a qu'à essayer tous les nombres aléatoires potentiellement générés par le client qui ne dispose pas d'une bonne entropie.
Cela s'applique aussi aux autres algorithmes d'échange de clé parce qu'ils reposent tous sur le principe que le client (au minimum) a généré un nombre aléatoire que lui seul connaît. Ce n'est pas une faiblesse du protocole, seulement un prérequis.
Donc la clé de chiffrement de la connexion TLS peut être obtenu par une personne positionnée en man in the middle entre le client et le serveur, ce qui lui permet ensuite de déchiffrer le contenu de la connexion et donc d'obtenir les données aléatoires renvoyées par le serveur, et donc d'obtenir une très grande partie des informations qui seront par la suite utilisées pour amorcer le PRNG.
Tu l'as super mal prepare ton troll quand meme, tes arguments sont tous bateaux et tu passes surtout pour un clown quand tu réponds.
Je suis presque déçu que cela ai été perçu comme un troll. Je ne me permets pas non plus de traiter les autres de clown. Par contre beaucoup de gens se sont permis de se débarrasser de mes arguments (qu'ils soient bons ou mauvais) en les traitant de FUD, ou en me traitant d'incompétent, ce qui simplifie bien les choses.
[^] # Re: Fallait attendre vendredi
Posté par Siosm . En réponse au journal Ubuntu 14.04 LTS : Pourquoi il vaudrait mieux ne pas du tout s'en servir. Évalué à -4. Dernière modification le 03 mai 2014 à 21:43.
Encore une fois, ce n'est pas du tout de cela dont je parle.
Rappels sur l'établissement d'une session TLS :
L'élément qui pose problème ici est que l'échange d'information (Key Exchange) pour établir la clé de chiffrement se fait avec très peu d'entropie du côté client vu que le client pollen est exécuté très tôt au démarrage du système, avant que les autres services ne se lancent.
Si l'on prend l'exemple de l'algorithme d'échange de clé Diffie-Hellman, et en considérant que le secret généré aléatoirement par le client n'est pas si aléatoire que cela, alors il est très facile pour un attaquant de déterminer le secret partagé obtenu à la fin de l'échange à partir des informations envoyées par le serveur. Il n'a qu'à essayer tous les nombres aléatoires potentiellement générés par le client qui ne dispose pas d'une bonne entropie.
Cela s'applique aussi aux autres algorithmes d'échange de clé parce qu'ils reposent tous sur le principe que le client (au minimum) a généré un nombre aléatoire que lui seul connaît. Ce n'est pas une faiblesse du protocole, seulement un prérequis.
Donc la clé de chiffrement de la connexion TLS peut être obtenu par une personne positionnée en man in the middle entre le client et le serveur, ce qui lui permet ensuite de déchiffrer le contenu de la connexion et donc d'obtenir les données aléatoires renvoyées par le serveur, et donc d'obtenir une très grande partie des informations qui seront par la suite utilisées pour amorcer le PRNG.
Tout ceci n'est même pas de moi. C'est ce qui est expliqué dans ce post et les commentaires qui suivent, que j'ai déjà mentionné dans l'article.
Je suis presque déçu que cela ai été perçu comme un troll. Je ne me permets pas non plus de traiter les autres de clown. Par contre beaucoup de gens se sont permis de se débarrasser de mes arguments (qu'ils soient bons ou mauvais) en les traitant de FUD, ou en me traitant d'incompétent, ce qui simplifie bien les choses.