[exim] tls_advertise_hosts

[Richard Clayton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


from the fine documentation

When Exim has been built with TLS support, it advertises the
availability of the STARTTLS command to client hosts that match
tls_advertise_hosts, but not to any others. The default value of
this option is unset, which means that STARTTLS is not advertised
at all. This default is chosen because you need to set some other
options in order to make TLS available, and also it is sensible
for systems that want to use TLS only as a client.

from README.UPDATING about #4.87

<void>

from doc/Changelog

JH/18 Bug 1709: When built with TLS support, the tls_advertise_hosts
option now defaults to "*" (all hosts). The variable is now
available when not built with TLS, default unset, mainly to enable
keeping the testuite sane.

If a server certificate is not supplied (via tls_certificate) an
error is logged, and clients will find TLS connections fail on
startup. Presumably they will retry in-clear. Packagers of Exim
are strongly encouraged to create a server certificate at
installation time.

- From my logfile (see, I read all sorts of things)

Warning: No server certificate defined; TLS connections will fail.
Suggested action: either install a certificate or change
tls_advertise_hosts option

and from a Yahoo account of mine talking to my server which I have just
updated to #4.87

Warning: could not send message for past 4 hours
...
Deferred: 403 4.7.0 TLS handshake failed

I can find nothing in RFC3207 saying that Yahoo's behaviour is incorrect
and much in RFC5321 to say it is entirely correct.

So my question is:

on exactly what specification or belief is the statement
"Presumably they will retry in-clear" based ??

(because if it's Yahoo's error I have some influence there) ...

At the very least BTW there should be something in README.UPDATING about
changes that impact existing configurations :-(

- --
richard Richard Clayton

Those who would give up essential Liberty, to purchase a Benjamin
little temporary Safety, deserve neither Liberty nor Safety. Franklin

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBVx44Nju8z1Kouez7EQLP4ACg/ct3df43UlXNRpXc6x1BEeG8niAAn14f
CrulJ1AR66qZCce4+jIMulQv
=sVP1
-----END PGP SIGNATURE-----

[Jeremy Harris]

Post by Richard Clayton
on exactly what specification or belief is the statement
"Presumably they will retry in-clear" based ??
(because if it's Yahoo's error I have some influence there) ...

Merely personal observation of common behaviour. I'm sorry
you have found a counterexample.

Post by Richard Clayton
At the very least BTW there should be something in README.UPDATING about
changes that impact existing configurations :-(

Fair point. Not a file I've done much to.

[Heiko Schlittermann]

Viktor Dukhovni <exim-***@dukhovni.org> (Mo 25 Apr 2016 17:53:14 CEST):



The Postfix behaviour when server-side TLS is administratively
enabled, but no certificate is configured is to log warnings and
not advertise STARTTLS. Advertising STARTTLS when it is sure to
fail is not ideal.

Probably Exim could implement it in a similiar fashion. But
it's not as easy as it sounds


I can understand the implementation rationale. Exim likely does




IIRC, the Exim SMTP server runs indefinitely, and so preloading
the cert is not as attractive, since it will get stale.

The process handling the connection is a child of a long running
process. This child is responsible for offering the
STARTTLS. So it's no problem with stale or useless certs.

BUT the tls_*file options are expanded at runtime on request. Some
variables are set already at TCP connection time or EHLO time, but the
client may send SNI information during SSL handshake. And the
tls_{certificate,privatekey} options may contain a $tls_in_sni expando.
So there is no chance to expand and check the tls_* options beforehand.

In Postfix, I've opted for providing a script that generates
and configures the cert/key and leaving the decision of enabling
inbound TLS by default to O/S distributions. They provide the
code that installs and activates Postfix, so are in a better
position to work with the user to enable or not enable TLS.

The O/S distros are free to set the default of tls_advertise_hosts
to an empty string in their configuration templates, and/or provide
an (automatic) script to generate a self signed cert.

The current flood of warnings is (IMHO) only from legacy installations
that don't use TLS and are now a victim of the changed built-in default.

Maybe we *could* check if there is at least something configured for
tls_{certificate,privatekey} and suppress the STARTTLS offer if these
global options are missing (but continue to issue the warning.)

Jeremy? What do you think?

Best regards from Dresden/Germany
Viele GrÌße aus Dresden
Heiko Schlittermann

[Mike Tubby]

Gents,

I have to say that this is all sounding very complicated, please can we
have the old default back? ... its seems to make most sense, to me, to have:

tls_advertise_hosts = <null>

and require users to:

a) turn it on by specifying something else, and
b) put some meaningful certificates in place

This is both logical and convergent as use of TLS is an, optional,
upgrade (choice of the sysadmin) over a base install.


Mike

Post by Heiko Schlittermann
…

The Postfix behaviour when server-side TLS is administratively
enabled, but no certificate is configured is to log warnings and
not advertise STARTTLS. Advertising STARTTLS when it is sure to
fail is not ideal.

Probably Exim could implement it in a similiar fashion. But
it's not as easy as it sounds…

I can understand the implementation rationale. Exim likely does

…

IIRC, the Exim SMTP server runs indefinitely, and so preloading
the cert is not as attractive, since it will get stale.

The process handling the connection is a child of a long running
process. This child is responsible for offering the
STARTTLS. So it's no problem with stale or useless certs.
BUT the tls_*file options are expanded at runtime on request. Some
variables are set already at TCP connection time or EHLO time, but the
client may send SNI information during SSL handshake. And the
tls_{certificate,privatekey} options may contain a $tls_in_sni expando.
So there is no chance to expand and check the tls_* options beforehand.

In Postfix, I've opted for providing a script that generates
and configures the cert/key and leaving the decision of enabling
inbound TLS by default to O/S distributions. They provide the
code that installs and activates Postfix, so are in a better
position to work with the user to enable or not enable TLS.

The O/S distros are free to set the default of tls_advertise_hosts
to an empty string in their configuration templates, and/or provide
an (automatic) script to generate a self signed cert.
The current flood of warnings is (IMHO) only from legacy installations
that don't use TLS and are now a victim of the changed built-in default.
Maybe we *could* check if there is at least something configured for
tls_{certificate,privatekey} and suppress the STARTTLS offer if these
global options are missing (but continue to issue the warning.)
Jeremy? What do you think?
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann

[Heiko Schlittermann]

Post by Mike Tubby
Gents,
I have to say that this is all sounding very complicated, please can we have
tls_advertise_hosts = <null>
a) turn it on by specifying something else, and
b) put some meaningful certificates in place
This is both logical and convergent as use of TLS is an, optional, upgrade
(choice of the sysadmin) over a base install.

Hm. What about setting tls_advertise_hosts to an empty default, but
complain if this option isn't mentioned in the configuration at all?

Then you'll get warnings if if forget to think about TLS, but your
installation will be operational all the time in a compatible way (by
not advertising STARTTLS).

As soon as you agree with this (insecure) default by putting it into your
configuration, the warnings will go away, no matter whay value you put
there.

Best regards from Dresden/Germany
Viele GrÌße aus Dresden
Heiko Schlittermann

[Mike Tubby]

Post by Heiko Schlittermann

Post by Mike Tubby
Gents,
I have to say that this is all sounding very complicated, please can we have
tls_advertise_hosts = <null>
a) turn it on by specifying something else, and
b) put some meaningful certificates in place
This is both logical and convergent as use of TLS is an, optional, upgrade
(choice of the sysadmin) over a base install.

Hm. What about setting tls_advertise_hosts to an empty default, but
complain if this option isn't mentioned in the configuration at all?
Then you'll get warnings if if forget to think about TLS, but your
installation will be operational all the time in a compatible way (by
not advertising STARTTLS).
As soon as you agree with this (insecure) default by putting it into your
configuration, the warnings will go away, no matter whay value you put
there.
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann

Yes, I think that works and would make sense as long as it's a "soft
warning" that occurs if:

a) the binary is built with TLS capability (openssl, GNU TLS,
other), and
b) the variable tls_advertise_hosts is set to empty/null

then when Exim starts it could generate a warning like:

Warning: Exim is capable of use TLS/SSL but it is currently
disabled in configuration - see http://www.exim.org/...

likewise, if the Exim binary can do TLS, and tls_advertise_hosts is non
zero but Exim cannot find any valid certificates this could generate a
warning.

As for the SNI stuff this can only be done a connection time ...


Mike






Warning:

[Jasen Betts]

Post by Mike Tubby
likewise, if the Exim binary can do TLS, and tls_advertise_hosts is non
zero but Exim cannot find any valid certificates this could generate a
warning.

it does, but can't look until TLS is requested, because
tls_cert is expanded, and could depend on connection parameters

It could check that it is defined I guess,

[Ralf Cirksena]

Post by Heiko Schlittermann
Hm. What about setting tls_advertise_hosts to an empty default, but
complain if this option isn't mentioned in the configuration at all?

Good idea.
For those of us updating from an erlier exim a warning would be fine.

[Jeremy Harris]

Post by Mike Tubby
I have to say that this is all sounding very complicated, please can we
have the old default back?

So much for encouraging people to actually use security.

[Richard Clayton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Jeremy Harris
So much for encouraging people to actually use security.

There's a difference between "encouragement" and subtly breaking
existing configurations without even a mention in the Fine Manual (or
the upgrade instructions).

On balance I don't think you should ever break existing systems at all
without a compelling security case (or perhaps, with a view to
simplifying the codebase, by upgrading legacy warnings to errors if they
have been present for a considerable number of revisions).

Note that for many people STARTTLS is either irrelevant (their threat
model does not encompass network layer attackers) or insufficient
(because of MiTM attacks, downgrades etc). That is, I don't think this
security case is currently so compelling that failure to force its use
would be negligent.

BTW: I consulted folks yesterday evening, and Yahoo's mail system is
very closely based on a extremely widely deployed MTA -- and so the
expectation is that they will not have been far from alone in failing to
deliver email to my upgraded system over the past few days :-(

Fixes along the lines being discussed seem sane -- changing the default
back, but also producing a warning when Exim starts that more security
could be achieved by adding a certificate and changing the config.

- --
richard Richard Clayton

Those who would give up essential Liberty, to purchase a Benjamin
little temporary Safety, deserve neither Liberty nor Safety. Franklin

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBVx9B4Tu8z1Kouez7EQIEzwCggEoZmcfM59zDANpOex0LyQg543AAoLjA
MaGCnJ5SSbKSq2Q2OnVH0HUg
=qFA2
-----END PGP SIGNATURE-----

[Jeremy Harris]

Post by Richard Clayton

Post by Jeremy Harris
So much for encouraging people to actually use security.

There's a difference between "encouragement" and subtly breaking
existing configurations

The logged error was too subtle?

[Richard Clayton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message <***@wizmail.org>, Jeremy Harris <***@wizmail.org>
writes

Post by Jeremy Harris

Post by Richard Clayton

Post by Jeremy Harris
So much for encouraging people to actually use security.

There's a difference between "encouragement" and subtly breaking
existing configurations

The logged error was too subtle?

If you mean

2016-04-25 03:01:00 Warning: No server certificate defined; TLS
connections will fail. Suggested action: either install a
certificate or change tls_advertise_hosts option

that's a warning, not an error :)

If you mean the error that is logged for the delivery failure: I
generally find that my logs a bit verbose for regular reading ... I just
look at them when things break, and when most email is turning up just
fine I tend to just ignore them.

When I did realise I had a problem I found the log said

2016-04-25 00:23:00 TLS error on connection from
mrout1-b.corp.bf1.yahoo.com [98.139.253.104]:26298 (SSL_accept):
error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher
2016-04-25 00:23:00 TLS client disconnected cleanly (rejected our
certificate?)

and that is indeed subtly hinting that the cert (which in my case I have
not got) is at the root of the problem ... but it's not really recording
(ie: the subtlety continues) the actually relevant event (that a 4xx has
been presented to the remote machine) the cleanliness makes it all sound
better than it is :(

- --
richard Richard Clayton

Those who would give up essential Liberty, to purchase a Benjamin
little temporary Safety, deserve neither Liberty nor Safety. Franklin

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBVx9Ojzu8z1Kouez7EQLQ/QCePTxMYg/qf6HFA19AiatH1mna2K4AoPef
EOSSHrg+PvndPk3wmjkEhscM
=3KC0
-----END PGP SIGNATURE-----

[Chris Siebenmann]

Post by Heiko Schlittermann
Maybe we *could* check if there is at least something configured for
tls_{certificate,privatekey} and suppress the STARTTLS offer if these
global options are missing (but continue to issue the warning.)

As a bystander here who may in the future be affected by this, I
think that this is a sensible answer to the overall problem. If Exim
knows that it can never successfully negociate TLS because nothing is
configured at all, not offering STARTTLS seems very sane and useful.

- cks