3.9 KiB
| layout | title | tags | ||
|---|---|---|---|---|
| post | Comment faire du TLS dans son homelab |
|
Dans une infrastructure personnelle ou dans un homelab, la sécurité passe souvent en second plan. Les mesures de sécurisation sont en effet souvent coûteuses, non applicables, ou simplement pas très fun à faire. Aujourd'hui, nous allons nous concentrer sur la question du chiffrement des flux avec TLS, et de la gestion de certificats.
Chiffrer les transferts de données au sein d'une infrastructure n'est pas forcément une priorité, n'étant par définition pas exposé sur internet, mais cela permet de limiter les effets de certaines attaques, ou de typiquement sécuriser ses flux contre une personne curieuse ou malveillante connectée au réseau local. C'est également une bonne pratique, et un bon entrainement pour ensuite le faire sur dees infrastructures réelles ou de production.
Il existe bien des solutions pour héberger sa propre infrastructure de certificats interne (comme step-ca), mais l'installation et la maintenance est lourde, et cela nécessite surtout d'installer le certificat racine sur tous les appareils du réseau... Pas très pratique pour laisser ses amis accéder au serveur de photo. Nous allons donc voir comment utiliser Let's Encrypt pour générer ses certificats internes, proprement et de manière sécurisée.
Approche naïve : challenge HTTP
Let's Encrypt propose deux manières principales pour obtenir des certificats : les challenges HTTP-01 et DNS-01. Le challenge HTTP-01 est de très loin le plus courant aujourd'hui. Le fonctionnement est simple : le serveur applicatif qui a besoin d'un certificat le demande à Let's Encrypt, qui lui donne un secret à héberger sur un serveur web servi sous le nom de domaine à vérifier, puis Let's Encrypt vient lire le site pour vérifier que le secret y a été mis en place.
[schema]
Bien que très simple à mettre en place, ce challenge a un gros soucis : il ne fonctionne que pour des machines accessibles depuis internet. Comment donc utiliser Let's Encrypt pour des sites privés ?
Le challenge DNS-01
Le challenge DNS-01 est justement là pour nous aider. Son fonctionnement est légèrement plus complexe :
[schema]
La différence, dans cette approche, est que l'application écrit le secret fourni non plus dans un site web sous le domaine à vérifier, mais dans un enregistrement TXT sur le serveur DNS autoritaire sur la zone à vérifier. La vérification peut donc fonctionner pour une zone DNS complète et plus seulement pour un nom de domaine précis, ce qui permet au passage la génération de certificats wildcard. Coté application, cela veut dire qu'elle doit avoir un accès à l'API du serveur DNS autoritaire (qu'il soit managé ou auto-hébergé).
Double the DNS for twice the privacy
Personnellement, je n'aime pas utiliser cette approche telle quelle à cause d'un gros soucis qu'elle a : à utiliser une zone DNS publique pour mon infrastructure privée, je me retrouve à exposer mon adressage privé dans des entrées DNS publiques, ce qui n'est pas propre. On peut améliorer un peu le schéma précédent pour en tenir compte :
[schema]
Ici, le serveur DNS autoritaire officiel de la zone ne sert qu'à la résolution du challenge DNS-01, et ne contient aucune entrée DNS pour mon infrastructure. Toutes ces entrées sont gérées dans le deuxième serveur DNS, entièrement interne, que j'interoge pour résoudre mes services internes. Cette approche fonctionne au mieux avec un domaine ou un sous-domaine dédié à l'infrastructure interne (par exemple, *.internal.example.org)
Voici comment configurer une infrastructure DNS pour pouvoir utiliser le challenge DNS-01, avec bind9 :
[config]
Pour rajouter une couche de sécurité, n'hésitez pas à restreindre l'accès à cette API à une plage d'IP, voire mieux, à ne pouvoir y accéder qu'à travers un pont VPN.