verifying per site TLS policy -- maps override?

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

verifying per site TLS policy -- maps override?

yodeller
Hi

I just want to make sure I understand per-site domain policy maps' priority.

If I set up an outbound postfix instance with

  -o smtp_tls_security_level=may
  -o smtp_tls_policy_maps=lmdb:/etc/postfix/tls_policy_outbound

the way that works is that both are used, right?

In other words, the DEFAULT policy will =may, and will be OVERRIDDEN by matches in tls_policy_outbound?

Thanks
Reply | Threaded
Open this post in threaded view
|

Re: verifying per site TLS policy -- maps override?

Viktor Dukhovni

> On Aug 22, 2017, at 11:52 AM, [hidden email] wrote:
>
> I just want to make sure I understand per-site domain policy maps' priority.
>
> If I set up an outbound postfix instance with
>
>  -o smtp_tls_security_level=may
>  -o smtp_tls_policy_maps=lmdb:/etc/postfix/tls_policy_outbound
>
> the way that works is that both are used, right?

The global security level set via "smtp_tls_security_level" is
optionally preƫmpted by the per-destination policy table (which
can also override selected additional TLS settings).

> In other words, the DEFAULT policy will =may, and will be OVERRIDDEN by matches in tls_policy_outbound?

Yes.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: verifying per site TLS policy -- maps override?

yodeller


On Tue, Aug 22, 2017, at 09:00 AM, Viktor Dukhovni wrote:
> The global security level set via "smtp_tls_security_level" is
> optionally preƫmpted by the per-destination policy table (which
> can also override selected additional TLS settings).

Yeah I see the option to set the additional TLS params.  That's exactly what I'm looking for.

> > In other words, the DEFAULT policy will =may, and will be OVERRIDDEN by matches in tls_policy_outbound?
>
> Yes.

Perfect. Thanks.

For *INBOUND*, either @ postscreen or @ the after-postscreen smtpd handoff I can set

 -o postscreen_tls_security_level=<setting>

or

 -o smtpd_tls_security_level=<setting>

respectively.

Is there an inbound  per-domain TLS policy map?

I looked for both

 smtpd_tls_policy_maps
 postscreen_tls_policy_maps

but didn't see anything in the docs.

Are they named differently, or not available because of the way the handshake happens?
Reply | Threaded
Open this post in threaded view
|

Re: verifying per site TLS policy -- maps override?

Viktor Dukhovni

> On Aug 22, 2017, at 12:08 PM, [hidden email] wrote:
>
> Is there an inbound  per-domain TLS policy map?

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

One may be tempted to try enforcing TLS for mail from specific sending organizations, but this, too, runs into obstacles. One such obstacle is that we don't know who is (allegedly) sending mail until we see the "MAIL FROM:" SMTP command, and at that point, if TLS is not already in use, a potentially sensitive sender address (and with SMTP PIPELINING one or more of the recipients) has (have) already been leaked in the clear. Another obstacle is that mail from the sender to the recipient may be forwarded, and the forwarding organization may not have any security arrangements with the final destination. Bounces also need to be protected. These can only be identified by the IP address and HELO name of the connecting client, and it is difficult to keep track of all the potential IP addresses or HELO names of the outbound email servers of the sending organization.

Consequently, TLS security for mail delivery to public MX hosts is almost entirely the client's responsibility. The server is largely a passive enabler of TLS security, the rest is up to the client. While the server has a greater opportunity to mandate client security policy when it is a dedicated MSA that only handles outbound mail from trusted clients, below we focus on the client security policy.

> Are they named differently, or not available because of the way the handshake happens?

See above.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: verifying per site TLS policy -- maps override?

yodeller
On Tue, Aug 22, 2017, at 09:13 AM, Viktor Dukhovni wrote:
> > Is there an inbound  per-domain TLS policy map?
>
> http://www.postfix.org/TLS_README.html#client_tls_limits

Thanks. Okay I get that.  But that reads like policy to me.  It doesn't sound like it's impossible.

The reason that I'm asking is that I'd like to set my inbound policy =may by default, but for specific servers (that I may be working or warring with) sending email to me I want to force policy =encrypt.

For infrequent one offs like that, even if I could specify a few sending hosts, by hostname &/or even IP, to force inbound TLS =encrypt policy it'd be useful.

But if it can't be done, ok it can't. I get that.
Reply | Threaded
Open this post in threaded view
|

Re: verifying per site TLS policy -- maps override?

/dev/rob0
On Tue, Aug 22, 2017 at 09:21:33AM -0700, [hidden email] wrote:
> The reason that I'm asking is that I'd like to set my inbound
> policy =may by default, but for specific servers (that I may
> be working or warring with) sending email to me I want to
> force policy =encrypt.
>
> For infrequent one offs like that, even if I could specify a
> few sending hosts, by hostname &/or even IP, to force inbound
> TLS =encrypt policy it'd be useful.

See reject_plaintext_session, and in the case as you described,
check_client_access:

http://www.postfix.org/postconf.5.html#reject_plaintext_session
http://www.postfix.org/postconf.5.html#check_client_access
http://www.postfix.org/access.5.html
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Reply | Threaded
Open this post in threaded view
|

Re: verifying per site TLS policy -- maps override?

yodeller
On Tue, Aug 22, 2017, at 09:36 AM, /dev/rob0 wrote:
> See reject_plaintext_session, and in the case as you described,
> check_client_access:
>
> http://www.postfix.org/postconf.5.html#reject_plaintext_session
> http://www.postfix.org/postconf.5.html#check_client_access
> http://www.postfix.org/access.5.html

Ok, didn't know about

  reject_plaintext_session

so thanks!

Based on your comment I found

  http://postfix.1071664.n5.nabble.com/Server-equivilent-of-smtp-tls-policy-maps-td26112.html

that provides the concrete example

 smtpd_client_restrictions =
    check_client_access lmdb:/etc/postfix/require_crypt

 # require_crypt.lmdb
  example.com  reject_plaintext_session

So that looks like it should work.
Reply | Threaded
Open this post in threaded view
|

Re: verifying per site TLS policy -- maps override?

Viktor Dukhovni

> On Aug 22, 2017, at 12:52 PM, [hidden email] wrote:
>
> Based on your comment I found
>
>  http://postfix.1071664.n5.nabble.com/Server-equivilent-of-smtp-tls-policy-maps-td26112.html
>
> that provides the concrete example
>
> smtpd_client_restrictions =
>    check_client_access lmdb:/etc/postfix/require_crypt
>
> # require_crypt.lmdb
>  example.com  reject_plaintext_session
>
> So that looks like it should work.

Yes, but what security goal does this achieve?  Firstly listing the
client domain name there works unreliably, because the PTR lookup
or the forward address lookup may tempfail, and then the client
will be able to send in the clear.   It is generally unwise to
use "reject_unknown_client_hostname" to insist that all clients
have working FCrDNS, so this check is fragile.

You also have no assurance that the client verified the server
certificate, so the connection might be via an MiTM attacker's
system.  The only protection this gets you is from passive
attacks, when there are no DNS hiccups.

A CIDR table (policy by client IP) is more reliable, but still
leaves room for active attacks, and tracking client IPs is often
difficult.

My advice for mandatory inbound TLS on port 25 public MX hosts
is "don't bother".

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: verifying per site TLS policy -- maps override?

yodeller


On Tue, Aug 22, 2017, at 10:19 AM, Viktor Dukhovni wrote:
> > So that looks like it should work.
>
> Yes, but what security goal does this achieve?

Just what I said above.  To help working with specific senders if only to debug, etc.

I'm not looking for a policy or a philosphy, I'm just looking for a tool.  rob0's approach does it for me for now.