STARTTLS é menos seguro que TLS / SSL?

No Thunderbird (e presumo que em muitos outros clientes também), tenho a opção de escolher entre "SSL / TLS" e "STARTTLS".

Tanto quanto eu entendo, "STARTTLS" significa em palavras simples "criptografar se ambas as extremidades suportam TLS, caso contrário, não criptografa a transferência" . E "SSL / TLS" significa em palavras simples "sempre criptografar ou não conectar" . Isso está correto?

Ou em outras palavras:

O STARTTLS é menos seguro que o SSL / TLS, porque pode fazer o fallback para texto sem formatação sem me notificar?

A resposta, com base no STARTTLS RFC para SMTP ( RFC 3207 ) é:

STARTTLS é menos seguro que TLS.

Em vez de falar pessoalmente, permitirei que a RFC fale por si mesma, com os quatro bits relevantes destacados em BOLD :

Um ataque intermediário pode ser iniciado excluindo a resposta "250 STARTTLS" do servidor. Isso faria com que o cliente não tentasse iniciar uma sessão TLS. Outro ataque man-in-the-middle é permitir que o servidor anuncie sua capacidade STARTTLS, mas alterar a solicitação do cliente para iniciar o TLS e a resposta do servidor. Para se defender de tais ataques, clientes e servidores DEVEM poder ser configurados para exigir uma negociação TLS bem-sucedida de um conjunto de cifras apropriado para hosts selecionados antes que as mensagens possam ser transferidas com êxito. A opção adicional de usar TLS quando possível DEVE também ser fornecida. Uma implementação PODE fornecer a capacidade de registrar que o TLS foi usado na comunicação com um determinado par e gerar um aviso se não for usado em uma sessão posterior.

Se a negociação do TLS falhar ou se o cliente receber uma resposta 454, o cliente precisará decidir o que fazer em seguida. Existem três opções principais: vá em frente com o restante da sessão SMTP , [...]

Como você pode ver, o próprio RFC declara (não muito claramente, mas com clareza suficiente) que NADA NECESSITA que os clientes estabeleçam uma conexão segura e informem os usuários se uma conexão segura falhar. Ele explicitamente oferece aos clientes a opção de estabelecer silenciosamente conexões de texto sem formatação .

Não há diferença na segurança entre as duas opções.

• O SSL / TLS abre uma conexão SSL / TLS primeiro e depois inicia a transação SMTP. Isso deve ocorrer em uma porta que não tenha um servidor SMTP não SSL / TLS já em execução; é impossível configurar uma única porta para lidar com conexões de texto sem formatação e criptografadas devido à natureza dos protocolos.

• STARTTLS inicia a transação SMTP e procura suporte do outro lado para TLS na resposta ao EHLO. Se o cliente vê STARTTLS na lista de comandos suportados, envia STARTTLS e inicia a negociação para criptografia. Tudo isso pode (e geralmente ocorre) na porta SMTP padrão de 25, em parte para compatibilidade com versões anteriores, mas também para permitir a criptografia oportunista entre os terminais que o suportam, mas não necessariamente o exigem.

Geralmente, o SSL / TLS é usado apenas entre clientes finais e servidores. STARTTLS é mais comumente usado entre MTAs para proteger o transporte entre servidores.

Dadas essas duas implementações, o STARTTLS pode ser considerado inseguro se o usuário ou administrador estiver assumindo que a conexão está criptografada, mas na verdade não a configurou para exigir criptografia. No entanto, a criptografia usada é exatamente igual ao SSL / TLS e, portanto, não é mais ou menos vulnerável a um ataque Man-in-the-Middle além desse tipo de erro de configuração.

Para o email em particular, em janeiro de 2018, foi lançado o RFC 8314 , que recomenda explicitamente que o "TLS implícito" seja usado de preferência ao mecanismo STARTTLS para envios de IMAP, POP3 e SMTP.

Em resumo, este memorando agora recomenda que:

• O TLS versão 1.2 ou superior deve ser usado para todo o tráfego entre MUAs e servidores de envio de email e também entre MUAs e servidores de acesso a email.
• MUAs e Mail Service Providers (MSPs) (a) desencorajam o uso de protocolos de texto não criptografado para acesso e envio de mensagens e (b) descontinuam o uso de protocolos de texto não criptografado para esses fins o mais rápido possível.
• As conexões com os Servidores de Envio de Correio e Servidores de Acesso ao Correio devem ser feitas usando o "TLS Implícito" (conforme definido abaixo), de preferência para conectar-se à porta "texto não criptografado" e negociar o TLS usando o comando STARTTLS ou um comando semelhante.

(enfase adicionada)

A resposta depende até certo ponto do que você quer dizer com "seguro".

Primeiro, seu resumo não captura a diferença entre SSL / TLS e STARTTLS.

• Com SSL / TLS, o cliente abre uma conexão TCP com a "porta SSL" atribuída ao protocolo de aplicativo que deseja usar e começa a falar TLS imediatamente.
• Com o STARTTLS, o cliente abre uma conexão TCP com a "porta de texto não criptografado" associada ao protocolo do aplicativo que deseja usar e pergunta ao servidor "quais extensões de protocolo você suporta?". O servidor responde com uma lista de extensões. Se uma dessas extensões for "STARTTLS", o cliente poderá dizer "ok, vamos usar o TLS" e os dois começarão a falar sobre o TLS.

Se o cliente estiver configurado para exigir TLS, as duas abordagens serão mais ou menos igualmente seguras. Mas existem algumas sutilezas sobre como o STARTTLS deve ser usado para torná-lo seguro, e é um pouco mais difícil para a implementação do STARTTLS obter esses detalhes corretamente.

Por outro lado, se o cliente estiver configurado para usar TLS apenas quando o TLS estiver disponível e usar texto não criptografado quando o TLS não estiver disponível, o que o cliente pode fazer é primeiro tentar se conectar à porta SSL usada pelo protocolo e, se falhar, conecte-se à porta de texto não criptografado e tente usar STARTTLS e, finalmente, volte ao texto não criptografado se o TLS não estiver disponível nos dois casos. É bastante fácil para um invasor causar uma falha na conexão da porta SSL (basta alguns pacotes TCP RST oportunos ou o bloqueio da porta SSL). É um pouco mais difícil - mas apenas um pouco - para um invasor derrotar a negociação do STARTTLS e fazer com que o tráfego permaneça em texto não criptografado. E então o invasor não apenas lê seu email, mas também captura seu nome de usuário / senha para uso futuro.

Portanto, a resposta simples é que, se você estiver se conectando a um servidor que você já sabe que suporta TLS (como deve ser o caso ao enviar ou ler e-mails), use SSL / TLS. Se a conexão estiver sendo atacada, a tentativa de conexão falhará, mas sua senha e email não serão comprometidos.

Por outro lado, se você estiver se conectando a algum serviço que não sabe se ele suporta TLS, o STARTTLS pode ser um pouco melhor.

Quando o STARTTLS foi inventado, os ataques "passivos" apenas para escuta eram muito comuns; os ataques "ativos" nos quais o invasor injetava tráfego para tentar diminuir a segurança eram menos comuns. Nos 20 anos seguintes, ataques ativos tornaram-se mais viáveis ​​e comuns.

Por exemplo, se você estiver tentando usar um laptop em um aeroporto ou em algum outro local público e tentar ler seus e-mails por meio do wifi fornecido lá, não terá ideia do que essa rede wifi está fazendo com seu tráfego. É muito comum as redes wifi rotearem certos tipos de tráfego para "proxies" que se interpõem entre os aplicativos clientes e os servidores com os quais eles estão tentando conversar. É trivial para esses proxies desativar o STARTTLS e "tentar uma porta e depois outra" na tentativa de fazer com que o cliente volte ao texto não criptografado. Sim, isso acontece e é apenas um exemplo de como seu tráfego pode ser espionado por uma rede. E esses ataques não se limitam a agências de três letras apoiadas pelo estado,

Sim, você tem o básico certo. E sim, o STARTTLS é definitivamente menos seguro. Não apenas pode fazer failback para texto sem formatação sem notificação, mas porque está sujeito a ataques intermediários. Como a conexão é iniciada sem problemas, um MitM pode remover o comando STARTTLS e impedir que a criptografia ocorra. No entanto, acredito que os servidores de e-mail possam especificar que as transferências somente ocorram após a instalação de um túnel criptografado. Então você pode resolver isso.

Então, por que essa coisa existe? Por motivos de compatibilidade. Se um dos lados não suportar criptografia, você ainda pode querer que a conexão seja concluída corretamente.

Concorde com @Greg. Esses ataques são possíveis. No entanto, os MTAs podem ser configurados (dependendo do MTA) para usar "TLS obrigatório", não "TLS oportunista". O que isso significa é que TLS e apenas TLS são usados ​​(isso também inclui STARTTLS) para as transações de email. Se o MTA remoto não suportar STARTTLS, o email será devolvido.

Não, é não menos seguro, quando seu aplicativo manipula-lo corretamente.

Existem quatro maneiras de lidar com o TLS e muitos programas permitem que você escolha:

• Sem TLS
• TLS na porta dedicada (apenas tenta TLS)
• Use TLS se disponível (tenta starttls, usa uma conexão não criptografada quando falha)
• Sempre use TLS (usa starttlse falha se não funcionar)

A vantagem do TLS em uma porta dedicada é que você pode ter certeza de que não há substituto ao usar um programa que ainda não conhece ou que não expõe as configurações detalhadas para tratamento de erros em seu assistente de primeira inicialização.

Mas, em geral, a segurança depende do tratamento de erros de segurança. Um programa pode decidir mudar para a porta de texto sem formatação quando o TLS na porta TLS também falhar. Você precisa saber o que ele fará e escolher configurações seguras. E os programas devem usar padrões seguros.