Mengingat LetsEncrypt tidak mengeluarkan sertifikat pada IP, akan lebih baik untuk mendeteksi dan mengabaikan alamat IP sebelum mengirim permintaan ke LetsEncrypt, daripada harus menambahkan logika itu ke dalam konfigurasi/fungsi allow_domain.
Saya baru saja menulis cek untuk itu, hanya untuk mengetahui bahwa itu sudah gagal sejak awal, pada:
ssl_certificate(): auto-ssl: tidak dapat menentukan domain untuk permintaan (SNI tidak didukung?) - menggunakan fallback -
Ketika browser melakukan permintaan ke alamat IP, itu tidak mengirim header SNI, jadi "domain" bahkan tidak akan disetel.
Saya tidak yakin mengapa milik saya mengirim permintaan untuk memungkinkan enkripsi yang kemudian mengirim kesalahan tentang mendaftarkan sertifikat SSL dengan IP: S
@discobean : Apakah Anda memiliki pesan kesalahan khusus yang terjadi ketika Anda melihat ini?
@GUI Saya terkadang mendapatkan kesalahan yang sama. Dugaan saya ini karena klien (yang mungkin adalah bot pemindai) mengirim header Host yang sama dengan alamat IP target, misalnya:
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
di mana XXX.XXX.XX.XX
adalah alamat IP server kami yang sebenarnya
Saya setuju untuk memblokir ini dalam kode, tetapi, eh: Allow_domain() Anda harus _only_ mengizinkan FQDN yang Anda inginkan untuk menghasilkan sertifikat (pendekatan daftar putih) sebagai lawan dari "bukan untuk ini" (pendekatan daftar hitam).
Anda tidak boleh hanya "mengembalikan true" di allow_domain(). Ini memberi tekanan pada sistem Anda dan mengumpulkan kegagalan menuju LE.
Kami akan selangkah lebih maju, meskipun. Kami mengekspor daftar semua pelanggan webhosting kami ke file tabel Lua di disk, membacanya dan menyimpannya di penyimpanan kunci/nilai SHM di dalam nginx sehingga kami dapat dengan mudah memeriksa host mana yang harus kami buatkan sertifikatnya atau tidak.
Kami memiliki beberapa sertifikat wildcard untuk nama host manajemen kami, jadi kami keluar lebih awal dengan rantai SSL yang diganti dengan sertifikat SSL yang sesuai di dalamnya. Kami keluar lebih awal pada alamat IP, dan localhost. Dan terakhir kami memeriksa DNS dan apakah nama tersebut benar-benar ada dalam daftar domain kami yang dikonfigurasi di sistem kami.
Sebagian besar cek ini hanya menang tepat waktu, tetapi tidak terlalu diperlukan. Intinya adalah: Gunakan daftar putih alih-alih daftar hitam. Ini juga merupakan praktik kode yang umum. Lebih baik aman daripada menyesal.
Dan terkadang lebih baik untuk tidak merekayasa secara berlebihan dan melewatkan berbagai pemeriksaan yang bisa menjadi titik kegagalan lainnya :) Terutama jika Anda memiliki lingkungan yang sangat dinamis.
Saya tidak mengatakan ini harus diblokir di lua-resty-auto-ssl, hanya membagikan apa yang saya temukan saat menguji apakah ada orang lain yang menemukan masalah ini.
Retas cepat di allow_domain
:
local ip_chunks = {domain:match("(%d+)%.(%d+)%.(%d+)%.(%d+)")}
if (#ip_chunks == 4) then
return false
end
Whitelisting tidak over-engineering, itu melakukannya dengan benar. Ada begitu banyak insiden keamanan di dunia karena pengembang menggunakan daftar hitam daripada daftar putih, itu bahkan tidak lucu.
Cek Anda juga melewatkan alamat IPv6, dan sebenarnya direkayasa berlebihan:
if string.match(domain, "(%d+).(%d+).(%d+).(%d+)") or string.find(domain, ":", 1, true) then
return false
end
Anda tidak tahu situasi kami, tetapi Anda cepat menilai. Poin diambil.
Anda mungkin dapat membuat PR dan mengubah allow_domain
di README.md menjadi sesuatu yang lebih masuk akal daripada mengembalikan true
untuk membuat semua orang lebih aman
Komentar yang paling membantu
Whitelisting tidak over-engineering, itu melakukannya dengan benar. Ada begitu banyak insiden keamanan di dunia karena pengembang menggunakan daftar hitam daripada daftar putih, itu bahkan tidak lucu.
Cek Anda juga melewatkan alamat IPv6, dan sebenarnya direkayasa berlebihan: