Resumo

  • A RFC 8314 recomenda TLS implícito para acesso e submissão de e-mail: nas portas 465, 993 e 995, a negociação TLS começa logo após a conexão TCP, antes de comandos da aplicação.
  • Esse início protege o canal, mas não comprova sozinho a identidade do serviço esperado, não autentica nem autoriza o usuário e não prova aceitação ou entrega da mensagem.

Uma central de suporte expandiu o ícone verde e encontrou uma sequência mais longa. O cliente havia alcançado a porta 465, negociado TLS e validado um certificado. Depois, o login funcionou. Ainda assim, o servidor recusou o remetente usado no envelope. A última decisão não desmentia as anteriores: ela aplicava um direito específico que nenhuma delas tinha concedido.

A interface costuma transformar essa sequência numa palavra, “seguro”. Por baixo dela existem o nome de serviço pretendido, a descoberta de rede, o endereço alcançado, a porta, o transcript TLS, o certificado, o nome validado, o mecanismo de autenticação, a conta resultante e a política para cada operação. Uma etapa bem-sucedida fornece contexto à próxima; não produz o resultado da próxima.

Keith Moore e Chris Newman publicaram a RFC 8314 em 2018. O documento propõe que texto em claro deixe de ser o padrão entre um Mail User Agent e os servidores de acesso ou submissão. Para POP, IMAP e SMTP Submission, recomenda TLS implícito em vez de abrir uma sessão de aplicação em claro e elevá-la depois com STARTTLS ou comando semelhante.

“Implícito” designa a ordem do protocolo. Na porta padrão 465 do serviço submissions, o handshake TLS começa imediatamente após o estabelecimento de TCP. O mesmo modelo usa 993 para IMAP e 995 para POP. Somente quando o canal está estabelecido prossegue o protocolo de correio. Com STARTTLS, o cliente primeiro conversa em claro, recebe as capacidades, pede a elevação e então inicia TLS.

Retirar a fase anterior ao handshake reduz uma superfície de downgrade. Não torna o número 465 uma prova criptográfica. Uma configuração de porta não mostra qual endereço foi resolvido, qual processo respondeu, qual certificado apareceu ou se o cliente verificou o nome correto. O recibo precisa conter a conexão realmente observada.

A RFC 8314 não ignora a base instalada. Ela registra o uso amplo de STARTTLS na porta 587 e recomenda que, durante uma transição, clientes e servidores suportem tanto 587/STARTTLS quanto 465/TLS implícito. Não é correto dizer que todo STARTTLS é inseguro. O ponto decisivo é se a política exige proteção e encerra a sessão quando a capacidade some ou a elevação falha.

A RFC 2595 definiu STARTTLS para IMAP, POP3 e ACAP e descreveu um intermediário capaz de remover a capacidade anunciada ou provocar falha. A ausência de uma capacidade não prova ataque, pois também pode vir de configuração ou versão. E a simples continuação da conexão não prova segurança. É necessário preservar a resposta bruta, a regra do cliente e sua ação após o erro.

Uma sessão TLS também precisa de uma identidade de referência. A RFC 8314 exige que os clientes implementem validação de certificados. A RFC 9525, posterior e escrita por outros autores, descreve o quadro geral atual: o cliente constrói identificadores de referência a partir de entrada ou configuração confiável, valida o caminho de certificação e procura correspondência com os identificadores apresentados. Um nome intermediário obtido no DNS não se torna automaticamente a identidade pretendida.

Quando a correspondência passa, ela autentica o serviço da aplicação naquele escopo. Não autentica a pessoa que usa o cliente, não garante que o servidor seja isento de falhas e não lhe atribui autoridade sobre nomes fora do conjunto validado. Tampouco concede acesso a uma caixa postal. Identidade do serviço e identidade do usuário são sujeitos diferentes.

Certificados de cliente podem participar sem eliminar a fronteira. A RFC 8314 permite seu uso e também permite que o servidor exija autenticação de aplicação mesmo depois de receber um certificado. Um transcript de TLS mútuo não prova uma operação autorizada se não registrar como o certificado foi associado à conta e quais direitos a política entregou.

SASL dá nomes à separação. A RFC 4422 distingue a identidade de autenticação ligada às credenciais da identidade de autorização sob a qual o cliente pede para agir. O servidor verifica a primeira e decide se ela pode representar a segunda. O intercâmbio falha se a credencial ou essa delegação falhar. Omitir uma identidade de autorização separada costuma pedir para agir como a própria identidade autenticada, mas a decisão do servidor permanece.

Submissão de mensagens acrescenta direitos próprios. A RFC 6409 separa submissão de retransmissão e reserva a porta 587 para o serviço. Um Message Submission Agent pode limitar o acesso a usuários autorizados e recusar um MAIL FROM sem direitos suficientes ou incompatível com a autenticação. Chegar ao MSA por TLS não pré-aprova remetentes, destinatários, tamanho ou conteúdo.

Nem a aceitação do MSA comprova entrega final. Ela registra que o agente assumiu responsabilidade naquele estágio. Ainda vêm transferência, resposta do servidor destinatário, filtros, colocação na caixa e leitura humana. “TLS passou”, “serviço validado”, “usuário autenticado”, “comando autorizado”, “mensagem aceita” e “mensagem entregue” são recibos diferentes.

Uma cadeia reprodutível conserva o serviço configurado e a entrada de descoberta; o endereço e a porta realmente contatados; o modo de início de TLS, transcript, versão e certificado; o caminho de confiança, os identificadores de referência e a correspondência. Depois registra mecanismo SASL, identidade autenticada, identidade de autorização pedida, regra aplicada, comando e resposta exata. Para saída de correio, acrescenta eventos de transferência e entrega.

O trabalho de Newman e Moore adiantou a proteção até o primeiro ato da conexão. Não entregou à porta o poder de decidir tudo o que acontece depois. TLS implícito estabelece o canal; autorização continua sendo uma decisão do serviço.

Fontes