O certificado por tras do seu cadeado ja tinha anunciado a pagina que voce ainda nao tinha lancado

Um concorrente lanca exatamente a mesma cidade uma semana depois que a equipe terminou de testa-la em silencio, antes mesmo de comprar um unico anuncio ou publicar um unico link. Um operador descobre, por um desconhecido num forum, que alguem bisbilhotou uma pagina de login que ninguem fora da empresa deveria saber que existia. Nenhum dos dois casos parece vazamento de funcionario, email invadido ou golpe de sorte. Os dois costumam se explicar por algo bem mais simples: um certificado de seguranca, emitido automaticamente, fazendo exatamente o que foi projetado para fazer.

O mecanismo se chama Certificate Transparency e nao tem nada a ver com invasao. E um registro publico e permanente de certificados HTTPS que existe desde 2018, pesquisavel gratuitamente, e que ja contem o historico completo de cada nome de host que este site, ou qualquer site, colocou atras de um certificado que funcionasse sem aviso do navegador. Quase nenhum operador ja conferiu a propria entrada nesse registro. Essa e a verdadeira lacuna a fechar aqui, nao uma falha no sentido comum, mas um registro que sempre foi publico e nunca foi tratado como tal.

No que um certificado silenciosamente se transforma, no momento em que e emitido

Desde 2018, um certificado de confianca publica, o tipo que faz o Chrome e o Safari mostrarem um cadeado simples em vez de um aviso, precisa ser registrado em um dos varios logs de Certificate Transparency, ou esses navegadores nao confiam nele. A Apple acrescentou a mesma exigencia no Safari mais tarde, no mesmo ano. Isso nao visava sites adultos ou diretorios de classificados em particular: foi criado para impedir que alguem emitisse secretamente um certificado falso para o dominio de outra pessoa e interceptasse seu trafego. O efeito colateral e que o registro tambem guarda cada certificado real que um site obtem para si mesmo, e esse registro nunca foi pensado para permanecer privado.

O registro lista, por nome, cada host que um certificado realmente cobre. Um certificado emitido para admin.exemplo.com mostra exatamente esse nome, em texto simples, para sempre. Nao importa se a pagina por tras desse nome algum dia foi linkada no menu do site, mencionada num mapa do site ou indexada por um buscador. A autoridade certificadora registrou isso no instante em que o emitiu, fosse Let's Encrypt, Cloudflare ou o gerenciador automatico de certificados embutido na maioria dos paineis de hospedagem, porque todos seguem as mesmas regras de navegador.

Conferir isso nao custa nada e leva menos de um minuto. Uma ferramenta gratuita chamada crt.sh permite que qualquer um digite um dominio e veja todos os certificados ja registrados para esse nome, sem conta, sem cadastro. Digitar o dominio de um concorrente funciona exatamente como digitar o proprio, e e isso que transforma um registro tecnico rotineiro num risco de negocio. Qualquer operador lendo isto pode abrir essa pagina agora mesmo e ver, pela primeira vez, o que o proprio dominio ja contou ao mundo.

Ha uma excecao real, e ela importa para tudo o que vem a seguir: um certificado wildcard, aquele que cobre um padrao inteiro como *.exemplo.com em vez de um nome exato, so registra esse padrao. Os nomes de host especificos que realmente o usam, novacidade.exemplo.com ou staging.exemplo.com, nao aparecem pelo nome no registro. Ja um certificado dedicado a um unico subdominio exato sempre aparece pelo nome. Essa diferenca e a alavanca concreta que um operador realmente tem, e volta mais adiante.

O que isso realmente entrega a um estranho, de tres formas concretas

A primeira e o momento de uma expansao. Uma nova pagina de cidade ou de pais quase sempre e construida e testada no proprio subdominio dias ou semanas antes de o marketing estar pronto para anuncia-la, e testa-la via HTTPS significa que o certificado dela e emitido justamente nesse periodo silencioso, nao no dia do lancamento. Existem ferramentas de monitoramento gratuitas, construidas sobre o mesmo registro publico, que avisam quem as usa em minutos a poucas horas sempre que surge um novo certificado para um dominio que estao observando. Um concorrente que ja conhece o dominio principal, publico por definicao, nao precisa adivinhar o nome da nova cidade: so precisa estar observando, e o registro entrega isso antes mesmo de sair o anuncio.

A segunda e o mapa das ferramentas internas. Um diretorio desse tamanho geralmente mantem uma pagina de login para a equipe, uma fila para quem revisa os anuncios, talvez um painel separado para um fornecedor externo de pagamentos. Se cada um deles ganhou seu proprio certificado com nome descritivo, admin, moderacao, faturamento, o registro agora se le como uma planta do predio. Essa planta e exatamente o ponto de partida por tras do tipo de invasao ja tratado aqui, onde a forma habitual de entrar nao e um exploit espetacular, mas uma senha reutilizada testada contra a pagina de login mais facil de encontrar. Um subdominio com nome descritivo nao causa essa invasao sozinho, mas tira o primeiro passo, encontrar a pagina de login, que de outra forma teria atrasado o invasor.

A terceira e uma historia que ninguem consegue apagar. O registro nao esquece. Um subdominio de teste de tres anos atras, uma pagina de vida curta criada para um parceiro que nao existe mais, uma copia de staging que um desenvolvedor pretendia excluir e esqueceu: tudo isso permanece no registro para sempre, mesmo depois que o certificado expira, mesmo depois que o registro DNS que apontava para ele e removido. Pesquisar um dominio hoje no crt.sh pode revelar nomes que ninguem na equipe atual lembra de ter criado. A parte perigosa nao e a entrada em si, e a possibilidade de o servidor que respondia naquele endereco ainda estar la, nunca atualizado, porque todos assumiram que remover o link era o mesmo que desliga-lo.

Nada disso exige qualquer habilidade que a maioria chamaria de invasao. So e preciso saber que existe uma caixa de busca gratuita e digitar nela um nome de dominio, e e exatamente por isso que vale a pena levar isso a serio em vez de arquivar como um problema de seguranca que e responsabilidade de outra pessoa.

O que nao impede nada disso, e o que realmente funciona

E tentador recorrer as mesmas ferramentas usadas para gerenciar como os buscadores veem um site, mas nenhuma delas se aplica aqui. As escolhas que este diretorio ja faz sobre quais rastreadores podem ver quais paginas passam pelo robots.txt e pela indexacao em buscadores, um sistema completamente diferente do qual um registro de certificados nunca ouviu falar. Bloquear um bot, desindexar uma pagina ou marca-la como noindex nao muda nada sobre o certificado dela aparecer no registro, porque o registro anota o certificado em si, nao a visibilidade da pagina para os buscadores.

Tambem nao existe uma forma legitima de conseguir um certificado que funcione sem aviso no navegador de um visitante e mante-lo fora do registro. Pedir a um provedor de hospedagem ou a uma autoridade certificadora que faca uma excecao e pedir algo que nao existe para um negocio voltado ao publico: os unicos certificados isentos de registro sao os emitidos por uma autoridade certificadora privada e interna, que os navegadores de visitantes comuns nao reconhecem de forma alguma, o que os torna inuteis para qualquer coisa que um cliente ou anunciante realmente precise abrir.

Renomear ou excluir um subdominio depois tambem nao resolve nada, porque a entrada antiga no registro permanece exatamente onde estava. Nao existe limpeza retroativa para um nome ja registrado dessa forma: a unica coisa que um operador realmente pode mudar e o que acontece daqui para frente.

O que realmente funciona e o certificado wildcard descrito acima, usado de proposito. Ferramentas internas, copias de staging e tudo o que e testado antes de um lancamento publico deveriam rodar atras de um unico certificado que cobre um padrao inteiro, em vez de um certificado novo emitido por nome a cada vez. A maioria dos paineis de hospedagem e redes de distribuicao de conteudo emite por padrao um certificado nomeado automaticamente no momento em que um novo subdominio e adicionado, porque esse padrao e mais simples de construir, nao porque seja a escolha mais segura; pedir ao provedor de hospedagem ou ao desenvolvedor para mudar exatamente essa configuracao para tudo o que nao for uma pagina de marketing publica e uma pergunta concreta e verificavel, nao um pedido vago de melhorar a seguranca.

A segunda solucao real e parar de confiar num nome obscuro como se fosse uma fechadura. Uma pagina de login, uma fila de moderacao ou um painel de faturamento precisam de uma verificacao real por senha e, quando possivel, de uma restricao a um conjunto conhecido de enderecos de escritorio ou de equipe, independentemente do nome, porque o nome nunca foi a unica forma de encontra-los: existem outros metodos tecnicos para revelar os subdominios de um site que nao tem nada a ver com certificados. Tratar um nome dificil de adivinhar como a principal defesa e o erro real aqui, nao a escolha do certificado em si. A escolha do certificado so decide se esse nome e entregue de graca antes mesmo de alguem precisar procura-lo.

O que realmente conferir esta semana

O primeiro passo nao custa nada e leva cinco minutos: abrir o crt.sh, digitar o dominio deste site e ler a lista completa de tudo o que aparece. Qualquer entrada nao reconhecida merece uma pergunta direta a quem administra a hospedagem: isso ainda esta funcionando, e se sim, por que a internet publica conhece esse endereco hoje.

Para tudo nessa lista que se revelar uma funcionalidade abandonada, um teste concluido ou um projeto para um parceiro que ja nao existe, a correcao nao e apenas remover o registro DNS. O que quer que estivesse por tras daquele endereco deveria ser desligado no nivel do servidor, com a confirmacao de que nao responde mais a nenhuma requisicao, em vez de deixado funcionando em silencio enquanto so a placa que apontava para ele e retirada.

Para o proximo lancamento de uma cidade ou pais novo, a fase de testes deveria rodar sob um certificado wildcard ou um compartilhado de uso interno, em vez de um certificado emitido com o nome especifico daquela cidade, para que o registro nao anuncie a expansao antes do marketing. E uma unica configuracao a confirmar com um desenvolvedor ou provedor de hospedagem antes do proximo lancamento, nao uma reconstrucao de algo que ja esta no ar.

Para cada pagina interna de login, moderacao ou faturamento ja ativa hoje, a pergunta nao e se o nome dela e dificil de adivinhar. E se existe uma senha de verdade na frente e, onde possivel, uma restricao por endereco, independentemente do nome, porque essa e a parte que realmente se sustenta depois que o nome em si ja e publico, o que, depois de conferir o crt.sh, muito provavelmente ja e o caso.