El candado de la barra de direcciones ahora es más fiable: Chrome endurece las normas contra los hackers.

La industria de certificados HTTPS comienza a eliminar de forma gradual los métodos menos fiables de comprobación de derechos sobre un dominio: Chrome Root Program y CA/Browser Forum aprobaron nuevos requisitos para las autoridades de certificación, que retirarán progresivamente 11 métodos "heredados" de Domain Control Validation (DCV).

La idea es sencilla: si la confianza en un certificado se apoya en señales débiles como correos, llamadas o datos de contacto dispersos, los atacantes tienen la oportunidad de eludir las comprobaciones y obtener un certificado para un dominio ajeno. Ahora se cierran intencionadamente estas brechas y se pone el énfasis en enfoques automatizados y verificables criptográficamente.

Las decisiones quedaron plasmadas en los boletines SC-080, SC-090 y SC-091 y se implementarán de forma gradual para que los propietarios de sitios tengan tiempo de pasar a esquemas modernos. El efecto completo de este endurecimiento debe alcanzarse en marzo de 2028, cuando las comprobaciones obsoletas queden definitivamente fuera de uso. Los autores de los cambios los vinculan con la hoja de ruta pública Moving Forward, Together, lanzada en 2022: entonces era más una dirección de desarrollo, y las actualizaciones de los TLS Baseline Requirements convierten la apuesta por "automatización y modernización de la infraestructura" en una política obligatoria para el sector, continuando la ola de iniciativas para mejorar la seguridad que antes lograron avanzar hasta convertirse en estándares comunes.

DCV es un procedimiento crítico que debe garantizar que un certificado se emite solo al operador real del dominio, y no a un tercero. Sin ese control, un atacante podría obtener un certificado aparentemente "válido" para un sitio ajeno y utilizarlo para suplantar el recurso o interceptar tráfico, permaneciendo formalmente dentro de la cadena de confianza. En los modelos modernos la verificación suele construirse como un reto-respuesta: la autoridad de certificación emite un valor aleatorio, y el solicitante confirma el control colocándolo, por ejemplo, en un registro TXT de DNS o en otro lugar acordado de antemano, tras lo cual la autoridad comprueba el resultado.

Históricamente se usaron métodos indirectos basados en indicios de propiedad, por ejemplo, datos de contacto de WHOIS o correspondencia con direcciones que "se parecen a las correctas". Precisamente esas prácticas se consideran problemáticas: en el marco del rechazo gradual se dejarán de usar comprobaciones que se apoyan en mensajes a los contactos del dominio o a la dirección IP mediante correo electrónico, fax, SMS o correo postal, direcciones de correo "construidas" para el dominio, así como envíos a contactos especificados a través de DNS CAA o DNS TXT. En la misma categoría quedan las confirmaciones telefónicas mediante el contacto del dominio, mediante "teléfono en DNS TXT", mediante "teléfono en DNS CAA" y mediante el contacto de la dirección IP, así como el esquema de comprobaciones inversas por dirección IP y el reverse address lookup.

Para los usuarios habituales del navegador estos cambios apenas se notan, y ese es precisamente el objetivo. Tras bambalinas deben dificultar intentos de engañar a la autoridad de certificación aprovechando señales obsoletas o poco transparentes, como registros de contacto desactualizados, cadenas de reenvío en la infraestructura telefónica y postal o elementos "heredados" de administración.

Como resultado, la industria se apoya más en métodos DCV estandarizados, modernos y auditables, incluyendo la automatización mediante ACME, y al mismo tiempo recibe un incentivo para acelerar y simplificar la gestión del ciclo de vida de los certificados. En última instancia se trata de eliminar los eslabones débiles del proceso que sostiene la confianza en las conexiones seguras en Internet y de hacer que esta infraestructura básica sea más resistente para todos.