Google ha contado en su blog que unos atacantes han conseguido certificados HTTPS válidos para varios dominios de Google y de “varias marcas globales y servicios muy usados”. Lo más llamativo es que no ha fallado ninguna autoridad de certificación ni se ha comprometido ningún sistema de Google: los atacantes secuestraron los registros de tres dominios de país, .gh (Ghana), .sl (Sierra Leona) y .as (Samoa Americana), y desde ahí todo lo demás vino solo.
Me ha parecido un buen recordatorio de que la seguridad de HTTPS depende de algo tan poco vistoso como el DNS, y de que hay un par de cosas que cualquiera con un dominio puede hacer.
Cómo se consigue un certificado sin romper nada
Para emitir un certificado, una autoridad de certificación tiene que comprobar que quien lo pide controla el dominio. Es la domain control validation (DCV), y casi siempre es automática: publicar un registro TXT en el DNS, servir un fichero en una ruta concreta por HTTP… Así funciona Let’s Encrypt, y es lo que ha permitido que hoy casi toda la web vaya cifrada.
El problema es que esa comprobación da por bueno lo que diga el DNS. Si controlas el DNS de un dominio, aunque sea un rato, puedes demostrar que “controlas” el dominio.
flowchart LR
A["Registro del ccTLD · comprometido"] --> B["Cambio de nameservers · y registros DNS"]
B --> C["Validación DCV · superada"]
C --> D["Certificado válido · emitido por una CA legítima"]
D --> E["Suplantación · del dominio"]Eso es lo que pasó aquí. Con el control de los registros de .gh, .sl y .as, los atacantes cambiaron la delegación de nameservers y los registros DNS de dominios concretos bajo esos TLDs (Google no ha dicho cuáles). Las autoridades de certificación hicieron su comprobación, el DNS respondió lo que los atacantes querían y emitieron los certificados. Google lo dice claramente: “no tenemos motivos para creer que las autoridades de certificación que emitieron los certificados hicieran nada mal”.
Cómo se detectó y qué ha hecho Chrome
Aquí es donde se ve para qué sirve Certificate Transparency (CT). Desde hace años, todo certificado en el que confíe Chrome tiene que estar publicado en unos logs públicos, de sólo añadir, que cualquiera puede consultar. Un certificado emitido a escondidas, Chrome lo rechaza.
Google bloqueó primero los certificados de sus propios dominios mediante CRLSets, el mecanismo de Chrome para revocar certificados sin esperar al proceso oficial de revocación, que es lento. Después, revisando los logs de CT, encontró certificados de otras organizaciones afectadas por los mismos ataques, los bloqueó también y avisó a quien pudo.
El incidente recuerda al de DigiNotar en 2011, cuando se emitieron certificados falsos para google.com y más de 200 dominios, que se usaron para espiar a unas 300.000 personas en Irán. La gran diferencia es que entonces la autoridad de certificación estaba comprometida, y que Certificate Transparency no existía todavía: precisamente nació como respuesta a casos como ese.
Lo que recomienda Google a quien tiene dominios
Lo que más me ha gustado del aviso es que no se queda en “Chrome ya te protege”. Dice que no se debe confiar sólo en el navegador, porque no pueden garantizar haber encontrado todos los dominios afectados y porque los bloqueos de Chrome no protegen a quien usa otros navegadores o clientes. Y recomienda dos cosas.
Vigilar los logs de Certificate Transparency
Si alguien emite un certificado para tu dominio, aparecerá en los logs de CT. Hay servicios que te avisan, y para echar un vistazo rápido basta con crt.sh:
curl -s "https://crt.sh/?q=antoniocortes.com&output=json" \
| jq -r '.[] | "\(.not_before) \(.issuer_name)"' | sort | tail
Lo he probado con este blog: 135 certificados, todos de Let’s Encrypt, que es lo que usa Netlify. Si un día apareciera uno de otra autoridad, sabría que algo va mal. Google insiste en vigilar todos los dominios, incluidos los aparcados o los de otros países, que suelen ser los olvidados.
Publicar registros CAA restrictivos
Un registro CAA (Certification Authority Authorization) es un registro DNS en el que indicas qué autoridades pueden emitir certificados para tu dominio. Las autoridades están obligadas a consultarlo antes de emitir:
antoniocortes.com. CAA 0 issue "letsencrypt.org"
antoniocortes.com. CAA 0 issuewild ";"
antoniocortes.com. CAA 0 iodef "mailto:seguridad@example.com"
Con esto, sólo Let’s Encrypt podría emitir certificados, nadie podría emitir comodines y los intentos rechazados se notificarían a esa dirección. Google, por ejemplo, sólo permite su propia autoridad (0 issue "pki.goog").
Hay que ser honesto con sus límites, y Google lo es: CAA no evita nada durante un secuestro de DNS activo, porque el atacante controla también ese registro. Su valor está en lo que pasa después. Las autoridades pueden reutilizar durante un tiempo una validación ya hecha, así que un atacante que validó el dominio mientras controlaba el DNS podría seguir pidiendo certificados después de que lo recuperes. Un CAA restrictivo, sobre todo si se ata a una cuenta ACME concreta y a un método de validación con las extensiones accounturi y validationmethods, corta esa puerta.
Al escribir esto he comprobado que este dominio no tiene ningún registro CAA. Con un servicio como Netlify, que gestiona los certificados por ti, atar el CAA a una cuenta ACME no es práctico, porque la cuenta no es tuya. Pero limitar la emisión a Let’s Encrypt sí lo es, y no cuesta nada.
Lo que me llevo
La cadena de confianza de HTTPS es tan fuerte como su eslabón más débil, y aquí el eslabón débil ha estado en un sitio que casi nadie mira: los registros de dominios de país, gestionados a veces con muchos menos recursos que los grandes. Si tu dominio cuelga de uno de ellos, dependes de su seguridad tanto como de la tuya.
También me parece una buena demostración de que Certificate Transparency funciona: sin esos logs públicos, Google difícilmente habría encontrado los certificados de otras organizaciones. Y encaja con lo que lleva tiempo empujando el CA/Browser Forum: certificados cada vez más cortos (en 2029 durarán 47 días como máximo) y menos tiempo para reutilizar validaciones, para que un incidente como este deje menos rastro.
La parte práctica es corta: vigilar los logs de CT de tus dominios y publicar un CAA que diga quién puede emitir. Son cinco minutos.
