Mailing List Archive

Next Exim: TLS: changed smarthost example config
Folks,

I've committed and pushed a change to the default Exim configuration
file for the next Exim release. This change has the example SMTP
Transport used for _smarthosts_, such as talking to an ISP, using TLS by
default, with _strong_ TLS enabled, and certificate verification, and
sending SNI.

The commented-out "smarthost" Router now uses a Transport named
"smarthost_smtp" instead of "remote_smtp". The new smarthost_smtp
currently looks like the text below, which is subject to change before
the next release.

NOTE: every single bit of this configuration should work with the
current release of Exim, and the past several releases in fact. So you
can try this out now to see if it works or not, if your current
configuration isn't this demanding. *DO* watch your queues after doing
so.

Because many mail-clients are configured to talk directly to ISP
smarthosts and mail-clients usually enable TLS with decent verification
(or at least, the ones I use do), there _shouldn't_ be any issues.
But if there are, then they're likely to be:

1. Mail-provider does not provide STARTTLS on their smarthost. In 2018.
Seriously? Find a new mail-provider.

2. Certificate does not verify. File a Support request with the
mail-provider to get it fixed.
In 2018? Seriously consider a new mail-provider.

3. You have to comment out the tls_require_ciphers because the
mail-provider is running with really poor TLS support.
File a Support request. If they don't fix this quickly, then
consider a new mail-provider.


The example configuration, all of which can be simplified by removing
the .ifdef branches which don't apply to you:

--------------------------8< smarthost_smtp >8--------------------------
smarthost_smtp:
driver = smtp
message_size_limit = ${if > {$max_received_linelength}{998} {1}{0}}
multi_domain
#
.ifdef _HAVE_TLS
# Comment out any of these which you have to, then file a Support
# request with your smarthost provider to get things fixed:
hosts_require_tls = *
tls_sni = $host
tls_verify_hosts = *
# As long as tls_verify_hosts is enabled, this won't matter, but if you
# have to comment it out then this will at least log whether you succeed
# or not:
tls_try_verify_hosts = *
#
.ifdef _HAVE_OPENSSL
tls_require_ciphers = HIGH:@STRENGTH
.endif
.ifdef _HAVE_GNUTLS
tls_require_ciphers = NONE:+VERS-TLS1.2:SECURE192
.endif
.endif
--------------------------8< smarthost_smtp >8--------------------------
Re: Next Exim: TLS: changed smarthost example config [ In reply to ]
> On Apr 20, 2018, at 8:17 PM, Phil Pennock via Exim-users <exim-users@exim.org> wrote:
>
> .ifdef _HAVE_OPENSSL
> tls_require_ciphers = HIGH:@STRENGTH
> .endif

I'd make that:

HIGH:!aNULL:!aDSS:!kECDHr:!kECDHe:!kDHr:!kDHd

Because, the ciphers are already sensibly ordered as of OpenSSL 1.0.0.
The HIGH ciphers are only HIGH by virtue of symmetric cipher strength,
but in fact include anon-DH ciphers with strong bulk crypto, which given
the desired to authenticate the peer should not be included.

This also disables DSA which nobody uses and fixed DH/ECDH ciphers which
are not and should not be used. With OpenSSL 1.0.2 this brings the cipher
count down from 82 to 52.

--
Viktor.


--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Next Exim: TLS: changed smarthost example config [ In reply to ]
Phil Pennock via Exim-users <exim-users@exim.org> wrote:
[...]
> .ifdef _HAVE_GNUTLS
> tls_require_ciphers = NONE:+VERS-TLS1.2:SECURE192
> .endif
[...]

Hello,

That priority string does not work, it disables everything and does
not enable e.g. X509 support. Also it is subject to bitrot, it will need
updating when TLS1.3 is common.

If you wanted to disable TLS 1.0 and 1.1 now you could simply use
NORMAL:-VERS-TLS1.0:-VERS-TLS1.1
or
SECURE192:-VERS-TLS1.0:-VERS-TLS1.1.

Personally I am not convinced that this is the right way for trying to
enforce stronger encryption standards on mail providers. I doubt there
is going to be any effect, people won't change their email address
because the hosting smarthost does not provide TLS1.2 (due to SPF et
al they cannot simply switch smarthosts) and mail providers still not
providing TLS1.2 will not change their service due to a couple of
strange reports from exim users.

cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Next Exim: TLS: changed smarthost example config [ In reply to ]
On 21/04/18 01:17, Phil Pennock via Exim-users wrote:
> The commented-out "smarthost" Router now uses a Transport named
> "smarthost_smtp" instead of "remote_smtp". The new smarthost_smtp
> currently looks like the text below, which is subject to change before
> the next release.

Having split the smarthost_smtp transport from the remote_smtp, we could
also add to the latter:

.ifdef _HAVE_DANE
dnssec_request_domains = *
hosts_try_dane = *
.endif


(again, fully back-compatible)
--
Cheers,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Next Exim: TLS: changed smarthost example config [ In reply to ]
On 2018-04-21 at 11:23 +0200, Andreas Metzler via Exim-users wrote:
> Personally I am not convinced that this is the right way for trying to
> enforce stronger encryption standards on mail providers.

It's not about that. It's about providing people relying upon defaults
with worthwhile security, so that when their system goes to send email,
it's not trivially susceptible to MitM attack.

Along the way, I'm saying roughly "if these things don't work, then it's
breakage on the mail provider's side, here's my wet-finger-in-air
assessment of what these types of breakage mean as to whether or not you
should be using that mail-provider."

> is going to be any effect, people won't change their email address
> because the hosting smarthost does not provide TLS1.2 (due to SPF et

I didn't actually provide a wet-finger-in-air assessment of this point.
I covered "no TLS", "unverifiable certificate" and "ciphersuite
problems".

I mapped "no TLS" to "change mail provider" and I'm pretty serious
there: having to send email without any kind of link security at all
should be unacceptable.

I mapped "unverifiable certificate" to "seriously consider" changing
mail provider; after the past six years, since Heartbleed, enough
attention has been paid to TLS security that anyone providing a
commercial service to others should be able to manage a verifiable
certificate. Let's Encrypt is two years old and now common enough to be
a baseline minimum. If folks aren't offering a verifiable certificate
to their userbase, then now is the time to fix that.

This can be something from an internal certificate authority for an
organization which has such a thing and only lets internal systems send
email, or can be a free certificate if the more general public needs to
be able to send email. The verifiable identity should be "whatever you
tell end users is the real name of the server". None of this applies to
MX delivery.

I mapped "ciphersuite problems" to something which folks should expect
their mail provider to be able to fix quickly. If there are issues and
they can't be fixed quickly, then why trust that the provider can do
much of anything to provide TLS service?

I did not map "no TLS1.2 support" but would tend to treat it much like
ciphersuite problems.

> cu Andreas

Thanks for the GnuTLS fixes, I'll apply those. I did consider TLS 1.3
but there's enough uncertainty there that it seemed reasonable to wait,
rather than debug what protocol strings may or may not exist and be
parsed for SSLv3 etc etc.

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Next Exim: TLS: changed smarthost example config [ In reply to ]
On 2018-04-20 at 22:38 -0400, Viktor Dukhovni via Exim-users wrote:
> I'd make that:
>
> HIGH:!aNULL:!aDSS:!kECDHr:!kECDHe:!kDHr:!kDHd
>
> Because, the ciphers are already sensibly ordered as of OpenSSL 1.0.0.

No matter what we tell people and how much we push towards 1.0.2 as a
minimum, I am confident that as long as someone can cobble together a
way to keep running with OpenSSL 0.9.8 then _someone_ will do so.

Thus @STRENGTH stays. I believe that !aNULL is covered by requiring
verification, but sure good to disable here. The others: it's more
complex knowledge of what should be put where end administrators touch
things than I'm entirely comfortable with.

So your string is "better" but I don't want to be putting that level of
intimidating TLS configuration into our starting configuration file.

Thus "HIGH:!aNULL:@STRENGTH" and _if_ I find time to work on the
suggested OpenSSL integration revamp, then something which disables
older versions of TLS, as for GnuTLS.

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Next Exim: TLS: changed smarthost example config [ In reply to ]
On 2018-04-22 Phil Pennock <pdp@exim.org> wrote:
> On 2018-04-21 at 11:23 +0200, Andreas Metzler via Exim-users wrote:
[...]
>> is going to be any effect, people won't change their email address
>> because the hosting smarthost does not provide TLS1.2 (due to SPF et

> I didn't actually provide a wet-finger-in-air assessment of this point.
> I covered "no TLS", "unverifiable certificate" and "ciphersuite
> problems".
[...]
> I mapped "ciphersuite problems" to something which folks should expect
> their mail provider to be able to fix quickly. If there are issues and
> they can't be fixed quickly, then why trust that the provider can do
> much of anything to provide TLS service?

> I did not map "no TLS1.2 support" but would tend to treat it much like
> ciphersuite problems.
[...]

Good morning,

I understood

| hosts_require_tls = *
| [...]
| tls_require_ciphers = NONE:+VERS-TLS1.2:SECURE192

as intent to require a) TLS and b) not any TLS-version, but TLS 1.2. If
that is not the case the proper fix is not the one I originally posted
but to simply not set tls_require_ciphers for GnuTLS, since the defaults
(exim uses NORMAL - see "gnutls-cli --list --priority=NORMAL") are not
unreasonable.

cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/