🚲 Tanguy Ortolo a écrit 12224 commentaires

Il peut être signé par une fausse autorité.

Facile :
1. tu génère un faux certificat avec les informations administratives de la vraie AC ;
2. tu génères un sous-certificat, signé avec cette fausse AC ;
3. tu génères un certificat pour le site, signé avec cette fausse sous-AC ;
4. tu montes un proxy, qui déchiffre ce qui sort du vrai site et le chiffre avec ton faux certificat avant de l'envoyer au client.

Vu du client, on voit alors un site chiffré, avec un certificat signé par ce qui ressemble à une AC, mais qui n'est pas dans la liste. D'où une alerte du navigateur. Exactement celle qui s'affiche avec le site des listes de mariage des Galeries.

Et bien curieusement, Firefox affiche une alerte de sécurité. Le certificat « d'AddTrust » en question, ça n'a pas l'air d'être le vrai.

Il me semblait bien, aussi, que Télécom Paris n'était vraiment pas à côté d'Eyrolles. :-)

Bon, alors c'est l'ESTP, pas l'ENSTP. Les travaux publics, pas Télécom Paris. Je n'aime pas utiliser les sigles d'Écoles : on n'y comprend rien et en plus il y a souvent ambiguïté. Télécom Paris, travaux publics, Polytechnique, Normale Sup', Sup'Optique, Supélec, Centrale Paris, Mines, Ponts, ça, tout le monde comprend.

dans les locaux d'Eyrolles
me semble antinomique avec :
à l'ENSTP, qui prête son grand amphi

C'est chez Eyrolles ou à l'ENSTP ? D'ailleurs, l'ENSTP, c'est Télécom Paris, c'est ça ?

Non, désolé, je persiste. Chiffré avec une clef symétrique générée par un échange utilisant une clef asymétrique du site.

En revanche, ce qui est un délit, et un vrai, c'est de ne pas sécuriser les données qu'on détient. :-)

Introduit ? Je me suis introduit dans quoi ? J'ai été voir un site web, avec Iceweasel, avec Epiphany, avec wget, links, telnet, openssl s_client puis gnutls-cli. C'est consulter des informations publiques, ça.

Si ça, c'est un délit, alors consulter quelque site web que ce soit en est un aussi. Allez hop, tous en prison.

Pour envoyer un message à Rue89, je devrais me rendre anonyme ? Ils sont du genre balance ?

Il s'agit d'argent, là. Ce n'est pas comme si on avait le choix. Mon argent est déjà à la Société Générale. Que je leur fasse ou non confiance pour des paiements en ligne ne change rien, ils ont déjà tout mon argent.

Non, mais si tu es certain de t'adresser à Orange et que ta communication est chiffrée avec une clef symétrique qui n'a pu être déchiffrée qu'avec la clef privée d'Orange (bref, si tu es sur HTTPS correct), s'il y a un keylogger dans la page, ou si les informations fuient d'une façon ou d'une autre, tu es sûr que c'est la faute d'Orange.

D'une façon générale, avec les systèmes de chiffrement et de signature, on n'est jamais sûr qu'on s'adresse à la bonne personne ou qu'elle est seule à pouvoir déchiffrer : ce dont on est sûr, c'est que si ce n'est pas le cas, c'est sa faute.

Une trace de quoi ? Que quelqu'un utilise ma carte bleue avec un autre compte Amazon, c'est un problème qui n'a rien à voir avec celui que je décris. Là, ce qui m'ennuie, c'est qu'Amazon conserve dans ses bases de données de quoi se servir sur mon compte. Le jour où ils se plantent, ou un de leurs programmes déconne, ou tout simplement s'ils se font pirater, c'est fichu.

Ce système absurde peut être évité, en utilisant une banque comme intermédiaire, comme ça se fait sur les sites marchants sérieux.

Inutilisable par un libriste, pardon.

Et même si j'étais équipé, si ce truc nécessite Flash, il exécute sur mon poste du code que je ne peux pas lire, pas question que je fasse confiance à un dispositif de sécurité que je ne peux pas vérifier.

C'est une bonne chose. Dommage que ce soit inutilisable, en tout cas avec la Société Générale : il paraît qu'il faut Flash, et puis Windows ou MacOS X. Comme c'est payant, je ne vais pas m'amuser à tester si je risque de ne pas pouvoir l'utiliser.

Certains systèmes de paiement, oui. Typiquement, ceux qui te redirigent vers le site d'une banque le temps de payer, puis redirigent vers le site marchand.

La Fnac, Amazon et quelques autres, pour payer, te demandent directement le numéro de ta carte, la date d'expiration et le prétendu « cryptogramme de sécurité », enregistrent ces informations, puis vont se servir auprès de la banque. Et ensuite, conservent ces informations dans leurs bases de données pour pouvoir se servir à nouveau la prochaine fois qu'ils le voudront.

Là, il y a deux problèmes :
- on n'a aucune certitude que seul le site auquel on croit s'adresser reçoit les informations (il peut les recevoir ainsi qu'un homme au milieu) ;
- dans le meilleur des cas, on donne son numéro de carte bancaire non pas à une banque pour qu'elle confirme aux Galeries qu'on a bien payé, mais aux Galeries pour qu'elles se servent.

Le second point est hors du propos de mon journal, et explique que je refuse d'acheter quoi que ce soit chez Amazon, à la Fnac en ligne ou chez LDLC par carte bleue. Donne mon numéro de carte bancaire, ok, mais à une banque, pas à un magasin qui l'enregistrera pour des achats ultérieur ou pour Dieu sait quoi (oui, Amazon et la Fnac, ils l'enregistrent).

Quant aux vérifications par les AC, il me semble qu'elles demandent tout de même des justifications comme des relevés de compte, pour intégrer le nom de la personne dans le certificat. De toute façon, pour le moment, ce que j'ai vu de plus sérieux comme vérification, c'était CAcert. La façon dont SSL est actuellement utilisée est complètement anormale, je trouve. Vérifier l'identité des gens, c'est le boulot des États.

En fait, l'échec de connexion avec certaines implémentations vient de ce que le serveur envoie un bout de données en clair. Donc c'est doublement anormal, avec en plus le certificat qui est invalide.

C'est juste le contact qui n'est plus employé des Galeries, je pense. Est-ce que ça rend le domaine ouvert aux acheteurs, aucune idée. De toute façon, vu que Galeries Lafayette, c'est une marque déposée, c'est s'exposer à des ennuis.

Au passage, notez que coder n'est pas chiffrer. Un code, c'est le remplacement de mots ou d'ensembles de mots par d'autres symboles. Par exemple, parler de Mandarine au lieu d'un opérateur téléphonique et Internet, c'est un code.

Le chiffrement existe depuis bien plus longtemps que l'informatique, et les apports de l'informatique dans ce domaine ne changent rien au besoin de vocabulaire : on a toujours chiffré, et on peut continuer à chiffrer sans changer ce mot qui convient très bien.

Le dictionnaire de l'Académie est vieux ? Et alors, rien n'a changé, on chiffre toujours, on déchiffre toujours, on décrypte toujours. Il n'y a absolument aucun besoin d'introduire de nouveaux mots, synonymes qui plus est, et encore moins de détruire le sens du mot décrypter.

« Et/ou », c'est assez moche, quand même. Là, un simple « et » aurait suffit, je pense.

D'après la Wikipédia, crypter ne figure pas au dictionnaire de l'Académie française. Là où les anglais ont deux mots : to encrypt (chiffrer) et to decrypt (déchiffrer ou décrypter), on a la chance d'en avoir trois : chiffrer, déchiffrer et décrypter (remettre en clair par cryptanalyse).

Si on commence à utiliser crypter et décrypter à la place de chiffrer et déchiffrer, on perd le sens original du verbe décrypter.

Quant à la vieillesse des termes chiffrer et déchiffrer, elle ne change rien à leur sens, ces mots convenant encore tout à fait. Chiffrer n'implique pas l'utilisation exclusive de chiffres, d'ailleurs le chiffre de César utilise uniquement des lettres. Et en plus, en informatique, on n'utilise que des chiffres, de fait.

Je vais vérifier tout ça, mais de toute façon, même si crypter est un vrai verbe, encryptage est une horreur, il faudrait dire cryptage, tout simplement.

C'est sérieux, ça ? On en est là ? À signaler tout de suite à l'ARCEP…