{"id":91951,"date":"2020-08-20T19:42:11","date_gmt":"2020-08-20T17:42:11","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/pochta-mail-ru-nachinaet-v-testovom-rezhime-primenyat-politiki-mta-sts"},"modified":"2020-08-20T19:42:11","modified_gmt":"2020-08-20T17:42:11","slug":"pochta-mail-ru-nachinaet-v-testovom-rezhime-primenyat-politiki-mta-sts","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/pochta-mail-ru-nachinaet-v-testovom-rezhime-primenyat-politiki-mta-sts","title":{"rendered":"O Mail.ru come\u00e7a a aplicar pol\u00edticas MTA-STS em modo de teste","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"O
\n
\nEm resumo, MTA-STS \u00e9 uma maneira de proteger ainda mais os e-mails contra intercepta\u00e7\u00f5es (ou seja, ataques de homem-no-meio, conhecido como MitM) durante a transmiss\u00e3o entre servidores de e-mail. Ele resolve parcialmente problemas arquitet\u00f4nicos herdados dos protocolos de e-mail e est\u00e1 descrito em um padr\u00e3o relativamente recente, o RFC 8461. O Mail.ru \u00e9 o primeiro grande servi\u00e7o de e-mail na Runet a implementar esse padr\u00e3o. Uma explica\u00e7\u00e3o mais detalhada pode ser encontrada abaixo.
\n<\/a><\/noindex><\/p>\n

Qual problema o MTA-STS resolve?<\/h1>\n

\nHistoricamente, os protocolos de e-mail (SMTP, POP3, IMAP) transmitiam informa\u00e7\u00f5es em texto claro, o que permite sua intercepta\u00e7\u00e3o, por exemplo, ao acessar um canal de comunica\u00e7\u00e3o.<\/p>\n

Como funciona o mecanismo de entrega de e-mail de um usu\u00e1rio para outro:<\/p>\n

\"O
\n
\nHistoricamente, ataques MitM eram poss\u00edveis em todos os locais onde circulam e-mails.<\/p>\n

O padr\u00e3o RFC 8314 exige o uso obrigat\u00f3rio de TLS entre o cliente de e-mail do usu\u00e1rio (MUA) e o servidor de e-mail. Se seu servidor e os aplicativos de e-mail utilizados estiverem em conformidade com o RFC 8314, voc\u00ea (em grande medida) eliminou a possibilidade de ataques Man-in-the-Middle entre o usu\u00e1rio e os servidores de e-mail.<\/p>\n

O cumprimento de pr\u00e1ticas estabelecidas (os RFC 8314 padronizados) elimina ataques pr\u00f3ximos ao usu\u00e1rio:<\/p>\n

\"O
\n
\nOs servidores de e-mail do Mail.ru j\u00e1 estavam em conformidade com o RFC 8314 antes mesmo da aceita\u00e7\u00e3o do padr\u00e3o; na verdade, ele apenas documenta pr\u00e1ticas j\u00e1 adotadas, e n\u00e3o foi necess\u00e1rio fazer ajustes adicionais. Mas, se seu servidor de e-mail ainda permite acesso a usu\u00e1rios atrav\u00e9s de protocolos inseguros, implemente obrigatoriamente as recomenda\u00e7\u00f5es deste padr\u00e3o, pois \u00e9 prov\u00e1vel que, pelo menos, parte de seus usu\u00e1rios utilize a e-mail sem criptografia, mesmo que voc\u00ea a suporte.<\/p>\n

O cliente de e-mail sempre trabalha com o mesmo servidor de e-mail da mesma organiza\u00e7\u00e3o. E \u00e9 poss\u00edvel for\u00e7ar todos os usu\u00e1rios a se conectarem de maneira segura, tornando tecnicamente imposs\u00edvel a conex\u00e3o insegura (isso \u00e9 exatamente o que RFC 8314 exige). Isso \u00e0s vezes \u00e9 complicado, mas vi\u00e1vel. Com o tr\u00e1fego entre os servidores de e-mail, a situa\u00e7\u00e3o \u00e9 ainda mais complexa. Os servidores pertencem a diferentes organiza\u00e7\u00f5es e muitas vezes s\u00e3o usados no modo 'instalou e esqueceu', o que torna imposs\u00edvel a mudan\u00e7a simult\u00e2nea para um protocolo seguro sem comprometer a conectividade. No SMTP, j\u00e1 existe h\u00e1 bastante tempo a extens\u00e3o STARTTLS, que permite que servidores que suportem criptografia migrem para TLS. Mas um atacante que tem a capacidade de influenciar o tr\u00e1fego pode 'cortar' as informa\u00e7\u00f5es sobre o suporte a esse comando e for\u00e7ar os servidores a se comunicarem pelo protocolo de texto simples (o chamado downgrade attack \u2014 ataque de rebaixamento de vers\u00e3o do protocolo). Por essa raz\u00e3o, a conformidade do certificado normalmente n\u00e3o \u00e9 verificada para o STARTTLS (um certificado n\u00e3o confi\u00e1vel pode proteger contra ataques passivos, e isso n\u00e3o \u00e9 pior do que enviar uma mensagem em texto simples). Portanto, o STARTTLS protege apenas contra a escuta passiva.<\/p>\n

O MTA-STS elimina parcialmente o problema da intercepta\u00e7\u00e3o de e-mails entre servidores de e-mail, quando o atacante tem a capacidade de influenciar ativamente o tr\u00e1fego. Se o dom\u00ednio do destinat\u00e1rio publica uma pol\u00edtica MTA-STS, e o servidor do remetente suporta MTA-STS, ele enviar\u00e1 a mensagem apenas atrav\u00e9s de uma conex\u00e3o TLS, somente para servidores determinados pela pol\u00edtica, e apenas com verifica\u00e7\u00e3o do certificado do servidor.<\/p>\n

Por que parcialmente? O MTA-STS funciona apenas se ambas as partes se preocuparem em implementar este padr\u00e3o, e o MTA-STS n\u00e3o protege contra cen\u00e1rios em que o atacante tem a capacidade de obter um certificado v\u00e1lido de dom\u00ednio em uma das CA p\u00fablicas.<\/p>\n

Como funciona o MTA-STS<\/h1>\n

\nDestinat\u00e1rio<\/b><\/p>\n

    \n
  1. Configura o suporte ao STARTTLS com um certificado v\u00e1lido no servidor de e-mail.\u00a0<\/li>\n
  2. Publica a pol\u00edtica MTA-STS via HTTPS, utilizando um dom\u00ednio especial mta-sts e um caminho especial well-known, por exemplo https:\/\/mta-sts.mail.ru\/.well-known\/mta-sts.txt<\/code>. A pol\u00edtica cont\u00e9m uma lista de servidores de e-mail (mx) que t\u00eam permiss\u00e3o para receber e-mails para esse dom\u00ednio.<\/li>\n
  3. Publica um registro TXT especial _mta-sts no DNS com a vers\u00e3o da pol\u00edtica. Quando a pol\u00edtica \u00e9 alterada, esse registro deve ser atualizado (isso sinaliza ao remetente a necessidade de solicitar a pol\u00edtica novamente). Por exemplo, _mta-sts.mail.ru. TXT \"v=STSv1; id=20200303T120000;\"<\/code><\/li>\n<\/ol>\n

    \nRemetente<\/b><\/p>\n

    O remetente solicita o registro DNS _mta-sts e, se dispon\u00edvel, faz um pedido da pol\u00edtica via HTTPS (verificando o certificado). A pol\u00edtica recebida \u00e9 armazenada em cache (caso o invasor bloqueie o acesso a ela ou substitua o registro DNS).<\/p>\n

    Ao enviar um e-mail, verifica-se que:<\/p>\n