> On Oct 20, 2017, at 4:54 PM, J Doe <gene...@nativemethods.com> wrote:
> 
> I currently have a Postfix 3.1.0 server with smtpd configured to use
> opportunistic TLS encryption:
> 
>    /etc/postfix/main.cf
>        smtpd_tls_security_level = may

This setting is for inbound mail from remote servers to you.

> In the documentation I have noted that even if STARTTLS is enabled, mail
> delivery will not be stopped even if the certificate at the other server
> is invalid or is a self-signed certificate. As such, TLS encryption is
> used but authentication of the remote server does not happen.

Now you've switched to talking to about outbound mail (delivery from
your system to other systems).

> I have noticed in my logs today an entry:
> 
>    postfix/smtpd[1234]: Untrusted TLS connection established from 
> example.com[1.2.3.4]: TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 
> bits)
> 
> ...where example.com is not the real server name.

And now you're looking at inbound mail again, and it seems that you've
enabled receipt of client certificates, which is generally not a good
idea on port 25 (the default is smtpd_tls_ask_ccert = no).

> When smtpd parsed the certificate before this log entry, I noticed that
> the subject_CN of the certificate is the same as the issuer - for example:
> 
>    subject_CN=example
>    issuer=example
> 
> ...where example is not a FQDN but the hostname of the remote server.
> There is also no references to certificate authorities.

Perfectly normal even for receiving server, but escpecially for SMTP
client certificates CA-issued names are not especially meaningful.
What would you do differently on port 25 when receiving inbound mail
from a client with a given certificate?

More generally, see:

        http://www.postfix.org/TLS_README.html#client_tls_limits

> I am wondering two things:
> 
> [1] Am I correct that the remote server has not been authenticated but
> has used encryption ?

The transmission channel is encrypted all the way from the remote
server to any TLS man in the middle attacker, and again all the
way from the man in the middle attacker to you. :-)

More seriously, the channel is immune to passive wiretaps, but
unless the client authenticated your server somehow, and would
not have continued sans authenticated TLS, MiTM attacks cannot
be excluded.

> [2] Is it not authenticated in this case because the remote server
> appears to be a self-signed certificate ?

You're still confusing the sending and receiving sides...

-- 
        Viktor.

Reply via email to