L'application Home Assistant verrouillée par un certificat, avec nginx ou Caddy et sans Cloudflare

Le même verrou, votre propre porte

L’application Home Assistant via Cloudflare, verrouillée par un certificat place le verrou à la périphérie de Cloudflare. Le téléphone détient un certificat, Cloudflare le vérifie, et rien de ce qui n’en a pas n’atteint la maison. Ça marche, c’est gratuit, et ça veut dire que Cloudflare tient la porte et lit le trafic au passage.

Ici, c’est le même verrou avec la porte dans votre propre maison. nginx ou Caddy vérifie le certificat. Votre propre autorité de certification l’émet. Personne d’autre n’est sur le chemin. La page de connexion reste invisible pour tout ce qui n’a pas de certificat, donc ce qui change, ce n’est pas si des inconnus entrent. C’est qui fait le travail, et qui porte le risque quand ça tourne mal.

Tout ce qui suit a été construit et testé : nginx 1.30.5 et Caddy 2.11.7 sous Podman, des certificats de step-ca 0.30.2, chaque proxy attaqué sans certificat, avec un bon certificat, avec un révoqué et avec une montée en WebSocket, en IPv4 et en IPv6. Le backend du test était un petit remplaçant qui renvoie les en-têtes qu’il reçoit, donc les résultats montrent exactement ce que Home Assistant recevrait.

Ce qui change quand Cloudflare s’en va

Les deux lignes qui comptent le plus tirent en sens opposés. Personne d’autre ne lit votre trafic ni ne peut vous couper, et c’est la souveraineté, toute la raison de le faire. Mais la redirection de port est de retour, donc les scans et les inondations frappent votre ligne au lieu de celle de Cloudflare. La différence avec la simple redirection de port du comparatif de l’article Cloudflare, c’est ce qu’ils trouvent en arrivant : un proxy qui coupe la connexion pendant la poignée de main, pas la page de connexion de Home Assistant.

Soyez clair sur ce que ça achète et ce que ça n’achète pas. Votre propre reverse proxy ne vous donne aucune protection DDoS. Le mTLS empêche un inconnu d’entrer. Il ne fait rien pour empêcher un inconnu de saturer votre ligne, et une inondation n’a pas besoin de certificat pour la saturer. Cloudflare absorbe ça pour vous sur toutes ses offres, la gratuite comprise¹. Ici, il n’y a personne en amont pour l’absorber, donc une inondation assez grosse sort toute la maison d’internet, et le proxy ne peut refuser que les connexions qu’il arrive à voir.

nginx ou Caddy

Les deux font le travail. Ils diffèrent à un endroit qui compte. La révocation.

C’est sur la révocation qu’il faut trancher. La documentation de Caddy liste exactement un vérificateur livré avec Caddy standard, leaf, et il vérifie si le certificat « is one of a defined set of permitted certificates »². Il n’y a ni CRL ni OCSP pour les certificats clients. Pointez Caddy sur l’AC seule et un téléphone révoqué entre comme chez lui. Le test a montré exactement ça : phone2, révoqué une heure plus tôt, a eu un 200. La liste d’autorisation comble le trou. C’est aussi une liste que vous tenez à la main, aussi longtemps que vous faites tourner tout ça.

La configuration nginx

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name ha.example.com;

    ssl_certificate         /etc/nginx/pki/server-chain.pem;
    ssl_certificate_key     /etc/nginx/pki/server.key;
    ssl_protocols           TLSv1.2 TLSv1.3;

    # The mTLS half: only certificates from our CA, and not revoked.
    ssl_client_certificate  /etc/nginx/pki/client-ca.pem;
    ssl_verify_client       on;
    ssl_verify_depth        2;
    ssl_crl                 /etc/nginx/pki/crl-chain.pem;

    location / {
        proxy_pass http://192.0.2.10:8123;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
    }
}

Le fichier CRL est la partie qui demande du soin, et tout est dans Des certificats clients depuis step-ca : pourquoi la CRL de step-ca est rejetée tant qu’un modèle ne corrige pas sa portée, pourquoi nginx veut aussi une CRL de la racine, et la minuterie qui la rafraîchit avant qu’elle n’expire. Sautez ça et nginx bloque tous les téléphones, les bons compris.

Ce que le test a renvoyé :

Avant l’ajout de listen [::]:8443, la requête IPv6 ne se connectait pas du tout. curl sortie 7.

La configuration Caddy

ha.example.com {
	tls /etc/caddy/pki/server-chain.pem /etc/caddy/pki/server.key {
		client_auth {
			mode require_and_verify
			trust_pool file /etc/caddy/pki/client-ca.pem
			verifier leaf {
				file /etc/caddy/pki/allowed-phones.pem
			}
		}
	}
	reverse_proxy 192.0.2.10:8123
}

require_and_verify veut dire que le certificat doit être présent et doit remonter jusqu’à l’AC². verifier leaf, c’est la révocation. Seuls les certificats de allowed-phones.pem entrent, donc révoquer un téléphone veut dire retirer son certificat de ce fichier et recharger.

La liste d’autorisation a son propre piège, et le test est tombé en plein dedans. La liste contient des certificats exacts, pas des noms. Réémettez le certificat d’un téléphone et le nouveau n’est pas sur la liste. phone1 a été réémis à mi-parcours du test et Caddy l’a refusé avec tls alert bad certificate jusqu’à ce que la liste soit reconstruite. Chaque renouvellement, ce sont maintenant deux tâches. Émettre le certificat, puis mettre la liste à jour. Oubliez la seconde et le téléphone est bloqué pour rien.

Caddy journalise aussi enabling strict SNI-Host enforcement because TLS client auth is configured au démarrage. C’est lui qui fait ce qu’il faut : une requête doit demander le même nom d’hôte dans la poignée de main que dans la requête HTTP, pour que personne ne puisse passer la vérification de certificat pour un site puis en demander un autre.

Le côté Home Assistant

Les mêmes réglages que dans la version Cloudflare, visant un autre proxy. Sous Settings → System → Network → HTTP server⁴ :

Listez l’adresse IPv6 du proxy en plus de son adresse IPv4. Le test montre nginx transmettant ::1 comme adresse du client en IPv6, et en service il transmet l’adresse d’où vient le téléphone, quelle qu’elle soit. Si Home Assistant ne fait confiance qu’à l’adresse IPv4 du proxy, chaque requête qui lui arrive du proxy en IPv6 est refusée.

Le téléphone

Depuis step-ca, le téléphone a besoin de trois fichiers. Tout est couvert dans l’article sur les certificats clients de step-ca, et la mise en place de l’AC elle-même dans Votre propre autorité de certification.

Le certificat serveur du proxy vient lui aussi de step-ca. L’application Android de Home Assistant fait confiance aux certificats d’AC installés par l’utilisateur⁶, donc elle l’accepte, et c’est un second verrou, pas une gêne. Un appareil qui ne détient pas votre racine ne fait pas confiance au serveur, avant même que se pose la question de son propre certificat.

Réglez ensuite le niveau de sécurité de connexion de l’application sur Most secure, comme dans la version Cloudflare⁷.

Là où ça coince

Aucun de ces cas n’est caché. Chacun est une tâche. Notez-la avec une date ou une commande à côté et elle reste une tâche, pas une surprise.

Posséder le tout

La version Cloudflare et celle-ci tiennent dehors le même inconnu. La différence, c’est à qui vous devez faire confiance pendant qu’elles le font.

Avec Cloudflare, vous faites confiance à une entreprise pour tenir la porte, déchiffrer le trafic et continuer à l’offrir gratuitement. Avec ceci, vous vous faites confiance pour rafraîchir une CRL, tenir une liste à jour et remarquer quand une date arrive. Aucune des deux n’échappe à la confiance. L’une la confie à quelqu’un que vous ne payez pas et que vous ne pouvez pas appeler. L’autre la garde à la maison, où vous pouvez la voir échouer et la réparer.

Pour la porte d’entrée d’une maison, je sais ce que je préfère. Le travail, c’est quelques fichiers et une minuterie. En tant que tel, la seule chose qu’il demande vraiment, c’est que vous vous en occupiez, ce que posséder quoi que ce soit a toujours voulu dire.