El certificado detras de tu candado ya habia anunciado la pagina que todavia no habias lanzado

Un competidor lanza exactamente la misma ciudad una semana despues de que el equipo terminara de probarla en silencio, antes de que se comprara un solo anuncio o se publicara un solo enlace. Un operador se entera, por un desconocido en un foro, de que alguien curioseo en una pagina de acceso que nadie fuera de la empresa deberia haber sabido que existia. Ninguno de los dos casos parece una filtracion de un empleado, un correo hackeado o un golpe de suerte. Los dos suelen deberse a algo mucho mas simple: un certificado de seguridad, emitido en automatico, haciendo exactamente lo que fue disenado para hacer.

El mecanismo se llama Certificate Transparency y no tiene nada que ver con un ataque informatico. Es un registro publico y permanente de certificados HTTPS que existe desde 2018, se puede consultar gratis, y ya contiene el historial completo de cada nombre de host que este sitio, o cualquier sitio, ha puesto alguna vez detras de un certificado que funcionara sin aviso del navegador. Casi ningun operador ha revisado nunca su propia entrada en ese registro. Ese es el verdadero vacio que hay que cerrar aqui: no una falla en el sentido habitual, sino un registro que siempre fue publico y nunca se trato como tal.

En que se convierte un certificado en silencio, en el momento en que se emite

Desde 2018, un certificado de confianza publica, el tipo que hace que Chrome y Safari muestren un candado simple en lugar de una advertencia, tiene que quedar registrado en uno de varios logs de Certificate Transparency o esos navegadores no confiaran en el. Apple sumo el mismo requisito en Safari mas tarde ese mismo ano. Esto no apuntaba a sitios para adultos ni a directorios de clasificados en particular: se creo para impedir que alguien emitiera en secreto un certificado falso para el dominio de otra persona e interceptara su trafico. El efecto secundario es que el registro tambien guarda cada certificado real que un sitio obtiene para si mismo, y ese registro nunca fue pensado para ser privado.

El registro enumera, por nombre, cada host que un certificado realmente cubre. Un certificado emitido para admin.ejemplo.com muestra exactamente eso, en texto plano, para siempre. No importa si la pagina detras de ese nombre fue alguna vez enlazada desde el menu del sitio, mencionada en un mapa del sitio o indexada por un buscador. La autoridad certificadora lo registro en el momento mismo en que lo emitio, ya fuera Let's Encrypt, Cloudflare o el gestor automatico de certificados integrado en la mayoria de los paneles de hosting, porque todos responden a las mismas reglas de los navegadores.

Comprobarlo no cuesta nada y toma menos de un minuto. Una herramienta gratuita llamada crt.sh permite a cualquiera escribir un dominio y ver todos los certificados jamas registrados para ese nombre, sin cuenta, sin registro. Escribir el dominio de un competidor funciona exactamente igual que escribir el propio, y eso es lo que convierte un registro tecnico rutinario en un riesgo de negocio. Cualquier operador que lea esto puede abrir esa pagina ahora mismo y ver, por primera vez, lo que su propio dominio ya le conto al mundo.

Hay una excepcion real, y importa para todo lo que sigue: un certificado wildcard, el que cubre un patron entero como *.ejemplo.com en lugar de un nombre exacto, solo registra ese patron. Los nombres de host concretos que realmente lo usan, nuevaciudad.ejemplo.com o staging.ejemplo.com, no aparecen por nombre en el registro. Un certificado dedicado a un solo subdominio exacto, en cambio, siempre aparece por nombre. Esa diferencia es la palanca concreta que un operador realmente tiene, y vuelve mas adelante.

Que entrega realmente a un desconocido, de tres formas concretas

La primera es el momento de una expansion. Una pagina nueva de ciudad o de pais casi siempre se construye y se prueba en su propio subdominio dias o semanas antes de que marketing este listo para anunciarla, y probarla por HTTPS significa que su certificado se emite justo durante ese periodo de silencio, no el dia del lanzamiento. Existen herramientas de monitoreo gratuitas, construidas sobre el mismo registro publico, que avisan a quien las use en cuestion de minutos a unas pocas horas cada vez que aparece un certificado nuevo para un dominio que estan vigilando. Un competidor que ya conoce el dominio principal, que es publico por definicion, no necesita adivinar el nombre de la nueva ciudad: solo tiene que estar vigilando, y el registro se lo entrega antes de que salga el anuncio.

La segunda es el mapa de las herramientas internas. Un directorio de este tamano suele tener una pagina de acceso para el personal, una cola para quienes revisan los anuncios, quiza un panel separado para un proveedor externo de pagos. Si cada uno de ellos obtuvo su propio certificado con su propio nombre descriptivo, admin, moderacion, facturacion, el registro ya se lee como un plano del edificio. Ese plano es exactamente el punto de partida detras del tipo de intrusion ya tratado aqui, donde la forma habitual de entrar no es un exploit espectacular sino una contrasena reutilizada probada contra la pagina de acceso mas facil de encontrar. Un subdominio con nombre descriptivo no causa por si solo esa intrusion, pero quita el primer paso, encontrar la pagina de acceso, que de otro modo habria frenado al atacante.

La tercera es una historia que nadie puede borrar. El registro no olvida. Un subdominio de prueba de hace tres anos, una pagina de corta vida creada para un socio que ya no existe, una copia de staging que un desarrollador pensaba eliminar y olvido: todo queda en el registro para siempre, incluso despues de que el certificado expire, incluso despues de que se elimine el registro DNS que apuntaba hacia el. Buscar hoy un dominio en crt.sh puede sacar a la luz nombres que nadie del equipo actual recuerda haber creado. La parte peligrosa no es la entrada en si, sino la posibilidad de que el servidor que respondia en esa direccion siga ahi, sin actualizar, porque todos dieron por hecho que quitar el enlace equivalia a apagarlo.

Nada de esto requiere ninguna habilidad que la mayoria llamaria hacking. Solo hace falta saber que existe un cuadro de busqueda gratuito y escribir ahi un nombre de dominio, y por eso mismo vale la pena tomarselo en serio en lugar de archivarlo como un problema de seguridad del que se ocupa otro.

Que no frena nada de esto, y que si funciona de verdad

Es tentador recurrir a las mismas herramientas que se usan para gestionar como ven un sitio los buscadores, pero aqui no sirven. Las decisiones que este directorio ya toma sobre que rastreadores pueden ver que paginas pasan por robots.txt y por la indexacion de los buscadores, un sistema completamente distinto del que un registro de certificados nunca ha oido hablar. Bloquear un bot, desindexar una pagina o marcarla como noindex no cambia nada sobre si su certificado aparece en el registro, porque el registro anota el certificado en si, no la visibilidad de la pagina ante los buscadores.

Tampoco existe una forma legitima de conseguir un certificado que funcione sin aviso en el navegador de un visitante y mantenerlo fuera del registro. Pedirle a un proveedor de hosting o a una autoridad certificadora que haga una excepcion es pedir algo que no existe para un negocio de cara al publico: los unicos certificados exentos del registro son los emitidos por una autoridad certificadora privada e interna, que los navegadores de los visitantes comunes no reconocen en absoluto, lo que los hace inutiles para cualquier cosa que un cliente o un anunciante realmente necesite abrir.

Renombrar o eliminar un subdominio despues tampoco arregla nada, porque la entrada antigua en el registro se queda exactamente donde estaba. No existe ninguna limpieza retroactiva para un nombre que ya quedo registrado de esta forma: lo unico que un operador puede cambiar de verdad es lo que pasa de aqui en adelante.

Lo que si funciona es el certificado wildcard descrito arriba, usado a proposito. Las herramientas internas, las copias de staging y todo lo que se prueba antes de un lanzamiento publico deberian correr detras de un unico certificado que cubra un patron entero, en lugar de un certificado nuevo emitido por nombre cada vez. La mayoria de los paneles de hosting y de las redes de distribucion de contenido emiten por defecto un certificado con nombre propio en el momento mismo en que se anade un subdominio nuevo, porque esa opcion por defecto es mas simple de construir, no porque sea la mas segura; pedirle al proveedor de hosting o al desarrollador que cambie justo esa configuracion para todo lo que no sea una pagina de marketing publica es una pregunta concreta y verificable, no una peticion vaga de mejorar la seguridad.

La segunda solucion real es dejar de confiar en un nombre dificil de adivinar como si fuera una cerradura. Una pagina de acceso, una cola de moderacion o un panel de facturacion necesitan una verificacion real con contrasena y, idealmente, una restriccion a un conjunto conocido de direcciones de oficina o de personal, sin importar como se llamen, porque el nombre nunca fue la unica forma de encontrarlos: existen otros metodos tecnicos para descubrir los subdominios de un sitio que no tienen nada que ver con los certificados. Tratar un nombre dificil de adivinar como la defensa principal es el verdadero error aqui, no la eleccion del certificado en si. La eleccion del certificado solo decide si ese nombre se regala gratis antes de que nadie tenga siquiera que buscarlo.

Que revisar de verdad esta semana

El primer paso no cuesta nada y toma cinco minutos: abrir crt.sh, escribir el dominio propio de este sitio y leer la lista completa de todo lo que aparece. Cualquier entrada no reconocida merece una pregunta directa a quien gestiona el hosting: sigue funcionando, y si es asi, por que hoy internet conoce su direccion.

Para todo lo que en esa lista resulte ser una funcion abandonada, una prueba terminada o un proyecto para un socio que ya no esta, la solucion no es solo quitar el registro DNS. Lo que fuera que estaba detras de esa direccion deberia apagarse a nivel de servidor, confirmando que ya no responde a ninguna peticion, en lugar de dejarlo funcionando en silencio mientras solo se quita el cartel que apuntaba hacia el.

Para el proximo lanzamiento de una ciudad o un pais nuevo, la fase de pruebas deberia correr bajo un certificado wildcard o uno compartido de uso interno, en lugar de un certificado emitido con el nombre especifico de esa ciudad, para que el registro no anuncie la expansion antes que el marketing. Es un solo ajuste que confirmar con un desarrollador o un proveedor de hosting antes del proximo lanzamiento, no la reconstruccion de algo que ya esta en linea.

Para cada pagina interna de acceso, moderacion o facturacion que ya este activa hoy, la pregunta no es si su nombre es dificil de adivinar. Es si delante tiene una contrasena real y, cuando sea posible, una restriccion por direccion, sin importar el nombre, porque esa es la parte que realmente aguanta una vez que el nombre mismo ya es publico, algo que, despues de revisar crt.sh, lo mas probable es que ya lo sea.