Let’s Encrypt encurta sua cadeia de confiança

• A Let’s Encrypt não vai renovar a assinatura cruzada (cross-sign) que expira em 30 de setembro de 2024 e vai migrar para uma cadeia de certificados mais curta, terminando na ISRG Root X1
• No início do lançamento, sua própria raiz ainda não era suficientemente confiável, então ela dependia da DST Root CA X3 da IdenTrust; agora, porém, o alcance de confiança da ISRG Root X1 se ampliou bastante
• A assinatura cruzada de raiz adicionada em 2021 para compatibilidade com Androids antigos foi uma medida temporária, que permitiu que dispositivos Android antigos confiassem nos certificados da Let’s Encrypt por mais 3 anos
• Nos últimos 3 anos, a proporção de dispositivos Android que confiam na ISRG Root X1 subiu de 66% para 93,9%, e a remoção da assinatura cruzada também reduz em mais de 40% os bytes de certificado no handshake TLS
• Usuários de Android 7.0 ou inferior são aconselhados a usar o Firefox Mobile, e operadores de sites e autores de clientes ACME devem verificar o tratamento de cadeias de acordo com o cronograma de transição de 2024

---

Contexto do fim da assinatura cruzada

• No início, para que seus certificados fossem amplamente confiáveis, a Let’s Encrypt assinou de forma cruzada seu certificado intermediário com a DST Root CA X3, da IdenTrust
  • A ideia era fazer com que os certificados emitidos por esse intermediário fossem confiáveis mesmo quando sua própria raiz, a ISRG Root X1, ainda não era amplamente confiável
• Com o tempo, a ISRG Root X1 passou a ser amplamente confiável por conta própria
• No fim de 2021, tanto o certificado intermediário assinado de forma cruzada quanto a própria DST Root CA X3 estavam previstos para expirar
  • Na época, os navegadores modernos confiavam na raiz da Let’s Encrypt, mas mais de um terço dos dispositivos Android ainda usava versões antigas do sistema operacional
  • Esses dispositivos poderiam deixar de confiar repentinamente em sites que usavam certificados da Let’s Encrypt
• Em 2021, a Let’s Encrypt aplicou uma assinatura cruzada diretamente à raiz, em vez de ao certificado intermediário, criando uma medida temporária que duraria mais que a DST Root CA X3
  • Com essa medida, dispositivos Android antigos puderam confiar nos certificados da Let’s Encrypt por mais 3 anos
• Essa assinatura cruzada expira em 30 de setembro de 2024

Por que mudar para uma cadeia mais curta

• A Let’s Encrypt não vai mais obter uma nova assinatura cruzada para estender a compatibilidade
  • Nos últimos 3 anos, a proporção de dispositivos Android que confiam na ISRG Root X1 subiu de 66% para 93,9%
  • O Android 14 pode atualizar o repositório de confiança sem uma atualização completa do sistema operacional, então essa proporção pode aumentar ainda mais
  • Remover a assinatura cruzada reduz em mais de 40% o número de bytes de certificados transmitidos no handshake TLS
  • Os custos operacionais também caem bastante, permitindo que a Let’s Encrypt concentre recursos em melhorias de privacidade e segurança

Cronograma de transição de 2024

• Quinta-feira, 8 de fevereiro de 2024: o fornecimento padrão da assinatura cruzada em solicitações ao endpoint da API /acme/certificate será interrompido
  • Para a maioria dos assinantes, o cliente ACME configurará a cadeia que termina na ISRG Root X1, e o servidor web oferecerá a cadeia mais curta no handshake TLS
  • A cadeia mais longa que termina na assinatura cruzada prestes a expirar ainda podia ser solicitada como cadeia alternativa
• Quinta-feira, 6 de junho de 2024: o fornecimento da cadeia mais longa com assinatura cruzada será totalmente interrompido
  • Isso ocorre pouco mais de 90 dias antes da expiração da assinatura cruzada, período equivalente à vida útil de um certificado
  • O cronograma visa garantir pelo menos um ciclo completo de emissão para que os assinantes possam sair da cadeia com assinatura cruzada
• Segunda-feira, 30 de setembro de 2024: o certificado de assinatura cruzada expira
  • Para a maioria dos usuários, isso não deve ser um evento específico; falhas de clientes já deveriam ter ocorrido nos 6 meses anteriores

O que usuários e operadores devem verificar

• Usuários de Android 7.0 ou inferior podem precisar tomar medidas para continuar acessando sites protegidos por certificados da Let’s Encrypt
  • A Let’s Encrypt recomenda instalar e usar o Firefox Mobile, que usa seu próprio repositório de confiança em vez do repositório de confiança do Android OS
• Operadores de sites devem verificar as estatísticas de uso do site e as strings user-agent ativas no 2º e 3º trimestres de 2024
  • Se as visitas de Android caírem repentinamente, é possível que haja um número significativo de usuários de Android 7.0 ou inferior
  • Recomenda-se orientar esses usuários a usar o Firefox Mobile
• Autores de clientes ACME devem baixar e instalar corretamente a cadeia de certificados fornecida pela API em cada emissão e renovação de certificado
  • Tipos de falhas no passado incluíram casos em que a cadeia não era baixada e apenas o certificado end-entity era fornecido
  • Também houve casos em que uma cadeia codificada de forma fixa era fornecida sem baixar a cadeia
  • Houve ainda casos em que a cadeia era baixada apenas na primeira emissão e não era baixada novamente na renovação
• Perguntas sobre a transição podem ser feitas no fórum da comunidade da Let’s Encrypt

[GN⁺]

Comentários do Hacker News

• Lembro que a Let's Encrypt anunciou no verão de 2019 que faria essa transição, mas depois adiou após ouvir o feedback da comunidade
  Eu fui uma das pessoas que pediu fortemente uma reconsideração na época, mas não imaginava que nesta questão eles ultrapassariam tanto as expectativas e atrasariam por 4 anos e meio. Sou grato por tratarem o ecossistema TLS com tanto cuidado

  • Pode explicar? Eu uso, mas frequentemente esqueço o quanto a Let's Encrypt é importante para o meu site

• Para cobrir 95% dos dispositivos Android, é preciso dar suporte até o Android 7.0 Nougat, de agosto de 2016
  https://en.wikipedia.org/wiki/Android_Nougat
  Para cobrir 95% dos dispositivos iOS, basta o iOS 14, de setembro de 2020, e mesmo olhando só para 90%, no Android é 8.1 (2017) e no iOS é 15 (2021)
  https://iosref.com/ios-usage
  https://en.wikipedia.org/wiki/IOS_14
  Parece que a Apple faz um trabalho melhor em convencer ou permitir que as pessoas migrem para sistemas operacionais mais recentes

  • A Apple não vende celulares de 10 dólares em países em desenvolvimento. Se você comparar aparelhos na mesma faixa de preço, dos principais fabricantes ou operadoras, a diferença provavelmente não será tão extrema
  • É mais simples. A Apple impede terceiros de fabricarem iPhones, enquanto o Google permite que terceiros fabriquem celulares Android
    O motivo de os dispositivos não serem atualizados é que o fabricante para de fornecer atualizações
  • As atualizações de sistema operacional são mal conduzidas pelo Google e pelos fabricantes de dispositivos em conjunto, mas não há motivo para que o bundle de CAs tenha de ficar atrelado à versão do sistema operacional
    Segundo a página do bundle de CAs do curl, o bundle da Mozilla tem cerca de 200 KB descompactado, e no meu Android o app do Chrome tem 25 MB, então mantê-lo atualizado com um aumento de 1% no tamanho do app parece razoável
    Claro, outros apps também podem querer CAs atualizadas, mas também vale discutir se precisam de todas as CAs ou apenas das que realmente têm chance de usar
  • Se você controla toda a stack de hardware e software, fica muito mais fácil manter os dispositivos antigos dos clientes atualizados
    O Google não pode fazer muita coisa se algum fabricante barato decidir não fornecer atualizações aos clientes. Pode exigir que forneçam atualizações por um certo período para obter ou manter a certificação Android, mas em algum momento esse fabricante pode simplesmente abandonar o próprio Android
    Além disso, a Qualcomm também deixa de fornecer kernels e blobs atualizados para chipsets antigos com o passar do tempo. O Google negociou para estender isso em relação aos antigos e lamentáveis 18 meses, mas a Qualcomm não tem obrigação de cooperar mais do que isso. Quando o Google começou a fabricar seus próprios chipsets, seu interesse nesse problema também diminuiu um pouco
    Não quer dizer que isso seja bom, mas no modelo do Android geralmente acaba sendo assim, e o modelo da Apple permite controlar melhor esse tipo de coisa
  • No meu caso, é por causa da câmera melhor

• O jeito como mantiveram a antiga assinatura cruzada funcionando foi bem interessante
  A nova assinatura cruzada era um tanto incomum, no sentido de se estender além da expiração da DST Root CA X3. Isso foi possível porque o Android intencionalmente não impõe a data de expiração de certificados usados como âncoras de confiança
  Na prática, as âncoras de confiança funcionam de forma bem diferente de outros certificados, o que pode surpreender
  [1] https://letsencrypt.org/2020/12/21/extending-android-compati...
  [2] https://alexsci.com/blog/name-non-constraint/

  • Essa solução não foi perfeita. A maior parte foi resolvida bem rápido, mas acabou gerando uma das discussões mais longas que já vi no fórum da LE: https://community.letsencrypt.org/t/help-thread-for-dst-root...
    Se me lembro bem, um dos grandes problemas era que versões antigas do OpenSSL verificavam a expiração da âncora raiz. E esse não foi o único problema: na empresa em que eu estava na época, o Ubuntu precisou aplicar algum patch para lidar com a situação, e o patch só saiu poucos dias antes da expiração, então alguns sistemas tiveram uma breve indisponibilidade. Tivemos de reconstruir em massa imagens Docker para corrigir o problema
    Esse paliativo foi tão agressivo e sem precedentes que imagino que só tenham seguido por esse caminho porque a diferença de custo em relação a obter uma assinatura cruzada de uma raiz não expirada e amplamente compatível era enorme. Também deve ter exigido muitos testes. Não foi perfeito, mas foi impressionante como, no geral, tudo transcorreu de forma relativamente suave
  • Fiquei um pouco surpreso ao descobrir que o método do Android não é o padrão em outros lugares. Eu achava que a validação temporal de uma cadeia de certificados TLS C0 -> C1 -> C2 ... -> Cn funcionava mais ou menos como este pseudocódigo
    1 time_check = now()
    2 for cert in Cn to C0
    3 if time_check < cert.valid_from || time_check > cert.valid_to
    4 return EXPIRED
    5 time_check = cert.issue_time
    6 return NOT_EXPIRED
    Mas, pesquisando, vi que na prática funciona sem a linha 5, então todas as verificações de tempo são feitas com base no horário atual. Todos os certificados da cadeia precisam estar válidos agora
    Certificados de assinatura de código funcionam do jeito que eu imaginava que TLS também funcionasse. Código com timestamp continua válido mesmo que o certificado raiz tenha expirado, desde que a raiz estivesse válida no momento do timestamp)

• Espero que o vencimento do certificado com assinatura cruzada não cause nada para a maioria das pessoas, mas a expiração da assinatura cruzada DST não foi assim
  Se bem me lembro, o GnuTLS não conseguia montar corretamente o caminho após a expiração. Parece que ele só construía o caminho até o certificado expirado, informava que ele estava expirado e parava, ignorando outros caminhos possíveis
  O pior é que o GnuTLS era a biblioteca TLS usada pelo apt ao usar HTTPS. HTTPS não era o padrão, mas nossa equipe de segurança queria distribuir todos os pacotes com segurança via vendoring, o que em si era razoável, mas o custo foi indisponibilidade. Acho que isso foi corrigido no Bullseye, e por pura sorte foi só cerca de uma semana antes da expiração. A Azure também teve várias interrupções relacionadas àquela expiração

  • Os operadores de todos os espelhos do apt não renovam os certificados LE com o certbot mais ou menos uma vez por mês? Nesse caso, depois de 6 de junho de 2024 eles deveriam receber certificados assinados pela nova raiz da LE, sem expiração e sem assinatura cruzada; estou deixando passar alguma coisa?

• Tirando usar HTTP sem criptografia, existe alguma solução proposta para fazer com que TLS deixe de ser o componente mais frágil da web?
  Mudanças constantes como descontinuação de protocolos, vencimento de certificados e substituições parecem ter ampliado demais a obsolescência programada

  • Não vejo o TLS como o componente mais frágil da web. Esse prêmio provavelmente vai para o DNS, o BGP ou, dependendo do critério, a us-east-1
  • O problema não é que o TLS continue mudando. Ele precisa mudar por segurança
    A parte ruim que leva à obsolescência programada é que os dispositivos deixam de receber atualizações do fabricante rápido demais, e terceiros também não podem atualizá-los
    A solução que eu preferiria é uma lei exigindo que o fabricante não possa parar de produzir atualizações de segurança antes de 10 anos após o fim das vendas ou, se parar ou quiser parar, tenha de liberar tudo como código aberto ou reembolsar integralmente todos os compradores
  • A maior parte do incômodo no TLS parece ser ter de acompanhar continuamente a reemissão de certificados
    A razão para isso é que a revogação distribuída em escala mundial é um problema absurdamente difícil. Para mitigar o fato de que parte da associação entre usuário e certificado é praticamente impossível de revogar, reduz-se a validade dos certificados para limitar o alcance do dano
    Claro que isso não consola muito, mas o mundo dos certificados de curta duração após o ACME ainda oferece uma experiência de desenvolvimento melhor do que o mundo de pesadelo dos certificados Verisign de longa duração. Vale lembrar que qualquer alternativa ao TLS inevitavelmente enfrentaria problemas parecidos
  • Fundamentalmente, acho que nenhuma entidade pode ser confiável para sempre. A melhor solução é fornecer atualizações de certificados separadas do caminho normal de atualização
    O formato de certificado x509 praticamente não mudou há muito tempo
    As mudanças no protocolo agora parecem estar se estabilizando. O TLS 1.2 foi introduzido em 2008 e ainda é considerado aceitável, então já não dá para chamar isso de novo. Muita gente já examinou isso a fundo, então esperamos que a maioria dos problemas já tenha aparecido
  • DANE: https://wikipedia.org/wiki/DNS-based_Authentication_of_Named...
    Na minha opinião, o que o Let's Encrypt faz é basicamente DANE, então imagino: por que não simplesmente oferecer suporte? Claro, pode haver casos de uso em que o DANE não seja adequado
    Não parece haver motivo para deixar que a perfeição impeça algo suficientemente bom, e quem quiser pode usar DANE

• Quando dizem que “reduzir significativamente os custos operacionais permite concentrar recursos em melhorar privacidade e segurança”, isso significa que estão pagando algo como milhões de dólares pela assinatura cruzada?

  • No Form 990 de 2021, foram pagos US$ 434.000 à Identrust sob a rubrica “Internet Services”. Não sei se eles recebem mais alguma coisa da Identrust além da assinatura cruzada, mas esse valor parece poder ser o custo da assinatura cruzada
    Como o custo total naquele ano foi de US$ 5,1 milhões, esse gasto representa quase 10% do orçamento
    [0]: https://beta.candid.org/profile/9328188?keyword=46-3344200&a...

• Alguém conhece os bastidores de como conseguiram que uma empresa de certificados fizesse a assinatura cruzada? O Let’s Encrypt não mata completamente o modelo de negócios deles?

  • O que o Let's Encrypt matou foi o modelo de negócios de vender certificados de validação de domínio por US$ 10 ao ano. Se você quisesse wildcard, era muito mais caro
    Empresas como RapidSSL ou GoDaddy provavelmente não teriam feito uma assinatura cruzada para o Let’s Encrypt a menos que recebessem uma proposta do tipo “comprem todo o nosso negócio de CA”
    Mas vender certificados DV não era o modelo de negócios da IdenTrust, então, como outros já estimaram, ela pode ter topado fornecer a assinatura cruzada por um valor de menos de seis dígitos. Pela forma como os certificados raiz TLS funcionam, a assinatura cruzada da IdenTrust era tão útil para a LE quanto a assinatura cruzada de uma CA altamente lucrativa
  • Se eu fosse uma empresa de certificados cujo mercado-alvo são as grandes empresas, pouco propensas a usar Let’s Encrypt, eu teria feito a assinatura cruzada para enfraquecer concorrentes mais dependentes de pequenas empresas ou de outros projetos atraídos pelo Let’s Encrypt
  • Provavelmente convenceram pagando. Se não fosse, outra empresa teria feito
    Também não parece que a IdenTrust tenha quebrado
    1 IdenTrust 48.5% 53.6%
    2 DigiCert Group 13.1% 14.5%
    3 Sectigo (Comodo Cybersecurity) 12.1% 13.4%
    4 GlobalSign 6.1% 6.7%
    5 Let's Encrypt 5.8% 6.4%
    6 GoDaddy Group 4.8% 5.3%
    https://en.wikipedia.org/wiki/Certificate_authority
  • De jeito nenhum. As principais autoridades certificadoras vendem todas para clientes corporativos e continuarão fazendo isso. A maioria dos usuários do Letsencrypt está muito mais próxima do uso pessoal ou hobby

• No fim de 2021, quando o certificado intermediário com assinatura cruzada e o próprio DST Root CA X3 expiraram, todos os navegadores modernos já confiavam na raiz da LE, mas mais de um terço dos dispositivos Android ainda rodavam sistemas operacionais antigos, então os sites que usavam certificados da LE corriam o risco de de repente deixarem de ser confiáveis para eles
  Só fiquei sabendo disso algumas semanas depois, mas parece que os usuários da Ubiquiti também foram afetados

• Recentemente, ao migrar o backend da AWS para um servidor local, tive que trocar o Letsencrypt por ZeroSSL
  Isso porque os equipamentos IoT de 2016 ainda suportados não tinham o certificado raiz necessário para validar certificados da LE. Acho que provavelmente teve relação com a expiração em 2021 do certificado raiz R3 que a LE usava
  Foi bem chocante perceber que a expiração de um único certificado pode transformar em tijolo toda uma linha de produtos já vendida. Neste caso, não foi um grande problema porque havia um certificado raiz válido de outro provedor

  • Quando o SHA-1 foi sendo descontinuado gradualmente, várias CAs reclamaram bastante no mozilla.dev.security.policy porque tinham colocado certificados SHA-1 em dispositivos médicos e sistemas de POS, e quase não havia forma de atualizá-los
    Elas chegaram a continuar emitindo mesmo depois da data definida pelo CA/Browser Forum. Na época, achei que todo mundo tinha percebido que usar a Web PKI sem um meio de enviar atualizações era algo incompatível, mas pelo visto não

• Desde logo após a introdução da assinatura cruzada, sites voltados para desktop vêm removendo os certificados com assinatura cruzada
  Isso porque surgiram problemas de compatibilidade que antes não existiam, e alguns validadores de certificados travavam ao encontrar um certificado raiz expirado. Como os usuários afetados não eram técnicos, nunca conseguiram descobrir a causa raiz