karim67 a écrit 1 commentaire

  • # rfc7858

    Posté par  . En réponse à la dépêche Quad9, résolveur DNS public, et sécurisé par TLS. Évalué à 10.

    Quoi de neuf ?

    On ne peut que se réjouir de l'arrivée d'un acteur qui devrait favoriser la démocratisation de l'usage de DNS sur TLS (rfc7858).
    Dans cette quête de "privacy" autour de DNS, il serait malheureux que ce soit une solution quasi propriétaire (DNSCrypt) ou promue par Google (dns-over-https) qui l'emporte.
    On regrettera évidemment le choix délibéré de filtrer les réponses mais on ne va pas faire la fine bouche, c'est préférable à tout ce que l'on a vu jusqu'à présent.
    Espérons que d'autres initiatives plus neutres viennent à l'avenir concurrencer celle-ci.

    Une (micro) contribution en complément à cet excellent journal

    De nos jours, devoir se passer de l'authentification TLS du résolveur est, pour certains, rédhibitoire.
    Pour pallier ce manque, voici une horreur permettant de "découvrir" la valeur "tls_pubkey_pinset" voulue par Stubby : 

    ip=9.9.9.9
port=853

openssl s_client -showcerts -connect $ip:$port </dev/null 2>/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64

    Cela permet d'obtenir, à l'heure qu'il est, la configuration Stubby suivante 1 : 

    dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
upstream_recursive_servers:
   - address_data: 9.9.9.9
     tls_auth_name: "dns.quad9.net"
     tls_pubkey_pinset:
       - digest: "sha256"
         value: MujBQ+U0p2eZLTnQ2KGEqs+fPLYV/1DnpZDjBDPwUqQ=

    Un (petit) retour d'expérience de DNS sur TLS

    J'ai mené ces dernières semaines quelques expérimentations autour de solutions permettant de mettre en oeuvre le rfc7858 chez soi.

    Mon retour d'utilisation de Stubby est mitigé.
    Heureux possesseur d'un routeur Turris, j'ai configuré le résolveur Knot pour rediriger les requêtes DNS vers un container LXC qui héberge une instance Stubby (ouf). J'utilise les trois premiers résolveurs de la configuration par défaut de Stubby qui, depuis ma connexion Orange, offrent une latence acceptable 2 . Cette configuration fonctionne parfaitement… jusqu'à ce qu'elle tombe en panne.
    Il faut régulièrement relancer Stubby qui se fige au bout de quelques heures.
    Le diagnostic n'est pas aisé car le logging de stubby est, pour l'instant, assez rudimentaire.
    Il faudrait effectuer une analyse de trafic réseau.
    TLS masquant la couche application, cela pourrait être fastidieux.
    Pour ne rien arranger, j'ai autour de moi des utilisateurs exigeants qui n'arrivent pas à comprendre que, sous prétexte d'échapper au regard de la NSA, twitch.tv ou vente-privee.com ne soient régulièrement plus accessibles 3 …

    Pour rétablir la paix dans mon foyer, j'ai du me rabattre sur un mode fort bien expliqué ici (et là) qui couple un tunnel TLS à destination du résolveur public (réalisé avec stunnel) avec une instance du résolveur Unbound chargée d'établir un "pont" TCP/UDP.
    Cette configuration est la plus stable que j'ai trouvée jusqu'à présent.
    Elle présente cependant le défaut majeur d'établir une session TCP/TLS à chaque requête DNS 4 . En plus de ne pas être performant, c'est assez peu respectueux des ressources sollicitées.
    Si une bonne âme avait une idée pour configurer stunnel (ou socat) afin de "persister" la session TCP client, je lui serais éternellement reconnaissant :)
    En attendant, je vais tenter un retour à Stubby avec Quad9 pour tester si la stabilité est au rendez-vous.

    À suivre © …

    1 Les lecteurs attentifs ne manqueront pas d'observer que :

    • ce hack permettrait tout aussi bien de récupérer la signature du certificat public d'un attaquant déjà en place,
    • une nouvelle valeur devra être appliquée à chaque émission d'un nouveau certificat, ce qui en utilisant une CA comme Let's Encrypt se produira fréquemment. Idéalement, Quad9 devrait utiliser un certificat autosigné (attention, troll inside) avec un délai d'expiration suffisamment long et, comme dit dans le journal, communiquer la clef publique par différents moyens sécurisés.

    2
    À propos de latence (qui est critique en matière de DNS), un traceroute lancé ce jour depuis le réseau Orange montre que le dernier saut avant 9.9.9.9 est l'adresse IP 83.231.233.182 qui s'avère géolocalisée en Grande Bretagne.
    Cela laisse penser qu'il n'y a pas (encore) d'instance Quad9 en France.
    Dommage avec un nom pareil :(

    3
    Que diraient-ils s'ils savaient que, alors que j'argumente autour de la nécessaire protection de leur vie privée, je m'abstiens de dire que le seul chiffrement du trafic DNS ne les protège pas des regards indiscrets du fait du transport en clair du champ SNI à l'initialisation d'HTTPS…
    (Quand on lit ceci qui n'est qu'à l'état de proposition, on a la désagréable impression que ce n'est pas demain que l'on aura un niveau de "privacy" acceptable même avec le fameux cadenas vert).

    4
    L'auteur de la page sus-citée a commis un outil qui cherche à résoudre le problème.