Provar um nome de anfitrião sem certificado

Qualquer produto que deixe um cliente escrever um nome de anfitrião e depois o verifique a cada minuto construiu duas coisas. A primeira é monitorização. A segunda é um gerador distribuído de pedidos, apontado para onde o cliente quiser, com o nome da empresa no agente de utilizador e a morada de faturação do cliente por trás.

A objeção habitual é que o alvo tem um endereço público, portanto qualquer pessoa lhe poderia enviar tráfego de qualquer maneira. Isso é verdade e não é o ponto. Um endereço público não é permissão para medir alguém, e «qualquer um podia» não é uma defesa que sobreviva à primeira queixa de abuso, sobretudo quando o tráfego é periódico, sustentado e tem origem numa plataforma comercial identificável.

Portanto um alvo que seja um nome de anfitrião tem de ser ganho. Este é o desenho em que ficámos, incluindo as partes que são menos óbvias do que parecem.

Dois métodos que provam coisas diferentes

Há duas maneiras práticas de alguém demonstrar que um nome lhe pertence, e vale a pena ser claro que não são equivalentes.

Um registo TXT no DNS prova o controlo da zona. Quem consegue pôr lá um valor decide para onde o nome aponta, que é a afirmação mais forte que existe acerca de um nome.

Um ficheiro no servidor web prova o controlo da máquina para a qual o nome resolve neste momento. Isso é mais fraco: em alojamento partilhado, mais gente o consegue produzir do que consegue editar a zona. É também muito mais alcançável para um cliente que tem um servidor mas não tem acesso ao fornecedor de DNS da sua entidade patronal.

É o mesmo par de compromissos que as autoridades de certificação fazem com os seus dois tipos de desafio comuns, e segue-se a mesma conclusão: ofereça os dois, registe qual foi usado, e não finja que têm o mesmo peso.

A forma do desafio

O registo TXT fica sob uma etiqueta própria em vez de ficar no próprio domínio. Isso não é arrumação. Um registo no ápice fica ao lado dos registos de política de correio do cliente, onde cada cadeia adicional empurra a resposta para mais perto do tamanho a partir do qual os resolvedores começam a ter um mau dia, e onde a limpeza que outra pessoa faça dos «registos TXT antigos» o remove sem má intenção. Sob uma etiqueta própria fica sozinho.

O ficheiro vive sob um caminho reservado com o token como nome de ficheiro, e o ficheiro contém o token e mais nada.

O token em si tem trinta e dois caracteres hexadecimais, o que são cento e vinte e oito bits. Não é um segredo e não é uma chave: vai ficar em DNS público ou num servidor web público. O que tem de ser é impossível de adivinhar, porque quem consiga prever um token válido pode reclamar um nome que não lhe pertence pondo-o primeiro no seu próprio servidor. O hexadecimal em minúsculas mantém-no seguro para um registo de DNS, seguro num URL e livre de caracteres que possam ser mal lidos quando um cliente o copia à mão.

Uma regra estrutural: exatamente um pedaço de código escreve o desafio, e o resultado viaja com o pedido até quem faz a verificação. Se ambos os lados conhecessem o prefixo de forma independente, haveria mais tarde ou mais cedo um dia em que o painel mostra uma etiqueta e o verificador procura outra, e a mensagem resultante é «o registo não está lá» acerca de um registo que está lá. Nada é mais caro de apoiar do que uma resposta correta a uma pergunta que ninguém fez.

Porque é o agente que vai buscar

Esta é a decisão de que o resto depende.

A plataforma não resolve o nome e não vai buscar o ficheiro. Se o fizesse, a nossa própria infraestrutura estaria a estabelecer ligações para um nome escrito por um utilizador, o que é falsificação de pedidos do lado do servidor com um campo de formulário como superfície de ataque. O resultado clássico é um pedido a um ponto final de metadados de nuvem a partir de dentro da nossa própria rede, feito por nós, a pedido.

Em vez disso é o agente do próprio cliente que o faz: o mesmo agente que vai correr as verificações depois, dentro da rede do próprio cliente e a ligar-se apenas para fora. Mentir sobre o resultado não traz nada, porque a recompensa é a permissão para medir uma coisa que o agente já conseguia alcançar. A verificação é feita pela parte que já tem o acesso, que é o único arranjo em que o incentivo para fazer batota desaparece.

Há uma consequência que vale a pena dizer em voz alta, porque parece uma salvaguarda em falta. As recomendações para este tipo de funcionalidade costumam dizer para bloquear gamas privadas, loopback, link-local e endereços de metadados. Essa regra pertence a sondas alojadas, ou seja, pontos de medição que nós operamos e que ficam na nossa rede. Para um agente dentro da rede do próprio cliente, os endereços privados são o caso normal: o hipervisor dele, o comutador dele, o armazenamento dele. Bloqueá-los desativaria a única fonte de medição exatamente para a situação a que ela existe para servir.

O que ambos os caminhos partilham é uma única função a decidir que endereços são permitidos. Se a verificação e a medição tivessem cada uma a sua lista, haveria um dia em que discordariam, e nesse dia uma delas é um desvio à volta da outra.

Falhar fechado em respostas mistas

Um nome pode resolver para vários endereços, e eles não têm de ser igualmente aceitáveis.

Se um nome responder com o endereço público do cliente e também com um ponto final de metadados, então cada execução é um novo sorteio. Nove execuções medem o endereço público e a décima fala com outra coisa qualquer. Portanto a contagem de respostas aceitáveis não transporta informação nenhuma: um endereço proibido no conjunto torna o nome inteiro inutilizável, e diz-se ao cliente qual foi o endereço, porque uma recusa sobre a qual ele não pode agir é apenas uma mensagem de erro.

O mesmo vale durante a verificação e durante as verificações correntes, que é mais uma vez a razão pela qual existe uma política de endereços e não duas.

Pormenores que só se aprendem a correr aquilo

Três destes saíram de construir o verificador; o quarto é uma decisão de desenho que pertence ao mesmo conjunto.

Compare com «contém» e não com igualdade. Um fornecedor de DNS pode apresentar um valor TXT com aspas à volta, e alguns painéis de controlo acrescentam aspas que depois voltam a retirar na sua própria apresentação. O token é longo e opaco: ou está lá ou não está, e exigir uma correspondência exata só castiga clientes que fizeram tudo bem.

Envie o nome no cabeçalho de anfitrião e no nome de servidor do TLS. A ligação vai para um endereço que já passou a verificação da política, mas é preciso dizer a um servidor web com vários sítios qual deles está a ser pedido. Sem os dois, um cliente corretamente configurado falha a verificação porque lhe foi servido o sítio por omissão de outra pessoa.

Permita exatamente um redirecionamento. Um servidor web que empurra tudo para HTTPS é normal, e recusar o redirecionamento reprovaria metade da internet. Permitir muitos deixaria a prova acabar noutro sítio qualquer. Um salto, e só para o mesmo anfitrião.

Não exija HTTPS para o desafio por ficheiro. A prova é o token. Um certificado não lhe acrescenta nada, e exigir um transforma uma verificação de posse numa verificação de certificado, que é uma pergunta diferente com modos de falha diferentes. É o mesmo raciocínio por trás do tipo de desafio em HTTP simples na emissão de certificados. Note-se que esta predefinição é específica da verificação: quando o esquema é a própria coisa a ser medida, adivinhá-lo produziria uma medição verde de outra coisa que não aquilo que o cliente configurou, e aí o comportamento certo é recusar.

A prova expira, porque os domínios mudam de dono

Um nome verificado não deve ficar verificado para sempre, e a razão não é paranoia acerca dos nossos próprios registos.

Os domínios mudam de dono sem avisar ninguém. Um cliente deixa um registo caducar, outra pessoa apanha-o, e a partir desse momento estamos a medir a máquina de um estranho a cada minuto com o nome do nosso cliente colado ao horário. Ninguém nessa cadeia fez nada de errado e o resultado continua a ser inaceitável.

Noventa dias é a validade que escolhemos, que é da mesma ordem de um certificado de vida curta e pela mesma razão: curta o suficiente para que uma transferência seja notada depressa, longa o suficiente para que os clientes não estejam a tratar de papelada todas as semanas. A reverificação começa catorze dias antes de expirar, o que é deliberadamente generoso, porque uma reverificação falhada costuma significar que o agente estava offline ou que um resolvedor estava lento, e não que a posse mudou.

As tentativas são limitadas a uma a cada seis horas, sem ligação ao intervalo de monitorização. Uma verificação não é uma medição: não diz nada sobre disponibilidade, não pertence a um valor de tempo em funcionamento, e perguntar mais vezes só gera tráfego contra o DNS do cliente. Seis horas ao longo de catorze dias dão mais de cinquenta tentativas, o que transforma «expirado» num sinal a sério em vez de má sorte.

Os estados que saem disto são pendente, verificado, a expirar, expirado e revogado, e um deles não é uma cancela. «A expirar» existe para que a interface possa avisar alguém; uma prova que caduca daqui a dez dias é válida hoje, e as verificações continuam a correr. Tratá-lo como um estado de bloqueio separado tiraria a monitorização a um cliente num dia em que nada mudou.

A base de dados impõe o emparelhamento em vez de confiar no código: uma linha ou tem hora de verificação e hora de expiração, ou não tem nenhuma das duas. Uma linha verificada sem expiração é uma concessão permanente que ninguém escolheu, que é precisamente aquilo que este desenho todo existe para evitar.

O que escreveríamos

1. 01Decida o que o desafio prova, controlo da zona ou controlo da máquina, e guarde qual deles foi usado.
2. 02Ponha o desafio sob uma etiqueta sua, nunca no ápice ao lado dos registos de correio de alguém.
3. 03Faça do verificador a parte que já tem o acesso. Se a sua plataforma for buscar um nome fornecido pelo utilizador, construiu uma funcionalidade de falsificação de pedidos.
4. 04Uma política de endereços para verificação e medição. Duas listas tornam-se dois comportamentos.
5. 05Falhe fechado em respostas mistas, e nomeie na recusa o endereço que a causou.
6. 06Dê à prova um prazo de validade, e comece a renová-la muito antes, porque a falha contra a qual se está a proteger é silenciosa por natureza.

Para ser claro acerca do nosso próprio estado: isto é um desenho que existe em código com testes próprios, monitorização não é uma coisa que nos possa comprar hoje, e nada do que está acima deve ser lido como um anúncio de produto. É a forma que voltaríamos a construir.

Do trabalho de monitorização no Provibr. A questão relacionada de medir sem tocar, e quantos bytes uma verificação pode enviar, está em porque um scanner deve enviar zero bytes; como um agente decide qual dos vários pontos de medição usar está em como um agente escolhe o servidor de fronteira.