- A Let's Encrypt em breve deve oferecer suporte à emissão de certificados com SAN de endereço IP, inicialmente apenas no perfil shortlived, com expiração de 6 dias, e por um período operando de forma restrita via whitelist
- Até o lançamento oficial, não há cronograma detalhado nem orientações de inscrição, enquanto testes internos e preparativos seguem em andamento
- No ambiente de staging, foram divulgados um certificado de exemplo com endereço IPv6 e um site que o utiliza, com pedido para que a comunidade compartilhe anomalias ou feedback
- Foi encontrado um bug no Firefox relacionado à exibição de IP SAN (BZ #1973855), e os testes continuam
- Exemplos reais de teste confirmaram potencial de confusão em casos que misturam DNS SAN e IP SAN, mostrando que a notação de TLD e de endereços IPv6 pode parecer semelhante
Let's Encrypt, Getting ready to issue IP address certificates
Situação da preparação para suporte a IP SAN
- A Let's Encrypt planeja em breve oferecer suporte, em ambiente de produção, à emissão de certificados que incluam IP SAN
- Esses certificados serão emitidos apenas no perfil shortlived, com validade de 6 dias, e por algum tempo terão operação restrita via allowlist
- Ainda não há definição da data de lançamento oficial nem de como solicitar entrada na allowlist, pois ainda são necessários preparativos internos adicionais
Testes e certificados de exemplo
- No ambiente de staging, foram divulgados exemplos de certificado com IP SAN e de site real aplicado (endereço IPv6)
- Foi pedido aos usuários da comunidade que compartilhem qualquer anomalia, ponto interessante ou problema encontrado
Casos mistos de IP SAN e DNS SAN
- Durante os testes, foi demonstrada a possibilidade de emitir certificados com DNS SAN e IP SAN ao mesmo tempo, além de casos de confusão na forma de exibição
- Certos TLDs, como
.cafe, podem se parecer com a notação de endereços IPv6, o que pode gerar confusão
- Também foi identificado no Firefox um bug relacionado à exibição de IP SAN (BZ #1973855)
Resumo
- O suporte da Let's Encrypt a certificados para endereços IP será aplicado primeiro de forma limitada, com whitelist e certificados de curta duração
- Antes da aplicação em serviços reais, serão avaliadas estabilidade e compatibilidade por meio de testes em vários casos e feedback da comunidade
- Questões de exibição no navegador decorrentes da mistura de SAN de nomes DNS e endereços IP também estão sendo discutidas
1 comentários
Comentários do Hacker News
Acho que certificados para endereços IP também são úteis.
Mas acho que teria um impacto muito maior se o Let’s Encrypt desse suporte a certificados S/MIME.
Há anos existe uma situação meio cômica em torno da criptografia de e-mail.
Agora a maioria dos principais clientes de e-mail já oferece suporte direto à criptografia S/MIME, mas, assim como na web, para uma experiência fluida o usuário precisa obter um certificado de uma CA.
Já não restam CAs que ofereçam certificados S/MIME confiáveis, gratuitos e válidos por mais de um ano.
O resultado é que usuários individuais praticamente não usam criptografia de e-mail.
PGP é inconveniente demais, então quase ninguém além de entusiastas técnicos usa.
Acho que agora também deveríamos criptografar nosso e-mail.
Aliás, se a CA gerar a chave secreta no lugar do usuário, eu não consideraria esse certificado confiável.
Além disso, no S/MIME é preciso manter os certificados antigos para descriptografar e-mails antigos, então certificados que mudam com frequência são pouco práticos.
Sobre a observação de que é preciso o certificado antigo para descriptografar e-mails antigos no S/MIME, acho que não é obrigatório trocar a chave com frequência, porque a própria chave de descriptografia pode ser reutilizada ao emitir um novo certificado com a mesma chave existente (por exemplo, a opção
--reuse-keydo certbot).Se isso é uma boa prática já é outra discussão.
O que realmente faz falta é uma automação de emissão de certificados no estilo ACME.
Hoje o processo de renovação de certificado é incômodo demais, por isso quase ninguém usa.
O PGP agora tem uma abordagem chamada WKD (Web Key Directory) link, que permite aplicar a cadeia de confiança do TLS ao e-mail.
Certificados TLS são muito mais fáceis de obter do que certificados S/MIME.
Terceiros fazendo a gestão de identidade também pode ajudar, mas a maioria das pessoas trabalha em empresas nas quais esse tipo de gestão de identidade não se encaixa muito bem.
Se for em uma empresa, acho mais adequado fazer a gestão de identidade internamente.
A confusão recente do Signalgate 1.0 link me pareceu bastante instrutiva, no sentido de mostrar uma falha de gestão de identidade em criptografia de ponta a ponta.
Por isso, acho que certificados S/MIME ou WKD também poderiam ser úteis para governos, se viessem a ser adotados como sistemas realmente utilizáveis.
Pessoalmente sou relativamente otimista quanto à criptografia de e-mail baseada em S/MIME, mas sinto que a viabilidade prática é baixa.
Usuários comuns muitas vezes já têm dificuldade até para gerenciar a própria chave privada, sem falar em cuidar adequadamente da senha do e-mail.
No fim, isso leva a uma situação em que a emissão de certificados precisa ser centralizada por domínio, ou então os usuários acabam sem conseguir obter certificados, enquanto cibercriminosos passam a enviar e-mails assinados com S/MIME.
Quando passkeys se tornarem comuns e houver renovação geracional, aí sim talvez faça sentido esperar que as pessoas lidem diretamente com pares de chaves.
Minha opinião é que criptografia de e-mail simplesmente deveria desaparecer.
Referência: Stop using encrypted email
Não conheço bem a criptografia S/MIME, então tenho uma dúvida.
Por que seria necessário usar o mesmo protocolo para descriptografar e-mails antigos?
Eu sempre achei que certificados serviam para a camada de transporte, e que no armazenamento real haveria alguma forma própria de criptografia do servidor ou host; então me parece mais lógico separar as coisas, usando certificados de curta duração no transporte e a criptografia que se quiser para o armazenamento. Estou deixando passar alguma coisa?
Fico curioso para saber se todas as entidades que administram endereços, como ISPs e provedores de nuvem, também vão embarcar nessa.
Elas às vezes reciclam IPs muito rapidamente, em alguns casos até em menos de 6 dias.
Eu entenderia se o provedor de nuvem aplicasse um período de cooldown antes de reanalisar o IP ou consultasse e revogasse certificados associados àquele IP; caso contrário, surge a complexidade de o usuário ter que validar o host header por conta própria, rejeitar conexões baseadas em IP que não deseja, ou esperar até que certificados legados desapareçam por completo.
Também fico curioso para saber quantos certificados IP será possível obter em cada provedor de nuvem e quanto isso vai custar.
Na verdade, acho que isso não é tão diferente do fornecimento de domínios customizados/vanity por provedores de nuvem.
Por exemplo, no Azure você pode associar a uma VM um DNS como
myapp.westus.cloudapp.azure.com, e qualquer pessoa pode obter da CA um certificado para esse domínio referência.Nesses casos também não há um cooldown separado; quando a VM desaparece, outra pessoa pode assumir aquele domínio imediatamente.
Certificados HTTPS podem ser renovados por 90 dias até um dia antes do vencimento do domínio, e a CA também não tem como saber o limite do cartão de crédito.
Quem vai usar certificados IP provavelmente não é o mesmo tipo de usuário que abandona o IP logo em seguida.
Os casos mais úteis parecem ser softwares legados muito peculiares, ou situações como a do Cloudflare em que é preciso suporte a ECH (Encrypted Client Hello) ou ESNI (Encrypted SNI) sem IP compartilhado.
No primeiro caso (legado), a pessoa não vai abrir mão do IP com facilidade; no segundo (ECH/ESNI), acho difícil que conexões ao domínio real cheguem a se concretizar.
Sobre a pergunta se os ISPs precisam embarcar nisso, eu diria justamente o contrário.
O papel dos ISPs não é alocar IPs de um jeito alinhado ao padrão TLS; o papel do emissor de certificados TLS é fazer a “validação de identidade” de acordo com a forma como o ecossistema vincula identidades (domínios, IPs etc.).
Ainda não ficou detalhado como isso será feito desta vez, mas meu palpite é que o Let’s Encrypt vai manter uma lista de IPs que são transferidos por longos períodos com base em ASNs (números de sistema autônomo), talvez em uma base pública mantida de forma colaborativa, como a Mozilla Public Suffix List, e só emitirá certificados para os IPs dessa lista, tratando revogações quando houver mudança para outro ASN.
Espero que isso também seja compartilhado com outros emissores ACME.
Se a dúvida é quantos certificados IP podem ser obtidos em várias nuvens e por qual preço, também fico curioso se no futuro haverá suporte a certificados curinga.
No meu caso, eu já ficaria muito satisfeito se pudesse ter um certificado IP válido por apenas um dia para testar uma URL
https.Tecnicamente entendo como funciona, mas fico curioso sobre qual é exatamente o uso pretendido no mundo real.
Acho que só o suporte a ECH (Encrypted Client Hello) ou ESNI (Encrypted SNI) já faz isso valer muito a pena.
No início do ESNI, só grandes proxies HTTPS como o Cloudflare conseguiam aplicar isso, então a ideia de certificados IP parecia algo quase de sonho; agora qualquer servidor pode participar de ESNI/ECH.
Se os clientes começarem a presumir que todo servidor tem um certificado IP e passarem a tentar ESNI, isso pode ajudar muito a melhorar a privacidade da internet como um todo.
Várias respostas já citaram bons exemplos, mas também vale mencionar NTS (Network Time Security).
Sem certificado IP, o NTS também fica dependente de DNS, então se o DNS cair, a sincronização de tempo autenticada se torna impossível.
O DNSSEC falha na validação se o relógio não estiver correto, e com dependência de DNS+NTS não há recuperação possível.
Se for possível distribuir tempo autenticado sem depender de DNS, usando um certificado que inclua o IP, isso resolve esse problema.
Também pode ser útil quando é preciso manter um certificado válido durante mudanças significativas de DNS, por exemplo para garantir acesso ao painel ou para que automações antigas não parem por causa de erro de DNS.
Outro caso seria montar ambientes de teste de forma mais simples, sem depender de DNS, ou expor rapidamente algo como o Cockpit para acesso externo.
Na prática, abre uma variedade de usos limitada só pela imaginação.
Também seria uma abordagem interessante para fazer DoTLS (consultas DNS sobre TLS) “oportunista” voltado a authdns (servidores DNS autoritativos).
O servidor DNS autoritativo poderia atender na porta de DoTLS com um certificado contendo o IP público no SAN (Subject Alternative Name).
Hoje isso já é possível com hostname, mas como um único IP público pode ter vários nomes diferentes, um SAN baseado em IP cria uma vinculação mais clara.
Acho que isso atende bem quem quer usar algo sem domínio, ligando diretamente um IP ao projeto, seja por hobby ou para algo descartável.
Fico pensando por que os RIRs (registros regionais da internet) ou LIRs (registros locais da internet) não emitem eles mesmos esses certificados.
Por que um terceiro teria que validar o registrante no RIR ou LIR?
Será que os registrantes de domínio já têm trabalho demais?
Fico em dúvida se o motivo é o mesmo.
Isso me dá a sensação de que surgiram mais brechas para abusar de TLS.
Antes o problema era emitir certificados para domínios que você não possui; agora talvez passe a ser possível emitir certificados para IPs que você não possui.
Imagino o pessoal black hat comemorando isso no Telegram.
Fico curioso se isso permitiria acessar por
httpsa interface de administração do roteador local, tipo192.168.0.1, sem erro de self-signed.Não, mas talvez um dia possa.
Endereços locais não são alocados de forma universal nem roteados globalmente, então essencialmente não há como validá-los.
Mas se o fabricante do roteador realmente quiser, em um equipamento atrás de nada como CG-NAT e com IPv4 público atribuído, seria possível solicitar um certificado para o endereço público.
Com IPv6 isso seria ainda mais fácil, porque na maioria dos casos ele é roteado globalmente.
Não, e nem deveria.
Na prática, dá para fazer isso tranquilamente combinando um proxy, um domínio real, um certificado real e reescrita de DNS.
Por exemplo, usando a interface do nginx manager e o adguard como DNS.
Basta restringir o DNS do roteador ao adguard, reescrever seu domínio para o proxy, registrar o domínio e emitir um certificado real.
Eu mesmo já uso
httpsem todos os meus serviços locais.Certificados não serão emitidos para IPs privados.
O mesmo IP privado pode apontar para equipamentos totalmente diferentes em redes diferentes, então não existe garantia de posse exclusiva.
É o contrário.
Se não for um IP público, não dá para emitir um certificado válido.
Já existe o caminho de obter um certificado de domínio e encaminhar esse domínio para
192.168.0.1.Para obter o certificado, você precisa realmente possuir aquele IP, ou seja, um IP público.
Será que isso também valeria para IPv4 interno (
192.168.x.x,172.16.x.x,10.x.x.x)? Ou será que os navegadores deveriam mesmo ignorar esses endereços? E, se não, daria para emitir ao menos um certificado curinga para a rede interna?No contexto de certificados emitidos por uma CA pública, acho que essa pergunta nem faz muito sentido.
Diferentemente de domínios, um IP privado como
10.10.10.10é “possuído” por inúmeras pessoas ao mesmo tempo.Para desenvolvimento interno existem ferramentas como mkcert, e para recursos internos compartilhados em uma empresa, certificados TLS baseados em domínio costumam ser mais simples.
Se fosse possível provar que a chave privada do equipamento jamais seria exposta, até daria para tentar isso com uma CA existente.
Mas, no caso de certificados para endereços internos, se alguém comprar o dispositivo e extrair a chave privada, o problema de revogação da chave passa a ser imediato.
Por isso, se o equipamento for confiável, o mais realista é importar manualmente o certificado para acessar sem erro ou, se houver vários dispositivos, montar uma CA própria para distribuir certificados.
Com um servidor ACME open source, dá até para automatizar a emissão internamente do mesmo jeito que o Let’s Encrypt faz.
A ideia seria apontar o DNS primeiro para um servidor público para emitir o certificado e depois fazer o DNS resolver internamente para
192.168..., copiando então o certificado e a chave.Só é preciso tomar cuidado porque alguns roteadores podem simplesmente descartar respostas DNS que encaminhem para endereços internos, então convém testar antes.
Acho que os navegadores não deveriam ignorar redes privadas.
No meu caso, uma rede privada é só meu roteador local, mas para outras pessoas pode ser uma rede que cobre o mundo inteiro.
É interessante que o certificado de exemplo não tenha campo subject.
Será que isso acontece por ele ter sido solicitado por IP e trazer DNS no SAN?
Isso já foi aplicado no perfil de certificados curtos de 6 dias, mas ainda não no perfil “clássico” de 90 dias.
Alguém brinca que talvez seja hora de a vulnerabilidade CVE-2010-3170 voltar aos holofotes.
Mas, na prática, para explorar isso ainda seria necessário que uma CA com comportamento incorreto emitisse o certificado correspondente, então acho improvável.
Uma pena que certificados para endereços IP não possam ser emitidos por desafio DNS.
Mas entendo o motivo.