Lua-resty-auto-ssl: Ignorar las direcciones IP al emitir certificados

Acabo de escribir un cheque para eso, solo para descubrir que ya falla bastante pronto, en:

ssl_certificate (): auto-ssl: no se pudo determinar el dominio para la solicitud (¿SNI no es compatible?) - usando respaldo -

Cuando un navegador realiza una solicitud a una dirección IP, no envía un encabezado SNI, por lo que ni siquiera se configurará el "dominio".

No estoy seguro de por qué el mío enviaba una solicitud para permitir el cifrado que luego enviaba un error sobre el registro de un certificado SSL con una IP: S

@discobean : ¿Tiene el mensaje de error específico que aparece cuando ve esto?

@GUI A veces recibo el mismo error. Supongo que esto se debe a que los clientes (que probablemente sean bots de escáner) envían un encabezado de host que equivale a la dirección IP de destino, por ejemplo:

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

donde XXX.XXX.XX.XX es la dirección IP real de nuestro servidor

Estoy a favor de bloquear esto en el código, pero, eh: Su allow_domain() debería _solo_ permitir FQDN para los que desee que se genere un certificado (enfoque de lista blanca) en lugar de "no para estos" (enfoque de lista negra).

Nunca debe simplemente "devolver verdadero" en allow_domain(). Pone tensión en su sistema y acumula fallas hacia LE.

Sin embargo, vamos un paso más allá. Exportamos una lista de todos nuestros clientes de alojamiento web a un archivo de tabla Lua en el disco, lo leemos y lo almacenamos en un almacén de clave/valor SHM dentro de nginx para que podamos verificar fácilmente para qué hosts deberíamos generar certificados o no.

Tenemos varios certificados comodín para nuestros nombres de host de administración, por lo que salimos temprano con una cadena SSL reemplazada con el certificado SSL correspondiente. Salimos temprano en direcciones IP y localhost. Y, por último, verificamos el DNS y si el nombre está o no en nuestra lista de dominios que están configurados en nuestros sistemas.

La mayoría de estos controles son solo ganancias en el tiempo, pero no son realmente necesarios. El punto es: use una lista blanca en lugar de una lista negra. También es una práctica de código común. Más vale prevenir que lamentar.

Y, a veces, es mejor no hacer demasiada ingeniería y omitir varias comprobaciones, lo que podría ser otro punto de falla :) Especialmente si tiene un entorno muy dinámico.

No digo que esto deba bloquearse en lua-resty-auto-ssl, solo comparto lo que descubrí mientras probaba si alguien más se topa con este problema.

Truco rápido en allow_domain :

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

La inclusión en la lista blanca no es un exceso de ingeniería, es hacerlo bien. Hay tantos incidentes de seguridad en el mundo porque los desarrolladores están usando listas negras en lugar de listas blancas, que no es ni remotamente divertido.

Su verificación también omite las direcciones IPv6 y, en realidad, tiene un exceso de ingeniería:

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

No conoces nuestra situación, pero juzgas rápidamente. Punto a favor.

Probablemente podría crear un PR y cambiar el allow_domain en el README.md a algo más sensato que devolver true para que todos estén más seguros