• [^] # Re: Et DANE simplement

    Posté par . En réponse au journal Public Key Pinning Extension for HTTP. Évalué à 4.

    On fait confiance au cache des DNS, donc il faut systématiquement un serveur DNS local à la machine ?

    Pas forcément « systématiquement », mais c’est recommandé, en effet. Au minimum, il faut que le résolveur DNS validant soit sur le réseau local, et que celui-ci soit de confiance. C’est le problème dit de la « sécurité du dernier kilomètre », qui sort du cadre de DNSSEC. Si le résolveur validant est distant, il faut un mécanisme de protection supplémentaire, comme TSIG par exemple.

    Ça parait trop aberrant, donc ça doit être autre chose. Il a une notion de CA ?
    Et du coup il y a même problème de pining au niveau de DNSSEC, soit c'est piné par le client, soit ça utilise un CA ?

    Dans le cas idéal, le résolveur validant n’a besoin d’épingler que la clef de la racine. La plupart des logiciels résolveurs la connaissent déjà (tout comme ils connaissent les adresses des serveurs de noms de la racine).

    J'en déduis que pour chaque site que je visite il faut que je le whitelist ?

    Seulement si on ne peut pas remonter jusqu’à la racine, c’est-à-dire dans le cas (non idéal) où une des zones parentes n’est pas signée.

    Par exemple, si la zone fille.example.com. est signée mais que sa zone parente example.com. ne l’est pas, il est impossible de remonter jusqu’au TLD com. (signé) et a fortiori jusqu’à la racine (dont le résolveur connaît la clef). Jusqu’à ce que le gérant de example.com. signe sa zone (et communique sa clef au gérant de com.), la seule solution pour le résolveur souhaitant valider les données de fille.example.com. est d’ajouter directement la clef de cette zone dans la liste des clefs de confiance.