O STARTTLS é menos seguro que o TLS / SSL?

Question

No Thunderbird (e eu acredito em muitos outros clientes também), eu 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 criptografe a transferência" . E "SSL / TLS" significa em palavras simples "sempre criptografar ou não se conectar a todos" . Isso está correto?

Ou em outras palavras:

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

    

Answer 1

A resposta, baseada no STARTTLS RFC for SMTP ( RFC 3207 ) é:

STARTTLS é menos seguro que o TLS.

Em vez de falar sozinho, vou permitir que o RFC fale por si, com os quatro bits relevantes destacados em BOLD :

A man-in-the-middle attack can be launched by deleting the "250 STARTTLS" response from the server. This would cause the client not to try to start a TLS session. Another man-in-the-middle attack is to allow the server to announce its STARTTLS capability, but to alter the client's request to start TLS and the server's response. In order to defend against such attacks both clients and servers MUST be able to be configured to require successful TLS negotiation of an appropriate cipher suite for selected hosts before messages can be successfully transferred. The additional option of using TLS when possible SHOULD also be provided. An implementation MAY provide the ability to record that TLS was used in communicating with a given peer and generating a warning if it is not used in a later session.

If the TLS negotiation fails or if the client receives a 454 response, the client has to decide what to do next. There are three main choices: go ahead with the rest of the SMTP session, [...]

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

    

Answer 2

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

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

• STARTTLS inicia a transação SMTP e procura suporte da outra extremidade para o TLS na resposta ao EHLO. Se o cliente vir STARTTLS na lista de comandos suportados, ele enviará STARTTLS e iniciará a negociação para criptografia. Tudo isso pode (e geralmente ocorre) na porta SMTP padrão de 25, parcialmente para compatibilidade com versões anteriores, mas também para permitir a criptografia oportunista entre os endpoints que o suportam, mas não necessariamente o exigem.

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

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

    

Answer 3

Para o e-mail 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.

In brief, this memo now recommends that:

• TLS version 1.2 or greater be used for all traffic between MUAs and Mail Submission Servers, and also between MUAs and Mail Access Servers.
• MUAs and Mail Service Providers (MSPs) (a) discourage the use of cleartext protocols for mail access and mail submission and (b) deprecate the use of cleartext protocols for these purposes as soon as practicable.
• Connections to Mail Submission Servers and Mail Access Servers be made using "Implicit TLS" (as defined below), in preference to connecting to the "cleartext" port and negotiating TLS using the STARTTLS command or a similar command.

(ênfase adicionada)

    

Answer 4

A resposta depende em certa medida do que você entende por "seguro".

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

• Com o 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 de aplicativo que deseja usar e, em seguida, pergunta ao servidor "que extensões de protocolo você suporta?". O servidor responde então 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 em TLS.

Se o cliente estiver configurado para exigir TLS, as duas abordagens serão mais ou menos seguras. Mas há 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 acertar esses detalhes.

Por outro lado, se o cliente estiver configurado para usar o TLS somente 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 é tentar se conectar à porta SSL usada pelo protocolo, e se isso falhar, conecte-se à porta de texto não criptografado e tente usar STARTTLS e, finalmente, retorne ao cleartext se o TLS não estiver disponível nos dois casos. É bastante fácil para um invasor causar falha na conexão da porta SSL (bastam alguns pacotes TCP RST ou bloqueio da porta SSL). É um pouco mais difícil - mas só um pouquinho - para um invasor derrotar a negociação 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 e-mail, mas também captura seu nome de usuário / senha para uso futuro.

Portanto, a resposta simples é se você estiver se conectando a um servidor que você já conhece como suporte a TLS (como deveria ser o caso quando estiver enviando ou lendo um email), você deve usar 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 de escuta "passiva" eram muito comuns, ataques "ativos" nos quais o invasor injetava tráfego para tentar baixar a segurança eram menos comuns. Nos cerca de 20 anos desde então, os ataques ativos tornaram-se mais viáveis e mais comuns.

Por exemplo, se você estiver tentando usar um laptop em um aeroporto ou algum outro local público e tentar ler seu e-mail pelo Wi-Fi fornecido, não fará ideia do que essa rede wifi está fazendo com seu tráfego. É muito comum as redes Wi-Fi rotearem certos tipos de tráfego para "proxies" que se interpõem entre seus aplicativos clientes e os servidores com os quais estão tentando conversar. É trivial para esses proxies desabilitar ambos os STARTTLS e "tentar uma porta e outra" na tentativa de fazer com que seu cliente retorne ao cleartext. 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, elas podem ser retiradas por um adolescente com um computador de US $ 35 que está escondido em um lugar público em algum lugar.

    

Answer 5

Sim, você tem o básico certo. E sim, o STARTTLS é definitivamente menos seguro. Não só pode fazer failback para texto sem notificação, mas porque está sujeito a ataques man-in-the-middle. Como a conexão começa de forma clara, um MitM pode remover o comando STARTTLS e impedir que a criptografia ocorra. No entanto, acredito que os servidores de e-mail podem especificar que as transferências só ocorrem depois que um túnel criptografado é configurado. Então você pode contornar isso.

Então, por que tal coisa existe mesmo? Por razões de compatibilidade. Se um dos lados não suportar criptografia, talvez você ainda queira que a conexão seja concluída corretamente.

    

Answer 6

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.

    

Answer 7

Não, não é não menos seguro, quando seu aplicativo manipula 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 falhar)
• Sempre use TLS (Usa starttls e falha se não funcionar)

A vantagem do TLS em uma porta dedicada é que você pode ter certeza de que não haverá fallback quando usar um programa que ainda não conhece ou que não exponha as configurações de detalhes para tratamento de erros em seu assistente de início.

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