O que você precisa saber sobre o uso de SSL/TLS para criptografar conexões feitas pelos seus servidores de email

Quando fui abordado
com o tópico para este post no blog, eu concordei com prazer. Aqui estão algumas paráfrases
de como ele caiu:

“Você poderia
escrever um post sobre a importância do TLS nos servidores de e-mail?” perguntou Patrick.

“Claro”, eu disse.

>

Whew, isso foi uma loucura
conversão para reviver! Como um turbilhão!

Então comecei a pensar nisso por um pouco. Existem realmente servidores de e-mail por aí que não estão usando criptografia para trânsito? Eu não estou falando de criptografia de ponta a ponta como já cobrimos no passado (S/MIME, PGP, etc). Estou me referindo a servidor a servidor ou a tudo entre criptografia para proteger os dados ao longo da rota de travessia.

Seguramente, nos dias de hoje, ninguém deixaria o seu correio de entrada/saída em texto simples atravessando Deus sabe qual a rota a ser interceptada e aproveitada. Muitas pessoas estão usando serviços de e-mail e não há como excluir a criptografia de trânsito do seu serviço. As violações de dados custam-lhes milhões em
processos judiciais e perda de negócios e vergonha……Hmmmm…..

Voltei a Patrick
com uma pergunta.

“Temos estatísticas
ou informações sobre servidores de e-mail que não usam criptografia? O meu palpite é que seria
baixo. Em outras palavras, o que o levou a me perguntar sobre este artigo”?

Patrick respondeu, “I
actualmente não. Pensei que seria um bom tópico considerando a importância
do e-mail e todos os aspectos necessários para a segurança”

OK. Isso faz sentido. Provavelmente há alguns servidores de e-mail por aí que não o utilizam de todo, embora sem dúvida uma percentagem muito maior possa estar a utilizar protocolos desactualizados ou certs expirados e possa apenas precisar de uma actualização.

Este artigo irá para
over onde estamos com o e-mail e criptografia de trânsito para ter certeza que você está
operando em um nível de segurança ideal que está disponível.

Criptografia em Servidores de Email

Neste ponto, provavelmente temos um entendimento geral de como o TLS funciona, mas vamos resumir no caso de você ser novo nisso.

Pessoa A quer enviar
comunicação segura Humana B. Pessoa A e Humana B têm um certificado pré-estabelecido
certificado. A Pessoa A usa o certificado para encriptar a informação e envia
a informação encriptada para o Human B. A informação é ilegível até que o Humano
B use o certificado para decifrar a informação encriptada.

Se a Pessoa B quer
corresponder à Pessoa A com a informação encriptada, então a Pessoa B usaria o
certificado para encriptar os dados e a Pessoa A usaria o certificado para
decriptar a mensagem.

Esta é geralmente a forma como
encriptar/descriptografar funciona. Agora substitua as pessoas listadas neste exemplo por
servers e outras conexões deste tipo. O mesmo conceito.

Agora se o Human B quer responder de volta à Pessoa A com informação criptografada, então o Human B usa a chave simétrica que acabou de ser gerada e agora eles podem tanto criptografar como enviar, e receber e decodificar dados um para o outro.

Geralmente é assim que a encriptação/descriptação com SSL/TLS funciona. Agora substitua as pessoas listadas neste exemplo por servidores e outras conexões desse tipo. O mesmo conceito. É assim que o TLS funciona com o e-mail, o que é um pouco diferente de como ele facilita uma conexão HTTPS, devido ao fato de que o e-mail usa protocolos diferentes. Mas, ainda existem algumas semelhanças distintas:

• Ocorre um aperto de mão
• Autenticação ocorre (embora ambas as partes se autentiquem neste contexto)
• As chaves de sessão são usadas para transmitir o fluxo de e-mails.

Fluxo de Ebb e (Mail) Flow

O próximo passo para este artigo
“entendendo porquê” é a parte “entendendo como”.

Em suma, um cliente de e-mail envia um e-mail para o servidor de saída. O servidor de saída fará uma busca DNS, baseada no domínio do e-mail de destino, e esse registro MX do DNS determinará para qual servidor enviar o e-mail e, possivelmente, esse servidor determinará se ele precisa ser encaminhado até chegar ao Mail Delivery Agent (MDA) da caixa de entrada do destino.

Não é suficiente para
confiar registros MX DNS, que é um outro problema de confiança, mas o servidor SMTP
(mail going out, MTA, etc) e o mail coming in ( via POP3, IMAP,
Exchange) precisam ser capazes de identificar um ao outro e ter as chaves corretas para
comunicar um com o outro. E, dependendo da rota, pode haver mais
comunicar com o servidor de e-mail de um só salto. Trocadores de correio, proxy
servers e outros podem estar no lugar ao longo da rota. Cada salto (deve) chamar por
um link criptografado. Muitas vezes, ele faz isso. Às vezes, não. Os usuários devem
preferir a informação sensível é criptografada ao longo do caminho. Encriptação de ponta-a-ponta
ajudas asseguram que há algum tipo de encriptação durante todo o caminho, mas
camadas de segurança são sempre, uh, melhores.

Reponder Thy Securi-Tie

Para o registo,
Securi-Tie não é uma palavra real. Eu só inventei essa palavra porque ela rimava. É
a reproduzir a palavra segurança.

>

Para uma espécie de trampolim
da seção anterior, devemos falar sobre as opções de segurança que, enquanto
seriam definidas a partir do lado do cliente, na verdade forneceriam alguma instrução
ao lado do servidor de e-mail para fins relacionados à segurança.

ao configurar um cliente de e-mail
(Outlook, Thunderbird, etc), o padrão é para uma configuração não criptografada
configuração. Mas, como é o ponto deste artigo, nós normalmente queremos ir
para a opção encriptada. De certa forma, não depende inteiramente do cliente: depende do que o lado do servidor é capaz de suportar. Assumindo que os seus servidores de entrada
e de saída podem suportar encriptação, porque não o faria você? Se você encomendar um bote em um restaurante e eles lhe oferecerem sirloin ou Kobe(wagyu) ribeye
pelo mesmo preço, por que você não encomendaria o corte de melhor qualidade?

Então, se você quiser usar
TLS/SSL no seu e-mail (esta é para a parte de trânsito e não a parte de ponta a ponta,
S/MIME que é discutida em outros posts do blog), ligue-a. Use as portas 465
ou 587 para SMTP (‘member, outbound mail) e 993 (IMAP) ou 995 (POP3) para
inbound traffic.

Existe um
protocolo de encriptação interessante que ainda é utilizado entre servidores de e-mail. Ele
tem seu bom com mau como é com a maioria das coisas. Em última análise, eu diria que
suas intenções são boas, mas a aplicação no mundo real não é tão ideal quanto poderia
could. Senhoras e senhores, esse protocolo é o STARTTLS.

STARTTLS é um protocolo de segurança
protocolo que basicamente é SSL/TLS. Muito simplesmente, o STARTTLS vai pegar em um texto em formato
existente e, portanto, uma conexão insegura, e tentar convertê-lo em uma conexão segura usando TLS (ou SSL). Portanto, o nível de segurança de
STARTTLS vs SSL/TLS não é na verdade diferente. Se tudo estiver bem definido, ambos encriptarão a informação usando o TLS (ou SSL).

A principal diferença é
baseado no estado de uma conexão e/ou no início da comunicação. STARTTLS
não garante a comunicação encriptada. Basicamente significa, ‘se a
conexão não está encriptada e você é capaz de, fazer isto em uma conexão segura
conexão’. Se o nó de conexão (provavelmente um servidor) é incapaz de transformar o
conexão em uma conexão criptografada, pode ser até o fim do cliente para
decidir como lidar com isso a partir daí.

Embora eu tenha usado o termo
qualificando STARTTLS como “útil”, ele poderia ser considerado menos seguro
do que selecionar SSL/TLS. A seleção padrão SSL/TLS é basicamente, “Use
encryption ou bust”. STARTTLS está dizendo: “Um, se você pudesse, por favor, faça isso. Se
não, podemos proceder com base noutras instruções”.

Aqui estão algumas conclusões

Muitas vezes, o óbvio precisa de ser dito e talvez
sobreavaliado. Então aqui está, ahem: Use encriptação. Especialmente para algo que
é tão importante, tão crucial e integrado na aparentemente a grande maioria de
qualquer estrutura organizacional que pode levar a fazer ou quebrar informações. Há
não há muito esforço que precisa ser colocado nela. Use tanto de ponta a ponta como em trânsito
encryption. Dois é melhor que um.

Se alguém acha que o esforço extra para configurar um e-mail
servidor a ser encriptado versus não encriptado não vale a pena, então alguém é
não vale a pena. Isto é simplesmente exagerar o óbvio. Encriptação de ponta a ponta, como S/MIME, tem uma abordagem
mais envolvida, mas também vale a pena quando se adicionam camadas e camadas de
segurança. Mas, não há desculpa para não tomar o tempo necessário para configurar e manter os links
secure.

Quando a visibilidade permite, qualquer caminho de email que possa não parecer seguro ou comprometido deve ser mantido sob escrutínio. E com isso, seja feliz no seu escrutínio por uma Internet mais segura. Saúde!

**** Este é um blog sindicalizado Security Bloggers Network da Hashed Out by The SSL Store™ de autoria de Ross Thomas. Leia o post original em: https://www.thesslstore.com/blog/encryption-and-email-servers/