Lua-resty-auto-ssl: 인증서 발급 시 IP 주소 무시

나는 그것에 대한 수표를 썼고, 이미 꽤 일찍 실패했다는 것을 알아냈습니다.

ssl_certificate(): auto-ssl: 요청에 대한 도메인을 결정할 수 없습니다(SNI가 지원되지 않습니까?) - 대체 사용 -

브라우저가 IP 주소를 요청할 때 SNI 헤더를 보내지 않으므로 "도메인"도 설정되지 않습니다.

내 요청이 암호화를 허용하라는 요청을 보낸 이유가 확실하지 않습니다. 그런 다음 SSL 인증서를 IP로 등록하는 것에 대한 오류를 보내는 중이었습니다.

@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 주소입니다.

저는 코드에서 이것을 차단하는 데 찬성합니다. 하지만, eh: "not for these"(블랙리스트 접근 방식)가 아닌 (화이트리스트 접근 방식)에 대해 인증서가 생성되기를 원하는 FQDN을 allow_domain() _only_ 허용해야 합니다.

allow_domain()에서 단순히 "true를 반환"해서는 안됩니다. 시스템에 부담을 주고 LE에 대한 실패를 누적합니다.

하지만 우리는 한 단계 더 나아가고 있습니다. 우리는 모든 웹호스팅 고객 목록을 디스크의 Lua 테이블 파일로 내보내고 이를 읽고 nginx 내부의 SHM 키/값 저장소에 저장하므로 인증서를 생성해야 하는지 여부를 쉽게 확인할 수 있습니다.

관리 호스트 이름에 대해 여러 개의 와일드카드 인증서가 있으므로 해당 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

당신은 우리의 상황을 모르지만 빠르게 판단합니다. 요점을 알았어.

모든 사람을 더 안전하게 만들기 위해 true 를 반환하는 것보다 PR을 만들고 README.md의 allow_domain 를 더 합리적인 것으로 변경할 수 있습니다.