Lua-resty-auto-ssl: Игнорировать IP-адреса при выдаче сертификатов

Я только что написал для этого чек, только чтобы узнать, что он уже довольно рано дает сбой, на:

ssl_certificate(): auto-ssl: не удалось определить домен для запроса (SNI не поддерживается?) - с использованием отката -

Когда браузер делает запрос к IP-адресу, он не отправляет SNI-заголовок, поэтому «домен» даже не будет установлен.

Я не уверен, почему мой отправлял запрос на шифрование, который затем отправлял ошибку о регистрации SSL-сертификата с IP-адресом: S

@discobean : У вас есть конкретное сообщение об ошибке, которое появляется, когда вы видите это?

@GUI Иногда я получаю ту же ошибку. Я предполагаю, что это связано с тем, что клиенты (которые, вероятно, являются ботами-сканерами) отправляют заголовок хоста, равный целевому IP-адресу, например:

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

где XXX.XXX.XX.XX — фактический IP-адрес нашего сервера.

Я полностью за то, чтобы заблокировать это в коде, но, а: ваш allow_domain() должен _только_ разрешать полные доменные имена, для которых вы хотите создать сертификат (подход белого списка), а не «не для них» (подход черного списка).

Вы никогда не должны просто "вернуть true" в allow_domain(). Это создает нагрузку на вашу систему и накапливает сбои в отношении LE.

Однако мы идем дальше. Мы экспортируем список всех наших клиентов веб-хостинга в файл таблицы Lua на диске, читаем его и сохраняем в хранилище ключей/значений SHM внутри nginx, чтобы мы могли легко проверить, для каких хостов мы должны создавать сертификаты или нет.

У нас есть несколько подстановочных сертификатов для наших имен хостов управления, поэтому мы выходим раньше с замененной цепочкой SSL с соответствующим сертификатом SSL в ней. Рано выходим на IP-адреса и localhost. И, наконец, мы проверяем DNS и действительно ли имя находится в нашем списке доменов, настроенных в наших системах.

Большинство этих проверок — только выигрыши во времени, но на самом деле они не нужны. Суть в том, что используйте белый список вместо черного. Это тоже обычная практика кода. Береженого Бог бережет.

И иногда лучше не переусердствовать и пропустить различные проверки, которые могут стать еще одной точкой отказа :) Особенно, если у вас очень динамичная среда.

Я не говорю, что это должно быть заблокировано в lua-resty-auto-ssl, просто делюсь тем, что я узнал во время тестирования, если кто-то еще наткнется на эту проблему.

Быстрый взлом в allow_domain :

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

Белый список — это не чрезмерная инженерия, это правильно. В мире так много инцидентов с безопасностью из-за того, что разработчики используют черные списки вместо белых списков, это даже отдаленно не смешно.

Ваша проверка также пропускает IPv6-адреса и на самом деле переработана:

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

Вы не знаете нашу ситуацию, но быстро судите. Дело принято.

Вероятно, вы могли бы создать PR и изменить allow_domain в README.md на что-то более разумное, чем возвращать true чтобы сделать всех безопаснее.