Journal Scandale de la NSA et cryptographie, le vrai du faux

Posté par Ely le 11 octobre 2013 à 19:23. Licence CC By‑SA.

Étiquettes :

oct.

2013

Sommaire

Un point sur Secure Socket Layer
- l'Authenticité
Quelles sont les faiblesses d’un tel système ?
Pourquoi s’embêter ?

Bonjour à tous,

Depuis le scandale de la National Security Agency en juin 2013 et les révélations sur le programme PRISM, la cryptographie a connu une explosion d'intérêt dans le monde entier. Les médias de masse s'en sont emparés, tout le monde s'est mis à en parler, et comme à chaque fois que l'on donne un sujet technique à Mme. Michu, d'énormes absurdités en sont ressorties, et on a enregistré un pic de popularité du mot "cryptocalypse".

J’espère ici faire le point sur ce qu’il se passe réellement avec la NSA, quelles sont les faiblesses de la cryptographie moderne, et aussi vous rappeler qu’à chaque fois que l’on dit « cryptage » dieu tue un chaton, car en France on dit « chiffrement ».

Quelques bases vous seront requises pour comprendre cet article dans son intégralité, mais je n'entre pas dans les détails et décrit parfois grossièrement certaines parties.

Un point sur Secure Socket Layer

Avant d’aborder le sujet en détail, un petit mot sur le protocole SSL/TLS qui anime à lui tout seul 90% des communications chiffrées du monde entier.

Ce protocole sert à établir un tunnel sécurisé entre deux machines au sein d’un réseau non sécurisé, et optionnellement à prouver l’authenticité de l’une d’entre elles, ou même des deux. L’établissement du tunnel et la preuve d’authenticité des entités est effectuée grâce à la cryptographie asymétrique (Diffie-Hellman et RSA notamment) et aux certificats électroniques X.509. La suite de la communication – l’échange des données – utilise la cryptographie symétrique (AES, RC4…) qui est bien plus rapide.

L’exemple d’utilisation de SSL le plus connu est HTTPS, le fameux protocole qui vous rend confiant en ajoutant un petit cadena dans la barre d’adresse. Il établit un canal sécurisé entre vous et le site web, et vous garantit l’authenticité du site que vous visitez. C’est une authenticité à sens unique, puisque le site web ne vérifie pas la votre (soit il s'en fiche, soit il s'y prend autrement, par exemple à l'aide d'un couple login/mot de passe).

l'Authenticité

La question est alors : mais comment votre ordinateur fait-il pour décider si en effet, le site que vous visitez est bien le site qu’il proclame être ?

Ceci est réalisable grâce à l’existence d’une infrastructure à clé publique (PKI), élément fondamental au bon fonctionnement d’un protocole comme SSL. Pour faire court, on trouve deux types d’entités dans une PKI :

Les autorités de certification. Elles sont responsables de délivrer des certificats électroniques aux entités qui en font la demande après avoir effectué des vérifications d’identité. Les plus connues sont VeriSign, Thawte, Geotrust.. Elles possèdent chacune un ou plusieurs certificats électroniques dits « racine » avec lesquels elles signent numériquement les certificats des demandeurs.
Les utilisateurs – notamment les sites internet – qui reçoivent des certificats des autorités, afin de prouver leur identité à leurs visiteurs.

Par exemple, le certificat google est signé par l'autorité « GeoTrust » :

certificatGoogle

Si vous êtes sous linux en ce moment, un petit coup d’œil au fichier /etc/ssl/certs/ca-certificates.crt vous donne la liste des certificats racine installés sur votre machine (codés en base64), et avec lesquels votre navigateur prouve l’authenticité des sites internet que vous visitez en https. (eh oui, c’est un fichier de 250ko qui prouve toute la sécurité des sites du monde entier, pas mal hein ?)

Il est à noter qu’à chaque certificat est associé une clé privée qui ne doit être connue et conservée que du propriétaire du certificat. C'est grâce à elle qu'une autorité de certification délivre des certificats, ou qu'un utilisateur prouve son identité.

Si la clé privée d’un site internet est compromise, un attaquant se trouvant au milieu du réseau (routeur quelconque) devient capable de faire passer son serveur pour le site web en question.
Si la clé privée d’une autorité est compromise, un attaquant devient capable de fabriquer des certificats valides pour le site web de son choix.

Quelles sont les faiblesses d’un tel système ?

Le paragraphe précédent vous a peut-être mis la puce à l’oreille : il est tout à fait probable que la NSA soit un jour venue toquer à la porte de VeriSign, demandant « Filez-nous votre clé privée, ou alors on ferme votre boîte ». Si ceci s’avère vrai, alors la NSA est capable de générer des certificats valides pour tout site internet et peut alors intercepter les requêtes google, vos transferts facebook/skype/xmpp…

Mais bon, avouons-le, ceci est tout de même compliqué, il y a des démarches pas franchement fines à effectuer, il faut du matériel conséquent, beaucoup de software…
Si l'on a la preuve aujourd'hui que la NSA a bel et bien du matériel d'écoute sur les gros noeuds de fibre optique des Etats-Unis, on ne sait toujours pas si elle a effectivement en sa possession les fameuses clés privées des autorités de certification.

Pourquoi s’embêter ?

Le second gros problème du https et du fameux « petit cadena magique qui vous garantit la sécurité absolue de vos données », c’est qu’il ne garantit pas que le site web que vous visitez est honnête !

Tout ce qu’il vous garantit, c’est que c’est bien avec lui que vous communiquez et qu’il n’y a pas de tier capable d’intercepter votre communication. Mais il ne vous renseigne en aucun cas sur l’utilisation qui est faite de vos données. Pour résumer, rien n’empêche un site web en https d’être profondément malhonnête avec vos données à la suite de la communication.

C’est ainsi que la NSA, au lieu de s’embêter à trafiquer les certificats électroniques, a tout simplement décidé d’installer des backdoors dans les systèmes d’information de géants du web : Google, Facebook, Skype pour n’en citer que quelques-uns.. Bien évidemment, tout ceci s’est fait avec la coopération des entreprises, qui n’avaient pas vraiment le choix.

Pour conclure, ce n'est pas vraiment la cryptographie qui est en cause, mais bel et bien la confiance aveugle que l'on fait aux entités qui la gouvernent.

# Attaques au milieu

Posté par khivapia le 11 octobre 2013 à 21:41. Évalué à 8.

"Mais bon, avouons-le, ceci est tout de même compliqué, il y a des démarches pas franchement fines à effectuer, il faut du matériel conséquent, beaucoup de software…"

Pourtant la NSA fait bien des attaques par le milieu (et redirige donc le trafic de certaines cibles vers ses serveurs), d'après les documents fuités par Snowden (qui s'ils constituent une opération d'intoxication, en constituent une qui a demandé beaucoup de travail). Elle est donc tout à fait capable d'intercepter les communications même chiffrées vers un site apparemment légitime.

Voir par exemple http://www.techdirt.com/articles/20130910/10470024468/flying-pig-nsa-is-running-man-middle-attacks-imitating-googles-servers.shtml
- [^] # Re: Attaques au milieu
  
  Posté par Ellendhel (site web personnel) le 12 octobre 2013 à 00:48. Évalué à 6.
  Il n'y a pas que la NSA, mais aussi un certain nombre d'individus malhonnêtes qui attaquent les autorités de certifications, en vue de créer de "vrai/faux" certificats. Et le principe de confiance vis à vis de ces même autorités de certification est largement écorné.
  - http://sid.rstack.org/blog/index.php/455-parce-qu-il-faut-parler-de-diginotar
  - http://news0ft.blogspot.com/2010/04/ssl-est-casse.html
  Il y a également un article dans le magazine MISC paru en septembre (numéro 69).
  
  SSL/TLS peut-être un bon moyen de sécurité, mais il a été promu suite aux débuts commerciaux d'Internet, avec l'essor du commerce électronique, à une époque où peu de gens se préoccupaient de sécurité. Le passage à l'échelle n'a pas été maîtrisé, et beaucoup d'acteurs privés ont instauré leur propre système, sans forcément suivre les "bonnes pratiques".
  
  C'est le genre de situation qu'il est difficile de corriger vu le nombre de facteurs à modifier (mises à jour de sites, éducation des utilisateurs, vérification sérieuse des autorités de certifications, ….).
  - [^] # Re: Attaques au milieu
    
    Posté par Thomas Debesse (site web personnel) le 12 octobre 2013 à 02:12. Évalué à 6.
    
    Sans compter les fois où un fournisseur aux produits largement déployé, par exemple Microsoft, rajoute dans le navigateur des utilisateurs une autorité de certification qui n'est rien d'autre que le gouvernement…
    
    ce commentaire est sous licence cc by 4 et précédentes
  - [^] # Re: Attaques au milieu
    
    Posté par pamputt le 12 octobre 2013 à 09:00. Évalué à 3. Dernière modification le 12 octobre 2013 à 10:42.
    
    Il n'y a pas que la NSA, mais aussi un certain nombre d'**individus malhonnêtes** qui attaquent les autorités de certifications
    
    Dois-je en conclure que lA NSA ne fait pas partie des individus malhonnêtes ?
- [^] # Re: Attaques au milieu
  
  Posté par Wawet76 le 14 octobre 2013 à 13:45. Évalué à 2.
  
  Un point important est qu'ils ne peuvent pas vraiment faire de surveillance de masse avec du man-in-the-middle.
  
  Il y a quand même une grosse différence entre tenter de surveiller les communications d'un suspect, et loguer/surveiller toutes les communications de tout le monde. La NSA logue apparemment tout ce qu'elle peut en méta-données, et elle ne peut probablement pas le faire pour ce qui est chiffré vers des serveurs qui ne participent pas à PRISM.
# le vrai et le faux

Posté par Thomas Debesse (site web personnel) le 11 octobre 2013 à 21:49. Évalué à 10. Dernière modification le 11 octobre 2013 à 21:49.
- Il établit un canal sécurisé entre vous et le site web
- et vous garantit l’authenticité du site que vous visitez.
Ce sont bien deux choses en effet, et malheureusement sur le web ces deux choses-là ne sont jamais dissociées.

Hors ce sont deux besoins :
- savoir que seul le correspondant entend notre dialogue
- savoir que le correspondant est le bon
Et parfois on serait satisfait de n'avoir déjà que le premier besoin de satisfait, et parfois on n'a pas besoin du premier.

Alors j'entends d'ici ceux qui feront remarquer « à quoi sert de chiffrer si tu ne peux pas authentifier ton correspondant ? », mais je leur ferai remarquer que cette remarque n'est qu'une variante subtile du « ceux qui ont rien à se reprocher n'ont rien à cacher ».

Il est toujours bon de chiffrer, même quand le correspondant n'est pas authentifié.

Le problème c'est que les navigateurs (comme Firefox) mettent énormément de bâtons dans les roues des internautes qui naviguent sur des sites chiffrés non authentifiés parce que non authentifiables. Est souvent invoquée la raison des banques et autres services critiques : si on ne dit plus qu'un site n'est pas authentifié parce que non authentifiable, comment s'assurer que le site est authentifié quand on a besoin d'authentification ?

Et bien en fait cette remarque n'a pas de sens. Si tous les sites étaient en HTTPS et que l'HTTP n'existait pas, et bien on ne mettrait de symbole cadenas ou autre marqueur de sécurité avancée qu'en cas d'authentification vérifiée (chaîne de confiance etc.), le chiffrement allant de soi.

Imaginez si SSH n'était possible qu'entre possesseurs de certificat certifié avec déclaration d'identité préalable, prise d'empreinte et enregistrement auprès d'une chaîne d'autorité ? et qu'à cause de cette contrainte le commun des mortels en était réduit à se satisfaire de telnet ?

Dans l'état actuel des choses, il n'existe pas vraiment d'intermédiaire grand public entre le fait d'être à poil sur le net et le canal chiffré avec agent assermenté. C'est là qu'on arrive au « si tu n'as rien à cacher tu ne dois rien cacher ».

Car le problème n'est pas le chiffrement, mais l'authentification. Il est possible de ne pas faire confiance en l'authentification, mais que l'on souhaite tout de même le chiffrement. Par exemple, si on ne fait pas confiance en l'autorité, l'authentification n'est pas jugée fiable, mais ça n'oblige pas à se déshabiller.

Et donc si on reprend les besoins :
- savoir que seul le correspondant entend notre dialogue
- savoir que le correspondant est le bon
Le premier n'est actuellement permis que si le second est possible, hors :
- Peut-être que parfois on n'a pas besoin d'authentifier (si seul le contenu importe, par exemple)
- Peut-être que parfois on ne veut pas authentifier (l'authentification serait un danger)
- Peut-être que parfois on ne fait pas faire confiance à l'authentification proposée (le système proposé est pourri ou dangereux)
- Peut-être que parfois on veut authentifier différemment (rien ne dit qu'une signature ne sera pas transmise, par exemple
Voilà le vrai problème ! Pour avoir droit à un chiffrement accessible au grand public, il faut être authentifiable (dit autrement, dénonçable¹).

Ce qui signifie tout simplement que :
- le secret des correspondances n'est permis que si l'identité d'au moins un des correspondant n'est pas secrète (hum).
Ce qui signifie encore :
- le secret des correspondances n'est permis que si l'on sait où placer une taupe à l'extérieur du chiffrage.
- le secret des correspondances n'est permis que si la coercition est possible.
En gros, le chiffrement n'est permis que si la clé à molette est permise :

Bref, en ne dissociation pas chiffrement et authentification déclarée, on rend PRISM possible.

Quand Firefox râle parce que le certificat CAcert utilisé par LinuxFr ne joue pas dans la cours des grands, il faut comprendre : « désolé petit, on ne sait pas si ce site est compatible PRISM », « si tu veux continuer met la main sur le cœur et répète trois fois “je ferai attention promis et je ne le referai plus” ».

Les gars de Firefox n'ont peut-être pas pensé à cela…
 
 
 
________ 
¹par exemple, même chez le moins cher (StartSSL) si on veut pouvoir faire des certificats un peu avancé (wildcard et tout) il faut présenter deux pièces d'identité, typiquement une CNI et un passeport. Parfois on veut seulement chiffrer. Il n'est pas toujours nécessaire de laisser ses gros doigts partout, parfois ça ne sert absolument à rien !

ce commentaire est sous licence cc by 4 et précédentes
- [^] # Re: le vrai et le faux
  
  Posté par flan (site web personnel) le 11 octobre 2013 à 22:10. Évalué à 5.
  
  Tu oublies un détail : si tu n'es pas capable d'assurer que tu parles à la bonne personne, alors tu n'es pas capable d'assurer que seule la bonne personne entend.
  
  Ce n'est pas « actuellement », ni une question d'implémentation, c'est par définition. Si tu autorises les MITM (en refusant d'authentifier la personne), alors tu ne garantis pas que seul le destinataire lit ce que ton trafic.
  - [^] # Re: le vrai et le faux
    
    Posté par lolcat le 11 octobre 2013 à 23:23. Évalué à 1.
    
    J'ai du mal à comprendre cette remarque. L'authentification se faisant à partir d'une clé privée, la seule et unique garantie que tu as qu'il n'y ait qu'un interlocuteur qui t'écoute est que sa clé privée ne soit distribuée dans la nature.
    
    Qu'est-ce que ça change que la clé privée soit sur le serveur d'une autorité compétente ou sur l'ordinateur d'un particulier ?
    - [^] # Re: le vrai et le faux
      
      Posté par flan (site web personnel) le 11 octobre 2013 à 23:32. Évalué à 4.
      
      Thomas parle d'utiliser SSL pour faire uniquement du chiffrement, sans la couche d'authentification du serveur.
      Je réponds que sans cette authentification, le chiffrement ne sert à rien (même si sur le fond, je suis d'accord avec lui). Il n'y a aucune notion de clef privée là-dedans.
  - [^] # Re: le vrai et le faux
    
    Posté par Thomas Debesse (site web personnel) le 12 octobre 2013 à 00:25. Évalué à 10.
    Tu oublies un détail : si tu n'es pas capable d'assurer que tu parles à la bonne personne, alors tu n'es pas capable d'assurer que seule la bonne personne entend.
    
    Tu oublies un détail, tu ne parles pas à une personne, mais à une machine.
    
    Si tu autorises les MITM (en refusant d'authentifier la personne), alors tu ne garantis pas que seul le destinataire lit ce que ton trafic.
    
    Tu ne garantie pas non plus qu'une seule personne lise le message déchiffré, tu garanties seulement que seule une clé appartenant à une seule personne déchiffre. Ce qu'il y a après tu n'en sais rien, ça peut être PRISM.
    
    Quand je fais ssh monserveur, si la clé change, je suis au courant qu'elle a changé. Que cette clé soit signée par toi ou par une tierce personne ne change pas ce fait. Tu pourras rétorquer qu'il faut alors faire confiance lors de la poignée de main initiale, mais ça vaut aussi pour la tierce personne.
    
    Système sans tiers :
```
 ___________________________________________________________________________
[ système clé à molette                                                     ]
[          _________________________________________________________        ]
[         [ système informatique                                    ]       ]
[         [  _________________  _____________  ___________________  ]       ]
[         [ [ ordinateur      ][ réseau      ][ ordinateur        ] ]       ]
[         [ [                 ][             ][                   ] ]       ]
[ alice → [ [ → chiffrement → ][ transport → ][ → déchiffrement → ] ] → bob ]
[       ¤ [ [ ¤             ø ][           ø ][ ø               ¤ ] ] ¤     ]
[         [ [_________________][_____________][___________________] ]       ]
[         [_________________________________________________________]       ]
[___________________________________________________________________________]

Légende si pas de tiers :
¤ MITM possible
ø MITM possible lors de la première poignée de main
```
    Système avec tiers :
```
 ___________________________________________________________________________
[ système clé à molette                                                     ]
[          _________________________________________________________        ]
[         [ système informatique                                    ]       ]
[         [  _________________  _____________  ___________________  ]       ]
[         [ [ ordinateur      ][ réseau      ][ ordinateur        ] ]       ]
[         [ [                 ][             ][                   ] ]       ]
[ alice → [ [ → chiffrement → ][ transport → ][ → déchiffrement → ] ] → bob ]
[       ¤ [ [ ¤             ø ][           ø ][ ø               ¤ ] ] ¤     ]
[         [ [_________________][_____________][___________________] ]       ]
[         [_________________________________________________________]       ]
[                   ↑                                  ↑                    ]
[ joséphine  →  signature                        → signature                ]
[___________________________________________________________________________]

Légende si pas confiance dans le tiers :
¤ MITM possible
ø MITM possible lors de la première poignée de main

Légende si confiance dans le tiers :
¤ MITM possible
ø MITM pas possible
```
    Système avec PRISM :
```
 ___________________________________________________________________________
[ système clé à molette + PRISM                                             ]
[          _________________________________________________________        ]
[         [ système informatique                                    ]       ]
[         [  _________________  _____________  ___________________  ]       ]
[         [ [ ordinateur      ][ réseau      ][ ordinateur        ] ]       ]
[         [ [                 ][             ][                   ] ]       ]
[ alice → [ [ → chiffrement → ][ transport → ][ → déchiffrement → ] ] → bob ]
[       ¤ [ [ ¤             ø ][           ø ][ ø               ¤ ] ] ¤     ]
[         [ [_________________][_____________][___________________] ]       ]
[         [_________________________________________________________]       ]
[                   ↑                                  ↑                    ]
[ joséphine  →  signature                        → signature                ]
[___________________________________________________________________________]

Légende :
¤ MITM possible
ø MITM possible
```
    Il n'y a pas de système optimal.
    
    Ne rien faire du tout sous prétexte que ce n'est pas optimal n'est jamais une bonne idée. On peut reprendre l'exemple de ssh et de telnet. Je préfère un ssh avec un doute à la poignée de main initiale que faire un login via telnet.
    
    On peut voir le chiffrage comme le niveau 1 du service : personne ne peut savoir entre deux point (mais il peut y avoir plusieurs paires chaînées, d'où la possibilité du MITM).
    On peut voir la signature comme le niveau 2 du service : si un tiers n'est pas compromis, seul deux savent.
    
    Quand j'accepte le certificat de LinuxFr ou de Facebook ou de monvoisin.net, qu'il soit signé par CaCert ou par Verisign, ou qu'il soit autosigné, je fais confiance à LinuxFr ou Facebook ou à mon voisin pour que le serveur ne soit pas compromis.
    
    D'où l'idée de la clé à molette… aucun système n'est parfait, alors ne soyons pas « tout ou rien ».
    
    Cas d'usage IRL, personellement j'aimerai pouvoir facilement donner un accès https à un ami ou quelqu'un de ma famille que j'héberge pour qu'il puisse mettre à jour son site et l'administrer via le web sans devoir expliquer comment contourner les batons de FireFox. En général, pour la majorité des gens, la solutions c'est le tout http, ce qui est pire.
    
    Et puis il y a des cas où l'on s'en moque complètement du correspondant. Si je surf par TOR ou que je suis un relai BitMessage, je me moque complètement d'authentifier mes relais, ce qui compte c'est que je trouve ce que je désire.
    
    surtout surtout surtout, la navigation sur le web n'exige pas d'être soi-même authentifié par le site, ce qui signifie qu'il n'est pas nécessaire d'authentifier le site, tout simplement.
    
    On peut imaginer le cas où une personne consulte des documents sur un site servi https, le site n'authentifie pas son lecteur, le lecteur n'authentifie pas le site.
    
    On peut savoir qu'un site sert tel document (c'est public servi en https), mais on peut ne pas savoir à qui appartient le site et qui sert les documents. Et surtout, on ne sait pas à qui ces documents sont servis et lequel d'entre eux, et le lecteur a son document.
    
    Note: le document peut être signé par l'auteur, le serveur n'est pas nécessairement l'auteur.
    
    Cas d'usage fictif :
    - l'église publie un commentaire biblique et le signe ;
    - un serveur le partage au milieu de nombre de documents de sujet divers qui sont servis en https ;
    - un chrétien qui cache sa foi dans un village tenu par des rebelles islamistes qui ont massacrés tous ses coreligionnaires visite anonymement le serveur et télécharge le commentaire biblique et vérifie la signature de l'église et le lit.
    Analyse :
    - L'église ne sait pas qui a lu le commentaire biblique ;
    - le serveur ne sait pas qui a téléchargé le commentaire biblique ;
    - le chrétien ne sait pas qui lui a fourni le commentaire biblique mais sait que c'est celui de l'église ;
    - le rebelle islamiste ne sait pas que quelqu'un a téléchargé un commentaire biblique.
    Pourquoi authentifier dans ce cas là ?
    Pourquoi tout ou rien ? Pourquoi si pas authentification, pas chiffrage ?
    
    Pourquoi faire du ssh même quand on n'a pas signé sa clé ssh chez Thawte ?
    
    ce commentaire est sous licence cc by 4 et précédentes
# Encore un point

Posté par RB le 12 octobre 2013 à 01:19. Évalué à 0.

Dans ta prose tu sous-entend que le chifrement SSL en soit est sûr. Ce n'est pas forcément le cas. Il est probable quand dans certains produits privateurs l'implémentation aie été pourrie à dessein pour en diminuer fortement la complexité (par exemple un générateur aléatoire qui ne sera pas si aléatoire que ça)… d'où l'importance de favoriser de bonnes implémentations libres à l'usage.
- [^] # Re: Encore un point
  
  Posté par flan (site web personnel) le 12 octobre 2013 à 21:05. Évalué à 6.
  
  Pourquoi seulement « privateurs » ?
  
  Entre l'implémentation d'OpenSSH dans ?BSD et la génération de clef moisie dans Debian…
  - [^] # Re: Encore un point
    
    Posté par RB le 13 octobre 2013 à 12:56. Évalué à 3.
    
    Les erreurs que tu cites ont été corrigées. Y a encore une grosse différence entre une erreur (grossière dans le cas de debian) et une vulnérabilité sournoise. Si le "problème" se remarque (ce qui ne manquera pas d'arriver dans un logiciel ouvert, juste une question de temps), on peut savoir qui (donc la personne qui la fait engage sa réputation) l'a intégrée alors que dans un programme propriétaire cela peut y rester ad eternum sans que personne ne puisse le savoir.
    - [^] # Re: Encore un point
      
      Posté par flan (site web personnel) le 13 octobre 2013 à 15:10. Évalué à 3. Dernière modification le 13 octobre 2013 à 15:11.
      
      Heureusement que les failles détectées ont été corrigées !
      
      Dur de savoir si ce sont des erreurs ou des erreurs « volontaires »… Quant à la backdoor d'OpenSSH dans ?BSD demandée par le FBI, je doute que ça soit une simple erreur.
      
      « Juste une question de temps ». La faille dans Debian est restée 4 ans. Certes, c'est toujours une question de temps, mais ça reste énorme.
      
      De toute façon, les codes des OS actuels sont trop énormes et évoluent trop vite pour espérer faire des audits de code, sans compter que même en ayant le code sous les yeux, on peut passer à côté (faudrait que je retrouve les infos sur une faille ajoutée en mettant & au lieu de && dans une ligne de code, je ne me souviens plus des détails).
      - [^] # Re: Encore un point
        
        Posté par groumly le 13 octobre 2013 à 20:17. Évalué à 3.
        
        La faille dans Debian est restée 4 ans. Certes, c'est toujours une question de temps, mais ça reste énorme.
        
        Et surtout, elle a ete trouvee completement par hasard (un gars s'est retrouve avec 2 fois la meme cle privee), le code n'a en rien aide a trouve la faille.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Encore un point
        
        Posté par RB le 13 octobre 2013 à 23:10. Évalué à 1.
        
        Bah, on est d'accord, reste que si on compare logiciel ouvert avec logiciel privateur on a que dans le premier cas il est possible par analyse du code de la détecter, et si c'est le cas, de ruiner une réputation. Dans le cas du logiciel privateur les chances de le détecter son juste moindres (et une anomalie détecter ne permet pas de mettre en évidence le code automatiquement ni l'auteur). A partir de là, je pense qu'il est préférable de privilégier les implémentations ouvertes et largement diffusées.
        
        [^] # Re: Encore un point
        
        Posté par groumly le 14 octobre 2013 à 02:15. Évalué à 1.
        
        Non, on est pas d'accord du tout.
        Une faille aussi beante restee ouverte aussi longtemps, ca a confirme ce que je pensais depuis un bail: personne ne relit le code, ceux qui le font n'ont pas les competences pour le faire bien, et ceux qui ont les competences ont bien trop de boulot pour le faire gracieusement.
        
        Au final, la disponibilite du code te permet de comprendre comment la faille arrive, depuis combien de temps la faille est la, mais c'est a peu pres tout. Pour la corriger, faut toujours passer par les channels habituels de release. En gros, ca aide apres la decouverte de la faille, mais avant, c'est kifkif. Et la liberte de la licence n'y fait pas grand chose, du shared source a la ms fait aussi bien l'affaire.
        
        Apres, oui, avoir le code, c'est mieux que ne pas l'avoir, mais la disponibilite du code ne presuppose en rien de la qualite de l'implementation. Si c'etait le cas, il suffirait de liberer IE6 pour en faire un bon browser, et je doute que la licence d'IE ait grand chose a voir avec l'activation par defaut des activex.
        
        Et partir du principe que comme c'est proprio, c'est forcemment plombe par la nsa, c'est tres con comme raisonnement.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Encore un point
        
        Posté par Marotte ⛧ le 14 octobre 2013 à 06:33. Évalué à 1.
        
        personne ne relit le code, ceux qui le font n'ont pas les competences pour le faire bien, et ceux qui ont les competences ont bien trop de boulot pour le faire gracieusement.
        
        Il y a bien des gens qui lisent le code, en témoignent toutes les découvertes régulières de failles potentielles.
        
        Pour le openssl de Debian je me dis que la faille était tellement grosse et openssl étant réputé bien écrit, personne n'a eu l'idée d'auditer ce code en particulier. Je vais même jusqu'à penser qu'aucun black hat n'a eu l'idée de chercher ce genre de faille ici tellement ça paraissait saugrenue :)
        
        Je me demande si le dév' Debian qui a introduit cette faille par mégarde se faire toujours charrier avec ça ?
        
        [^] # Re: Encore un point
        
        Posté par oinkoink_daotter le 14 octobre 2013 à 13:54. Évalué à 4. Dernière modification le 14 octobre 2013 à 13:56.
        
        Pour le openssl de Debian je me dis que la faille était tellement grosse
        
        Euh, tu la connais la faille ?!?
        Parce que de mémoire, la faille était plutôt subtile : openssl se servait d'une valeur non initialisée comme source d'entropie; La, un dev debian passe avec son valgind, qui détecte le truc; le dev initialise la variable à 0 (sans bien évidemment prévenir les gars d'openssl) et boom, le seed du PRNG n'a plus que 32k valeurs possibles.
        
        [^] # Re: Encore un point
        
        Posté par Marotte ⛧ le 14 octobre 2013 à 14:39. Évalué à 2.
        
        J'avais lu qu'un dév' avait initialisé cette variable avec une valeur fixe à des fins de test et avait oublié de la réinitialiser à partir d'une valeur aléatoire avant de livrer son code. Mais je me goure probablement, ton explication est sûrement la bonne.
        
        [^] # Re: Encore un point
        
        Posté par Jean-Philippe Garcia Ballester (site web personnel) le 14 octobre 2013 à 15:01. Évalué à 3. Dernière modification le 14 octobre 2013 à 15:01.
        
        La sienne est un peu mieux, mais pas parfaite. Son « sans bien évidemment prévenir les gars d'openssl » est faux, le mainteneur Debian a posé la question sur la liste mais personne n'a répondu.
        
        [^] # Re: Encore un point
        
        Posté par Marotte ⛧ le 14 octobre 2013 à 19:04. Évalué à 2. Dernière modification le 14 octobre 2013 à 19:04.
        
        En tous cas ce que j'en retiens c'est que seule Debian était impactée[1], l'upstream openssl et tous les autres qui se basaient[1] dessus n'ont pas été inquiétés.
        
        Un bel argument en faveur d'un écosystème GNU/Linux avec, mettons, 5 grosses distrib' qui se partageraient 90% du marché desktop, ici seule l'une (et Ubuntu je suppose, donc deux) d'entre elles était impactée[1].
        
        [1] Le premier Jack AllGood d'arrière-garde qui s'avise de me faire une seule remarque sur l'emploi de ces vocables dans mon commentaire je le fais disparaître à grands coups de poudre verte.
        
        [^] # Re: Encore un point
        
        Posté par flan (site web personnel) le 14 octobre 2013 à 20:58. Évalué à -1.
        
        Mouarf
        
        La faille avait été introduite par un mainteneur Debian, mais elle aurait très bien pu être introduite par un mainteneur d'OpenSSL…
        
        [^] # Re: Encore un point
        
        Posté par Marotte ⛧ le 14 octobre 2013 à 22:56. Évalué à 3.
        
        Je ne vois pas ce qui te permet d'affirmer ça.
        
        [^] # Re: Encore un point
        
        Posté par gnujsa le 14 octobre 2013 à 20:26. Évalué à 2.
        
        Une faille aussi beante restee ouverte aussi longtemps, ca a confirme ce que je pensais depuis un bail: personne ne relit le code, ceux qui le font n'ont pas les competences pour le faire bien, et ceux qui ont les competences ont bien trop de boulot pour le faire gracieusement.
        
        Quoi, un seul contre-exemple te permet d'invalider le fameux "given enough eyeballs, all bugs are shallow" ? C'est maigrichon et un peu facile. D'autant que comme le fait remarquer Marotte quelques commentaires plus bas, ça ne concerne que Debian et ses dérivés, pas l'upstream OpenBSD, ni les autres distrib Linux.
        
        [^] # Re: Encore un point
        
        Posté par groumly le 14 octobre 2013 à 23:27. Évalué à -1.
        
        Maigrichon? Une faille critique passee inapercue pendant 2 ans dans une distrib majeure t'appelles ca maigrichon?
        Moi j'appelle ca un echec complet du processus de qualite - ca inclue aussi le processus de test de debian. Ca prouve que given enough eyeballs, all bugs are shallow est completement faux (ou que le "enough" est ridiculement eleve). Surtout quand on considere que c'est meme pas une revue du code qui a trouve le bug… En gros, les eyeballs n'ont servi strictement a rien.
        C'est pas un concept nouveau dans le monde du development, mais le seul truc qui marche vraiment pour trouver les bugs, c'est des tests (automatiques si possible) qui tournent le plus souvent possible. Les yeux, ils font des erreurs, comme on le voit ici.
        
        T'es libre de dire que ca ne concerne "que" debian, ca reste une des distribs majeures et le bug a impacte beaucoup de monde.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Encore un point
        
        Posté par Benoît Sibaud (site web personnel) le 14 octobre 2013 à 23:51. Évalué à 8.
        
        C'est surtout tirer des conclusions à partir d'un seul élément qui est une erreur. Ou alors six ans de porte dérobée dans le SGBD Interbase montrerait que le logiciel propriétaire a tous les vices tandis que l'ouverture de son code source a permis de trouver la faille en moins d'un an. Ou encore la faille F5, Cisco Unified Videoconferencing, HP StorageWorks P2000 G3 ou celle du libre proftpd, etc. (sources http://fr.wikipedia.org/wiki/Porte_d%C3%A9rob%C3%A9e)
      - [^] # Re: Encore un point
        
        Posté par eingousef le 14 octobre 2013 à 11:38. Évalué à 3.
        
        La faille dans Debian est restée 4 ans.
        
        4 ans c'est entre le moment où elle a été introduite et le moment où elle a été découverte.
        
        La grosse différence entre le logiciel libre et le logiciel non-libre elle est dans la durée qui s'écoule entre le moment où la faille est découverte et le moment où elle est corrigée.
        
        *splash!*
        
        [^] # Re: Encore un point
        
        Posté par kursus_hc le 14 octobre 2013 à 15:57. Évalué à 2.
        
        Ou peut-être que certains le savaient avant et n'ont rien dit.
        
        [^] # Re: Encore un point
        
        Posté par eingousef le 14 octobre 2013 à 17:04. Évalué à 3.
        
        Ben ça c'est pareil dans le cas du libre et du non-libre.
        
        *splash!*
# Point étymologique

Posté par coid le 12 octobre 2013 à 09:16. Évalué à 3.

à chaque fois que l’on dit « cryptage » dieu tue un chaton, car en France on dit « chiffrement ».

Je réponds à ça, parce que les clichés sur la langue, c’est lourd à la longue.

Cryptage, ça vient du grec et ça signifie caché, voilé, etc. Son emploi en cryptographie est donc légitime. C’est même répertorié dans les dictionnaires.

Le chiffrement, c’est juste le moyen de cryptage.
- [^] # Re: Point étymologique
  
  Posté par rewind (Mastodon) le 12 octobre 2013 à 11:32. Évalué à -3.
  
  C’est même répertorié dans les dictionnaires.
  
  Non, ce n'est répertorié dans aucun dictionnaire.
  
  En français, décryptage existe et signifie déchiffrer sans la clef. Cryptage, s'il existait, signifierait chiffrer sans la clef, ce qui n'a aucun sens.
  - [^] # Re: Point étymologique
    
    Posté par Faya le 12 octobre 2013 à 16:39. Évalué à 6.
    
    http://www.larousse.fr/dictionnaires/francais/cryptage/20841
    https://fr.wiktionary.org/wiki/cryptage
    
    A moins que le Larousse ne soit pas un dictionnaire …
    - [^] # Re: Point étymologique
      
      Posté par coid le 12 octobre 2013 à 20:40. Évalué à 4. Dernière modification le 12 octobre 2013 à 20:40.
      
      On trouve aussi cryptage et crypter dans le Robert.
      
      Et des variantes dans le Trésor de la langue française informatisé et le dico de l’Académie.
      http://www.cnrtl.fr/definition/d%C3%A9crypter
      http://www.cnrtl.fr/definition/academie9/d%C3%A9crypter
      - [^] # Commentaire supprimé
        
        Posté par Anonyme le 12 octobre 2013 à 21:09. Évalué à 2.
        
        Ce commentaire a été supprimé par l’équipe de modération.
# Un article qui me fait dire "WTF"

Posté par octane le 12 octobre 2013 à 09:57. Évalué à 3.

J'aime bien cet article, mais il y a des imprécisions qui me font dresser les cheveux sur la tête. C'est la même chose que lorsque certaines personnes disent linux au lieu de GNU/linux, ou web au lieu d'internet :)

L’établissement du tunnel et la preuve d’authenticité des entités est effectuée grâce à la cryptographie asymétrique (Diffie-Hellman

Difie-Hellman ne donne aucune garantie sur l'authentification.

C’est une authenticité à sens unique, puisque le site web ne vérifie pas la votre (soit il s'en fiche, soit il s'y prend autrement, par exemple à l'aide d'un couple login/mot de passe).

Wut? Le site web à le droit de demander un certificat au client, signé lui aussi par une CA. Le mécanisme est le même: le client authentifie le site web par son certificat, puis le site web authentifie le client par son certificat. Les impôts français ont utilisés un temps ce système.

Si la clé privée d’une autorité est compromise, un attaquant devient capable de fabriquer des certificats valides pour le site web de son choix.

En fait, même une sous-CA est suffisante. Il suffit que ton certificat possède les bits qui vont bien.

il est tout à fait probable que la NSA soit un jour venue toquer à la porte de VeriSign, demandant « Filez-nous votre clé privée, ou alors on ferme votre boîte »

Ou plus simplement, signez nous un certificat qui nous donne tous les droits, y compris ceux de signature de certificats. Mais ceci dit, il est hautement probable que la NSA ait les clés de ce genre de sociétés.

Si l'on a la preuve aujourd'hui que la NSA a bel et bien du matériel d'écoute sur les gros noeuds de fibre optique des Etats-Unis, on ne sait toujours pas si elle a effectivement en sa possession les fameuses clés privées des autorités de certification.

Mouais, sauf qu'apparemment, la NSA casse du RC4 tous les jours au petit déjeuner, donc dans la majeure partie des cas, il est inutile de casser quoi que ce soit. Tu écoutes, tu déchiffres à la volée (ou presque), tu stockes, puis tu datamines.

Tout ce qu’il vous garantit, c’est que c’est bien avec lui que vous communiquez et qu’il n’y a pas de tier capable d’intercepter votre communication.

Même plus :) La seule chose que garantit le cadenas, c'est que le contenu entre ta machine et le serveur est chiffré. Il ne garantit finalement plus l'authenticité du site web (est-ce google, un serveur que la NSA a maquillé comme étant google, ou autre chose?) et il ne garantit pas que des tiers peuvent lire la communication (soit par un MiTM de la NSA, soit car le chiffrement est cassable, soit que le site web utilise mal SSL et que le site doive donner sa clé privée, permettant le déchiffrement des échanges). Et je passe sur les autres problèmes de la crypto, genre Dual EC DRBG qui cassent eux aussi toute la crypto.
- [^] # Re: Un article qui me fait dire "WTF"
  
  Posté par Ely le 12 octobre 2013 à 11:13. Évalué à 7.
  
  Hello,
  
  Je m'attendais à une réponse comme celle-ci vu certains points pas très clairs/grossiers de mon article.
  
  Difie-Hellman ne donne aucune garantie sur l'authentification.
  
  La phase entière est L’établissement du tunnel et la preuve d’authenticité des entités est effectuée grâce à la cryptographie asymétrique (Diffie-Hellman et RSA notamment). DH pour l'établissement de la connexion et RSA pour l'authentification (par exemple, cela peut être d'autres mécanismes). C'est vrai que j'aurais pu préciser.
  
  Wut? Le site web à le droit de demander un certificat au client, signé lui aussi par une CA. Le mécanisme est le même: le client authentifie le site web par son certificat, puis le site web authentifie le client par son certificat. Les impôts français ont utilisés un temps ce système.
  
  Je suis d'accord, mais je préférais parler du cas que l'on retrouve 99,999% du temps : une authentification à sens unique. Tu remarqueras que dans mon intro sur SSL, je dis que la double authentification est possible.
  
  En fait, même une sous-CA est suffisante. Il suffit que ton certificat possède les bits qui vont bien.
  
  Oui mais dans la chaîne de signature apparaît une sous-CA inconnue. C'est plus louche que d'avoir un certificat racine direct.
  
  Ou plus simplement, signez nous un certificat qui nous donne tous les droits, y compris ceux de signature de certificats. Mais ceci dit, il est hautement probable que la NSA ait les clés de ce genre de sociétés.
  
  Même réponse, cela rajoute une sous-CA qu'il faut justifier dans la chaîne de certification.
  
  Mouais, sauf qu'apparemment, la NSA casse du RC4 tous les jours au petit déjeuner, donc dans la majeure partie des cas, il est inutile de casser quoi que ce soit. Tu écoutes, tu déchiffres à la volée (ou presque), tu stockes, puis tu datamines.
  
  Y'a eu certes des articles là-dessus, mais comme tu le précises ça reste encore au stade "d'apparemment". On a pas la preuve que la NSA pète du RC4 avec des raspberry pi en quelques millisecondes.
  - [^] # Re: Un article qui me fait dire "WTF"
    
    Posté par boarf le 12 octobre 2013 à 12:31. Évalué à 2. Dernière modification le 12 octobre 2013 à 12:33.
    
    Oui mais dans la chaîne de signature apparaît une sous-CA inconnue. C'est plus louche que d'avoir un certificat racine direct.
    
    De ce que je constate avec les alertes Certpatrol lors de ma navigation quotidienne, aucun certificat n'est signé directement par une autorité racine. Il y a toujours un intermédiaire, ça permet de ne jeter que cette branche en cas de compromission. Les CA racines ne signent que des sous-CA. Et chacune de ces sous-CA peut signer n'importe quel certificat.
    
    Edit : et ces sous-CA ne sont que rarement connues à l'avance par les navigateurs, etc. Donc une sous-CA ne peut être par définition "louche", sauf si elle se nomme clairement "Sous-CA pas de la NSA veuillez regarder ailleurs SVP".
    
    Même réponse, cela rajoute une sous-CA qu'il faut justifier dans la chaîne de certification.
    
    Revenons au cas qu'on retrouve 99.999 % du temps, du coup : très peu de gens contrôlent que la chaîne de confiance n'a pas changé. Et le navigateur (et plus globalement les implémentations de SSL/TLS) ne facilite pas le travail : dès lors qu'il remonte la chaîne à une AC connue, il valide l'authenticité et la considère comme vraie. Il ne demande pas son avis à l'utilisateur, la confiance est imposée.
    
    Ce sont à mon sens les deux problèmes de SSL : la confiance imposée par l'implémentation, et le fait que n'importe quelle CA/sous-CA puisse signer un certificat pour n'importe quel nom.
    - [^] # Re: Un article qui me fait dire "WTF"
      
      Posté par Larry Cow le 14 octobre 2013 à 11:59. Évalué à 2.
      
      le fait que n'importe quelle CA/sous-CA puisse signer un certificat pour n'importe quel nom.
      
      Vivement que DANE commence à être adopté, alors.
- [^] # Re: Un article qui me fait dire "WTF"
  
  Posté par kursus_hc le 14 octobre 2013 à 16:03. Évalué à 1.
  
  Il suffit que ton certificat possède les bits qui vont bien.
  
  Désolé moi c'est cette expression qui me fait dresser les cheveux sur la tête ! On peut dire adéquat, adapté, congruent, etc.
# Toujours pas clair pour un néophyte

Posté par Maclag le 12 octobre 2013 à 11:10. Évalué à 4.

Tel que moi par exemple, donc ça tombe bien c'est comme ça qu'on évalue l'accessibilité d'une explication technique.

Je comprends le principe du chiffrement: deux fonctions paramétrées pour chiffrer puis déchiffrer, respectivement avec clé publique et clé privée. La paire de clés a été fabriquée par le destinataire, qui met la clé publique à disposition de ses interlocuteurs. Utiliser une paire de clé rend les fonctions complémentaires: appliquer l'une puis l'autre revient à la fonction identité.
Donc quelqu'un qui intercepte la communication se retrouve avec le message chiffré et sans la clé privée, ça ne veut rien dire.
(Tiens, en passant, je me suis toujours demandé si casser la clé nécessitait absolument la clé publique ou juste le message chiffré, parce que dans le dernier cas, comment l'algo sait qu'il a trouvé? Il faut être capable de comprendre le message pour ça!?)

Je ne comprends toujours pas, par contre, comment fonctionne l'authentification.

J'accède à un site. Il me montre un certificat signé? Et après?
Je l'utilise comme clé publique sur une chaîne aléatoire générée chez moi?
J'envoie le résultat à l'autorité?
Ils déchiffrent avec une clé privée et me renvoient ma chaîne initiale? J'en conclus qu'ils ont bien fabriqué la paire de clés ensembles?
Si j'ai un problème de MITM, comment je sais qu'il n'y a pas un MITM aussi quand je demande à l'autorité de vérifier?
Les fichiers dans /etc/ssl/certs sont déjà des trucs de chez moi passés à la moulinette par l'autorité et je vérifie juste que le site me renvoie la même chose (ou retrouve ma chaîne aléatoire d'origine)?
- [^] # Re: Toujours pas clair pour un néophyte
  
  Posté par Ely le 12 octobre 2013 à 11:22. Évalué à 4.
  
  Salut,
  
  Pour la première partie :
  
  l'attaque la plus connue contre ce que tu décris est l'attaque de l'homme du milieu. Au moment où le destinataire met à disposition sa clé publique, tu l'interceptes et tu refiles ta clé publique aux autres. Quand ces derniers vont renvoyer des messages chiffrés avec ta clé, tu déchiffres, et tu rechiffres avec la clé publique du destinataire original.
  
  Il est donc indispensable de définir des mécanismes qui prouvent que le destinataire est authentique.
  
  Et pour la partie sur l'authentification :
  
  avec une paire de clé publique/privée, on va plus loin que chiffrer/déchiffrer, on peut aussi vérifier une signature/signer un message . La clé privée servant à signer, et la clé publique mise à disposition permet de vérifier la validité d'une signature.
  
  Quand un site web te montre un certificat, ce n'est que la première étape. S'il proclame être authentique, ça veut dire qu'il possède la clé privée associée au certificat et qu'il est alors capable de signer des messages.
  
  S'ensuit alors une authentification par challenge : tu lui envoies un message aléatoire, et il te le renvoie signé. Grâce à la clé publique contenue dans le certificat, tu vérifies la validité de la signature. Une fois tout ceci fait, tu es sûr de l'authenticité du destinataire, à moins bien sûr qu'un homme du milieu possédait lui aussi la clé privée, ou pire la clé privée d'une autorité de certification avec lequel il t'aura délivré un faux vrai certificat :) .
- [^] # Re: Toujours pas clair pour un néophyte
  
  Posté par groumly le 12 octobre 2013 à 20:08. Évalué à 7.
  
  Pour faire simple: en asymetrique, un message signe avec un cle ne peut etre dechifre qu'avec l'autre cle.
  
  Tu peux utiliser ca de deux facons:
  - chiffre avec la cle publique, seul le possesseur de la cle prive peut dechiffrer: garantit la confidentialite, personne ne peut lire le contenu.
  - chiffre avec la cle prive, tout le monde peut dechiffrer (la cle publique est, ben, publique): garantit l'authenticite (ie celui qui a envoye est bien celui que tu penses).
  
  Partant de la, https fonctionne comme suit:
  - requete du client au serveur: salut! Files moi ton cert publique
  - reponse du serveur: tiens, voila, et au fait, files moi le tien tant qu'on y est. a ce point, les echanges sont en clair.
  - le client verifie le certificat du serveur (cf plus bas), et envoie le sien au serveur, chiffre avec la cle publique du serveur. En https de base, le cert client est genere a la volee.
  - le serveur verifie celui du client (ou pas, c'est optionel), et repond "ok, ca roule ma poule, envoie la sauce", chiffre avec la cle publique du client
  - le client genere une cle symmetrique (une master key en fait, mais on va faire simple), la chiffre avec la cle publique du serveur et lui renvoie
  - le serveur recupere la cle symetrique et ensuite, tous les echanges sont en chiffrage symetrique.
  
  En gros, le protocole utilise:
  - le chiffrement par cle prive pour garantir l'authenticite des hotes
  - le chiffrement par cle publique pour garantir la confidentialite de l'echange de cle symmetrique.
  - une fois le handshake ssl fini, on passe sur une crypto symetrique, vachement moins gourmande en ressources.
  
  Si quelqu'un intercepte les communications pendant le handshake, l'asymetrique garantit que c'est pas lisible sans la cle privee, donc fiable.
  De meme apres en symmetrique, c'est considere suffisament fiable sans la cle partagee, cle qui a ete generee a la volee pendant le handshake, et transmise de facon fiable, donc personne ne peut savoir ce qui se dit entre le client et le serveur.
  
  L'idee derriere est en gros:
  - on veut etre sur que les hotes sont bien ceux qu'ils pretendent. C'est pour ca qu'un certif pour www.google.com ne marchera pas pour google.fr
  - la crypto symetrique marche plutot bien, mais l'echange de cle est tres problematique, donc on utilise de l'asymetrique, vachement plus fort et pratique, pour echanger les cles.
  
  A noter qu'on parle de machines, donc un peu conne. Si tu possedes la cle privee d'un cert en google.com, alors tu es effectivement google.com aux yeux de toutes les machines. C'est pour ca que proteger ses cles prives est tres important.
  
  Qu'est ce qui t'empeche de generer un certif pour google.com donc? La chaine de confiance. On introduit un tiers, dit de confiance, pour garantir que les certifs corrspondent bien aux entites physiques: tu fais confiance a verisign, qui en echange s'engage a verifier l'identite physique des personnes a qui ils delivrent un certificat.
  Ces cert sont hashes, puis chiffres avec la cle privee de l'autorite, et ce hash inclu dans le cert.
  De son cote, le client a une liste de certificat publique racines. Pour valider un cert: tu le hash, et tu dechiffre le hash inclu dans le cert avec la cle publique de l'autorite. Si ca correspond, le certificat publique est considere comme valide, et le process continue sans alerter l'utilisateur. Si ca match pas, le navigateur gueule comme un putois.
  
  La partie client/serveur est trs robuste, et tres dur a casser, surtout en temps reel (mitm synchrone ou l'homme du milieu reencode tout a la volee).
  
  La partie confiance, ben c'est de la confiance, donc c'est plus du ressort de l'etre humain qu'autre chose. Si verisign deconne a plein tube et files des certs pour google.com aux mechants hackers ukrainien, ca marche plus.
  Si verisign se prends une requete de la nsa et doit leur donner leurs master keys privees, ca marche plus non plus, mais aucun protocole ne peut regler un probleme humain a cette echelle.
  
  C'est pour ca aussi que le business de verisign peut etre vu comme douteux: tu paye un fort montant pour un hash de qq centaines de bits. Ca fait cher du bit au final, mais tu payes surtout pour l'infrastructure de verification derriere. D'aucuns diront que c'est des clampins, perso je m'engage pas sur cette pente savonneuse.
  
  C'est l'avantage de ssl, c'est que ca passe tres tres bien a l'echelle d'un point de vue technique, et c'est aussi tres facile de revoquer des certificats si quelqu'un se met a deconner.
  
  Linuxfr, le portail francais du logiciel libre et du neo nazisme.
  - [^] # Re: Toujours pas clair pour un néophyte
    
    Posté par Maclag le 13 octobre 2013 à 15:30. Évalué à 3.
    
    Maintenant c'est clair!
    Merci à toi et Elyotna pour ces précisions!
  - [^] # Re: Toujours pas clair pour un néophyte
    
    Posté par khivapia le 14 octobre 2013 à 09:27. Évalué à 2.
    
    C'est l'avantage de ssl, c'est que ca passe tres tres bien a l'echelle d'un point de vue technique, et c'est aussi tres facile de revoquer des certificats si quelqu'un se met a deconner.
    Euh les listes de révocation des certificats ne passent pas à l'échelle du tout. Aucun navigateur, d'ailleurs, ne vérifie par défaut les CRL à chaque connexion SSL.
# Vraiment ?

Posté par Kerro le 12 octobre 2013 à 15:07. Évalué à 5.

Si l'on a la preuve aujourd'hui que la NSA a bel et bien du matériel d'écoute sur les gros noeuds de fibre optique des Etats-Unis,** on ne sait toujours pas si elle a effectivement en sa possession les fameuses clés privées des autorités de certification**.

Tu n'as vraiment pas une petite idée ?
Indice : la NSA a tous les pouvoirs (légaux ou pas) pour faire fléchir n'importe quelle entreprise des USA.
- [^] # Re: Vraiment ?
  
  Posté par vv222 le 14 octobre 2013 à 08:50. Évalué à -1.
  
  la NSA a tous les pouvoirs (légaux ou pas) pour faire fléchir n'importe quelle entreprise des USA.
  
  Mouais…
  Ce qui m'inquiète plus ce sont les quelques grands groupes mondiaux qui ont les moyens de faire fléchir la NSA.
# en France on dit...

Posté par fravashyo le 12 octobre 2013 à 17:59. Évalué à 6.

vous rappeler qu’à chaque fois que l’on dit « cryptage » dieu tue un chaton, car en France on dit « chiffrement ».

Marrant, parce qu'on dit également cryptographie, et non pas chiffographie, alors dieu peut tuer autant de chatons qu'il veut, ça ne sera pas de la faute de ceux qui écrivent cryptage au lieu de chiffrement, mais plutôt à cause de ceux qui écrivent « librairies » au lieu de « bibliothèques ».

« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
- [^] # Re: en France on dit...
  
  Posté par Guillaume Rossignol le 12 octobre 2013 à 23:44. Évalué à 4.
  
  La prochaine fois que j'irai chez mon libraire, j'essayerai d'emprunter le bouquin au lieu de l'acheter.
  
  Poussez pas, je suis déjà dehors.
# Et encore que..

Posté par maboiteaspam le 13 octobre 2013 à 06:07. Évalué à 0. Dernière modification le 13 octobre 2013 à 06:09.

Tout ce qu’il vous garantit, c’est que c’est bien avec lui que vous communiquez et qu’il n’y a pas de tier capable d’intercepter votre communication. Mais il ne vous renseigne en aucun cas sur l’utilisation qui est faite de vos données. Pour résumer, rien n’empêche un site web en https d’être profondément malhonnête avec vos données à la suite de la communication.

Et ce n'est pas même pas tout…

Tout ce qu'il garantit c'est que l'on communique bien avec le système d'hébergement.
On ne garantit ~~en rien du tout~~ pas plus que le contenu est authentifié.
On part du postulat que si la clef est authentifiée alors le contenu est forcément correcte. En fait pour aller plus loin on parrt du postulat que l'hébergement est safe tant que la clef est safe.
Hors si je suis un attaquant, je veux être discret, mode chaméléon, faker la clef en live sur internet c'est juste stupide.
Par contre prendre appui sur une clef d'un tiers reconnu de confiance pour infecter silencieusement son site internet de manière hautement sécurisée, c'est tellement plus rentable…

Bref, tout sa pour parler de ma vie.
Je travail avec les manifest d'applications en html5, et en gros y'à une clef de version à l'intérieur qui sert à identifier la version des contenus en cache et surtout de la page html cf http://www.html5rocks.com/en/tutorials/appcache/beginner/.
Le truc qui serait bien, amha, se serait de signer la clef version avec la clef ssl publique/privée(??) du site et la somme sha des fichiers en cache.
Ainsi, côté browser y'aurait plus qu'à re checker la version du manifest pour valider l'authenticité
du contenu
et du contenant.

Se serait pas mal, non ?
# au delà de la NSA

Posté par antistress (site web personnel) le 14 octobre 2013 à 00:23. Évalué à 2.

Au delà de la NSA, ce qui étonne c'est que ces certificats soient délivrés par une poignée de sociétés commerciales contre espèces sonnantes et trébuchantes.
Or nous ne connaissons rien de ces sociétés, pourquoi devrions nous leur faire confiance ?
C'est un point développé dans les conférence sur la FreedomBox qui propose un système alternatif basé sur la confiance décidée et non imposée
Je ne sais plus si c'était dans la présentation de la FreedomBox par James Vasile https://www.youtube.com/watch?v=9bDDUyJSQ9s ou dans celle d'Eben Moglen sur la perte de nos libertés à l'ère numérique http://benjamin.sonntag.fr/Moglen-a-Re-Publica-defendre-notre-liberte-de-penser-exige
De toutes façon les deux sont à voir impérativement
- [^] # Re: au delà de la NSA
  
  Posté par Ely le 14 octobre 2013 à 08:46. Évalué à 2.
  
  Et surtout, il suffit que l'une d'entre elles soit malhonnête pour que tout le système soit compromis..
# La NSA montre ses muscles

Posté par lolcat le 31 octobre 2013 à 16:17. Évalué à 1.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.