O que é STARTTLS?
O STARTTLS é o comando que faz dois servidores de e-mail combinarem, no meio de uma conversa que começou aberta, passar a trocar mensagens de forma criptografada. Ele é o motivo pelo qual a maior parte do e-mail hoje trafega protegido, e também a origem de um mal-entendido caro: a proteção é oportunista, acontece quando os dois lados conseguem, e um atacante no meio do caminho derruba tudo apagando uma única linha da conversa. Padronizado em 1999 e definido hoje pela RFC 3207, de 2002.
Como o STARTTLS funciona
A entrega de e-mail entre servidores acontece pelo protocolo SMTP e começa sempre em texto aberto. O STARTTLS é um convite feito dentro dessa conversa aberta, e por isso depende de o convite chegar.
O servidor anuncia que aceita
Aberta a conexão, o remetente se apresenta e o servidor de destino responde listando o que sabe fazer. Se souber criptografar, inclui nessa lista a linha 250 STARTTLS.
O remetente pede para trocar de canal
Vendo o anúncio, o servidor que envia responde pedindo a mudança. Se o anúncio não estiver lá, ele não pede, e a conversa segue aberta.
Os dois negociam a proteção
Servidor e cliente combinam a versão e a cifra que vão usar, e o canal passa a ser criptografado a partir daquele ponto.
A mensagem viaja protegida daquele trecho
Só então o conteúdo é enviado. A proteção vale para aquele salto entre dois servidores, não para o caminho inteiro nem para a mensagem parada na caixa.
Fonte: RFC 3207, a especificação oficial do STARTTLS em vigor, publicada pelo IETF em 2002, que define a extensão do SMTP para uso de TLS (Transport Layer Security) e alerta, nas suas Considerações de Segurança, para o ataque de supressão do anúncio.
O ponto cego que a própria norma denuncia
- A proteção é opcional por natureza. O STARTTLS só entra em ação se o destino anunciar que sabe e o remetente decidir pedir. Não há nada, no fluxo padrão, que obrigue qualquer um dos dois.
- Apagar uma linha derruba a criptografia. O texto da norma é explícito: um ataque no meio do caminho pode ser feito removendo a resposta 250 STARTTLS do servidor, o que faz o remetente simplesmente não tentar proteger a conversa.
- A queda é silenciosa. Quando o convite some, nada falha e ninguém é avisado: a mensagem é entregue normalmente, em texto aberto, e os dois lados seguem achando que está tudo certo.
- Criptografar não é identificar. A própria norma diz que acreditar ou não na autenticidade do outro lado é decisão local de cada servidor, e no uso oportunista o remetente costuma aceitar o certificado que aparecer, então o canal fica fechado sem que ninguém tenha provado com quem está falando.
Os três estados possíveis de uma entrega
- Sem criptografia nenhuma Um dos lados não sabe ou não quis. A mensagem atravessa a internet legível para qualquer ponto por onde passar. Continua acontecendo todo dia, em volume.
- Criptografia oportunista O caso mais comum. Funciona bem quando ninguém interfere, e é exatamente o que o ataque de supressão desmonta, porque o remetente aceita voltar ao texto aberto sem reclamar.
- Criptografia exigida O remetente se recusa a entregar se o canal não puder ser protegido e validado. A própria norma prevê essa configuração, e é ela que fecha o buraco. O que faltava era um jeito de o destinatário anunciar essa exigência, e isso veio depois, com o MTA-STS.
O que está em jogo enquanto a proteção é opcional
A conta desse desenho não aparece num incidente, aparece na ausência de um. Quando a criptografia é derrubada por supressão do anúncio, nada quebra: a mensagem chega, o remetente não recebe erro, o destinatário não recebe aviso, e o conteúdo trafegou legível por onde passou. É a diferença entre uma porta arrombada, que se percebe, e uma porta que nunca chegou a ser trancada, que não se percebe. Para uma empresa isso importa porque o e-mail entre servidores carrega justamente o que ninguém quer exposto: proposta comercial com preço, dados de cliente, anexo de folha de pagamento, discussão de contrato, código de recuperação de senha. E a exposição não depende do tamanho da empresa, e sim do trecho da internet por onde a mensagem passou naquele salto.
Como sair da criptografia opcional
O STARTTLS resolve metade do problema e não tem como resolver a outra metade sozinho. O caminho é acrescentar exigência e medição em volta dele:
- Garanta que os seus servidores anunciam e aceitamÉ o piso, e ainda há ambiente que não cumpre. Sem o anúncio no destino, nenhum remetente do mundo consegue proteger a entrega para você.
- Mantenha o certificado válido e com o nome certoCertificado vencido ou emitido para outro nome derruba a validação. Como no modo oportunista muita gente aceita assim mesmo, o defeito passa despercebido até o dia em que alguém passa a exigir.
- Publique uma exigência de canal protegidoÉ o que o MTA-STS faz: declara para o mundo que a sua entrada só aceita conversa criptografada e validada, tirando a decisão do calor do momento.
- Ligue o relatório antes de exigirO TLS-RPT devolve todo dia o que funcionou e o que falhou na entrada do seu domínio, e é ele que permite endurecer sem derrubar remetente legítimo.
- Trate isto como camada de transporte, não de conteúdoProteger o salto entre servidores não protege a mensagem depois de entregue, nem prova quem a escreveu. Autenticação de remetente e proteção da caixa são camadas distintas, que trabalham juntas.
Na prática
O STARTTLS é um convite para conversar em particular, e um terceiro derruba esse convite apenas fingindo que ele nunca foi feito. Por isso a pergunta certa nunca é se o seu e-mail usa criptografia, e sim se alguém consegue fazer o seu e-mail deixar de usar sem que ninguém perceba. Enquanto a resposta for sim, o que existe é a possibilidade de proteção, não a proteção.
Como a Zamak trata a criptografia de transporte
A Zamak Technologies trata o canal de e-mail como algo que se mede, não como algo que se supõe: confere se o destino anuncia e aceita a troca para canal protegido, se o certificado está válido e com o nome correto, e liga o relatório antes de propor qualquer exigência, ao lado da equipe que já administra o ambiente. Na prática isso significa fechar o buraco desta página com as duas peças que vêm depois dela: o MTA-STS, que publica a exigência de canal protegido, e o TLS-RPT, que mede se ela está sendo cumprida. A verificação de falsificação de e-mail dá o primeiro retrato do que o seu domínio declara hoje. O acompanhamento contínuo dessa camada faz parte da Segurança de E-mail Gerenciada e da Cibersegurança gerenciada do Método Zamak.