Lua-resty-auto-ssl: Ignorar endereços IP ao emitir certificados

Acabei de escrever um cheque para isso, apenas para descobrir que ele já falha muito cedo, em:

ssl_certificate(): auto-ssl: não foi possível determinar o domínio para solicitação (SNI não suportado?) - usando fallback -

Quando um navegador faz uma solicitação para um endereço IP, ele não envia um cabeçalho SNI, então o "domínio" nem mesmo será definido.

Não sei por que o meu estava enviando uma solicitação para criptografar que estava enviando um erro sobre o registro de um certificado SSL com um IP: S

@discobean : Você tem a mensagem de erro específica que acontece quando você vê isso?

@GUI Às vezes recebo o mesmo erro. Meu palpite é porque os clientes (que provavelmente são bots de scanner) estão enviando o cabeçalho do Host que é igual ao endereço IP de destino, por exemplo:

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

onde XXX.XXX.XX.XX é o nosso endereço IP real do servidor

Eu sou a favor de bloquear isso no código, mas, eh: Seu allow_domain() deve _only_ permitir FQDNs para os quais você deseja que um certificado seja gerado (abordagem de lista branca) em oposição a "não para estes" (abordagem de lista negra).

Você nunca deve simplesmente "retornar true" em allow_domain(). Isso sobrecarrega o seu sistema e acumula falhas em relação ao LE.

Estamos indo um passo além, no entanto. Exportamos uma lista de todos os nossos clientes de hospedagem para um arquivo de tabela Lua em disco, lemos e armazenamos em um armazenamento de chave/valor SHM dentro do nginx para que possamos verificar facilmente para quais hosts devemos ou não gerar certificados.

Temos vários certificados curinga para nossos nomes de host de gerenciamento, portanto, saímos antecipadamente com uma cadeia SSL substituída com o certificado SSL correspondente. Saímos cedo em endereços IP e localhost. E então, por último, verificamos o DNS e se o nome está ou não na nossa lista de domínios que estão configurados em nossos sistemas.

A maioria dessas verificações são apenas vitórias no tempo, mas não são realmente necessárias. Ponto a ser: Use uma lista branca em vez de uma lista negra. É uma prática de código comum também. Melhor prevenir do que remediar.

E às vezes é melhor não fazer engenharia demais e pular várias verificações que podem ser mais um ponto de falha :) Especialmente se você tiver um ambiente altamente dinâmico.

Não estou dizendo que isso deve ser bloqueado em lua-resty-auto-ssl, apenas compartilhando o que descobri ao testar se alguém mais se deparar com esse problema.

Hack rápido em allow_domain :

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

A lista de permissões não é engenharia excessiva, é fazer certo. Existem tantos incidentes de segurança no mundo porque os desenvolvedores estão usando listas negras em vez de listas brancas, não é nem remotamente engraçado.

Sua verificação também ignora os endereços IPv6 e, na verdade, é superprojetada:

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

Você não conhece nossa situação, mas é rápido em julgar. Ponto tomado.

Você provavelmente poderia criar um PR e mudar allow_domain no README.md para algo mais sensato do que retornar true para deixar todos mais seguros