4 231
modifications
(→SSHFP) |
|||
(12 versions intermédiaires par le même utilisateur non affichées) | |||
Ligne 1 : | Ligne 1 : | ||
[[Category:serveur]] | |||
[[Category:debian]] | |||
[[Category:security]] | |||
=DNSsec= | =DNSsec= | ||
=DANE= | =DANE= | ||
=TLSA= | |||
==Usage Field== | |||
* Usage 0 (PKIX-TA: Certificate Authority Constraint) : Permet de spécifier une CA public autorisé a générer des certificats pour votre domaine. Si une autre CA génère un certificat pour votre domaine, ce certificat sera considéré invalide (du point de vue de DANE). | |||
* Usage 1 (PKIX-EE: Service Certificate Constraint) : Permet de spécifier quel certificat serveur est valide. La chaine de certification sera tout de même vérifiée (et doit être valide). | |||
* Usage 2 (DANE-TA: Trust Anchor Assertion) : Permet de spécifier sa propre CA (non public ; générée et gérée soit même) comme étant valide pour ce domaine. | |||
* Usage 3 (DANE-EE: Domain Issued Certificate) : Permet de spécifier directement un certificat serveur même en dehors de toute chaine de certification. Aucune chaine de certification n'est nécessaire dans ce mode. | |||
==Selector Field== | |||
* Selector 0 - Cert: Utilisation d'un certificat complet | |||
* Selector 1 - SPKI: utilisation du sujet de la clé publique (SubjectPublicKeyInfo). Cette option permet de ne pas avoir à régénérer le champ TLSA a chaque renouvellement de certificat (a condition d'utiliser la même CSR à chaque fois (et donc la même clé privé) ; pratique pour [https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022 letsencrypt] par exemple). | |||
==Matching-Type Field== | |||
* 0 - Full: Pas de hash, les données sont directement comparés | |||
* 1 - SHA-256: SHA-256 hash | |||
* 2 - SHA-512: SHA-512 hash | |||
==Hash-slinger== | |||
<pre>tlsa --create --port 443 --protocol tcp --usage 3 --mtype 2 --certificate /etc/ssl/yourca/yourcert.pem yourserv.domain.tld.</pre> | |||
=SSHFP= | =SSHFP= | ||
=pourquoi ?== | ==pourquoi ?== | ||
En l'état actuel des choses, lorsque vous vous connectez à un nouveau serveur ssh, votre client doit (s'il ne le fait pas, changez en) vous informer que le serveur sur lequel vous tentez de vous connecter d'identifie avec une certaine fingerprint : | En l'état actuel des choses, lorsque vous vous connectez à un nouveau serveur ssh, votre client doit (s'il ne le fait pas, changez en) vous informer que le serveur sur lequel vous tentez de vous connecter d'identifie avec une certaine fingerprint : | ||
<pre> | <pre> | ||
Ligne 20 : | Ligne 47 : | ||
==Génération avec ssh-keygen== | ==Génération avec ssh-keygen== | ||
Cette commande est a utiliser sur le serveur pour lequel vous voulez générer les champs de sécurité dns. | |||
La syntaxe est simple : <code>ssh-keygen -r <hostname de votre serveur></code> | La syntaxe est simple : <code>ssh-keygen -r <hostname de votre serveur></code> | ||
Ligne 33 : | Ligne 62 : | ||
sshfp -k sshkeys | sshfp -k sshkeys | ||
</pre> | </pre> | ||
Ou vous pouvez aussi tout faire avec sshfp : | |||
<pre>sshfp --scan wiki.csnu.org.</pre> | |||
Cela devrait vous sortir une série de champ DNS que vous pouvez copier directement dans votre zone dns. N'oubliez pas de mettre a jour le SERIAL de la zone et de recharger la zone dans votre serveur dns ensuite. | Cela devrait vous sortir une série de champ DNS que vous pouvez copier directement dans votre zone dns. N'oubliez pas de mettre a jour le SERIAL de la zone et de recharger la zone dans votre serveur dns ensuite. | ||
Ligne 41 : | Ligne 74 : | ||
De cette manière, il sera necessaire que la clé soit confirmée a la fois par dns et par StrictHostKeyChecking. | De cette manière, il sera necessaire que la clé soit confirmée a la fois par dns et par StrictHostKeyChecking. | ||
Si vous souhaitez faire confiance automatiquement aux nouvelles clés ssh obtenue par dns (aka ajouter directement la clé dans votre fichier known_hosts sans que celà vous soit demandé), modifiez la ligne de cette manière : <code>VerifyHostKeyDNS yes</code> | Si vous souhaitez faire confiance automatiquement aux nouvelles clés ssh obtenue par dns (aka ajouter directement la clé dans votre fichier known_hosts sans que celà vous soit demandé), modifiez la ligne de cette manière : <code>VerifyHostKeyDNS yes</code>. Notez que même dans ce cas, ssh n'ajoutera automatiquement la clé QUE si le serveur dns utilisé pour résoudre l'hostname a utilisé dnssec pour authentifier le résultat ! |