Stéphane Bortzmeyer a écrit 645 commentaires

Il y a plusieurs solutions. Dans des cas similaires précédents (l'opération Tulipe Noire, par exemple), Google avait utilisé OCSP http://www.bortzmeyer.org/6960.html Il y a aussi des règles spéciales dans Chrome pour prévenir Google en cas de certificats suspects de la maison mère (si l'utilisateur a Chrome). Enfin, il y a la possibilité d'un utilisateur qui détecte le loup (il suffit d'une courte bogue dans le logiciel d'interception qui laisse échapper un message d'erreur non-Googlien), copie le certificat, et l'envoie à Google.

http://www.ietf.org/mail-archive/web/perpass/current/msg01162.html

Je ne comprends pas la remarque sur "une seule IP derrière une URL". C'est clairement faux. (Il y en a trois derrière http://www.bortzmeyer.org/)

Pourquoi gâchée ? Ce n'était pas dans le cahier des charges, c'est tout. Aujourd'hui, ça y est. Participez à perpass plutôt que de regretter le passé :-)

Déjà, c'est mal de dire « cryptage » http://www.bortzmeyer.org/cryptage-n-existe-pas.html

Si, mais cela ne marche pas si on veut TLS et d'autres protocoles (en l'occurrence SSH, car plein de réseaux ne laissent d'accès que via le port 443).

Tout à fait. Une durée de validité des signatures DNSSEC de deux mois me convient tout à fait. Ceci dit, quand la re-signature est automatique (ce qui est fortement recommandé), la question du délai est moins cruciale.

Et la comparaison avec TLS n'est pas bonne car TLS ne permet pas facilement d'attaques par rejeu.

"Certaines" ? Non. Sans authentification, TLS est vulnérable à toutes les attaques de l'homme du milieu. Sans DNSSEC, le DNS est même vulnérable à l'homme du bord (pas besoin d'être homme du milieu pour faire un empoisonnement DNS.) Sans authentification, TLS ne protège que contre un attaquant passif (genre Firesheep).

Tout à fait d'accord sur le risque que la sécurité n'empêche les "petits" acteurs de se développer et les décourage, avant de les jeter dans les bras des gros silos fermés.

Pour LinuxFr, je suppose qu'il y a assez de compétences disponibles. Pour M. Michu qui voudrait faire un truc équivalent, on manque en effet d'outils simples et bien intégrés. Une bonne discussion avait eu lieu sur LinuxFr à ce sujet : https://linuxfr.org/users/bortzmeyer/journaux/rendre-l-auto-hebergement-facile-et-sans-douleur

Attention, c'est vrai qu'il faut re-signer périodiquement lorsqu'on utilise DNSSEC mais ce n'est pas forcément à la main, il est même au contraire très recommandé d'utiliser un outil automatique. Je suggère OpenDNSSEC (libre, évidemment, et tournant sur Linux, évidemment). http://www.opendnssec.org/

C'est pas qu'on s'en éloigne, c'est qu'on file à l'autre bout de la galaxie : la solution OVH est du pur claoude. On peut aimer mais question liberté, c'est pas ça…

L'accès à www.bortzmeyer.org en HTTPS est sur mon TODO. Le principal problème est la pénurie d'adresses IPv4. J'ai peu d'adresses et le port 443 est déjà pris par autre chose.

C'est vrai que seulement deux serveurs de noms pour linuxfr.org, tous les deux chez le même opérateur, ça fait un peu léger. Je suis sûr qu'on trouverait des secondaires volontaires dans la communauté (je suis volontaire, par exemple).

Je ne comprends pas l'allusion à dns2tcp (c'est quoi ? juste un tunnel IP sur DNS ?) Il y a encore des gens compétents (pas des certifiés Cisco) pour limiter la taille des paquets DNS à 512 octets ???

Aucun détail, aucune référence ? Du pur FUD.

Non, IPv6 ne change quasiment rien. Ses propriétés de sécurité sont à peu près les mêmes que celles d'IPv4. http://www.bortzmeyer.org/ipv6-securite.html

Il existe des tas de bonnes raisons de pousser la migration vers IPv6 mais la vie privée n'en est pas une.

Et la disponibilité native d'IPsec est une légende http://www.bortzmeyer.org/6434.html

Une réponse plus détaillée en http://www.bortzmeyer.org/usurpation-adresse-ip.html

Sur le problème des métadonnées, voir http://www.bortzmeyer.org/metadonnees.html

Je ne vois pas non plus la protection de la vie privée dans cette liste très curieuse et très limitée de ce qu'est la sécurité (cette protection s'entend souvent mal avec l'authentification).

Et c'est tout ? La résistance aux pannes n'est pas incluse dans la sécurité (elle s'entend en général mal avec l'authenticité et l'intégrité) ?

C'est bien un argument fort en faveur des solutions JS+HTML+CSS comme reveal.js : tout ordinateur a un navigateur Web capable d'afficher ces présentations.

Usurper une adresse IP, en TCP (le protocole de transport qu'utilise SMTP) est très difficile, pour un attaquant aveugle (non situé sur le chemin). Cf. RFC 5961 http://www.bortzmeyer.org/5961.html

Euh, pas d'accord. Le verbe « sécuriser » est bien trop vague et décrit des tas de choses différentes et incompatibles. Dans le contexte de cet article, on parlait surtout de protection de la vie privée. Cela peut mener à des techniques comme les communications « sourceless » où on ne saurait pas qui nous parle. Excellent pour la vie privée, pas génial pour refuser le spam. Non, faut pas se faire d'illusions, il y aura des choix à faire.

http://www.bortzmeyer.org/ietf-securite-espionnage-bis.html

De toute façon, il semble bien, vus les derniers changements, que Google Hangouts ne permettra plus bientôt d'interagir avec le reste du monde XMPP (comme c'est déjà le cas de Facebook Chat). En tout cas, Google n'a jamais répondu aux demandes de clarification de sa position.