🚲 Tanguy Ortolo a écrit 12334 commentaires

Je suppose qu'il n'y a pas de "Focus Follows Mouse"

Argh, si c'est le cas, décidément, ce n'est pas demain que je passerai à Wayland. Mais bon, ça doit dépendre du compositeur ça, et de toute façon, si je passe à Wayland, ce sera pour un compositeur pavant, pas pour celui de Gnome. :-)

Ce n'est pas tant que cette option soit désactivée, c'est simplement que ça n'a pas de sens sans réglage.

Il y a une notion de pointeurs et de claviers maîtres, qui sont affichés et exposés aux logiciels. Grossièrement, un pointeur maître, c'est une flèche à l'écran, et un clavier maître, c'est un curseur de saisie.

Ces périphériques maîtres sont associés par deux, un pointeur et un clavier maître à chaque fois.

À côté de cela, il y a les périphériques réels, dits asservis, qui sont tous attachés à un périphérique maître. Quand on bouge une souris physique, ça envoie les événements correspondants au pointeur maître auquel elle est attachée. De même, quand on appuie sur une touche d'un clavier, ça envoie l'événement correspondant au clavier maître auquel il est attaché.

Par défaut, il y a une seule paire de périphériques maîtres, donc un pointeur maître et un clavier maître associé, et tous les périphériques réels y sont attachés, afin que quand on bouge un souris, ça bouge le pointeur à l'écran, et que quand on tape sur un clavier, ça écrive dans la zone de saisie qui a le focus. Par exemple, chez moi :

% xinput
⎡ Virtual core pointer                        id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ Logitech USB-PS/2 Optical Mouse           id=10   [slave  pointer  (2)]
⎣ Virtual core keyboard                       id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard                 id=5    [slave  keyboard (3)]
    ↳ Power Button                                id=6    [slave  keyboard (3)]
    ↳ Power Button                                id=7    [slave  keyboard (3)]
    ↳ Logitech USB Keyboard                       id=8    [slave  keyboard (3)]
    ↳ Logitech USB Keyboard                       id=9    [slave  keyboard (3)]
    ↳ Yubico Yubikey NEO OTP+CCID                 id=11   [slave  keyboard (3)]

À partir de là, on peut s'amuser à détacher des périphériques physiques : leurs événements ne sont alors plus transmis nulle part. Attention, c'est un bon moyen de se blo

On peut créer une nouvelle paire de périphériques maîtres, et y attacher des périphériques (si on a effectivement plusieurs souris, tablettes graphiques, joysticks et claviers, sinon ça ne sert à rien) : à l'écran, ça donne un pointeur supplémentaire, et potentiellement un focus de saisie supplémentaire.

Pour en revenir sur ce que je disais au début, en fait XInput est activé par défaut, seulement avec la seule configuration raisonnable et non troublante : tous les pointeurs et tous les claviers sont fusionnés.

Parmi les apports intéressants de Wayland, nous pouvons noter la gestion de pointeurs multiples : chaque périphérique de pointage est indépendant avec son propre pointeur (et même une icône de pointeur différente), contrairement à X où tous les périphériques se partageaient un pointeur unique.

D'où sort cette affirmation ? Avec XInput, on peut tout à fait avoir plusieurs pointeurs, et plusieurs claviers d'entrée bien distincts ! Ça se comporte certainement de façon étrange pour des logiciels qui ne sont pas prévus pour cela, mais côté serveur X, c'est prêt.

Le choix de faire reposer par défaut GNOME sur Wayland a été différé à de nombreuses reprises… Le travail d’intégration est achevé et GNOME-Wayland est à présent comparable en termes de fonctionnalités à GNOME-X11.

Est-ce à dire que le copier-coller à la souris a finalement été implémenté ? Parce que sans ça, il y a toute une catégorie d'utilisateurs, notamment de développeurs, qui ne passeront pas à Wayland.

IPv6 c'est l'opérateur qui décide, pas moi.

Mais libre à toi de choisir un fournisseur d'accès à Internet v6 à utiliser par-dessus ton accès à Internet v4. C'est à mon avis bien plus simple à mettre en place que du double NAT ou des vues DNS.

Note qu'IPv6 ne résous en rien le "le webservice doit pouvoir fonctionner même si couper d'internet (donc nom de domaine HS et pas moyen de mettre a jour le certificat)".

Comment ça nom de domaine HS ? Si tu as un de tes serveurs de nom chez toi, coupé d'accès à Internet, tu peux toujours résoudre tes noms. Pas les autres noms, mais les noms de ta zone DNS, si.

HPKP et DANE font parti de la stack X.509 et assimilé. DNSSec devrait être déployé partout (98% de MitM mail si tu es en Turquie à cause de ce manque…)
Une CA doit permettre de les respecter.
Sinon c’est juste une « yet another plain old CA ».

Eh bien, tout va bien alors, Let's Encrypt est une CA moderne, parce qu'ils ne posent aucun problème avec HPKP et DANE. Avec HPKP, c'est la clef publique qui est épinglée. Avec DANE, tu as le choix, donc tu peux épingler la clef publique. Il suffit, tous les 90 jours, de changer, non pas de clef et de certificat, mais seulement de renouveler le certificat avec la même clef, et ça roule, rien à changer pour HPKP ni DANE.

Ah, c'est vrai, ta religion t'impose d'épingler le certificat et de changer de clef tous les 90 jours, c'est ça ?

Et ça casse tout l’intérêt de DNSSec si tes clefs sont dispos sur une machine accessible depuis le net.

N'importe quoi. Ça permet certaines attaques qui sans cela seraient impossibles, mais ça conserve au contraire une bonne partie de l'intérêt de DNSSEC, à savoir de rendre la falsification de réponses DNS beaucoup plus difficile. Sans DNSSEC par exemple, contrôler un bout du lien entre le client et un serveur de nom faisant autorité pour une zone donnée suffit à changer les réponses pour ce qu'on veut. Avec DNSSEC, ce n'est plus possible, il faut avoir accès à la clef de signature de la zone.

Encore une fois, il y a une solution simple (IPv6 et pas de NAT), et d'autres solutions compliquées, c'est au choix.

En général, on est plutôt sur du 2048-bit pour les KSK et 1024-bit pour les ZSK — et encore, la tendance est à la généralisation du 2048-bit même pour la ZSK (par exemple, la nouvelle ZSK 2048-bit de la racine vient d’être pré-publiée, et devrait bientôt entrer en service).

Quand on n'utilise pas franchement des algorithmes à courbe elliptiques, qui permettent de réduire considérablement la taille des enregistrements pour une sécurité identique, voire supérieure.

C’est d’ailleurs la principale raison d’avoir une ZSK et une KSK séparées (non, ça non plus ce n’est pas « imposé » par DNSSEC).

Il y a une autre raison : il est beaucoup plus facile de changer de ZSK que de KSK, cette dernière devant être déclarée au bureau d'enregistrement, ce qui s'automatise assez mal.

Question : en IPv6 le problème du hairpinning disparaîtra?

Oui, puisqu'il n'y aura pas de NAT. Le nom de domaine de ton serveur résoudra sur son adresse IPv6, qui sera joignable depuis l'intérieur comme depuis l'extérieur.

Question annexe : quand on sera en IPv6, comment je fais pour trouver l'adresse IP d'un raspberry pi fraîchement installé? (actuellement j'utilise nmap 192.168.1.2-254 en IPv4 local mais si j'ai bien compris ça ne fonctionnera plus en ipv6)

C'est un peu hors sujet, parce que récupérer l'adresse d'un truc qu'on vient d'installer, c'est plutôt une question pour ceux qui ont fait la procédure d'installation. Tu peux toujours faire un nmap sur le sous-réseau IPv6, même si ça risque d'être un peu plus long. Il y a sans doute des outils plus appropriés ; personnellement, si un mDNS est installé sur cette nouvelle machine :

apt-get install libnss-mdns
getent ahostsv6 hostname.local

Dans ce cas, tunnel. Avec SixXS par exemple.

Depuis l'Intérieur (LAN)
- tu retentes comme en WAN avec https://www.monDomaine.be mais la le routeur de ton FAI a beaucoup de chance de ne pas être compatible hairpinning, si tu peux le changer par un autre (ce qui n'est pas mon cas!), t'as bien de la chance
-donc tu veux que sa fonctionne quand même

donc tu passe en IPv6.

À noter qu'avec Let's Encrypt, s'il est nécessaire de changer de certificat au moins tous les 90 jours, et qu'il est en pratique recommandé de le faire tous les 2 mois, il n'est nullement nécessaire de changer aussi souvent de clef. Le client officiel, Certbot, génère effectivement une nouvelle clef à chaque fois, mais ce n'est pas obligatoire, et d'autres implémentations permettent de renouveler les certificats existants à la place.

Compte tenu de ceci, si veut limiter la fréquence des changements, il est pertinent de procéder à des renouvellements sans changer de clef. Si on veut également mettre en place HPKP et DANE, on peut alors épingler non pas le certificat, qui changera tous les deux ou trois mois, mais la clef publique, qui demeurera tant qu'on ne l'aura pas manuellement changée.

Ainsi, si la récupération des certificats a lieu sur une machine donnée, celle-ci n'a plus besoin de pouvoir mettre à jour des enregistrements DNS, seulement de fournir les certificats renouvelés aux serveurs qui les utiliseront.

En suivant la recommandation de renouvellement tous le deux mois, cela laisse une marge d'un mois pour que les serveurs les récupèrent, ce qui peut très bien se faire de façon tirée, sans aucune synchronisation. Personnellement, je recommanderais d'aller chercher les éventuelles mises à jour toutes les semaines.

Maintenant, on peut avoir des raisons personnelles pour ne pas vouloir telle ou telle étape de ce système, par exemple parce qu'on n'aime pas PKIX-EE ou DANE-EE avec SPKI (cf. http://www.bortzmeyer.org/7218.html), mais ce sont là des contraintes qu'on s'impose, et en aucun cas des raisons de blâmer Let's Encrypt.

En clair, si tu veux changer de clef à chaque fois, et utiliser HPKP et DANE, oui, il va falloir mettre à jour des trucs qui, sans cela, auraient pu être laissés, mais c'est ton choix, donc ton problème. Et si tu veux épingler, non pas la clef, mais le certificat ou l'AC, il va aussi falloir mettre à jour des trucs, mais encore une fois, c'est ton choix, donc ton problème, pas celui de Let's Encrypt.

Pas de chance son mécanisme est trop compliqué pour l'utilisateur lambda qui veut se faire auto héberger son blog ou un owncloud.

Mais non. C'est trop compliqué pour l'utilisateur qui veut héberger son blog sur un système distribué et redondant pour avoir une haute disponibilité. Or ça, excuse-moi mais c'est tout sauf un utilisateur lambda. Et accessoirement, ce n'est pas de l'auto-hébergement, à moins d'avoir plusieurs maisons.

Pire il est tout simplement incompatible avec l'auto hébergement

Je ne devais pas être au courant de ce détail, c'est pour ça que j'ai pu réussir à l'utiliser. Et sans problème, je dois dire.

On ne peut donc pas critiquer quelque chose de gratuit, surtout si ce quelque chose ne possède pas d’alternative

S'il ne possède pas d'alternative, ce n'est pas leur faute, c'est seulement que personne n'en a proposé. Au boulot, donc.

(et qu'il est imposé)?

Décidément, c'est une manie…

Un des buts de Let's Encrypt étant de favoriser l'automatisation, ça n'arrivera pas.

Vu tes idées et ton goût pour la maintenance manuelle, je suggérerais plutôt de monter une alternative à Let's Encrypt, proposant le même service mais sans le but d'automatisation.

Par exemple les empreintes HPKP ou TLSA doivent être mise-à-jour en même temps que les certificats sur les HTTPd frontaux ou sur le postfix.

Je ne connais pas les détails d'HPKP, ne m'y étant pas intéressé parce que cette idée me semble foireuse, mais concernant TLSA, il me semble qu'on peut avoir plusieurs enregistrements à la fois, ce qui résoudrait le problème ici : au renouvellement du certificat, ta machine de la mort ajoute un TLSA, et ensuite les serveurs ont un mois pour tirer le nouveau certificat avant que le précédent expire. Lorsqu'il expire, la machine de la mort retire l'ancien TLSA.

Pour sécuriser encore plus cela, et éviter que ta machine de la mort ait la main sur tout le DNS, tu peux au choix :

• mettre en place un système de mise à jour dynamique du DNS, avec une clef pour cette machine de la morte, qui n'autorise qu'à mettre jour les enregistrements TLSA ;
• mettre en place un système tiré également, ou une autre machine dédiée au DNS irait récupérer le nouveau certificat puis l'utiliser pour construire un nouveau TLSA et l'ajouter.

Oui, c’est un problème. Actuellement, pour pouvoir pousser sur mon infra, je me retrouve avec une machine en DMZ avec un HTTPd dessus (pour le challenge ACME), contenant l’ensemble de mes clefs privées, CSR et certificats, avec une clef SSH root sans mot de passe permettant l’accès à la totalité de mon parc (HTTPd content + reverse, HA proxy, postfix/dovecot, jabber… nécessaire pour scp les clefs/certificats + restart des services associés), devant rester allumée la majorité du temps (quand tu gères une 100aine de certificats avec 90j de renew, tu en as au moins 1 par jour à être renouvelé), y compris au shadow master DNSSec (pour pouvoir changer les TLSA et resigner la zone) et à mes config HTTPd (pour les empreintes HPKP).

Eh bien, ça confirme que cette difficulté d'automatisation tient à ton infrastructure particulière, pas aux caractéristiques du service de Let's Encrypt.

Personnellement, à ta place je mettrais en place un système tiré. Tous les deux mois, ta machine spéciale fait signer et récupère un nouveau certificat, et toutes les semaines par exemple, tes machines tirent le certificat et relancent ou rechargent d'elles-mêmes leurs services. Si tu veux faire plus fin, elles peuvent ne relancer ou recharger leurs services que si le certificat a changé et après vérification de sa validité. Ça n'a pas besoin d'être spécialement synchronisé. Avec ce système, ta machine de la mort n'a plus d'accès root pour faire n'importe quoi, seulement moyen de filer de la merde comme certificat, ce qui est infiniment plus facile à résoudre en cas de problème, et rien de plus.

Si tu préfères faire ça à la main une fois par an, tu n'es pas obligé de te fournir chez Let's Encrypt. Et ce n'est pas une raison pour leur reprocher… pour leur reprocher quoi, au juste ?

Non. Je me retrouve à 1- utiliser LE, à désactiver la moitié de ses features et paramètres par défaut, pinner sur la clef ou 2- utiliser LE, pinner sur le cert, avoir la fucking machine de l’horreur en prod et en DMZ ou 3- utiliser LE, pinner sur le cert, ne pas pouvoir automatiser complètement (TLSA non pris en charge de manière sécurisée).

Lapin compris.

Non. L’automatisation avec LE implique une BAISSE de la sécurité globale de ton système. Uniquement par le fait du renouvellement du certificat à 90j. Ils le mettraient à 1 an, je pourrais automatiser complètement de manière sécurisée (avec certes un lancement humain de la procédure chaque année).

Comme je l'indique plus haut, tu peux l'automatiser, seulement tu as choisi de bouder cette possibilité pour des raisons qui t'appartiennent. C'est ton choix, donc tu ne peux pas en blâmer Let's Encrypt.

Ça protège plus que juste sur la clef. Un pin sur le certificat empèchera par exemple une interception MitM via un faux certificat généré avec la même clef.

Donc dans le cas ou un pirate aurait volé la clef sur ton serveur, mais n'aurait pas été capable de récupérer le certificat lui-même, pourtant public puisque non seulement présent sur ton serveur avec des permissions d'accès au moins aussi larges, mais en plus fourni à chaque connexion TLS.

Si tout l'intérêt de l'épinglage par certificat, c'est de se prémunir contre ce cas inexistant, autant dire que ça ne sert à rien.

Ce n’était pas le cas de certbot (à l’époque en tout cas) : il ne renouvellait que le certificat, et demandait à l’utilisateur d’embarquer en dur la chaîne intermédiaire (générée au 1er appel de certbot).

Mauvais client ACME, changer client ACME.

Et même pour ceux qui avait automatisé à mort, ils se sont retrouver avec 2 chaînes différentes (les certificats pas encore renouvelés et ceux fraîchement renouvelés), mais un seul chain.pem utilisé pour tous les vhosts via SSLCertificateChainFile (ça a donné pas mal de soucis en pratique en tout cas.)

Pareil, mauvais client ACME, changer client ACME. Sérieusement, récupérer le certificat intermédiaire automatiquement, mais le mettre au même endroit pour tous les certificats, c'est une grossière erreur de conception, à corriger ou à faire corriger.

Tirer, ça pose les problèmes de synchronisation. Il faut tiré pile après avoir renouvelé, et depuis toutes les machines en même temps pour éviter les problèmes de certificats pas identiques entre les machines.

Eh bien pousse, dans ce cas. Ah oui, mettre à jour un fichier sur un serveur ça demande d'avoir un accès en écriture dessus ? Et c'est censé être un problème ‽ Mais c'est normal ça, tu voudrais quoi d'autre ? Franchement, je ne comprends pas l'argument, là.

Et mon archi n’est pas compliquée, c’est le b.a-ba d’une infra correcte aujourd’hui (virtualisation, dual stack ipv4 (reverse proxy)-ipv6 (direct access), HA proxy…)

Eh bien, si ce n'est pas compliqué, il n'y a pas de problème. Tu veux que ce soit géré de façon automatique, automatise-donc sa gestion, mais ne te plains pas que Let's Encrypt ne le fasse pas pour toi : ils permettent de récupérer le certificat automatiquement, ce que tu en fais, ça te regarde.

Si tu changes de pin, il faut mettre à jour les entrées TLSA. Ce qui est encore plus compliqué à mettre en place que de tirer les certificats…

Ça, c'est toi qui voies ce que tu veux épingler avec TLSA. Si tu épingles la clef, tu peux faires des renouvellements sans changement de clef, et ne rien changer dans le DNS. Si tu épingles le certificat, forcément, tu doit faire un changement dans le DNS, mais ce n'est pas la faute de Let's Encrypt, seulement une conséquence de tes choix d'administrateur. Et si c'est compliqué à automatiser dans ton cas, tout ce que ça indique, c'est que tu as une architecture qui n'est gérée que de façon partiellement automatisée.

Dans tous ces cas, les problèmes que tu soulèves ne viennent pas de Let's Encrypt, qui font simplement, à peu de chose près, ce qui peut se faire de mieux, à savoir automatiser l'émission et la récupération de certificats. Intégrer ça sur un serveur tout simple, c'est trivial, intégrer ça dans une architecture plus complexe, eh bien c'est plus complexe, mais toujours automatisable quand on s'en donne les moyens. Et dans tous les cas, c'est toujours mieux que le processus manuel avec les autres autorités de certification.

• Passage de l’intermédiaire X1 à X3, ce qui a cassé toutes les chaînes de certificats (si vous aviez HSTS actif, ça a signifié l’impossibilité totale pour vos visiteurs de se connecter à votre site, il n’y a plus de bouton « Continuer quand même » sur l’alerte de sécurité dans ce cas).

Pourquoi veux-tu que ça casse quoi que ce soit ? Le protocole ACME, et son implémentation par Let's Encrypt, fournit l'URL certificat intermédiaire lors de l'émission du certificat. Un client ACME bien fichu doit pouvoir l'utiliser, et n'a aucune raison de dépendre d'un certificat intermédiaire donné : s'il change, il récupère le nouveau et tout marche comme sur des roulettes.

• Gestion du multi-frontal, par exemple un HA proxy ou de la virtualisation (comment je pousse le même certificat et clef sur tout le parc sans avoir un god-master root en DMZ sur tout mon parc ie le 7ème cercle de l’enfer)

Eh bien tu ne le pousse pas, tu le tires. Sérieusement, c'est un problème qui n'est pas du tout lié à Let's Encrypt : tu as une architecture compliquée, eh bien c'est compliqué à maintenir à la main, et compliqué à automatiser, c'est dur, mais c'est la vie.

• Gestion impossible ou extrêmement complexe de HPKP et pire de DANE/TLSA

Pour HPKP, c'est peut-être parce que l'idée même d'épingler un certificat est une belle connerie, qui est vouée à se retourner contre l'administrateur au moindre changement, et pour rappel, des changements, ça arrive de façon systématique et prévue, mais aussi de façon imprévue, hein.

Quant à DANE, je ne vois pas en quoi Let's Encrypt empêche ou complique excessivement quoi que ce soit.

• Pas de support de IPv6 jusqu’à très récemment

Génial l'argument : Let's Encrypt c'est nul parce qu'avant ça ne faisait pas telle chose. (Bon, maintenant ça le fait, mais avant ça ne le faisait pas, donc c'est trop nul quand même.)

• Impossibilité de récupérer le certificat racine automatiquement

Ça n'a pas été prévu en effet. Mais ça n'est pas pire que la concurrence, qui ne permet même pas de récupérer l'intermédiaire automatiquement.

Et accessoirement, en fait tu peux tout à fait récupérer le certificat racine automatiquement : le certificat intermédiaire est fourni, et une fois que tu l'as, tu peux chercher l'URL de CA Issuers, qui permet de télécharger le certificat racine.

Ce n'était pas une guerre de robots, mais j'eus un jour une expérience amusante avec un bot sur Wikipédia. Je cherchais alors les paroles de la chanson Cadet Rousselle, et de fil en aiguille, je m'égarai fort naturellement sur la page consacrée à sa parodie Bali Balo. Y ayant constaté des erreurs, je les corrigeai derechef. Cinq minutes plus tard, je recevais un message privé, expliquant que ma modification avait été annulée par je ne sais quel bot, qui l'avait identifiée comme du vandalisme, au motif qu'elle… était pleine de grossièretés.

Et il émule la mémoire sur la Flash SD ?

Argh.

Non, ce n'est pas totalement inexploitable. Si tu notes les connexion, tu auras les adresses MAC dedans. Pour les besoins d'une enquête sur quelque chose de sérieux, la police notera sans doute les adresses MAC des équipements des suspects, et le log des connexions pourra alors leur être utile. Sauf usurpation, mais ça c'est vrai pour tout, même pour un registre d'hôtel en fait.

D'accord pour ce mode d'utilisation de PayPal, qui revient en somme à avoir un autre compte courant et un moyen de paiement dédié.

Mes critiques visent le mode d'utilisation de PayPal avec enregistrement des informations de carte bancaire.