10.º aniversario de Let’s Encrypt, el punto de partida con la meta de masificar SSL/TLS
(letsencrypt.org)- En un contexto donde la información personal y empresarial circula cada vez más por internet, Let’s Encrypt surgió como una autoridad certificadora que buscaba reducir la barrera de entrada para la adopción de TLS con certificados de servidor gratuitos
- Aunque los navegadores y los servidores ya son compatibles con TLS, para los operadores la emisión, instalación y renovación de certificados seguía siendo un proceso complejo y costoso
- Mozilla, Cisco, Akamai, EFF, IdenTrust e investigadores de la University of Michigan colaboraron a través de ISRG para impulsar el suministro de infraestructura en el segundo trimestre de 2015
- Sus principios operativos son gratuidad, automatización, seguridad, transparencia, apertura y colaboración, e incluyen la publicación de registros de emisión y revocación y protocolos de estándares abiertos
- El enfoque no era una seguridad controlada por una organización específica, sino crear una seguridad de internet universal y abierta que toda la comunidad pudiera usar
La barrera de los certificados de servidor que frenaba la adopción de TLS
- Aunque la información personal y empresarial circula cada vez más por internet, no siempre es fácil para los usuarios saber cuándo ocurre esa transmisión
- TLS es la tecnología sucesora de SSL, y ya es compatible con los navegadores de todos los dispositivos y los servidores de centros de datos
- La pieza clave de una comunicación protegida con TLS es el certificado de clave pública, que demuestra que el usuario realmente se está comunicando con el servidor que pretende
- Para muchos operadores de servidores, incluso un certificado básico de servidor seguía siendo una carga
- El proceso de solicitud podía ser confuso
- Normalmente tenía un costo
- Instalarlo correctamente era complicado
- Renovarlo era engorroso
La autoridad certificadora gratuita y automatizada que propuso Let’s Encrypt
- Let’s Encrypt es una nueva autoridad certificadora gratuita basada en la colaboración y la apertura
- Los propietarios de dominios pueden obtener un certificado básico de servidor validado para su dominio mediante un proceso de un clic
- Mozilla Corporation, Cisco Systems, Akamai Technologies, Electronic Frontier Foundation, IdenTrust e investigadores de la University of Michigan colaboran a través de Internet Security Research Group (ISRG)
- ISRG es una corporación de beneficio público de California y también da la bienvenida a la participación de otras organizaciones con el mismo objetivo
- Sus principios operativos son los siguientes
- Gratis: los propietarios de dominios pueden obtener certificados validados para ese dominio sin costo
- Automatización: el registro del certificado se realiza durante la instalación o configuración inicial del servidor, y la renovación se ejecuta automáticamente en segundo plano
- Seguridad: sirve como plataforma para implementar técnicas de seguridad modernas y mejores prácticas
- Transparencia: publica los registros de emisión y revocación de certificados para que cualquiera pueda inspeccionarlos
- Apertura: los protocolos de emisión y renovación automáticas se crean como estándares abiertos, y se ofrece como software de código abierto tanto como sea posible
- Colaboración: funciona como un esfuerzo conjunto que beneficia a toda la comunidad, al igual que los protocolos de internet
- La información sobre ISRG y sus socios puede consultarse en la página About
1 comentarios
Opiniones de Hacker News
Por lejos, uno de los mejores servicios; hizo que se dejara de lucrar con los certificados y volvió Internet más seguro.
En una época, una conexión HTTPS era algo que se usaba solo en proyectos “serios”, porque el costo del certificado era mucho más alto que el del dominio. La idea era empezar sin certificado y, si el proyecto funcionaba, pagar unos 100 dólares para comprar uno.
Cuando lo descubrí, lo primero que pensé no fue “¿y si Let’s Encrypt me bloquea?”, sino “perdón por causarle carga innecesaria a Let’s Encrypt por mi configuración floja”. Let’s Encrypt es, como mínimo, lo mejor que le pasó a la Web en los últimos 10 años.
Antes de eso, no usaba SSL en ninguno de mis servicios. No cerraba la relación costo-beneficio. Desde entonces, no hay caso en que no lo use.
Si necesitabas un certificado wildcard que cubriera varios subdominios de proyectos personales, de pronto se volvía carísimo; me alegra que ese problema se haya resuelto por completo.
Según nuestro criterio, vemos el 10.º aniversario como en 2025, pero agradecemos las palabras cálidas de aquí.
Hoy se cumplen aproximadamente 10 años desde que anunciamos públicamente que lanzaríamos Let’s Encrypt, y el año que viene se cumplirán 10 años desde que Let’s Encrypt emitió su primer certificado real: https://letsencrypt.org/2015/09/14/our-first-cert/
En diciembre de 2015, es decir, hace unos 9 años desde hoy, quedó disponible para que cualquiera lo usara sin invitación: https://letsencrypt.org/2015/12/03/entering-public-beta/
En ese momento solo tenía dinero para comprar el dominio, no para pagar SSL, pero el sitio necesitaba SSL. Gracias al SSL gratuito de Let’s Encrypt, el proyecto tuvo éxito.
Parece que fue ayer cuando pagábamos por certificados, y peor aún, hubo una época en que operábamos directamente sin ellos.
No puedo creer que ya hayan pasado 10 años.
Tengo opiniones encontradas sobre Let’s Encrypt.
Está bueno que haya sido posible obtener certificados TLS gratis sin depender de proveedores sospechosos como StartSSL. Gracias a eso, cualquier sitio web pudo migrar fácilmente a HTTPS, y prácticamente desapareció el envío de datos sensibles, como inicios de sesión, por conexiones sin cifrar.
Por otro lado, creo que reforzó la estructura fundamentalmente rota del modelo de confianza de los certificados TLS, en el que cualquier autoridad certificadora puede emitir un certificado para mi dominio sin mi participación. Hay muchas mitigaciones, como los registros CAA o la transparencia de certificados, pero no son una solución al 100%. Si Let’s Encrypt no hubiera existido, quizá habría habido más incentivos para implementar un mecanismo de confianza mejor, como DNSSEC+DANE, que limite la emisión de certificados a las entidades que realmente tienen autoridad para determinar la propiedad del dominio.
También me preocupa la falta deliberada de compatibilidad hacia atrás en el proceso de migrar los sitios a TLS. No se trata simplemente de activar o desactivar TLS una sola vez, sino de que los protocolos y suites de cifrado se van retirando continuamente. Eso es razonable para cosas que deben ser seguras, como bancos o correo electrónico, pero no creo que sea estrictamente necesario para consultar información estática y poco importante, como recetas. Creo que el problema de que las operadoras inserten anuncios o cosas raras se resolvería mejor con regulación.
Si los certificados hubieran seguido siendo una experiencia dolorosa, quizá habría aparecido algo mejor que TLS, pero no parece que fuera a pasar. Porque el problema de fondo sigue siendo difícil.
Lo que más agradezco es el protocolo ACME
¿Recuerdan cómo se renovaban los certificados antes de Let’s Encrypt? Las claves privadas solían ir y venir por email como archivos ZIP adjuntos. Era casi teatro de seguridad y, por lo que sé, era una práctica común en varias autoridades certificadoras. Gracias, Let’s Encrypt.
Durante el proceso de generación del CSR, creo una clave nueva en el servidor y lo ejecuto en el propio servidor para que la clave no salga del almacenamiento interno. El CSR se envía a GlobalSign y, por procedimientos de una gran empresa, pasa por un tercero; unos días después recibimos el certificado y lo aplicamos en el servidor.
Me gustaría usar ACME y dejar la clave en un ramdisk en memoria o algo parecido, pero esa es la desventaja de trabajar en una empresa menos ágil que un buque petrolero.
Antes de eso solo participé un poco con algunos certificados TLS, pero al menos en los lugares que me tocaron exigían el método con CSR. Aunque en la realidad quizá esas prácticas horribles eran más comunes de lo que yo sabía.
Los balanceadores de carga en entornos cloud muchas veces no se integran fácilmente con proveedores ACME externos como letsencrypt, y los proveedores internos te exigen mover el dominio hacia ellos, así que no siempre es posible. Ni siquiera todos los proveedores cloud tienen esa función, y la mayoría parece tratar ACME como una funcionalidad agregada después.
Se puede armar algo más o menos hackeado con scripts usando terraform, jobs de cron y cosas así, pero queda sucio. El modo de falla es que, si falla la renovación del certificado, el sitio se cae; y gracias a que la vida útil de los certificados se volvió muy corta, eso pasa seguido. Ya me ocurrió.
Por eso hace unos días pagué el impuesto del certificado wildcard. Pagué unos cientos de dólares para no romperme la cabeza tratando de evitarlo y me deja mal sabor, pero no vale la pena gastar días para ahorrar lo que en mi tiempo equivale a menos de 2 horas. Emitir el CSR, recibir el certificado y copiarlo a los balanceadores de carga correspondientes es una tarea de 20 minutos.
Ojalá existiera algo así también en el mundo de los certificados de escritorio
Microsoft entró en modo completamente demente con sus requisitos actuales, y sus vendedores de certificados están ganando más dinero que antes sin mover un dedo.
Lo gracioso es que toda esa seguridad, auditoría y verificación interminable todavía se sostiene sobre una foto del pasaporte enviada por email.
Peter Eckersley (1978–2022) fue incorporado póstumamente al Internet Hall of Fame por su trabajo fundacional en Let’s Encrypt
Gracias a Peter y a muchos de sus colaboradores y colegas, internet se volvió un lugar mejor.
No he oído nombrar a ninguna de las personas que aparecen ahí. Sea lo que sea que eso signifique.
En la lista completa https://www.internethalloffame.org/inductees/all/ quizá reconocí a unas siete. Aun así, es un porcentaje de un solo dígito.
Justo recibí un email de una agencia del gobierno de los Países Bajos que es cliente potencial, pidiéndome que no use Letsencrypt
Dicen que prefieren pagar ellos el costo del certificado, aunque no sé por qué. Parece que no confían.
Mucha gente no sabe que los certificados HTTPS no necesariamente impiden ciertos tipos de ataques, como la inyección de DNS
Un ejemplo de la campaña de ataque DNSPionage, que obtuvo certificados válidos para usarlos en el ataque, se puede ver en <https://www.youtube.com/watch?v=exy5JwAU8qk>
En pocas palabras, la emisión de certificados HTTPS está automatizada y depende de la seguridad de DNS, lo cual se logra con DNSSEC, pero la mayoría no lo implementa.
El problema es que aquí los registros CAA tampoco ayudan, porque si puedes falsificar el registro A, también puedes falsificar el registro CAA. No conozco lo suficiente de DNS como para asegurar si DNSSEC ayudaría en este caso.
Otro ataque es el secuestro de IP. En ese caso, algo como la validación HTTP, que es el método ACME habitual, puede pasar, pero no se puede eludir el registro CAA. Aunque alguien posea la dirección IP a la que apunta mi registro A o AAAA, si mi CAA no incluye a letsencrypt como emisor aprobado, no puede obtener un certificado de letsencrypt.
Let’s Encrypt es un logro enorme y ya se volvió infraestructura esencial
Basarlo en un protocolo abierto fue una decisión inteligente para que no se convierta en un punto único de falla, y permite que la idea sobreviva incluso si desaparece una organización concreta.
Espero que haya muchos más aniversarios como este.