Por que meu navegador acha que https://1.1.1.1 é seguro?


133

Quando visito https://1.1.1.1 , qualquer navegador da Web que eu considere considera o URL seguro.

Isto é o que o Google Chrome mostra:

Barra de endereços do Google Chrome 65.0.3325.181 mostrando https://1.1.1.1

Normalmente, quando tento visitar um site HTTPS por meio do endereço IP, recebo um aviso de segurança como este:

Barra de endereços do Google Chrome 65.0.3325.181 mostrando https://192.168.0.2

Pelo meu entendimento, o certificado do site precisa corresponder ao domínio, mas o Visualizador de Certificados do Google Chrome não mostra 1.1.1.1:

Visualizador de certificado: * .cloudflare-dns.com

Artigo da GoDaddy na base de conhecimento "Posso solicitar um certificado para um nome de intranet ou endereço IP?" diz:

Não - não aceitamos mais solicitações de certificado para nomes de intranet ou endereços IP. Esse é um padrão de todo o setor , não específico do GoDaddy.

( ênfase minha)

E também:

Como resultado, a partir de 1º de outubro de 2016 , as Autoridades de Certificação (CAs) devem revogar certificados SSL que usam nomes de intranet ou endereços IP .

( ênfase minha)

E:

Em vez de proteger endereços IP e nomes da intranet, você deve reconfigurar os servidores para usar os FQDNs (nomes de domínio totalmente qualificados), como www.coolexample.com .

( ênfase minha)

É bem após a data de revogação obrigatória em 01 de outubro de 2016, mas o certificado 1.1.1.1foi emitido em 29 de março de 2018 (mostrado na captura de tela acima).


Como é possível que todos os principais navegadores pensem que https://1.1.1.1 é um site HTTPS confiável?


10
Vale ressaltar que há uma enorme diferença entre 192.168.0.2 e 1.1.1.1. Um 192.168.0.2não existe fora da sua intranet. Se você criou seu próprio certificado autoassinado, 192.168.0.2seria confiável e poderia usar a mesma abordagem para a SAN, em um domínio como fake.domain. Vale ressaltar que esse 1.1.1.1não é um endereço IP reservado, pelo que parece, qualquer CA teria emitido o certificado.
Ramhound

12
blog.cloudflare.com/announcing-1111 "Estamos animado hoje para dar mais um passo em direção a essa missão com o lançamento do 1.1.1.1 -., serviço de DNS do consumidor privacidade-primeiro o mais rápido do Internet"

11
Eu acho que você colocou a frase errada. Eles provavelmente queriam dizer 'deve revogar certificados SSL que usam intranet (nomes ou endereços IP)' não '' deve revogar certificados SSL que usam (nomes de intranet) ou endereços IP '.
Maciej Piechotka 12/04/19

11
@MaciejPiechotka está correto, isso significa "deve revogar certificados SSL que usam nomes de intranet ou endereços IP de intranet"
Ben Ben

2
Aliás ... não existe revogação obrigatória. Literalmente, nenhuma organização na Terra tem esse tipo de poder. O mais próximo que você fica é de um grupo de CAs concordando em fazer uma coisa.
Chao

Respostas:


95

Inglês é ambíguo . Você estava analisando assim:

(intranet names) or (IP addresses)

ou seja, proibir totalmente o uso de endereços IP numéricos. O significado que corresponde ao que você está vendo é:

intranet (names or IP addresses)

ou seja, proibir certificados para os intervalos de IP privados como 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16, bem como para nomes particulares que não são visíveis no DNS público.

Certificados para endereços IP roteados publicamente ainda são permitidos, mas geralmente não são recomendados para a maioria das pessoas, especialmente aquelas que também não possuem um IP estático.


Esta declaração é um conselho, não uma alegação de que você não pode proteger um endereço IP (público).

Em vez de proteger endereços IP e nomes da intranet, você deve reconfigurar os servidores para usar os FQDNs (nomes de domínio totalmente qualificados), como www.coolexample.com

Talvez alguém do GoDaddy tenha interpretado mal o texto, mas é mais provável que eles desejem manter seus conselhos simples e que recomendem o uso de nomes DNS públicos em certificados.

A maioria das pessoas não usa um IP estático estável para seus serviços. O fornecimento de serviços DNS é o único caso em que é realmente necessário ter um IP conhecido e estável em vez de apenas um nome. Para qualquer outra pessoa, colocar o seu IP atual no seu certificado SSL restringiria suas opções futuras, porque você não poderia permitir que outra pessoa começasse a usá-lo. Eles podem se passar por seu site.

O Cloudflare.com possui o controle do endereço IP 1.1.1.1 e não planeja fazer algo diferente com ele em um futuro próximo, por isso faz sentido que eles coloquem o IP no certificado. Especialmente como provedor de DNS , é mais provável que os clientes HTTPS visitem seu URL por número do que em qualquer outro site.


5
Isso responde exatamente porque eu estava confuso. Enviei uma sugestão ao GoDaddy para melhorar a redação do artigo . Espero que eles o consertem para esclarecer "(nome interno do servidor) ou (endereço IP reservado)", conforme documentado no CAB Forum .
Deltik

14
Pedanticamente, o Cloudflare não "possui" o endereço 1.1.1.1. É de propriedade do APNIC Labs , que deu ao Cloudflare permissão para operar um resolvedor de DNS lá em troca da assistência do Cloudflare no estudo do grande volume de pacotes de lixo endereçados por engano a esse IP .
22418 Kevin

12
Pedanticamente, @Kevin, o APNIC também não é o proprietário. Este artigo menciona a questão da propriedade e usa a frase "alocado para". A IANA, parte da ICANN, alocou o intervalo de endereços à APNIC, que alocou esses endereços ao Cloudflare. Os endereços IPv4 são simplesmente uma maneira elegante de escrever um número de 0-4294967296 (se você executar ping em 16843009 em muitos sistemas operacionais, verá uma resposta do 1.1.1.1) e os EUA não reconhecerão possuir um número (portanto, por que o nome "Pentium" foi criado)
TOOGAM

5
A coisa Intel foi um caso de marca, não a propriedade ...
StarWeaver

3
@TOOGAM: Quero dizer que, no sistema whois, que eu vinculei especificamente, 1.1.1.1 é alocado ao APNIC Labs. Se você escolher questões sobre alocação versus propriedade, não altere o significado de "alocado".
22418 Kevin

102

A documentação do GoDaddy está errada. Não é verdade que as autoridades de certificação (CAs) devem revogar certificados para todos os endereços IP ... apenas endereços IP reservados .

Fonte: https://cabforum.org/internal-names/

A autoridade de certificação para https://1.1.1.1 era o DigiCert , que, ao escrever esta resposta, permite comprar certificados de site para endereços IP públicos.

O DigiCert tem um artigo sobre isso chamado Emissão interna de certificado SSL de nome de servidor após 2015 :

Se você for um administrador de servidor usando nomes internos, precisará reconfigurar esses servidores para usar um nome público ou alternar para um certificado emitido por uma CA interna antes da data limite de 2015. Todas as conexões internas que exigem um certificado de confiança pública devem ser feitas por nomes públicos e verificáveis (não importa se esses serviços são acessíveis ao público).

( ênfase minha)

O Cloudflare simplesmente obteve um certificado para o endereço IP 1.1.1.1dessa CA confiável.

A análise do certificado para https://1.1.1.1 revela que o certificado utiliza SANs (Subject Alternative Names) para abranger alguns endereços IP e nomes de domínio comuns:

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

Essas informações também estão no Visualizador de certificados do Google Chrome, na guia "Detalhes":

Visualizador de certificado: Detalhes: * .cloudflare-dns.com

Este certificado é válido para todos os domínios listados (incluindo o curinga *) e endereços IP.


O link do seu artigo não parece estar funcionando. Melhor citar as informações relevantes.
Ramhound

11
Eu acho que não é tão errado quanto enganoso. Ele deve estar entre colchetes, pois 'deve revogar certificados SSL que usam intranet (nomes ou endereços IP)' não '' deve revogar certificados SSL que usam (nomes de intranet) ou endereços IP '.
Maciej Piechotka 12/04/19

3
Bem, isso faz dizer "nomes de intranet ou endereços IP". Nomes da intranet ou endereços IP da intranet. Não está errado, é apenas o OP que o lê seletivamente.
Leveza raças em órbita

45

Parece que o Nome Alt do Assunto do Certificado inclui o endereço 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

Tradicionalmente, acho que você só colocaria nomes DNS aqui, mas o Cloudflare também colocou seus endereços IP.

https://1.0.0.1/ também é considerado seguro pelos navegadores.


11
Não vejo como isso responde à pergunta. A publicação do conteúdo de um certificado não explica por que esse certificado pode ser entregue.
Dmitry Grigoryev

18
@DmitryGrigoryev: Mas isso não provar que esse certificado foi entregue, que foi um grande ponto de confusão na questão (o OP não poderia encontrar 1.1.1.1 listados na cert)
Leveza raças em órbita

3
Essa resposta realmente responde à pergunta do autor. Embora o autor tenha entrado em mais detalhes com relação à sua confusão, isso identifica o fato, o certificado em questão é realmente válido. Desde o autor da pergunta, nunca nos forneceu o que o GoDaddy realmente disse, difícil responder à pergunta com qualquer outra coisa.
Ramhound

4
@DmitryGrigoryev - Se a pergunta for "Por que meu navegador acha que 1.1.1.1 é seguro?" (o título desta página) ou "Como é possível que todos os principais navegadores pensem que 1.1.1.1 é um site HTTPS confiável?" (a única pergunta real dentro do corpo), "porque 1.1.1.1 está listado como uma SAN no certificado" responde claramente a essa pergunta.
precisa saber é o seguinte

@DmitryGrigoryev " não explica por que esse certificado pode ser entregue ", então a pergunta não é clara, pois nem sequer contém as informações completas do certificado e não é claramente uma questão técnica sobre a implementação do TLS nos navegadores ou uma questão de política sobre o CA, mas uma mistura de ambos
curiousguy
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.