Em 2013, documentos vazados por Edward Snowden revelaram que agências de inteligência estavam interceptando tráfego de e-mail entre os data centers de grandes provedores. As conexões não estavam criptografadas—o e-mail fluía em texto claro pelos cabos de fibra óptica, facilmente legível por qualquer um que conseguisse interceptá-lo.
A resposta foi rápida. Google, Microsoft, Yahoo e outros implantaram criptografia entre seus servidores. A tecnologia que eles usaram foi STARTTLS, um mecanismo que existia há anos mas não era implementado universalmente. Em poucos meses, a maior parte do tráfego de e-mail entre grandes provedores estava criptografada.
STARTTLS não é perfeito, mas é a base da criptografia de e-mail em trânsito. Entender como ele funciona ajuda a entender tanto sua proteção quanto suas limitações.
Como o STARTTLS funciona
STARTTLS é uma extensão de SMTP que faz upgrade de uma conexão em texto claro para uma conexão criptografada. O nome literalmente descreve o que acontece: você inicia o TLS.
Aqui está a sequência. Um cliente se conecta a um servidor em uma porta SMTP padrão. A conexão começa sem criptografia—ambos os lados podem ver tudo em texto claro. O cliente envia um comando EHLO, e o servidor responde com suas capacidades, incluindo "250-STARTTLS" se suportar criptografia.
Se o cliente quiser criptografia (e deveria), ele envia o comando STARTTLS. O servidor responde com "220 Ready to start TLS." Nesse ponto, ambos realizam o handshake de TLS—o mesmo processo que protege conexões HTTPS. Quando o handshake termina, tudo que se segue é criptografado.
O cliente então inicia a conversa SMTP novamente, mas agora criptografada. Ele envia outro EHLO, autentica se necessário, e prossegue com o envio de e-mail. Quem estiver observando a rede vê apenas dados criptografados sem sentido.
Essa abordagem de "upgrade" é chamada de criptografia oportunista. A conexão começa sem criptografia, e a criptografia é adicionada se ambos os lados a suportarem. Isso difere de TLS implícito (usado na porta 465), onde a conexão é criptografada desde o primeiro byte.
Por que a abordagem de upgrade
Você pode se perguntar por que o e-mail não começa já criptografado, como o HTTPS. A resposta é compatibilidade histórica.
SMTP foi projetado em 1982, muito antes de a criptografia ser uma preocupação. Milhões de servidores de e-mail foram implantados falando SMTP sem criptografia. Quando a criptografia se tornou importante, o protocolo precisava evoluir sem quebrar a infraestrutura existente.
STARTTLS resolveu isso tornando a criptografia opcional e negociada. Servidores antigos que não a suportam simplesmente não anunciam a capacidade, e as conexões prosseguem sem criptografia. Servidores novos podem fazer upgrade para criptografia ao falar com outros servidores novos. O ecossistema pôde migrar gradualmente.
Essa compatibilidade retroativa veio com trade-offs. O mecanismo de upgrade cria uma janela de vulnerabilidade, e a natureza opcional significa que a criptografia não é garantida. Mas ele permitiu que a criptografia se espalhasse pelo ecossistema de e-mail sem exigir um flag day em que tudo mudasse de uma vez.
As limitações de segurança
STARTTLS fornece proteção real, mas tem fraquezas conhecidas.
A maior questão é o ataque de downgrade. Como a negociação de STARTTLS acontece em texto claro, um atacante que consegue interceptar o tráfego pode remover o anúncio da capacidade STARTTLS. O cliente acha que o servidor não suporta criptografia e segue sem criptografia. Nenhum dos lados sabe que o ataque aconteceu.
Isso não é teórico. Pesquisadores documentaram ISPs e estados-nação realizando ataques de "STARTTLS stripping". Seu e-mail pode estar criptografado quando sai do seu servidor e criptografado quando chega ao destino, mas em algum ponto no meio, alguém removeu a criptografia e leu tudo.
Validação de certificado é outra fraqueza. Muitos servidores de e-mail não validam certificados estritamente durante o STARTTLS. Eles aceitam certificados autoassinados, expirados ou para o hostname errado. Isso facilita a implantação, mas significa que um atacante man-in-the-middle poderia apresentar um certificado falso e interceptar o tráfego.
Essas limitações são o motivo pelo qual MTA-STS e DANE existem—eles fornecem mecanismos para exigir criptografia e validar certificados, fechando as lacunas que o STARTTLS deixa abertas.
STARTTLS vs TLS implícito
O e-mail suporta duas abordagens de criptografia: STARTTLS (TLS explícito) e TLS implícito.
Com STARTTLS, a conexão começa sem criptografia e faz upgrade. Isso é usado na porta 587 para envio (submission) e pode ser usado na porta 25 para transferência entre servidores.
Com TLS implícito, a conexão é criptografada desde o primeiro byte. Não há fase em texto claro, nem negociação de upgrade. Isso é usado na porta 465 para envio.
O TLS implícito é, provavelmente, mais seguro porque não há oportunidade para ataques de downgrade durante o estabelecimento da conexão. O handshake de TLS acontece imediatamente; se ele falha, a conexão falha. Não há fallback para texto claro.
No entanto, STARTTLS é mais amplamente implementado, especialmente para comunicação entre servidores. Porta 25 com STARTTLS é como a maioria dos e-mails flui entre servidores. TLS implícito na porta 465 é usado principalmente para envio por clientes.
Para o envio do seu próprio e-mail, qualquer abordagem é aceitável se implementada corretamente. Para e-mail entre servidores, STARTTLS na porta 25 é o padrão, complementado por MTA-STS ou DANE para garantias mais fortes.
Verificando suporte a STARTTLS
Você pode verificar se um servidor suporta STARTTLS usando ferramentas de linha de comando.
Conecte-se com telnet ou netcat à porta SMTP e envie um comando EHLO. A resposta do servidor lista suas capacidades. Se "250-STARTTLS" aparecer na lista, o servidor suporta upgrades de criptografia.
Para testar a conexão TLS de fato, use OpenSSL: "openssl s_client -starttls smtp -connect mail.example.com:25". Isso se conecta, emite STARTTLS, realiza o handshake de TLS e mostra o certificado e os detalhes da conexão.
Ferramentas online como CheckTLS e MXToolbox podem testar o suporte a STARTTLS para os servidores de e-mail de qualquer domínio. Elas informarão se a criptografia está disponível e fornecerão detalhes sobre os certificados em uso.
Monitorar STARTTLS ao longo do seu tráfego de e-mail ajuda a identificar servidores que não suportam criptografia. Se você estiver enviando e-mail sensível para um domínio que não suporta STARTTLS, esse e-mail viaja em texto claro.
STARTTLS na prática
A maior parte da infraestrutura moderna de e-mail suporta STARTTLS, mas a qualidade da implementação varia.
Grandes provedores de e-mail (Gmail, Microsoft, Yahoo) suportam STARTTLS e o utilizam para a vasta maioria de seu tráfego de e-mail. O Google publica relatórios de transparência mostrando qual porcentagem de e-mail de e para o Gmail usa criptografia—é acima de 90% para a maioria do tráfego.
Servidores de e-mail corporativos variam muito. Implantações bem mantidas de Exchange e Google Workspace suportam STARTTLS. Servidores antigos ou mal mantidos podem não. Ao enviar para domínios corporativos, a criptografia não é garantida.
Servidores de e-mail auto-hospedados devem sempre habilitar STARTTLS. A configuração é direta nos MTAs modernos. Não há bom motivo para rodar um servidor de e-mail sem criptografia em 2024.
Serviços de e-mail (SendGrid, Mailgun, etc.) suportam STARTTLS tanto para conexões de entrada quanto de saída. Quando você envia através desses serviços, eles usarão criptografia quando o destino a suportar.
Além do STARTTLS
STARTTLS fornece criptografia em trânsito, mas não é criptografia de ponta a ponta. O e-mail é descriptografado em cada servidor ao longo do caminho. Se você precisa de criptografia verdadeiramente ponta a ponta—onde apenas o remetente e o destinatário podem ler a mensagem—você precisa de S/MIME ou PGP.
Para uma segurança de transporte mais forte, MTA-STS e DANE abordam as fraquezas do STARTTLS. MTA-STS publica uma política exigindo criptografia e especificando certificados válidos. DANE usa DNSSEC para autenticar certificados. Ambos evitam os ataques de downgrade que o STARTTLS sozinho não consegue impedir.
O ecossistema de e-mail está se movendo gradualmente em direção à criptografia obrigatória. Google e Microsoft penalizam cada vez mais conexões não criptografadas em suas pontuações de spam. Padrões futuros podem exigir criptografia em vez de torná-la opcional.
Frequently asked questions
O STARTTLS criptografa meu e-mail de ponta a ponta?
Não. O STARTTLS criptografa o e-mail em trânsito entre servidores, mas o e-mail é descriptografado em cada servidor. Administradores de servidor e qualquer pessoa com acesso ao servidor podem ler o conteúdo. Para criptografia de ponta a ponta, use S/MIME ou PGP.
STARTTLS é o mesmo que TLS?
STARTTLS é um comando que inicia a criptografia TLS em uma conexão existente. TLS é o protocolo de criptografia em si. STARTTLS é o mecanismo; TLS é o que ele ativa.
Por que alguns e-mails ainda vão sem criptografia?
STARTTLS é opcional. Se o servidor de recebimento não o suporta, ou se um man-in-the-middle remove a capacidade, o e-mail volta para texto claro. MTA-STS e DANE ajudam a evitar isso, mas a adoção não é universal.
Devo exigir STARTTLS para todo e-mail?
Para envio, você pode preferir criptografia, mas pode precisar permitir fallback para servidores que não o suportam. Para recebimento, exigir STARTTLS pode rejeitar e-mails legítimos de remetentes mal configurados. MTA-STS permite exigir criptografia com mais nuance.