Resumo

  • STARTTLS inseriu TLS numa conexão SMTP já aberta, mas não herdou a autoridade da conversa inicial: depois do handshake, ambos descartavam o que aprenderam em texto aberto e o cliente enviava outro EHLO.
  • O reinício impedia que afirmações alteráveis governassem o canal protegido. Não tornava a criptografia obrigatória nem autenticava toda a rota; DANE e MTA-STS depois trouxeram evidência externa capaz de proibir o recuo silencioso.

Uma conexão começou duas vezes

O servidor SMTP recebia a conexão com 220. O cliente se apresentava com EHLO, e o servidor enumerava as extensões disponíveis. Em 1999, STARTTLS entrou nessa gramática como uma palavra sem parâmetros. O cliente enviava STARTTLS; uma resposta 220 encerrava a fase aberta e iniciava o handshake TLS.

A escolha preservou a porta e o sistema MX. Clientes antigos continuavam funcionando, enquanto clientes novos descobriam criptografia na conexão existente. A migração não exigia duas redes de correio.

Mas a descoberta vinha antes da proteção. Um atacante no caminho podia trocar o primeiro nome, retirar capacidades ou apagar a linha STARTTLS. Os bytes iniciais levavam as partes até a fronteira criptográfica; não eram prova para decisões tomadas depois dela.

Criptografar exigiu esquecer

Concluído o TLS, o SMTP voltava ao estado inicial. O servidor descartava o argumento do primeiro EHLO e o cliente descartava a primeira lista de extensões. Então o cliente se apresentava de novo.

O segundo EHLO pertence a outro contexto. O servidor pode anunciar um método de autenticação somente após receber um certificado de cliente adequado. O cliente pode validar a identidade do servidor antes de aceitar funções. O handshake não transforma declarações anteriores em fatos autenticados; ele faz essas declarações expirarem.

A divisão também ordena os bytes. Depois de 220, o cliente precisa começar TLS antes de outro comando SMTP. Num grupo PIPELINING, STARTTLS fica por último. Assim, um comando aberto não se mistura ao handshake e uma escolha feita no estado antigo não invade o novo.

Um canal protegido ainda precisava de julgamento

TLS pode oferecer sigilo, integridade e autenticação, mas o fim do handshake não define se o resultado basta. Nome esperado, raízes confiáveis, algoritmos e credenciais do cliente continuam sujeitos à política local. Qualquer lado pode encerrar a sessão.

Essa separação contém a promessa. Cifrar contra escuta passiva não garante que o MX pretendido foi autenticado. Autenticar um retransmissor não autentica o autor humano. Proteger um salto não demonstra proteção nos saltos anteriores e posteriores.

A resposta 454 expõe a decisão: se TLS estiver temporariamente indisponível, o emissor pode seguir em aberto, enfileirar para tentar de novo ou falhar. A extensão fornece um mecanismo, não uma autorização automática para revelar a mensagem.

A interoperabilidade limitou a primeira obrigação

Um MX público precisava receber de sistemas ainda antigos. A RFC 3207 proibiu um servidor publicamente referenciado na porta 25 de exigir STARTTLS como condição geral para entrega local. Servidores privados e políticas de retransmissão podiam ser mais rigorosos.

O compromisso protegeu a alcançabilidade e permitiu adoção gradual. Também deixou a oferta STARTTLS sem uma obrigação durável. Se um atacante apagasse a linha, um cliente oportunista podia concluir que TLS nunca existira e entregar em aberto.

Não era uma falha do algoritmo TLS. A própria regra que exigiria TLS viajava dentro da conversa que o atacante conseguia editar.

A política saiu da conversa

DANE para SMTP associou a exigência e a autenticação do canal a registros TLSA validados por DNSSEC. Havendo um registro seguro e aplicável, a ausência de STARTTLS não autorizava texto aberto. A entrega precisava esperar.

MTA-STS tomou outro caminho. O destinatário sinaliza uma política, oferece seu conteúdo por HTTPS, e o remetente armazena os MX aceitos, a validação PKIX e um prazo. Durante a aplicação, STARTTLS ausente ou certificado inválido causa adiamento. A primeira descoberta tem uma exposição diferente da negação autenticada de DNSSEC, enquanto o cache reduz oportunidades posteriores.

Os dois preservam STARTTLS como transição dentro do SMTP. O que muda é a autoridade para responder quando a transição parece faltar.

A invenção duradoura foi a segunda saudação

Resumir STARTTLS como troca de texto aberto por cifra perde a lição principal. O protocolo deu prazo de validade ao estado anterior. Capacidades foram redescobertas, identidade passou por política explícita e recuo deixou de ser sinônimo de falha comum.

Todo protocolo antigo que ganha segurança enfrenta a mesma dívida. Criptografia nova não limpa decisões já tomadas sobre dados alteráveis. É preciso dizer que estado atravessa a fronteira, o que é apagado e quem pode permitir uma proteção inferior.

Fontes e limites

O desenho inicial e o alerta sobre remoção da oferta estão na RFC 2487; as regras revistas, o reinício e o limite de interoperabilidade estão na RFC 3207. A RFC 7672 define DANE para SMTP, e a RFC 8461 define MTA-STS. As normas não medem adoção atual nem volume global de ataques.