Perché il mio browser pensa che https://1.1.1.1 sia sicuro?

Quando visito https://1.1.1.1 , qualsiasi browser Web che utilizzo considera l'URL sicuro.

Questo è ciò che mostra Google Chrome:

Normalmente, quando provo a visitare un sito HTTPS tramite il suo indirizzo IP, ricevo un avviso di sicurezza come questo:

Da quanto ho capito, il certificato del sito deve corrispondere al dominio, ma il Visualizzatore certificati di Google Chrome non mostra 1.1.1.1:

Articolo della knowledge base di GoDaddy "Posso richiedere un certificato per un nome intranet o un indirizzo IP?" dice:

No: non accettiamo più richieste di certificati per nomi intranet o indirizzi IP. Questo è uno standard industriale , non specifico per GoDaddy.

^{_{( enfatizzare il mio)}}

E anche:

Di conseguenza, a partire dal 1 ° ottobre 2016 , le autorità di certificazione (CA) devono revocare i certificati SSL che utilizzano nomi o indirizzi IP della intranet .

^{_{( enfatizzare il mio)}}

E:

Invece di proteggere indirizzi IP e nomi intranet, è necessario riconfigurare i server per utilizzare nomi di dominio completi (FQDN), come www.coolexample.com .

^{_{( enfatizzare il mio)}}

È ben dopo la data di revoca obbligatoria del 1 ° ottobre 2016, ma il certificato per è 1.1.1.1stato emesso il 29 marzo 2018 (mostrato nello screenshot sopra).

Come è possibile che tutti i principali browser pensino che https://1.1.1.1 sia un sito Web HTTPS affidabile?

L'inglese è ambiguo . Lo stavi analizzando in questo modo:

(intranet names) or (IP addresses)

cioè vietare completamente l'uso di indirizzi IP numerici. Il significato che corrisponde a ciò che stai vedendo è:

intranet (names or IP addresses)

vale a dire vietare i certificati per gli intervalli IP privati come 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16, nonché per i nomi privati ​​che non sono visibili sul DNS pubblico.

I certificati per gli indirizzi IP instradabili pubblicamente sono ancora consentiti, ma non sono generalmente raccomandati per la maggior parte delle persone, in particolare quelli che non possiedono anche un IP statico.

Questa affermazione è un consiglio, non un'affermazione che non è possibile proteggere un indirizzo IP (pubblico).

Invece di proteggere indirizzi IP e nomi intranet, è necessario riconfigurare i server per utilizzare nomi di dominio completi (FQDN), come www.coolexample.com

Forse qualcuno di GoDaddy interpretava male la formulazione, ma molto probabilmente desiderava mantenere semplici i propri consigli e voleva raccomandare di usare nomi DNS pubblici nei certificati.

Molte persone non usano un IP statico stabile per il loro servizio. Fornire servizi DNS è l'unico caso in cui è veramente necessario disporre di un IP noto stabile anziché solo un nome. Per chiunque altro, inserire il tuo IP attuale nel tuo certificato SSL limiterebbe le tue opzioni future, perché non puoi permettere a qualcun altro di iniziare a usare quell'IP. Potrebbero impersonare il tuo sito.

Cloudflare.com ha il controllo dell'indirizzo IP 1.1.1.1 e non ha intenzione di fare qualcosa di diverso con esso nel prossimo futuro, quindi ha senso per loro mettere il loro IP nel loro programma. Soprattutto come provider DNS , è più probabile che i client HTTPS visitino il loro URL in numero che per qualsiasi altro sito.

La documentazione di GoDaddy è errata. Non è vero che le autorità di certificazione (CA) debbano revocare i certificati per tutti gli indirizzi IP ... solo indirizzi IP riservati .

^{_{Fonte: https://cabforum.org/internal-names/}}

La CA per https://1.1.1.1 era DigiCert , che al momento della stesura di questa risposta, consente l'acquisto di certificati del sito per indirizzi IP pubblici.

DigiCert ha un articolo su questo chiamato Emissione del certificato SSL del nome del server interno dopo il 2015 :

Se sei un amministratore del server che utilizza nomi interni, devi riconfigurare tali server per utilizzare un nome pubblico o passare a un certificato emesso da una CA interna prima della data di interruzione del 2015. Tutte le connessioni interne che richiedono un certificato attendibile pubblicamente devono essere eseguite tramite nomi pubblici e verificabili (non importa se tali servizi sono accessibili al pubblico).

^{_{( enfatizzare il mio)}}

Cloudflare ha semplicemente ottenuto un certificato per il proprio indirizzo IP 1.1.1.1da quella CA attendibile.

L'analisi del certificato per https://1.1.1.1 rivela che il certificato utilizza i nomi alternativi soggetto (SAN) per comprendere alcuni indirizzi IP e nomi di dominio ordinari:

deltik@node51 [~]$ openssl s_client -showcerts -connect 1.1.1.1:443 < /dev/null 2>&1 | openssl x509 -noout -text | grep -A1 'Subject Alternative Name:'
            X509v3 Subject Alternative Name: 
                DNS:*.cloudflare-dns.com, IP Address:1.1.1.1, IP Address:1.0.0.1, DNS:cloudflare-dns.com, IP Address:2606:4700:4700:0:0:0:0:1111, IP Address:2606:4700:4700:0:0:0:0:1001

Queste informazioni sono anche nel Visualizzatore certificati di Google Chrome nella scheda "Dettagli":

Questo certificato è valido per tutti i domini elencati (incluso il carattere jolly *) e gli indirizzi IP.

Sembra che il nome alternativo dell'oggetto certificato includa l'indirizzo IP:

Not Critical
DNS Name: *.cloudflare-dns.com
IP Address: 1.1.1.1
IP Address: 1.0.0.1
DNS Name: cloudflare-dns.com
IP Address: 2606:4700:4700::1111
IP Address: 2606:4700:4700::1001

Tradizionalmente immagino che avresti inserito solo i nomi DNS, ma Cloudflare ha inserito anche i loro indirizzi IP.

https://1.0.0.1/ è anche considerato sicuro dai browser.