3 pontos por GN⁺ 2024-11-21 | 1 comentários | Compartilhar no WhatsApp
  • Em um cenário em que informações pessoais e empresariais circulam com cada vez mais frequência pela internet, a Let’s Encrypt surgiu como uma autoridade certificadora voltada a reduzir a barreira de entrada para a adoção de TLS com certificados de servidor gratuitos
  • Navegadores e servidores já ofereciam suporte a TLS, mas, para operadores, emitir, instalar e renovar certificados era algo complexo e também custoso
  • Pesquisadores da Mozilla, Cisco, Akamai, EFF, IdenTrust e University of Michigan colaboraram por meio da ISRG para viabilizar a infraestrutura no 2º trimestre de 2015
  • Os princípios operacionais são gratuidade, automação, segurança, transparência, abertura e colaboração, incluindo a divulgação de registros de emissão e revogação e protocolos baseados em padrões abertos
  • O foco não era uma segurança controlada por uma organização específica, mas criar uma segurança de internet universal e aberta que toda a comunidade pudesse usar

A barreira dos certificados de servidor que dificultava a adoção de TLS

  • Informações pessoais e empresariais circulam com cada vez mais frequência pela internet, mas os usuários nem sempre conseguem saber quando essas transmissões acontecem
  • TLS é a tecnologia sucessora do SSL, e já é suportada por navegadores em todos os dispositivos e por servidores em data centers
  • O elemento central da comunicação protegida por TLS é o certificado de chave pública, que comprova que o usuário está realmente se comunicando com o servidor pretendido
  • Para muitos operadores de servidores, até mesmo um certificado básico de servidor ainda era um peso
    • O processo de solicitação podia ser confuso
    • Geralmente havia custo
    • A instalação correta era complicada
    • A renovação era trabalhosa

A autoridade certificadora gratuita e automatizada proposta pela Let’s Encrypt

  • A Let’s Encrypt é uma nova autoridade certificadora gratuita baseada em colaboração e abertura
  • Proprietários de domínios passaram a poder obter certificados básicos de servidor validados para seus domínios por meio de um processo de um clique
  • Mozilla Corporation, Cisco Systems, Akamai Technologies, Electronic Frontier Foundation, IdenTrust e pesquisadores da University of Michigan colaboraram por meio do Internet Security Research Group(ISRG)
  • A ISRG é uma entidade de benefício público da Califórnia e também acolhe a participação de outras organizações com os mesmos objetivos
  • Os princípios operacionais são os seguintes
    • Gratuito: proprietários de domínios podem obter certificados validados para seus domínios sem custo
    • Automação: o registro de certificados acontece durante a instalação ou configuração básica do servidor, e a renovação é realizada automaticamente em segundo plano
    • Segurança: atua como uma plataforma para implementar técnicas de segurança modernas e melhores práticas
    • Transparência: publica os registros de emissão e revogação de certificados para que qualquer pessoa possa inspecioná-los
    • Abertura: o protocolo de emissão e renovação automática será criado como um padrão aberto, e o máximo possível de software será fornecido como open source
    • Colaboração: funciona como um esforço conjunto que beneficia toda a comunidade, assim como os protocolos da internet
  • Informações sobre a ISRG e seus parceiros podem ser encontradas na página About

1 comentários

 
GN⁺ 2024-11-21
Opiniões no Hacker News
  • De longe, um dos melhores serviços; acabou com o negócio de vender certificados e tornou a internet mais segura.
    Houve uma época em que uma conexão HTTPS era algo usado só em projetos “sérios”, porque o custo do certificado era muito mais alto que o do domínio. A lógica era começar sem certificado e, se desse certo, pagar uns 100 dólares para comprar um.

    • Ainda hoje há bastante gente que, por desconhecimento, compra certificados diretamente da hospedagem todos os anos, como em 2013, ou paga por renovação automática.
    • Eu tinha um proxy configurado de qualquer jeito, que pedia certificados para qualquer domínio informado; um atacante descobriu isso e começou a enviar requisições HTTP com subdomínios aleatórios.
      Quando percebi, a primeira coisa que pensei não foi “e se eu for bloqueado pelo Let’s Encrypt?”, mas “desculpa por causar carga desnecessária ao Let’s Encrypt por causa da minha configuração preguiçosa”. O Let’s Encrypt foi, no mínimo, a melhor coisa que aconteceu à web nos últimos 10 anos.
    • A Mozilla recebe muitas críticas, mas só o letsencrypt já está tornando o mundo um lugar melhor.
      Antes disso, eu não usava SSL em nenhum dos meus serviços. O custo-benefício não fazia sentido. Depois dele, nunca mais deixei de usar.
    • Mesmo antes já havia serviços que ofereciam gratuitamente certificados “de verdade” para um único domínio, mas o processo era complicado e trabalhoso.
      Se você precisasse de um certificado curinga para cobrir vários subdomínios de um projeto pessoal, de repente ficava muito caro; é ótimo que esse problema tenha sido completamente resolvido.
    • Google/Chrome e Firefox também têm mérito por terem tornado possível uma autoridade certificadora gratuita e aberta.
  • Pelos nossos critérios, consideramos o 10º aniversário em 2025, mas agradecemos as palavras calorosas daqui.
    Hoje faz aproximadamente 10 anos desde o anúncio público de que lançaríamos o Let’s Encrypt, e o ano que vem marcará 10 anos desde que o Let’s Encrypt emitiu seu primeiro certificado de fato: https://letsencrypt.org/2015/09/14/our-first-cert/
    Em dezembro de 2015, ou seja, cerca de 9 anos atrás a partir de hoje, ele ficou disponível para todos sem convite: https://letsencrypt.org/2015/12/03/entering-public-beta/

    • Ter acontecido exatamente em dezembro de 2015 foi, por coincidência, perfeito para mim.
      Na época, eu só tinha dinheiro para comprar o domínio, não para pagar SSL, mas o site precisava de SSL. Graças ao SSL gratuito do Let’s Encrypt, o projeto deu certo.
  • Parece que foi ontem que pagávamos por certificados — e, pior, houve uma época em que rodávamos sem nenhum.
    É difícil acreditar que já se passaram 10 anos.

    • É difícil acreditar que ainda existam excêntricos anti-TLS.
  • Tenho sentimentos um pouco mistos sobre o Let’s Encrypt.
    É bom termos passado a conseguir certificados TLS gratuitos sem depender de empresas suspeitas como a StartSSL. Graças a isso, qualquer site pôde migrar facilmente para HTTPS, e o envio de dados sensíveis, como logins, por conexões não criptografadas praticamente desapareceu.
    Por outro lado, acho que ele reforçou a estrutura fundamentalmente quebrada do modelo de confiança de certificados TLS, em que qualquer autoridade certificadora pode emitir um certificado para meu domínio sem minha participação. Há muitas mitigações, como registros CAA e Certificate Transparency, mas elas não são uma solução 100%. Se o Let’s Encrypt não existisse, talvez houvesse mais incentivo para implementar mecanismos de confiança melhores, como DNSSEC+DANE, que restringem a emissão de certificados a entidades com autoridade real para determinar a propriedade do domínio.
    Também me preocupa a falta deliberada de compatibilidade retroativa no processo de migrar sites para TLS. Isso não é apenas uma questão pontual de ativar ou desativar TLS, mas de protocolos e suítes de cifras que continuam sendo descontinuados. Isso faz sentido para coisas que precisam ser seguras, como bancos ou e-mail, mas não acho que seja necessariamente necessário até para consultar informações estáticas e sem importância, como receitas. Acredito que problemas como operadoras inserindo anúncios ou outras coisas estranhas seriam melhor resolvidos por regulação.

    • Sobre a ideia de que, sem o Let’s Encrypt, haveria incentivo para implementar mecanismos de confiança melhores, eu vejo o contrário: o Let’s Encrypt expôs ainda mais esses problemas e agora fez com que pessoas com autoridade realmente se preocupem com eles.
      Se os certificados continuassem sendo algo doloroso, talvez surgisse algo melhor que TLS, mas não parece ser o caso. O problema fundamental continua difícil.
  • O que mais agradeço é o protocolo ACME
    Você se lembra de como os certificados eram renovados antes do Let’s Encrypt? Chaves privadas iam e vinham por e-mail como anexos ZIP. Era quase teatro de segurança e, pelo que sei, era uma prática comum em várias autoridades certificadoras. Sou grato ao Let’s Encrypt

    • Ainda estou renovando certificados da GlobalSign manualmente
      No processo de geração do CSR, criamos uma nova chave no servidor e executamos tudo no próprio servidor para garantir que a chave não saia do armazenamento interno dele. O CSR é enviado à GlobalSign, passa por um terceiro por causa dos procedimentos de uma grande empresa e, alguns dias depois, recebemos o certificado e o aplicamos no servidor
      Eu gostaria de usar ACME e manter a chave em um ramdisk em memória ou algo parecido, mas essa é uma das desvantagens de trabalhar em uma empresa menos ágil que um petroleiro
    • Para onde foi a solicitação de assinatura de certificado? O objetivo original era justamente evitar o envio de chaves privadas de um lado para outro
      Antes disso eu só tinha me envolvido um pouco com alguns certificados TLS, mas pelo menos os lugares pelos quais passei exigiam o método com CSR. Ainda assim, na prática, esses costumes horríveis talvez fossem mais comuns do que eu sabia
    • Usando ou não Let’s Encrypt, o que deveria ser enviado em um arquivo ZIP é a chave pública, não a chave privada
    • Em algumas das minhas configurações, ainda preciso fazer esse tipo de besteira
      Load balancers em ambientes de nuvem muitas vezes não se integram facilmente a provedores ACME externos como o letsencrypt, e provedores internos exigem que você mova o domínio para eles, o que nem sempre é possível. Nem todos os provedores de nuvem sequer têm esse recurso, e a maioria parece tratar ACME como algo acrescentado depois
      Dá para fazer uma gambiarra com scripts usando terraform, tarefas cron e coisas do tipo, mas fica sujo. O modo de falha é o site parar quando a renovação do certificado falha, e isso passou a acontecer com frequência graças à vida útil muito curta dos certificados. Já passei por isso
      Por isso, alguns dias atrás paguei o imposto do certificado wildcard. Paguei algumas centenas de dólares para não quebrar a cabeça evitando isso e fiquei com uma sensação ruim, mas não vale a pena gastar dias para economizar um custo que, pelo meu tempo, equivale a menos de 2 horas. Emitir o CSR, receber o certificado e copiá-lo para os load balancers relevantes é uma tarefa de 20 minutos
    • Quantas dessas autoridades certificadoras ainda estão no repositório de confiança de todo mundo?
  • Seria bom se algo assim existisse também no mundo dos certificados de desktop
    A Microsoft entrou em modo completamente insano com os requisitos atuais, e os vendedores de certificados dela estão ganhando mais dinheiro do que antes sem mexer um dedo
    O engraçado é que toda essa segurança, auditoria e validação interminável ainda se apoia em uma única foto de passaporte enviada por e-mail

  • Peter Eckersley (1978–2022) foi incluído postumamente no Internet Hall of Fame pelo trabalho de fundação do Let’s Encrypt
    Graças a Peter e a seus muitos colaboradores e colegas, a internet se tornou um lugar melhor

  • Por coincidência, recebi um e-mail de uma agência do governo holandês, que é um cliente em potencial, pedindo para não usarmos Letsencrypt
    Eles preferem pagar pelos certificados, mas não sei por quê. Pelo jeito, parecem não confiar

  • Muita gente não sabe que certificados HTTPS não impedem necessariamente certos tipos de ataque, como injeção de DNS
    Um exemplo da campanha de ataque DNSPionage, que obteve certificados válidos para usar em ataques, pode ser visto em <https://www.youtube.com/watch?v=exy5JwAU8qk>
    Em resumo, a emissão de certificados HTTPS é automatizada e depende da segurança do DNS, que é alcançada com DNSSEC, mas a maioria não implementa isso

    • Tecnicamente, é um ataque contra a autoridade certificadora e contorna a verificação de autorização de “esta pessoa realmente tem o direito de emitir um certificado para este domínio?”
      O problema é que, nesse caso, entradas CAA também não ajudam, porque se você consegue falsificar um registro A, também consegue falsificar um registro CAA. Não conheço DNS o suficiente para ter certeza se DNSSEC ajudaria aqui
      Outro ataque é o sequestro de IP. Nesse caso, algo como validação HTTP, que é o método comum do ACME, pode passar, mas não consegue contornar registros CAA. Mesmo que alguém possua o endereço IP apontado pelo meu registro A ou AAAA, se o meu CAA não tiver letsencrypt como emissor aprovado, essa pessoa não consegue emitir um certificado pelo letsencrypt
  • Let’s Encrypt é uma conquista enorme e agora se tornou infraestrutura essencial
    Baseá-lo em um protocolo aberto para que não se tornasse um ponto único de falha foi uma escolha inteligente, permitindo que a ideia sobreviva mesmo que uma única organização desapareça
    Espero que muitos outros aniversários como este venham pela frente