Lua-resty-auto-ssl: Ignorer les adresses IP lors de l'émission de certificats

Je viens d'écrire un chèque pour cela, seulement pour découvrir qu'il échoue déjà assez tôt, sur :

ssl_certificate() : auto-ssl : impossible de déterminer le domaine pour la requête (SNI non pris en charge ?) - Utilisation de la solution de secours -

Lorsqu'un navigateur fait une demande à une adresse IP, il n'envoie pas d'en-tête SNI, donc "domaine" ne sera même pas défini.

Je ne sais pas pourquoi le mien envoyait une requête à let encrypt qui envoyait alors une erreur concernant l'enregistrement d'un certificat SSL avec une adresse IP :S

@discobean : Avez-vous le message d'erreur spécifique qui s'affiche lorsque vous voyez cela ?

@GUI J'obtiens parfois la même erreur. Je suppose que c'est parce que les clients (qui sont probablement des robots scanners) envoient un en-tête Host qui équivaut à l'adresse IP cible, par exemple :

2018/02/20 02:10:44 [warn] 490#490: *2723 [lua] init_by_lua:11: allow_domain(): auto-ssl: debug allow_domain domain XXX.XXX.XX.XX, context: ssl_certificate_by_lua*, client: 107.170.236.113, server: 0.0.0.0:8443
2018/02/20 02:10:49 [error] 490#490: *2723 [lua] lets_encrypt.lua:41: issue_cert(): auto-ssl: dehydrated failed: env HOOK_SECRET=XXXXX HOOK_SERVER_PORT=8999 /usr/local/bin/resty-auto-ssl/dehydrated --cron --accept-terms --no-lock --domain XXX.XXX.XX.XX --challenge http-01 --config /etc/resty-auto-ssl/letsencrypt/config --hook /usr/local/bin/resty-auto-ssl/letsencrypt_hooks status: 256 out: # INFO: Using main config file /etc/resty-auto-ssl/letsencrypt/config
Processing XXX.XXX.XX.XX
 + Signing domains...
 + Creating new directory /etc/resty-auto-ssl/letsencrypt/certs/XXX.XXX.XX.XX ...
 + Generating private key...
 + Generating signing request...
 + Requesting authorization for XXX.XXX.XX.XX...
 err:   + ERROR: An error occurred while sending post-request to https://acme-v01.api.letsencrypt.org/acme/new-authz (Status 400)

Details:
{
  "type": "urn:acme:error:malformed",
  "detail": "Error creating new authz :: Issuance for IP addresses not supported",
  "status": 400
}

, context: ssl_certificate_by_lua*, client: 107.170.236.113, server: 0.0.0.0:8443
2018/02/20 02:10:49 [error] 490#490: *2723 [lua] ssl_certificate.lua:97: issue_cert(): auto-ssl: issuing new certificate failed: dehydrated failure, context: ssl_certificate_by_lua*, client: 107.170.236.113, server: 0.0.0.0:8443
2018/02/20 02:10:49 [error] 490#490: *2723 [lua] ssl_certificate.lua:286: auto-ssl: could not get certificate for XXX.XXX.XX.XX - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: 107.170.236.113, server: 0.0.0.0:8443

où XXX.XXX.XX.XX est l'adresse IP réelle de notre serveur

Je suis tout à fait d'accord pour bloquer cela dans le code, mais, hein : Votre allow_domain() devrait _uniquement_ autoriser les FQDN pour lesquels vous souhaitez qu'un certificat soit généré (approche de la liste blanche) par opposition à "pas pour ceux-ci" (approche de la liste noire).

Vous ne devriez jamais simplement "retourner vrai" dans allow_domain(). Cela met votre système à rude épreuve et accumule les échecs vers LE.

Nous allons cependant un peu plus loin. Nous exportons une liste de tous nos clients d'hébergement Web vers un fichier de table Lua sur disque, lisons-le et le stockons dans un magasin clé/valeur SHM à l'intérieur de nginx afin que nous puissions facilement vérifier pour quels hôtes nous devrions générer des certificats ou non.

Nous avons plusieurs certificats génériques pour nos noms d'hôte de gestion, nous quittons donc tôt avec une chaîne SSL remplacée avec le certificat SSL correspondant. Nous sortons tôt sur les adresses IP et localhost. Et enfin, nous vérifions le DNS et si le nom figure ou non dans notre liste de domaines configurés sur nos systèmes.

La plupart de ces contrôles ne sont que des gains dans le temps, mais ils ne sont pas vraiment nécessaires. Le point étant : utilisez une liste blanche au lieu d'une liste noire. C'est aussi une pratique courante du code. Mieux vaut prévenir que guérir.

Et parfois, il vaut mieux ne pas trop concevoir et ignorer diverses vérifications qui pourraient être un autre point d'échec :) Surtout si vous avez un environnement très dynamique.

Je ne dis pas que cela devrait être bloqué dans lua-resty-auto-ssl, je partage simplement ce que j'ai découvert lors des tests si quelqu'un d'autre tombe sur ce problème.

Hack rapide en allow_domain :

          local ip_chunks = {domain:match("(%d+)%.(%d+)%.(%d+)%.(%d+)")}
          if (#ip_chunks == 4) then
            return false
          end

La liste blanche n'est pas une ingénierie excessive, c'est bien fait. Il y a tellement d'incidents de sécurité dans le monde parce que les développeurs utilisent la liste noire au lieu de la liste blanche, ce n'est même pas drôle à distance.

Votre vérification ignore également les adresses IPv6 et est en fait sur-conçue :

if string.match(domain, "(%d+).(%d+).(%d+).(%d+)") or string.find(domain, ":", 1, true) then
    return false
end

Vous ne connaissez pas notre situation, mais vous jugez rapidement. Point pris.

Vous pourriez probablement créer un PR et changer le allow_domain dans le README.md en quelque chose de plus sensé que de retourner true pour rendre tout le monde plus sûr