TLS oportunista - Opportunistic TLS

"STARTTLS" redireciona aqui. Para a autoridade de certificação, consulte StartCom § StartSSL .

O TLS oportunista (Transport Layer Security) refere-se a extensões em protocolos de comunicação de texto simples, que oferecem uma maneira de atualizar uma conexão de texto simples para uma conexão criptografada ( TLS ou SSL ) em vez de usar uma porta separada para comunicação criptografada. Vários protocolos usam um comando denominado " STARTTLS " para este propósito. É uma forma de criptografia oportunista e tem como objetivo principal uma contramedida ao monitoramento passivo .

O comando STARTTLS para IMAP e POP3 é definido no RFC  2595 , para SMTP no RFC  3207 , para XMPP no RFC  6120 e para NNTP no RFC  4642 . Para o IRC , o Grupo de Trabalho IRCv3 definiu a extensão STARTTLS. O FTP usa o comando "AUTH TLS" definido na RFC  4217 e o LDAP define uma extensão de protocolo OID na RFC  2830 . HTTP usa cabeçalho de atualização .

Layering

O TLS é neutro em relação ao aplicativo; nas palavras de RFC  5246 :

Uma vantagem do TLS é que ele é independente do protocolo do aplicativo. Os protocolos de nível superior podem se sobrepor ao protocolo TLS de forma transparente. O padrão TLS, entretanto, não especifica como os protocolos adicionam segurança com TLS; as decisões sobre como iniciar o handshaking TLS e como interpretar os certificados de autenticação trocados são deixadas para o julgamento dos projetistas e implementadores de protocolos que são executados no topo do TLS.

O estilo usado para especificar como usar TLS corresponde à mesma distinção de camada que também é convenientemente suportada por várias implementações de biblioteca de TLS. Por exemplo, a extensão SMTP RFC  3207 ilustra com a seguinte caixa de diálogo como um cliente e servidor podem iniciar uma sessão segura: 

  S: <waits for connection on TCP port 25>
  C: <opens connection>
  S: 220 mail.example.org ESMTP service ready
  C: EHLO client.example.org
  S: 250-mail.example.org offers a warm hug of welcome
  S: 250 STARTTLS
  C: STARTTLS
  S: 220 Go ahead
  C: <starts TLS negotiation>
  C & S: <negotiate a TLS session>
  C & S: <check result of negotiation>
  C: EHLO client.example.org
  . . .

O último comando EHLO acima é emitido por um canal seguro. Observe que a autenticação é opcional no SMTP, e a resposta do servidor omitida agora pode anunciar com segurança uma extensão AUTH PLAIN SMTP, que não está presente na resposta em texto simples.

Portas SSL

Além do uso de TLS oportunista, várias portas TCP foram definidas para versões protegidas por SSL de protocolos conhecidos. Eles estabelecem comunicações seguras e, em seguida, apresentam um fluxo de comunicação idêntico ao antigo protocolo não criptografado. Portas SSL separadas têm a vantagem de menos viagens de ida e volta ; além disso, menos metadados são transmitidos de forma não criptografada. Alguns exemplos incluem:

Protocolo Propósito Porta normal Variante SSL Porta SSL
SMTP Enviar email 25/587 SMTPS 465
POP3 Recuperar e-mail 110 POP3S 995
IMAP Leia e-mail 143 IMAPS 993
NNTP Novos leitores 119/433 NNTPS 563
LDAP Acesso ao diretório 389 LDAPS 636
FTP Transferência de arquivo 21 FTPS 990

Pelo menos para os protocolos relacionados a e-mail, o RFC  8314 favorece portas SSL separadas em vez de STARTTLS.

Fraquezas e mitigações

O TLS oportunista é um mecanismo de criptografia oportunista . Como o handshake inicial ocorre em texto simples, um invasor no controle da rede pode modificar as mensagens do servidor por meio de um ataque man-in-the-middle para fazer parecer que o TLS está indisponível (chamado de ataque STRIPTLS ). A maioria dos clientes SMTP enviará o e-mail e, possivelmente, as senhas em texto simples, geralmente sem notificação ao usuário. Em particular, muitas conexões SMTP ocorrem entre servidores de e-mail, onde a notificação do usuário não é prática.

Em setembro de 2014, dois ISPs na Tailândia estavam fazendo isso com seus próprios clientes. Em outubro de 2014, foi revelado que a Cricket Wireless , uma subsidiária da AT&T , estava fazendo isso com seus clientes. Esse comportamento começou já em setembro de 2013 pela Aio Wireless , que mais tarde se fundiu com a Cricket, onde a prática continuou.

Os ataques STRIPTLS podem ser bloqueados configurando clientes SMTP para exigir TLS para conexões de saída (por exemplo, o agente de transferência Exim Message pode exigir TLS por meio da diretiva "hosts_require_tls"). No entanto, como nem todo servidor de e-mail oferece suporte a TLS, não é prático simplesmente exigir TLS para todas as conexões.

Um exemplo de ataque STRIPTLS do tipo usado na tecnologia de vigilância em massa tailandesa :

Esse problema é abordado pela Autenticação de Entidades Nomeadas baseada em DNS (DANE), uma parte do DNSSEC e, em particular, pela RFC  7672 para SMTP. O DANE permite anunciar suporte para SMTP seguro por meio de um registro TLSA. Isso informa aos clientes de conexão que eles devem exigir TLS, evitando ataques STRIPTLS. O projeto STARTTLS Everywhere da Electronic Frontier Foundation funciona de maneira semelhante. No entanto, DNSSEC, devido às complexidades de implantação e críticas peculiares, enfrentou uma baixa taxa de adoção e um novo protocolo chamado SMTP MTA Strict Transport Security ou MTA-STS foi elaborado por um grupo de grandes provedores de serviço de e-mail, incluindo Microsoft, Google e Yahoo. O MTA-STS não exige o uso de DNSSEC para autenticar registros DANE TLSA, mas depende do sistema de autoridade de certificação (CA) e de uma abordagem de confiança no primeiro uso (TOFU) para evitar interceptações. O modelo TOFU reduz a complexidade, mas sem as garantias de primeira utilização oferecidas pelo DNSSEC. Além disso, o MTA-STS apresenta um mecanismo para relatório de falhas e um modo somente relatório, permitindo implantação progressiva e auditoria de conformidade.

Popularidade

Após as revelações feitas por Edward Snowden à luz do escândalo de vigilância em massa global , os provedores de e-mail populares melhoraram sua segurança de e-mail habilitando STARTTLS. O Facebook relatou que depois de habilitar STARTTLS e encorajar outros provedores a fazer o mesmo, até que o Facebook descontinuou seu serviço de e-mail em fevereiro de 2014, 95% dos e-mails enviados foram criptografados com Perfect Forward Secrecy e validação de certificado estrita.

Referências

links externos