> On Jul 25, 2017, at 3:59 AM, post...@xmas.de wrote:
>
> We have partners who have numerous domains and don't wan't to tell me
> the whole list of domains.
Postfix TLS security is by destination domain. Basing TLS security
policy on the insecurely obtained MX host is futile. If there's no
man-in-the-middle attack, and you have "smtp_tls_security_level = may"
as the default (destination-independent) security level in main.cf, then
STARTTLS opportunistic encryption will be used to any destination that
supports TLS on its receiving MX hosts.
If there is a man-in-the-middle (MiTM) attack, then the MX records can
be forged in DNS, and MX-based policy will not protect the traffic. In
fact, unless the remote certificates are verified, the MiTM can also
impersonate the remote destination via unauthenticated TLS, so even
an "encrypt" (encryption without authentication) TLS policy does not
protect traffic against active attacks.
Any domain they're unwilling to tell you about can't be a domain that
you're likely to correspond with. You may if you wish scan your logs
for email from your users to domains via the MX host in question, and
add those domains to the $smtp_tls_policy_maps table:
main.cf:
indexed = ${default_database_type}:${config_directory}/
smtp_tls_policy_maps = ${indexed}tls-policy
tls-policy:
example.com secure match=mx.example.com
tafile=/etc/ssl/example.com.CAs.pem
If you run smtp(8) chrooted, you'll need to have the "tafile" with the
root CAs trusted to authenticate "example.com" installed inside the
chroot jail, in this example, assuming the default queue_directory, it
would be:
/var/spool/postfix/etc/ssl/example.com.CAs.pem
If smtp(8) is not chrooted, the tafile is as specified and not relative
to $queue_directory.
> I only have the MX and have to ensure that the transport is encrypted.
There is still in Postfix a legacy insecure TLS policy interface left
over from the initial TLS implementation in version 2.2. That policy
interface is mutually exclusive with the preferred smtp_tls_policy_maps,
so if you're using that for destinations that don't refuse to disclose
their domain list, the legacy interface is not an option. The legacy
interface is per-MX, and was deprecated precisely because it is insecure.
I do not recommend its use:
http://www.postfix.org/TLS_LEGACY_README.html#client_tls_per_site
> I understand that DNSSEC/DANE is the best way to do it.
> But unfortunately, DNSSEC is still not common.
Yes, around 1--2% of domains have DNSSEC. As part of my DANE survey
I have thus far identified ~4.6 million DNSSEC domains, out of around
200 million domains combined in the various feeds I use.
> I think it would be worth to encrypt despite DNS is spoofable.
Well simple opportunistic encryption is pretty reliable in practice
and requires nothing beyond "may" security. If you want stronger
security, then presumably DNS spoofing or unauthenticated TLS MiTM
is part of the threat model.
> Maybe there is a workaround through transport and tcp-table?
If you redirect all IP traffic to the MX host in question to a
loopback address with another Postfix instance, that Postfix
instance can implement a default "encrypt" or stronger security
policy. This is a fragile hack, and not recommended.
--
Viktor.
