Lua-resty-auto-ssl: IP-Adressen beim Ausstellen von Zertifikaten ignorieren

Ich habe gerade einen Check dafür geschrieben, nur um herauszufinden, dass es schon ziemlich früh fehlschlägt:

ssl_certificate(): auto-ssl: Domäne für Anfrage konnte nicht ermittelt werden (SNI wird nicht unterstützt?) - Verwendung von Fallback -

Wenn ein Browser eine Anfrage an eine IP-Adresse sendet, sendet er keinen SNI-Header, sodass "Domain" nicht einmal festgelegt wird.

Ich bin mir nicht sicher, warum meiner eine Anfrage an Lets Encrypt gesendet hat, die dann einen Fehler über die Registrierung eines SSL-Zertifikats mit einer IP gesendet hat: S

@discobean : Hast du die spezifische Fehlermeldung, die auftritt, wenn du das gesehen hast?

@GUI Ich bekomme manchmal den gleichen Fehler. Ich vermute, das liegt daran, dass die Clients (die wahrscheinlich Scanner-Bots sind) einen Host-Header senden, der der Ziel-IP-Adresse entspricht, z.

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

wobei XXX.XXX.XX.XX unsere tatsächliche Server-IP-Adresse ist

Ich bin dafür, dies im Code zu blockieren, aber, eh: Ihre allow_domain() sollte _nur_ FQDNs zulassen, für die ein Zertifikat generiert werden soll (Whitelist-Ansatz), im Gegensatz zu „nicht für diese“ (Blacklist-Ansatz).

Sie sollten niemals einfach nur "true" in allow_domain() zurückgeben. Es belastet Ihr System und häuft Fehler in Richtung LE an.

Wir gehen aber noch einen Schritt weiter. Wir exportieren eine Liste aller unserer Webhosting-Kunden in eine Lua-Tabellendatei auf der Festplatte, lesen diese und speichern sie in einem SHM-Schlüssel/Wert-Speicher in nginx, damit wir leicht überprüfen können, für welche Hosts wir Zertifikate generieren sollten oder nicht.

Wir haben mehrere Wildcard-Zertifikate für unsere Management-Hostnamen, daher beenden wir vorzeitig mit einer ersetzten SSL-Kette mit dem entsprechenden SSL-Zertifikat darin. Wir verlassen frühzeitig IP-Adressen und localhost. Und schließlich überprüfen wir das DNS und ob der Name tatsächlich in unserer Liste der auf unseren Systemen konfigurierten Domänen enthalten ist.

Die meisten dieser Prüfungen sind nur Zeitgewinne, aber sie sind nicht wirklich notwendig. Der Punkt ist: Verwenden Sie eine Whitelist anstelle einer Blacklist. Es ist auch gängige Code-Praxis. Sicher ist sicher.

Und manchmal ist es besser, verschiedene Prüfungen nicht zu überarbeiten und zu überspringen, was ein weiterer Fehlerpunkt sein könnte :) Besonders wenn Sie eine hochdynamische Umgebung haben.

Ich sage nicht, dass dies in lua-resty-auto-ssl blockiert werden sollte, sondern teile nur mit, was ich beim Testen herausgefunden habe, falls jemand anderes auf dieses Problem stößt.

Schneller Hack in allow_domain :

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

Whitelisting ist kein Over-Engineering, es macht es richtig. Es gibt so viele Sicherheitsvorfälle auf der Welt, weil Entwickler Blacklisting statt Whitelisting verwenden, es ist nicht einmal im Entferntesten lustig.

Ihre Überprüfung überspringt auch IPv6-Adressen und ist tatsächlich überentwickelt:

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

Sie kennen unsere Situation nicht, aber Sie urteilen schnell. Punkt genommen.

Sie könnten wahrscheinlich eine PR erstellen und allow_domain in der README.md in etwas Sinnvolleres ändern, als true , um alle sicherer zu machen