SSL communication between MTAs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

SSL communication between MTAs

Eliza
Hello,

My MTA (postfix) has both 25 (non-SSL) and 465 (SSL) ports enabled.

How to enforce the peer MTA send messages only to 465 port for better
secure communication?

Can I just shutdown port 25?

Thanks.

a
Reply | Threaded
Open this post in threaded view
|

Re: SSL communication between MTAs

a
You can't enforce remote peer to use SSL unless that peer is under your control.

Maximum that you can do - enable STARTTLS and configure MTA-STS (rfc8461).

чт, 15 авг. 2019 г., 9:53 Eliza <[hidden email]>:
Hello,

My MTA (postfix) has both 25 (non-SSL) and 465 (SSL) ports enabled.

How to enforce the peer MTA send messages only to 465 port for better
secure communication?

Can I just shutdown port 25?

Thanks.

Reply | Threaded
Open this post in threaded view
|

Re: SSL communication between MTAs

Eliza
Hi,

on 2019/8/15 15:44, a wrote:
> Maximum that you can do - enable STARTTLS and configure MTA-STS (rfc8461).
>

Is there a guide for that?

thanks.
Reply | Threaded
Open this post in threaded view
|

Re: SSL communication between MTAs

Thilo Molitor
In reply to this post by a
MTA-STS is not the only technique, DANE (rfc7672) can be used, too (and in
fact it is by many big german providers at least).

See this slides for an introduction: https://www.netnod.se/sites/default/files/
2016-12/Anders_Berggren_can_haz_secure_mail.pdf
Or this wikipedia page: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities#Email_encryption

- Thilo


Am Donnerstag, 15. August 2019, 10:44:16 CEST schrieb a:

> You can't enforce remote peer to use SSL unless that peer is under your
> control.
>
> Maximum that you can do - enable STARTTLS and configure MTA-STS (rfc8461).
>
> чт, 15 авг. 2019 г., 9:53 Eliza <[hidden email]>:
> > Hello,
> >
> > My MTA (postfix) has both 25 (non-SSL) and 465 (SSL) ports enabled.
> >
> > How to enforce the peer MTA send messages only to 465 port for better
> > secure communication?
> >
> > Can I just shutdown port 25?
> >
> > Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: SSL communication between MTAs

Viktor Dukhovni
In reply to this post by Eliza
On Thu, Aug 15, 2019 at 02:52:12PM +0800, Eliza wrote:

> My MTA (postfix) has both 25 (non-SSL) and 465 (SSL) ports enabled.

Don't confuse port 25 used for (MTA-to-MTA) SMTP (inter-domain email
relay), with ports 587 and 465 used in the MUA-to-MTA *SUBMIT*
protocol, which is very similar to MTA-to-MTA SMTP, but serves a
different need and differs in some details, like the ports used.

Except through bileteral arrangements or abuse of your systems, no
remote system will send you email on ports other than 25.

> How to enforce the peer MTA send messages only to 465 port for better
> secure communication?

This is not possible.

> Can I just shutdown port 25?

No.  But you can enable inbound STARTTLS.

    http://www.postfix.org/TLS_README.html#quick-start

Once you've mastered that, you can DNSSEC-sign your domain, and publish
TLSA records.

    https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html
    https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources

and enable DANE outbound:

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

    main.cf:
        smtp_dns_support_level = dnssec
        smtp_tls_security_level = dane

    /etc/resolv.conf
        # A validating *local* resolver
        nameserver 127.0.0.1

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: SSL communication between MTAs

Eliza
These info are really helpful. thanks.

On 2019/8/15 星期四 下午 11:29, Viktor Dukhovni wrote:

> On Thu, Aug 15, 2019 at 02:52:12PM +0800, Eliza wrote:
>
>> My MTA (postfix) has both 25 (non-SSL) and 465 (SSL) ports enabled.
>
> Don't confuse port 25 used for (MTA-to-MTA) SMTP (inter-domain email
> relay), with ports 587 and 465 used in the MUA-to-MTA *SUBMIT*
> protocol, which is very similar to MTA-to-MTA SMTP, but serves a
> different need and differs in some details, like the ports used.
>
> Except through bileteral arrangements or abuse of your systems, no
> remote system will send you email on ports other than 25.
>
>> How to enforce the peer MTA send messages only to 465 port for better
>> secure communication?
>
> This is not possible.
>
>> Can I just shutdown port 25?
>
> No.  But you can enable inbound STARTTLS.
>
>      http://www.postfix.org/TLS_README.html#quick-start
>
> Once you've mastered that, you can DNSSEC-sign your domain, and publish
> TLSA records.
>
>      https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html
>      https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources
>
> and enable DANE outbound:
>
>      http://www.postfix.org/TLS_README.html#client_tls_dane
>
>      main.cf:
> smtp_dns_support_level = dnssec
> smtp_tls_security_level = dane
>
>      /etc/resolv.conf
> # A validating *local* resolver
> nameserver 127.0.0.1
>
Reply | Threaded
Open this post in threaded view
|

Re: SSL communication between MTAs

Viktor Dukhovni
In reply to this post by Viktor Dukhovni
> On Aug 16, 2019, at 1:29 AM, Viktor Dukhovni <[hidden email]> wrote:
>
> enable DANE outbound:
>
>   http://www.postfix.org/TLS_README.html#client_tls_dane
>
>   main.cf:
> smtp_dns_support_level = dnssec
> smtp_tls_security_level = dane
>
>   /etc/resolv.conf
> # A validating *local* resolver
> nameserver 127.0.0.1

I got an off-list suggestion to stress the importance of the
validating resolver being *local* to the Postfix server.  In
addition to improved performance when the DNS cache is local,
this avoids potential MiTM attacks that "forge" the AD bit or
data of a DNS response.

The Postfix DANE code fully trusts answers from the configured
resolvers, and only provides meaningful resistance to active
attacks when traffic between the validating resolver and Postfix
is not vulnerable to modification in transit.

And with distant validating resolvers you have no control over
the timing and reliability of potential changes in their validation
logic.  For example, 8.8.8.8 and 8.8.4.4 returned incorrect AD
bits for some domains for a few days this past week (now believed
resolved).

Bottom line, only trust local resolvers you deploy, configure
*correctly* and test.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: SSL communication between MTAs

Andrew Sullivan
On Fri, Aug 16, 2019 at 04:53:23PM +1000, Viktor Dukhovni wrote:
> Bottom line, only trust local resolvers you deploy, configure
> *correctly* and test.

Well, it doesn't _have_ to be local.  You could, for instance, be
connected to a resolver that you know you can trust (FSVO "know" and
"trust") over IPsec.  I believe that was the use case originally for
the AD bit, which otherwise is more or less useless for all the
reasons you outline.

(Your general point, of course, still stands.)

A

--
Andrew Sullivan
[hidden email]