Qual nome do host deve conter o certificado SSL para um servidor SMTP?

Eu tenho um servidor foo.example.com em 192.0.2.1

Ele executa o exim para receber emails de vários dos meus domínios.

Meus domínios têm um registro MX apontando para mx.example.com, que resolve para 192.0.2.1

Se eu quiser fazer com que o exim ofereça criptografia TLS para conexões de e-mail recebidas, que nome de host devo colocar no certificado SSL?

• foo.example.com porque é isso que o servidor dirá no HELO?
• mx.example.com porque esse é o nome do host ao qual os clientes terão se conectado?

http://www.checktls.com sugere que o último está correto, mas não consigo encontrar uma resposta definitiva.

Na verdade, isso não é definido explicitamente em nenhum lugar, e se o servidor deve ou não ser "confiável" depende do cliente (que pode ser outro servidor de email) conectado a ele; citando a RFC relevante ( RFC 2487 ):

Se o cliente SMTP decidir que o nível de autenticação ou
privacidade não é alto o suficiente para continuar, deve emitir um
comando SMTP QUIT imediatamente após a conclusão da negociação do TLS.
Se o servidor SMTP decidir que o nível de autenticação ou
privacidade não é alto o suficiente para continuar, DEVE responder a
todos os comandos SMTP do cliente (exceto um comando QUIT) com
o código de resposta 554 (com uma possível sequência de texto como como "Comando
recusado por falta de segurança").

A decisão de acreditar ou não a autenticidade da
outra parte em uma negociação TLS é uma questão local. No entanto, algumas
regras gerais para as decisões são:

- A SMTP client would probably only want to authenticate an SMTP
  server whose server certificate has a domain name that is the
  domain name that the client thought it was connecting to.

O que isso significa basicamente é que, quando o servidor oferece criptografia TLS usando um determinado certificado, a decisão sobre aceitar ou recusar depende totalmente da outra parte, que provavelmente desejará que o nome no certificado seja o mesmo ao qual está conectado, mas poderia aceite muito bem, mesmo que não corresponda.

Mas espere, tem mais. Citando novamente do mesmo RFC:

Após a conclusão do handshake TLS, o protocolo SMTP é redefinido para
o estado inicial (o estado no SMTP após um servidor emitir uma
saudação pronta para 220 serviços). O servidor DEVE descartar qualquer conhecimento
obtido do cliente, como o argumento para o comando EHLO,
que não foi obtido da negociação do TLS. O cliente
DEVE descartar qualquer conhecimento obtido do servidor, como a lista
de extensões de serviço SMTP, que não foram obtidas da
negociação do TLS . O cliente DEVE enviar um comando EHLO como o
primeiro comando após uma negociação bem-sucedida do TLS.

Portanto, o que o servidor está dizendo em resposta ao HELO / EHLO antes do handshake TLS não parece realmente importar.

Na minha experiência, os certificados autoassinados funcionam muito bem em servidores de email voltados para a Internet, o que significa que os outros servidores nem sequer se preocupam em validá-los, eles apenas aceitam com satisfação qualquer coisa que possa fornecer criptografia TLS, independentemente da emissão autoridade ou nome do sujeito.

Um MTA que entrega email para o seu domínio pesquisará o registro MX (que produzirá um nome de host) e, em seguida, um registro A para esse nome de host. O nome do host ao qual está se conectando é, portanto, o nome do host MX, e é isso que será verificado com relação ao nome comum do certificado SSL. Verificar o nome do host HELO não faz sentido, pois o servidor pode fornecer o nome de host HELO que desejar - não fornece segurança adicional.

Dito isso, verificar estritamente os certificados SSL ao entregar e-mails não é particularmente útil no momento, já que os MTAs (quase sempre) fazem fallback para entrega não-SSL, já que é assim que o SMTP funciona no momento. A configuração sensata é, portanto, usar SSL se o servidor MX oferecer, independentemente de o certificado SSL verificar ou não (uma vez que a criptografia sem autenticação é melhor do que nenhuma criptografia e nenhuma autenticação). Portanto, você também pode usar um certificado autoassinado para esse fim.

A tarefa de verificar o certificado do servidor e se ele corresponde ao nome do host do servidor é puramente a função do cliente, para qualquer protocolo que utilize SSL / TLS.

Como tal, o nome do host no certificado deve corresponder ao nome que o cliente está tentando acessar.

Quando a conexão SSL / TLS é iniciada com antecedência (SMTPS), o servidor não tem como ver o que a mensagem HELO diz antes da conexão ser estabelecida, portanto, ele deve usar aquele com o qual fez a solicitação.

Ao usar o SSL / TLS depois STARTTLS, o cliente ainda pretende conversar com o servidor com o qual foi configurado, então ainda é isso que deve verificar. Se isso não tornasse possível os ataques MITM:

• C-> S: Olá, eu sou Alice, quero falar com Bob.
• S-> C: Oi, eu sou Chuck, aqui está meu certificado para Chuck.
• C-> S: Ah, sim, seu certificado é realmente válido para Chuck. Vamos continuar.
• ... Há uma falha lá, é claro, já que Alice queria uma comunicação segura com Bob.

Nos dois casos, é o endereço MX que deve ser usado.

As regras de correspondência de nome de host foram reunidas recentemente em protocolos no RFC 6125 , mas poucos clientes o implementam totalmente (é mais uma RFC de práticas recomendadas do que uma alteração completa e ainda é bastante recente).

Em seu apêndice , ele resume o que existia antes sobre o SMTP (extraído das RFC 3207 e RFC 4954 ). Em particular " O cliente NÃO DEVE usar qualquer forma de nome de host do servidor derivado de uma fonte remota insegura (por exemplo, pesquisa de DNS insegura). " (Que se aplica ao banner do servidor, é claro). Além disso, as regras herdadas do SMTP eram um pouco mais relaxadas do que o HTTPS em relação aos Nomes Alternativos do Assunto ( devem, em vez de, devem ser usados).

A maneira moderna é definitivamente colocar o nome do host em uma entrada DNS do Nome Alternativo do Assunto. O uso de curinga também é desencorajado .

Eu acho que o melhor seria copiar o que é feito na prática. Verifiquei um endereço de e-mail do yahoo.com usando http://checktls.com Felizmente, no yahoo, eles usaram um domínio diferente para o nome do host e para o domínio mx. Portanto, o nome do host é yahoo.com e o domínio mx termina com yahoodns.net

dig mx yahoo.com gives mta6.am0.yahoodns.net. among others

Resultado de checktls: o certificado SSL CN = domínio MX (* .yahoodns.net)

Eu fiz o mesmo com Cisco e tive o mesmo resultado.

Na criptografia SSL / TLS, o cliente sempre verifica a correspondência entre o nome do host "real" / "declarado" na máquina remota e as informações contidas no certificado.

Portanto, você provavelmente deve definir foo.example.com ou gerar um certificado curinga ;-)