Que nome de host deve conter o certificado SSL para um servidor SMTP?

Question

Eu tenho um servidor foo.example.com em 192.0.2.1

Ele executa o exim para receber e-mails para vários dos meus domínios.

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

Se eu quiser que o exim ofereça criptografia TLS para conexões de e-mail recebidas, qual 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 se conectaram?

O

link sugere que o último está correto, mas não consigo encontrar uma resposta definitiva.

    

Answer 1

Na verdade, isso não é explicitamente definido em lugar algum, e o fato de o servidor ser ou não "confiável" depende do cliente (que poderia, é claro, ser outro servidor de correio) se conectar a ele; citando o RFC relevante ( RFC 2487 ):

If the SMTP client decides that the level of authentication or
privacy is not high enough for it to continue, it SHOULD issue an
SMTP QUIT command immediately after the TLS negotiation is complete.
If the SMTP server decides that the level of authentication or
privacy is not high enough for it to continue, it SHOULD reply to
every SMTP command from the client (other than a QUIT command) with
the 554 reply code (with a possible text string such as "Command
refused due to lack of security").

The decision of whether or not to believe the authenticity of the
other party in a TLS negotiation is a local matter. However, some
general rules for the decisions are:

- 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 basicamente significa é que, quando o servidor oferece criptografia TLS usando um determinado certificado, a decisão de aceitá-lo ou recusá-lo depende inteiramente da outra parte, que <<> provavelmente quer o nome no certificado para ser o mesmo que se conectou, mas poderia muito bem aceitá-lo, mesmo que não seja compatível.

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

Upon completion of the TLS handshake, the SMTP protocol is reset to
the initial state (the state in SMTP after a server issues a 220
service ready greeting). The server MUST discard any knowledge
obtained from the client, such as the argument to the EHLO command,
which was not obtained from the TLS negotiation itself. The client
MUST discard any knowledge obtained from the server, such as the list
of SMTP service extensions, which was not obtained from the TLS
negotiation itself. The client SHOULD send an EHLO command as the
first command after a successful TLS negotiation.

Então, o que o servidor está dizendo em resposta a HELO / EHLO antes que o handshake TLS não parece realmente ter importância.

Na minha experiência, os certificados auto-assinados funcionam muito bem em servidores de e-mail voltados para a Internet, o que significa que os outros servidores de e-mail não se importam em validá-los. que pode fornecer criptografia TLS, independentemente da autoridade de emissão ou do nome da entidade.

    

Answer 2

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

Dito isso, verificar rigorosamente os certificados SSL ao entregar e-mails não é particularmente útil no momento, já que os MTAs (quase sempre) retornam para a entrega não-SSL, pois é 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 (já 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 essa finalidade.

    

Answer 3

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

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

Quando a conexão SSL / TLS é iniciada na frente (SMTPS), o servidor não tem como ver o que a mensagem HELO diz antes que a conexão seja estabelecida, então deve usar aquela com a qual fez a requisição.

Ao usar o SSL / TLS após STARTTLS , o cliente ainda pretende falar com o servidor com o qual foi configurado, e isso ainda é o que deve ser verificado. Se isso não fizer com que ataques MITM sejam possíveis:

• C- > S: Olá, sou Alice, quero falar com o Bob.
• S- > C: Olá, 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 um seguro comunicação com Bob.

Em ambos os casos, é o endereço MX que deve ser usado.

As regras de correspondência de nomes de host foram reunidas recentemente em protocolos em RFC 6125 , mas poucos clientes a implementam totalmente (é mais de uma melhor prática RFC do que uma mudança completa, e ainda é bastante recente).

No seu apêndice , ele resume o que existia sobre o SMTP antes (tirado de O cliente NÃO DEVE usar qualquer forma de nome de host do servidor derivado de uma fonte remota insegura (por exemplo, busca de DNS insegura). " (que se aplica ao banner do servidor, é claro). Além disso, as regras herdadas do SMTP eram um pouco mais relaxadas que o HTTPS em relação aos nomes alternativos do assunto ( deve em vez de deve ser usado).

A maneira moderna é definitivamente colocar o nome do host em uma entrada DNS de Nome Alternativo de Assunto. O uso de curingas também não é recomendado .

    

Answer 4

Eu acho que o melhor seria copiar o que é feito na prática. Verifiquei um endereço de e-mail do yahoo.com usando o link Com sorte, no yahoo, eles usaram um domínio diferente para o nome do host e para o domínio mx. Então, o hostname deles é um yahoo.com e seu 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 o cisco e tive o mesmo resultado.

    

Answer 5

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 contêm o certificado.

Então, você provavelmente deve definir foo.example.com ou gerar um certificado wildcard; -)