Avec le poids qu'à Google, on peux y voir un moyen de pousser à une obligation de proposer TLS dans SMTP, non?
Hum, non.
Si Google voulait rendre TLS obligatoire, il n’aurait qu’à configurer ses serveurs pour interdire les connexions en clair.
Cette étude sert plutôt à expliquer au contraire pourquoi ils ne peuvent pas le faire — à cause de la « longue traîne » de fournisseurs de messagerie (modestes individuellement, mais représentant collectivement une part non-négligeable du traffic) qui sont incapables d’utiliser TLS.
On peut toujours espérer que cette étude poussera quelques-uns de ces fournisseurs à se bouger et à améliorer leur prise en charge de TLS, mais je ne me fais pas beaucoup d’illusions.
Au final l'étude ne s'intéresse qu'au chiffrement de bout en bout
Non, justement, elle ne s’intéresse qu’au chiffrement de point à point (du client au serveur, d’un serveur à un autre serveur, du serveur au destinataire). Et c’est le seul type de chiffrement auquel les fournisseurs de messagerie peuvent (et doivent) s’intéresser.
Le chiffrement de bout en bout, c’est de l’expéditeur au destinataire. Et par définition, ce ne peut être que du ressort des utilisateurs finaux.
Si c’est le fournisseur qui met en place l’utilisation de PGP, ce n’est pas du « bout en bout » — n’en déplaise à certains fournisseurs qui mettent en avant le fait qu’ils utilisent PGP sur leurs serveurs.
Pour ma part, ça fait longtemps que j’ai renoncé au prosélytisme. Ça n’a jamais marché. Au total, j’ai convaincu… une personne de passer aux logiciels libres, et encore elle était déjà intéressée quand je l’ai rencontrée, donc je ne suis même pas sûr d’avoir joué un quelconque rôle dans sa décision — au maximum, je l’ai seulement convaincu que le choix qu’elle était déjà en train de faire était le bon.
Je pense que la plupart des gens n’aiment pas qu’on tente de les convaincre. En tout cas, je n’aime pas qu’on tente de me convaincre.
Aujourd’hui, je me contente d’informer, de faire découvrir. Après, le choix appartient à mon interlocuteur. S’il choisit de continuer à utiliser des logiciels propriétaires, ben… c’est son choix et je n’ai rien à y redire. Au moins, je considère qu’il est déjà plus libre que lorsqu’il utilisait les mêmes logiciels propriétaires par défaut, simplement parce qu’il ne savait même pas qu’il existait autre chose.
(Je dis ça pour les logiciels libres, mais c’est tout aussi applicable à la question des GAFAM et autres services en ligne — là aussi, je me contente d’informer des problèmes potentiels, des risques, et des alternatives potentielles.)
Ce n’est peut-être pas plus « efficace » que le prosélytisme, mais au moins je ne passe pas pour le prêcheur d’une secte paranoïaque ou conspirationniste, pour le même résultat au final (et puis bon, le résultat de toute façon, quelle importance ? je n’ai pas quelqu’un qui me demande à la fin du mois « combien de personnes avez-vous convaincu ce mois-ci ? »).
Ah, au passage, si tu veux quand même continuer à essayer de convaincre, peut-être que ne pas mépriser tes interlocuteurs pourrait aider… (« puits sans fond d’ignorance et de jeunesse d’esprit », rien que ça ? et toi tu es un puits sans fond de sagesse et de maturité, je suppose ?)
À voir… Il y en a déjà qui n’ont pas hésité à postuler que toute personne se rendant en Turquie était suspecte, sans considération pour les motifs du voyage ou l’existence de « raisons sérieuses de penser que etc. » :
Pierre Lellouche : Toute personne se rendant à Istanbul dans un avion de Turkish Airlines ou d’Air France devrait faire l’objet d’une surveillance.
[…]
Sébastien Pietrasanta : Se rendre en Turquie rend-il suspect ? […]
D’une part, tout nouveau protocole (ou modification d’un protocole pré-existant comme TLS/X.509) nécessitant de modifier le code des serveurs et des clients a très peu de chance d’être mis en place, et s’il l’est ce ne sera pas avant plusieurs années. Il y a une inertie énorme, il suffit de voir le temps qu’il a fallu pour déployer TLS 1.2 — on trouvait encore il y a quelques mois beaucoup de serveurs ne supportant rien de mieux que SSL 3.0, obsolète depuis plus de quinze ans (il a fallu l’attaque POODLE pour donner un coup de pied dans la fourmillière).
D’autre part, des alternatives aux « bêtes certificats actuels », ou des méthodes pour combler leurs déficiences, il y en a déjà plusieurs. Au moins deux sont particulièrement dignes d’intérêt :
les certificats OpenPGP (RFC 6091), beaucoup plus flexibles que les certificats X.509 (ils peuvent notamment porter un nombre arbitraire de signatures, et la confiance en chaque signature n’est pas binaire) ;
l’épinglage des certificats (ou des clefs brutes, RFC 7250) dans le DNS (DANE, RFC 6698).
Ni l’un ni l’autre ne sont largement supportés. À ma connaissance, seule la bibliothèque GnuTLS implémente le RFC 6091, et aucun navigateur ne supporte nativement DANE (un plugin existe pour ceux qui le veulent).
Toute proposition de solution aura besoin de l’appui d’un poids lourd du web pour s’imposer, indépendamment de ses mérites. C‘est comme ça que seul Certificate Transparency, qui est activement poussé par Google, a une chance d’aller loin (et c’est malheureux, car c’est une fausse solution qui ne résoud aucun des problèmes de X.509).
l'(illusion de) sécurité supplémentaire apportée par les certificats ne consiste qu'en un déplacement temporel de l'attaque MITM pour qu'elle soit effective
Même pas.
Le système actuel ne fournit aucune sécurité contre les attaques de type MITM. Il y a trop de moyens d’obtenir un certificat frauduleux qui sera accepté par le plus grand nombre. Trop d’autorités de certification (et encore plus de CA intermédiaires) à laquelle on accorde une confiance totale (X.509 ne connait rien d’autre que la confiance complète) et aveugle.
Tu peux bien obtenir un certificat à validation étendue (EV) en payant très cher une CA irréprochable (admettons qu’une telle CA existe)… ça n’empêchera pas un attaquant d’obtenir un certificat frauduleux pour ton domaine auprès de l’une quelconque des milliers de CA ou CA intermédiaires malhonnêtes ou incompétentes — et ce certificat sera accepté comme valide par les clients.
Les CA ne servent à rien. Tout le monde le sait, mais tout le monde fait semblant de l’ignorer.
Ce n’est que pour se protéger des attaques actives de type MITM que l’on a besoin d’autorités de certification (contre les attaques passives, un certificat auto-signé est suffisant, nul besoin de CA), et c’est précisément contre ce type d’attaque qu’elles n’apportent aucune garantie…
Ça mine fortement ma confiance en la sécurité du web tout ça
Ça fait longtemps que la mienne est complètement détruite.
le client pourrait vérifier que le nouveau certificat est à la fois signé par l'autorité mais aussi par l'ancien certif
Là ce n’est pas le protocole ACME qu’il faut changer, mais le format des certificats. Un certificat X.509 ne peut pas porter plusieurs signatures.
Sur des sites ou on va régulièrement, par exemple une fois par trimestre au moins, on aurait aussi une protection contre une attaque sur l'autorité elle même.
Pour ça, il y a l’épinglage de certificats dans les en-têtes du serveur web (déjà implémenté dans la plupart des navigateurs) et/ou dans le DNS.
C’est qui ou quoi cette « Sécurité européenne » qui décide comme ça d’envoyer un rapport (probablement confidentiel puisque personne d’autre n’en a connaissance) au premier blogueur venu ?
Among other things, the attack took down the French mobile data network
Une attaque a fait s’écrouler nos réseaux mobiles pendant 48 heures et personne (à part bien sûr la Sécurité européenne) ne s’est rendu compte de rien… D’ailleurs, les Parisiens n’ont pas du tout utilisé leurs téléphones portables pour s’informer de la situation vendredi soir.
The attack was not a straightforward DDOS attack but a sophisticated attack that targeted a weakness in infrastructure hardware.
Bizarremment, dès qu’on parle d’une attaque informatique on dit toujours qu’elle est « très sophistiquée »…
Such an attack is beyond the capability of most organizations and requires capability that is unlikely to be in ISIL’s arsenal.
Sans détails sur la (pseudo-)attaque en question, cette affirmation est totalement gratuite. Ainsi que tout le paragraphe qui suit d’ailleurs.
It is common for people with no experience in government to believe that false flag attacks are not possible
« 13-November was an inside job » — Je me demandais au bout de combien de temps on allait la voir arriver, celle-là…
I am unable to reveal any further information.
Ben voyons. Et pourquoi donc ? Pourquoi ne pas divulguer ce fameux rapport ?
j'essaye sur mon Android de base pas bien vieux de recevoir un appel, et bam marche pas. Comment oser filer ça à une personne dont je ne connais pas le navigateur? Question de communication, plus simple de dire "installe skype".
Attention avant de conseiller Skype sur Android… Les dernières versions ont un (gros) bug qui le rend complètement inutilisable sur cet OS (ou certaines versions de l’OS, au moins) : impossible de recevoir un appel sitôt que l’application n’est plus en avant-plan ou que l’appareil passe en veille.
Skype, « le truc qui marche partout, passe partout » ? Pas tant que ça, non.
Ma question est comment les admins système peuvent bloquer Skype, si il est blocable.
Manifestement, il l’est. Les administrateurs ont réussi à le bloquer dans mon ancien institut.
D’après ce que j’ai compris, ils ont profité d’une remise à niveau du réseau pour installer des routeurs capables de faire du « Deep Packet Inspection » ciblant spécifiquement Skype.
(Le sysadmin avait expliqué la chose à peu près en ces termes : « On a installé des nouveaux routeurs qui détectent et bloquent le traffic Skype. Ça faisait déjà plusieurs années que Skype était interdit, la différence c’est que maintenant on applique l’interdiction. »)
et que les customs actions de Thunar (car Thunar en général respecte les standards FDO) ont été sûrement implémentés avant que le standard FDO n'aparaisse.
Oui. Le plugin UCA de Thunar date au moins de 2006, la spécification DES-EMA de 2009.
(Au passage, DES-EMA n’est pas un standard FDO, c’est une proposition indépendante, qui ré-utilise et étend le format DES de freedesktop.org.)
Et avant que quelqu’un ne dise « donc ce sont les auteurs de DES-EMA qui souffrent du NIH syndrome, pourquoi n’ont-ils pas repris le format déjà utilisé par le plugin UCA ? » :
Apparemment, personne chez Thunar n’a prétendu que ce format avait une vocation universelle, c’est un format purement interne au projet.
Les autres DE avaient eux aussi leur propre sauce, pourquoi aurait-il fallu choisir celle de Thunar spécifiquement ?
Le format de Thunar-UCA n’est pas sans défaut. Le plus gros à mon sens (et le point sur lequel DES-EMA est supérieur) : toutes les actions sont définies dans un unique fichier XML. Ajouter/enlever/modifier une action nécessite de modifier cet unique fichier. Cela manque énormément de souplesse, comparé à DES-EMA où chaque action est dans un fichier individuel (avec en plus la possibilité de « surcharger » un fichier selon le mécanisme de la spécification XDG-Basedir).
Sérieux, on peut répondre dans le sujet?
Le sujet n'est pas le changement par l'utilisateur, mais qu'un développeur puisse supporter tous les 0.1% de DE Linux dans y passer des plombes
Je t’ai indiqué la (proposition de) spécification qui semble supportée par le plus grand nombre de DE (dont les deux plus « gros ») et même par au moins un explorateur de fichier indépendant de tout DE.
Si tu veux être le plus accommodant pour tes utilisateurs Linuxiens (ce qui est tout à ton honneur), je pense que la meilleure chose à faire est d’implémenter cette spécification (c’est-à-dire, fournir un fichier .desktop inspiré de celui que j’ai posté plus haut).
Personne ne t’oblige à « supporter tous les 0.1% de DE Linux », et je suis convaincu que personne ne te reprochera de ne pas fournir une custom action pour l’explorateur de XFCE¹ — et si quelqu’un le fait, tu sais quoi répondre : « pas mon affaire, moi j’ai fait ce qu’il fallait, plaignez-vous auprès des développeurs de votre DE / envoyez-leur un patch / changez de DE ».
¹ De toute façon, le mode de fonctionnement du plugin UCA de Thunar (responsable des custom actions) ne semble clairement pas conçu pour permettre d’ajouter/enlever/modifier automatiquement des actions, lors de l’installation d’un paquetage par exemple (contrairement au principe de la spécification DES-EMA). Donc on ne peut pas te reprocher de ne pas faire ce que Thunar ne permet pas de faire.
Comme cité plus haut, si les étudiants sont français il n’y a pas d’ambiguïté
Vu que les posters sont publiés sur une page web (et non pas seulement affichés en classe), ils ne sont pas uniquement destinés à des étudiants français. Francophones à la limite, mais pas français.
(D’ailleurs, si le nom de domaine est d’une quelconque indication, même dans la salle de classe de l’auteur les étudiants ne sont pas français mais belges.)
Même en ne ciblant que la francophonie, est-ce que tous les pays francophones utilisent le format JJ/MM/AAAA ? Je n’en mettrais pas ma main à couper (rien qu’au Québec, par exemple…), d’où l’intérêt d’un format standard.
Les anglo-saxons, pour leur quotidien, n'ont pas voulu de notre système métrique, pourquoi devrions nous adopter leur système de notation de date ?
Il ne s’agit pas ici du format anglo-saxon (MM-JJ-AAAA) mais du format ISO (AAAA-MM-JJ).
Et je vois pour ma part au moins deux avantages à ce dernier :
il évite les ambiguités du genre 01-03-2015, qui peut représenter le 1er mars 2015 ou le 3 janvier selon le format utilisé (non, le contexte ne suffit pas toujours à trancher) — 2015-03-01 sera toujours le 1er mars, parce que personne n’utilise un format AAAA-JJ-MM ;
trier des dates ISO dans l’ordre lexicographique revient aussi à les trier dans l’ordre temporel (2014-01-03 est avant 2015-03-01).
L'opération décrite par Foutaise permet de créer un fichier desktop dans ~/.local/share/file-manager/actions/.
Euh, chez moi (Thunar 1.6.3), les custom actions de Thunar sont enregistrées dans un fichier $XDG_CONFIG_HOME/Thunar/uca.xml, dans un format propre à Thunar. Et le même Thunar ne tient aucun compte de ce qui se trouve dans $XDG_DATA_DIRS/file-manager/actions.
Il faut ajouter un fichier .desktop dans $XDG_DATA_DIRS/file-manager/actions. Quelque chose comme ça (non testé pour cet exemple précis) :
[Desktop Entry]
Name = Media information
Name[fr] = Informations sur le média
Profiles = on_media_file
[X-Action-Profile on_media_file]
MimeTypes = video/allfiles
SelectionCount = 1
Exec = mediainfo -i %f | zenity --text-info --title %w --width=480 --height=640
Mais il ne semble pas que XFCE/Thunar prenne en charge cette spécification, malheureusement. Nautilus et Konqueror le font, apparemment, de même que PCManFM (pour ce dernier j’en suis sûr, vu que c’est ce que j’utilise).
on connaît quelques méthodes de stockage des mots de passe, par ordre croissant de sécurité:
[…]
idem 2., en utilisant une fonction qui va mieux : bcrypt
Pour information, le concours Password Hashing Competition, qui visait à sélectionner une fonction de condensation de mot de passe (sur le modèle des concours qui ont sélectionné AES et SHA-3), a annoncé cet été avoir choisi l’algorithme Argon2.
Faudrait sans doute un champs DNSSEC qui dise qu'il faut SSL, mai on est encore loin de ça…
Pour info, le RFC 7672 spécifie que la seule existence d’enregistrements TLSA pour un serveur mail suffit à indiquer que TLS est obligatoire pour contacter ledit serveur (section 2.2, “TLS Discovery”).
Postfix implémente ce comportement avec smtp_tls_security_level = dane (Victor Dukhovni, co-auteur du RFC, est un des développeurs de Postfix).
les MX qui seront bloqués à F […] Mon serveur de submission à lui la note de C.
L’inverse me semblerait plus logique…
Les serveurs de soumissions, qui sont directement contactés par les utilisateurs finaux (et donc potentiellement une large gamme de systèmes plus ou moins obsolètes comme Windows XP, Android 2.3, etc.) ont intérêt à être tolérant.
Mais les MX, qui sont essentiellement contactés par d’autres serveurs (c’est quand la dernière fois que vous avez envoyé un mail en contactant directement le MX de votre correspondant depuis votre propre poste, sans passer par un relai ?) peuvent probablement se permettre d’être moins laxistes, du moins d’après mes observations.
Mon propre MX est noté A, et dans mes logs je constate que la plupart des connections entrantes sont bien chiffrées, et que celles qui ne le sont pas viennent de serveurs qui n’ont dès le départ même pas tenté de négociation TLS.
Je ne saisi pas pourquoi le site teste startTLS alors que ce n'est pas la seule méthode de connexion (TLS) chiffré.
Parce que c’est ce qui compte vraiment quand tu veux envoyer un mail à une destination quelconque.
Le comportement classique d’un serveur à qui on demande de transférer un mail à alice@example.org est de contacter la machine mentionnée dans le MX de example.org, sur le port 25. Je ne pense pas que beaucoup de serveurs prennent le temps d’essayer une connection sur le port 465 pour voir si une une connection chiffrée (SMTP-over-TLS) serait disponible par là.
SMTP-over-TLS n’est guère utilisable qu’entre des machines qui se connaissent, et qui savent qu’elles doivent se contacter sur le port 465.
bouyguestelecom.fr grade A 92% avec mail.messaging.microsoft.com et bouyguestelecom-fr.mail.protection.outlook.com (qu'es-ce que vient faire MS dans cette histoire) ??
Apparemment c’est Microsoft qui fournit le service de mail pour bouyguestelecom.fr :
À noter que Facebook a des données intéressantes sur le chiffrement SMTP et sur la validation des certificats en particulier.
Ce que je retiens notamment, c’est que ce qui dissuade de valider strictement les certificats n’est pas la proportion de certificats auto-signés (qui sont en fait négligeables contrairement à ce que je pensais, de même que les certificats signés par des CA non-reconnues), mais la proportion de certificats incorrects : dans 99.35% des cas (!), la validation stricte échoue parce que le nom mentionné dans le certificat ne correspond pas au nom du serveur.
(Du coup, avec autant de mauvais certificats qui traînent, tu peux être tranquille avec ton certificat auto-signé, les administrateurs ne sont pas près de pouvoir exiger des certificats valides…)
# TLS obligatoire ?
Posté par gouttegd . En réponse au journal Gmail cherche à pousser les autres fournisseurs de courriel à envoyer/recevoir de manière chiffrée. Évalué à 9.
Hum, non.
Si Google voulait rendre TLS obligatoire, il n’aurait qu’à configurer ses serveurs pour interdire les connexions en clair.
Cette étude sert plutôt à expliquer au contraire pourquoi ils ne peuvent pas le faire — à cause de la « longue traîne » de fournisseurs de messagerie (modestes individuellement, mais représentant collectivement une part non-négligeable du traffic) qui sont incapables d’utiliser TLS.
On peut toujours espérer que cette étude poussera quelques-uns de ces fournisseurs à se bouger et à améliorer leur prise en charge de TLS, mais je ne me fais pas beaucoup d’illusions.
[^] # Re: PGP
Posté par gouttegd . En réponse au journal Gmail cherche à pousser les autres fournisseurs de courriel à envoyer/recevoir de manière chiffrée. Évalué à 10.
Non, justement, elle ne s’intéresse qu’au chiffrement de point à point (du client au serveur, d’un serveur à un autre serveur, du serveur au destinataire). Et c’est le seul type de chiffrement auquel les fournisseurs de messagerie peuvent (et doivent) s’intéresser.
Le chiffrement de bout en bout, c’est de l’expéditeur au destinataire. Et par définition, ce ne peut être que du ressort des utilisateurs finaux.
Si c’est le fournisseur qui met en place l’utilisation de PGP, ce n’est pas du « bout en bout » — n’en déplaise à certains fournisseurs qui mettent en avant le fait qu’ils utilisent PGP sur leurs serveurs.
# Informer seulement
Posté par gouttegd . En réponse au message Prosélytisme efficace. Évalué à 7.
Pour ma part, ça fait longtemps que j’ai renoncé au prosélytisme. Ça n’a jamais marché. Au total, j’ai convaincu… une personne de passer aux logiciels libres, et encore elle était déjà intéressée quand je l’ai rencontrée, donc je ne suis même pas sûr d’avoir joué un quelconque rôle dans sa décision — au maximum, je l’ai seulement convaincu que le choix qu’elle était déjà en train de faire était le bon.
Je pense que la plupart des gens n’aiment pas qu’on tente de les convaincre. En tout cas, je n’aime pas qu’on tente de me convaincre.
Aujourd’hui, je me contente d’informer, de faire découvrir. Après, le choix appartient à mon interlocuteur. S’il choisit de continuer à utiliser des logiciels propriétaires, ben… c’est son choix et je n’ai rien à y redire. Au moins, je considère qu’il est déjà plus libre que lorsqu’il utilisait les mêmes logiciels propriétaires par défaut, simplement parce qu’il ne savait même pas qu’il existait autre chose.
(Je dis ça pour les logiciels libres, mais c’est tout aussi applicable à la question des GAFAM et autres services en ligne — là aussi, je me contente d’informer des problèmes potentiels, des risques, et des alternatives potentielles.)
Ce n’est peut-être pas plus « efficace » que le prosélytisme, mais au moins je ne passe pas pour le prêcheur d’une secte paranoïaque ou conspirationniste, pour le même résultat au final (et puis bon, le résultat de toute façon, quelle importance ? je n’ai pas quelqu’un qui me demande à la fin du mois « combien de personnes avez-vous convaincu ce mois-ci ? »).
Ah, au passage, si tu veux quand même continuer à essayer de convaincre, peut-être que ne pas mépriser tes interlocuteurs pourrait aider… (« puits sans fond d’ignorance et de jeunesse d’esprit », rien que ça ? et toi tu es un puits sans fond de sagesse et de maturité, je suppose ?)
[^] # Re: Un contrepoint
Posté par gouttegd . En réponse au journal [HS] Ils ont gagné cette bataille. Évalué à 4.
À voir… Il y en a déjà qui n’ont pas hésité à postuler que toute personne se rendant en Turquie était suspecte, sans considération pour les motifs du voyage ou l’existence de « raisons sérieuses de penser que etc. » :
Débat à l’Assemblée nationale, le 16 septembre 2014
[^] # Re: La question liberté sécurité
Posté par gouttegd . En réponse au journal [HS] Ils ont gagné cette bataille. Évalué à 5.
For the record, Benjamin Franklin n’a jamais écrit la fin de la phrase (« et finira par perdre les deux »), c’est une extrapolation.
La formule d’origine était précisément :
[^] # Re: Automatisme ?!?
Posté par gouttegd . En réponse au journal Let’s Encrypt en bêta : petit retour d’expérience. Évalué à 3.
Non mais là tu rêves éveillé…
D’une part, tout nouveau protocole (ou modification d’un protocole pré-existant comme TLS/X.509) nécessitant de modifier le code des serveurs et des clients a très peu de chance d’être mis en place, et s’il l’est ce ne sera pas avant plusieurs années. Il y a une inertie énorme, il suffit de voir le temps qu’il a fallu pour déployer TLS 1.2 — on trouvait encore il y a quelques mois beaucoup de serveurs ne supportant rien de mieux que SSL 3.0, obsolète depuis plus de quinze ans (il a fallu l’attaque POODLE pour donner un coup de pied dans la fourmillière).
D’autre part, des alternatives aux « bêtes certificats actuels », ou des méthodes pour combler leurs déficiences, il y en a déjà plusieurs. Au moins deux sont particulièrement dignes d’intérêt :
les certificats OpenPGP (RFC 6091), beaucoup plus flexibles que les certificats X.509 (ils peuvent notamment porter un nombre arbitraire de signatures, et la confiance en chaque signature n’est pas binaire) ;
l’épinglage des certificats (ou des clefs brutes, RFC 7250) dans le DNS (DANE, RFC 6698).
Ni l’un ni l’autre ne sont largement supportés. À ma connaissance, seule la bibliothèque GnuTLS implémente le RFC 6091, et aucun navigateur ne supporte nativement DANE (un plugin existe pour ceux qui le veulent).
Toute proposition de solution aura besoin de l’appui d’un poids lourd du web pour s’imposer, indépendamment de ses mérites. C‘est comme ça que seul Certificate Transparency, qui est activement poussé par Google, a une chance d’aller loin (et c’est malheureux, car c’est une fausse solution qui ne résoud aucun des problèmes de X.509).
[^] # Re: Automatisme ?!?
Posté par gouttegd . En réponse au journal Let’s Encrypt en bêta : petit retour d’expérience. Évalué à 7.
Même pas.
Le système actuel ne fournit aucune sécurité contre les attaques de type MITM. Il y a trop de moyens d’obtenir un certificat frauduleux qui sera accepté par le plus grand nombre. Trop d’autorités de certification (et encore plus de CA intermédiaires) à laquelle on accorde une confiance totale (X.509 ne connait rien d’autre que la confiance complète) et aveugle.
Tu peux bien obtenir un certificat à validation étendue (EV) en payant très cher une CA irréprochable (admettons qu’une telle CA existe)… ça n’empêchera pas un attaquant d’obtenir un certificat frauduleux pour ton domaine auprès de l’une quelconque des milliers de CA ou CA intermédiaires malhonnêtes ou incompétentes — et ce certificat sera accepté comme valide par les clients.
Les CA ne servent à rien. Tout le monde le sait, mais tout le monde fait semblant de l’ignorer.
Ce n’est que pour se protéger des attaques actives de type MITM que l’on a besoin d’autorités de certification (contre les attaques passives, un certificat auto-signé est suffisant, nul besoin de CA), et c’est précisément contre ce type d’attaque qu’elles n’apportent aucune garantie…
Ça fait longtemps que la mienne est complètement détruite.
[^] # Re: Automatisme ?!?
Posté par gouttegd . En réponse au journal Let’s Encrypt en bêta : petit retour d’expérience. Évalué à 3.
Que le client a bien la main sur le domaine pour lequel il demande un certificat, comme expliqué ici.
C’est peu ou prou la même chose que ce que font les autres CA pour délivrer des certificats domain-validated, juste un peu plus automatisé.
[^] # Re: Durée courte
Posté par gouttegd . En réponse au journal Let’s Encrypt en bêta : petit retour d’expérience. Évalué à 6.
Là ce n’est pas le protocole ACME qu’il faut changer, mais le format des certificats. Un certificat X.509 ne peut pas porter plusieurs signatures.
Pour ça, il y a l’épinglage de certificats dans les en-têtes du serveur web (déjà implémenté dans la plupart des navigateurs) et/ou dans le DNS.
[^] # Re: Quelqu'un a-t-il lu quelque chose là-dessus?
Posté par gouttegd . En réponse au journal Paris sous les balles. Évalué à 8.
C’est qui ou quoi cette « Sécurité européenne » qui décide comme ça d’envoyer un rapport (probablement confidentiel puisque personne d’autre n’en a connaissance) au premier blogueur venu ?
Une attaque a fait s’écrouler nos réseaux mobiles pendant 48 heures et personne (à part bien sûr la Sécurité européenne) ne s’est rendu compte de rien… D’ailleurs, les Parisiens n’ont pas du tout utilisé leurs téléphones portables pour s’informer de la situation vendredi soir.
Bizarremment, dès qu’on parle d’une attaque informatique on dit toujours qu’elle est « très sophistiquée »…
Sans détails sur la (pseudo-)attaque en question, cette affirmation est totalement gratuite. Ainsi que tout le paragraphe qui suit d’ailleurs.
« 13-November was an inside job » — Je me demandais au bout de combien de temps on allait la voir arriver, celle-là…
Ben voyons. Et pourquoi donc ? Pourquoi ne pas divulguer ce fameux rapport ?
# Il y a longtemps
Posté par gouttegd . En réponse au sondage J'utilise les touches "Arrêt Défil" et/ou "Pause/Attn". Évalué à 7.
À l’époque où j’étais encore sous Windows, je n’ai utilisé qu’un seul programme qui se servait de ces touches… et c’est moi qui l’avais écrit !
J’avais choisi ces touches précisément parce que je ne m’en servais jamais pour autre chose.
[^] # Re: Hello et version mobile
Posté par gouttegd . En réponse à la dépêche Firefox ? 42 !. Évalué à 5.
Attention avant de conseiller Skype sur Android… Les dernières versions ont un (gros) bug qui le rend complètement inutilisable sur cet OS (ou certaines versions de l’OS, au moins) : impossible de recevoir un appel sitôt que l’application n’est plus en avant-plan ou que l’appareil passe en veille.
Skype, « le truc qui marche partout, passe partout » ? Pas tant que ça, non.
[^] # Re: Hello et version mobile
Posté par gouttegd . En réponse à la dépêche Firefox ? 42 !. Évalué à 8.
Manifestement, il l’est. Les administrateurs ont réussi à le bloquer dans mon ancien institut.
D’après ce que j’ai compris, ils ont profité d’une remise à niveau du réseau pour installer des routeurs capables de faire du « Deep Packet Inspection » ciblant spécifiquement Skype.
(Le sysadmin avait expliqué la chose à peu près en ces termes : « On a installé des nouveaux routeurs qui détectent et bloquent le traffic Skype. Ça faisait déjà plusieurs années que Skype était interdit, la différence c’est que maintenant on applique l’interdiction. »)
[^] # Re: A l'install
Posté par gouttegd . En réponse au journal Intégrer Mediainfo à Thunar (XFCE). Évalué à 6.
Oui. Le plugin UCA de Thunar date au moins de 2006, la spécification DES-EMA de 2009.
(Au passage, DES-EMA n’est pas un standard FDO, c’est une proposition indépendante, qui ré-utilise et étend le format DES de freedesktop.org.)
Et avant que quelqu’un ne dise « donc ce sont les auteurs de DES-EMA qui souffrent du NIH syndrome, pourquoi n’ont-ils pas repris le format déjà utilisé par le plugin UCA ? » :
[^] # Re: A l'install
Posté par gouttegd . En réponse au journal Intégrer Mediainfo à Thunar (XFCE). Évalué à 4.
Je t’ai indiqué la (proposition de) spécification qui semble supportée par le plus grand nombre de DE (dont les deux plus « gros ») et même par au moins un explorateur de fichier indépendant de tout DE.
Si tu veux être le plus accommodant pour tes utilisateurs Linuxiens (ce qui est tout à ton honneur), je pense que la meilleure chose à faire est d’implémenter cette spécification (c’est-à-dire, fournir un fichier .desktop inspiré de celui que j’ai posté plus haut).
Personne ne t’oblige à « supporter tous les 0.1% de DE Linux », et je suis convaincu que personne ne te reprochera de ne pas fournir une custom action pour l’explorateur de XFCE¹ — et si quelqu’un le fait, tu sais quoi répondre : « pas mon affaire, moi j’ai fait ce qu’il fallait, plaignez-vous auprès des développeurs de votre DE / envoyez-leur un patch / changez de DE ».
¹ De toute façon, le mode de fonctionnement du plugin UCA de Thunar (responsable des custom actions) ne semble clairement pas conçu pour permettre d’ajouter/enlever/modifier automatiquement des actions, lors de l’installation d’un paquetage par exemple (contrairement au principe de la spécification DES-EMA). Donc on ne peut pas te reprocher de ne pas faire ce que Thunar ne permet pas de faire.
[^] # Re: Mon avis
Posté par gouttegd . En réponse au journal Hommage aux Hackers moins-connus. Évalué à 3.
Vu que les posters sont publiés sur une page web (et non pas seulement affichés en classe), ils ne sont pas uniquement destinés à des étudiants français. Francophones à la limite, mais pas français.
(D’ailleurs, si le nom de domaine est d’une quelconque indication, même dans la salle de classe de l’auteur les étudiants ne sont pas français mais belges.)
Même en ne ciblant que la francophonie, est-ce que tous les pays francophones utilisent le format JJ/MM/AAAA ? Je n’en mettrais pas ma main à couper (rien qu’au Québec, par exemple…), d’où l’intérêt d’un format standard.
[^] # Re: Mon avis
Posté par gouttegd . En réponse au journal Hommage aux Hackers moins-connus. Évalué à 6.
Il ne s’agit pas ici du format anglo-saxon (MM-JJ-AAAA) mais du format ISO (AAAA-MM-JJ).
Et je vois pour ma part au moins deux avantages à ce dernier :
il évite les ambiguités du genre 01-03-2015, qui peut représenter le 1er mars 2015 ou le 3 janvier selon le format utilisé (non, le contexte ne suffit pas toujours à trancher) — 2015-03-01 sera toujours le 1er mars, parce que personne n’utilise un format AAAA-JJ-MM ;
trier des dates ISO dans l’ordre lexicographique revient aussi à les trier dans l’ordre temporel (2014-01-03 est avant 2015-03-01).
[^] # Re: A l'install
Posté par gouttegd . En réponse au journal Intégrer Mediainfo à Thunar (XFCE). Évalué à 5.
Euh, chez moi (Thunar 1.6.3), les custom actions de Thunar sont enregistrées dans un fichier
$XDG_CONFIG_HOME/Thunar/uca.xml, dans un format propre à Thunar. Et le même Thunar ne tient aucun compte de ce qui se trouve dans$XDG_DATA_DIRS/file-manager/actions.[^] # Re: A l'install
Posté par gouttegd . En réponse au journal Intégrer Mediainfo à Thunar (XFCE). Évalué à 9.
Pour ça, il y a la (proposition de) spécification DES-EMA.
Il faut ajouter un fichier
.desktopdans$XDG_DATA_DIRS/file-manager/actions. Quelque chose comme ça (non testé pour cet exemple précis) :Mais il ne semble pas que XFCE/Thunar prenne en charge cette spécification, malheureusement. Nautilus et Konqueror le font, apparemment, de même que PCManFM (pour ce dernier j’en suis sûr, vu que c’est ce que j’utilise).
# Password Hashing Competition
Posté par gouttegd . En réponse au message Y a-t-il des cryptographes dans la salle? Stockage de mots de passe. Évalué à 3.
Pour information, le concours Password Hashing Competition, qui visait à sélectionner une fonction de condensation de mot de passe (sur le modèle des concours qui ont sélectionné AES et SHA-3), a annoncé cet été avoir choisi l’algorithme Argon2.
Une implémentation de référence est en cours de développement.
[^] # Re: Chiffrement opportuniste
Posté par gouttegd . En réponse au journal Chiffrement de SMTP, une obligation?. Évalué à 3.
Pour info, le RFC 7672 spécifie que la seule existence d’enregistrements TLSA pour un serveur mail suffit à indiquer que TLS est obligatoire pour contacter ledit serveur (section 2.2, “TLS Discovery”).
Postfix implémente ce comportement avec
smtp_tls_security_level = dane(Victor Dukhovni, co-auteur du RFC, est un des développeurs de Postfix).[^] # Re: Outil de test + STARTTLS
Posté par gouttegd . En réponse au journal Chiffrement de SMTP, une obligation?. Évalué à 3.
L’inverse me semblerait plus logique…
Les serveurs de soumissions, qui sont directement contactés par les utilisateurs finaux (et donc potentiellement une large gamme de systèmes plus ou moins obsolètes comme Windows XP, Android 2.3, etc.) ont intérêt à être tolérant.
Mais les MX, qui sont essentiellement contactés par d’autres serveurs (c’est quand la dernière fois que vous avez envoyé un mail en contactant directement le MX de votre correspondant depuis votre propre poste, sans passer par un relai ?) peuvent probablement se permettre d’être moins laxistes, du moins d’après mes observations.
Mon propre MX est noté A, et dans mes logs je constate que la plupart des connections entrantes sont bien chiffrées, et que celles qui ne le sont pas viennent de serveurs qui n’ont dès le départ même pas tenté de négociation TLS.
[^] # Re: Postfix
Posté par gouttegd . En réponse au journal Chiffrement de SMTP, une obligation?. Évalué à 8.
Pourquoi ne pas plutôt utiliser smtp_tls_policy_maps, qui (avec Postfix ≥ 2.3) sert à précisément à ça ?
[^] # Re: starttls.info
Posté par gouttegd . En réponse au journal Chiffrement de SMTP, une obligation?. Évalué à 4.
Parce que c’est ce qui compte vraiment quand tu veux envoyer un mail à une destination quelconque.
Le comportement classique d’un serveur à qui on demande de transférer un mail à alice@example.org est de contacter la machine mentionnée dans le MX de example.org, sur le port 25. Je ne pense pas que beaucoup de serveurs prennent le temps d’essayer une connection sur le port 465 pour voir si une une connection chiffrée (SMTP-over-TLS) serait disponible par là.
SMTP-over-TLS n’est guère utilisable qu’entre des machines qui se connaissent, et qui savent qu’elles doivent se contacter sur le port 465.
Apparemment c’est Microsoft qui fournit le service de mail pour bouyguestelecom.fr :
[^] # Re: Chiffrement opportuniste
Posté par gouttegd . En réponse au journal Chiffrement de SMTP, une obligation?. Évalué à 4.
À noter que Facebook a des données intéressantes sur le chiffrement SMTP et sur la validation des certificats en particulier.
Ce que je retiens notamment, c’est que ce qui dissuade de valider strictement les certificats n’est pas la proportion de certificats auto-signés (qui sont en fait négligeables contrairement à ce que je pensais, de même que les certificats signés par des CA non-reconnues), mais la proportion de certificats incorrects : dans 99.35% des cas (!), la validation stricte échoue parce que le nom mentionné dans le certificat ne correspond pas au nom du serveur.
(Du coup, avec autant de mauvais certificats qui traînent, tu peux être tranquille avec ton certificat auto-signé, les administrateurs ne sont pas près de pouvoir exiger des certificats valides…)