Stéphane Bortzmeyer a écrit 664 commentaires

Ce qui prouve que Python n'utilise pas la catégorie Unicode Lettre puisque ce caractère, U+1F464 BUST IN SILHOUETTE, a la catégorie Symbole, comme tous les émojis. (Mauvaise idée de Python, à mon avis.)

La date du 21 janvier ne semble plus d'actualité, la négociation se passant mal. Donc, tout cela est repoussé mais pas annulé, donc la lutte contre cette directive continue.

L'épinglage de clé publique ? Ya encore des gens qui utilisent ça ? C'est très casse-gueule, surtout avec Let's Encrypt.

Quant à TLS+HSTS, oui, les navigateurs vérifient mais les apps et autres logiciels ne le font pas forcément.

J'avais oublié quelques trucs intéressants. D'abord, beaucoup de registres de noms de domaine ont une solution nommée « verrouillage » (ou « lock » en anglais) qui permet d'empêcher toute modification d'un domaine (l'éventuel déverrouillage nécessitant une opération manuelle, avec vérification). Cela coûte de l'argent, mais cela aurait sans doute protégé linux.org.

Ensuite, l'AFNIC aussi a une documentation sur la sécurité de vos noms de domaine.

Référence ?

On n'est pas forcé de croire l'ICANN au pied de la lettre : depuis des années, des serveurs whois sont conformes (le RGPD ne date pas d'aujourd'hui) https://twitter.com/Gnppn/status/986187291566764032

Si le port 853 n'est pas bloqué. L'avantage de HTTPS, c'est qu'il passe partout.

Je trouve dommage que, jusqu'à présent, tous les commentaires portent sur le djandeur et sur la grammaire. LinuxFr n'est pas l'Académie Française, normalement, on connait le C mieux que le français. Donc, siouplè, merci de commenter aussi sur le fond, sur les MMORPG, sur le graphisme, sur le financement, et sur comment gérer sa Kimsufi.

Les ICMP "packet too big" existent aussi en IPv4. Si un administrateur réseaux incompétent les bloque, c'est tout aussi bête qu'en IPv6. Franchement, je ne vois pas l'intérêt de ces règles ultra-compliquées.

Tiens, justement, le clown ridicule qui publie ces drafts (pas ses meilleurs : le meilleur était celui où il concevait un réseau de satellites connectés par des fibres optiques) vient de faire une nouvelle version, la -11 :-}

Cette fois, il a ajouté une section DNS :-(

Ben, d'abord, la plupart des utilisat·eur·rice·s ne comprennent pas IPv4, et cela ne les empêche pas de dormir. Donc, qu'ielles ne comprennent pas IPv6 n'est pas trop grave.

Ensuite, pour ce·ux·lles qui ont besoin de comprendre (administrat·eur·rice réseaux, par exemple) IPv6 n'est pas un autre protocole, c'est une nouvelle version du même protocole, donc ça s'apprend comme IPv4, les concepts de base sont les mêmes (datagrammes, adresses, préfixes, routage, (in-)sécurité, etc).

L'autoconfiguration fondée sur l'adresse MAC est officiellement fortement déconseillée depuis 2012 http://www.bortzmeyer.org/6724.html mais, en pratique, Ubuntu, Windows et quelques autres ne l'utilisait déjà plus par défaut.

Pour les pare-feux, comme indiqué plus haut, c'est comme en IPv4.

Et pour l'histoire de vie privée, c'est 99 % de FUD http://www.bortzmeyer.org/7721.html

Au passage, au FOSDEM, ce week-end, le Wifi est en IPv6 seul par défaut. Avec NAT64. Et ça juste marche. Quand les gens bossent, au lieu de chouiner et de faire des réunions, IPv6 est simple. Juste fais le.

    % iwconfig wlp2s0
    wlp2s0    IEEE 802.11abgn  ESSID:"FOSDEM"  
              Mode:Managed  Frequency:5.24 GHz  Access Point: 64:D9:89:90:2E:2C   
              Bit Rate=300 Mb/s   Tx-Power=22 dBm   
              Retry short limit:7   RTS thr:off   Fragment thr:off
              Power Management:on
              Link Quality=27/70  Signal level=-83 dBm  
              Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
              Tx excessive retries:0  Invalid misc:4   Missed beacon:0

    % ip addr show wlp2s0
    3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1350 qdisc mq state UP group default qlen 1000
        link/ether b8:08:cf:18:6f:48 brd ff:ff:ff:ff:ff:ff
        inet6 2001:67c:1810:f051:5da8:d941:e88b:c1f4/64 scope global temporary dynamic 
           valid_lft 604636sec preferred_lft 85636sec
        inet6 2001:67c:1810:f051:6196:815a:49b3:d495/64 scope global mngtmpaddr noprefixroute 
           valid_lft forever preferred_lft forever
        inet6 fe80::d22:3668:c059:8007/64 scope link 
           valid_lft forever preferred_lft forever

C'est marrant qu'on ne se préoccupe de sécurité que quand il faut trouver une excuse pour ne pas déployer IPv6. Normalement, le réseau local de M. Michu est plein de machines Windows vérolées et de caméras membres de Mirai et tout à coup, on dit « ah non, pas IPv6, ça permettrait de pirater M. Michu »

Scanner ? En IPv6 ? Bon courage http://www.bortzmeyer.org/7707.html

Bouygues Telecom (je suis client) a IPv6 sur le réseau mobile et ça juste marche (je peux pinguer mon téléphone depuis mon PC, trop bien).

Je suis chez Bouygues Telecom et ça marche très bien en IPv6 (il faut changer manuellement l'APN, ce n'est pas par défaut).

Ce qui est un peu dommage, je trouve c'est que leur "dns-over-https" n'est pas du DNS/HTTPS. Ce n'est pas vraiment le protocole DNS, mais le contenu des champs des messages DNS encodés en JSON

Le groupe de travail DoH de l'IETF travaille justement à normaliser un DNS sur HTTPS utilisant le « wire format », c'est-à-dire l'encodage habituel du DNS (et pas JSON). Un premier prototype a été produit au hackathon à l'IETF 100 à Singapour la semaine dernière.

Un truc que je trouve assez dommage c'est que Stubby tourne forcément en root pour le moment.

Nuançons : il peut parfaitement tourner sous un compte utilisateur ordinaire (c'est ce qui est proposé dans la dépêche, et décrit au début). Le problème est si on veut écouter sur le port 53.

Dans ce cas, c'est une très bonne chose que DNS-LG ne le gère pas (c'est très dangereux pour la vie privée).

J'avoue ne pas comprendre « supporte l'utilisation de subnet client arbitraire ».

Des arguments sérieux ? Parce que « c'est pas compatible avec les lecteurs d'écran pour malvoyants » est un argument faux, émis par quelqu'un qui n'a jamais testé ces lecteurs, et « c'est peu lisible » est un argument rigolo, venant sur LinuxFr où les gens lisent et écrivent des regexp toute la journée.

DNS-over-HTTPS est très cool mais :

1) Aucun client DNS ne sait l'utiliser donc ce n'est pas une alternative à des systèmes présentés dans la dépêche. Ça n'a aujourd'hui d'intérêt que pour un client Javascript, ou bien pour ceux qui utilisent leur script shell avec curl et jq.

2) Il y avait bien d'autres de ces « DNS looking glasses » avant celui de Google.

Dans le journal original, cette phrase était en écriture inclusive. Certains lecteurs de LinuxFr, ayant le niveau politique (et l'âge ?) d'un membre de l'Académie Française, ont protesté. La phrase a donc été réécrite (et ce n'est effectivement pas terrible).

« la géolocalisation va aussi loin qu'elle le peut » Euh, non. Je ne comprends pas à quelle partie de la politique de vie privée cela fait référence.

Le problème, c'est aussi que ce n'est pas du DNS : il n'existe pas de client qui envoie les requêtes sur HTTPS et interprètent le JSON de sortie.

Parce que des DNS-sur-HTTPS en JSON, il y en avait bien avant Google, par exemple le mien en https://dns.bortzmeyer.org/

Parmi les différences avec Cisco OpenDNS et Google Public DNS :

• Quad9 est géré par une organisation sans but lucratif, PCH,
• organisation que je connais (c'est le point « spécial copinage »),
• Quad9 s'engage à ne pas enregistrer les adresses IP des clients (oui, je sais, c'est impossible à vérifier, cf. le point précédent)
• Quad9 a DNS-sur-TLS (ce qui est très important car, quand on utilise Google Public DNS ou bien les résolveurs DNS publics de FDN, le problème n'est pas uniquement la politique de Google ou de FDN, c'est aussi « est-ce que je parle vraiment à Google ou FDN ? » et « qui d'autre que Google ou FDN peut écouter le trafic ? » Il existe .