Re: [exim] PFS encryption

On 2013-07-30 at 12:54 +0200, Cyborg wrote:
> Am 30.07.2013 11:19, schrieb Graeme Fowler:
> > On 30 Jul 2013, at 08:56, Cyborg <cyborg2@???> wrote:
> >> as i just read about PFS, i was wondering how exim is handling the key exchange.
> >>
> >> the article suggested to use these ciphers in this order:
> >>
> >> TLS_ECDHE_RSA_WITH_RC4_128_SHA
> >> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
> >> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> >> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
> > Look for tls_require_ciphers in the docs.
> >
>
> But was is the DEFAULT ?

The default is whatever the SSL library, whether OpenSSL or GnuTLS,
provides as the default.

Rationale: although I happen to know a bit about crypto engineeering
(but not crypto math), it's a bad call for application developers to be
making decisions about which ciphersuites to trust. We lock ourselves
into a decaying trap if we do that. So instead, we leave the decisions
to the experts (the OpenSSL and GnuTLS developers) and provide
configuration options so that folks can change the settings.


Next: note that Exim when connecting outbound does check the trust chain
to a certificate but does not verify hostnames, because there has
historically been nothing trustworthy to verify. We're still hoping to
have improvements for this in before Exim 4.82, with DANE support.
Unfortunately for Exim, my day job is at a start-up which keeps me very
busy, so there's been no code movement here for some time. :(

Thus if you're caring about PFS, this is presumably for Exim-as-server,
not Exim-as-client.

> if so, i don't see any ellipticbased ciphers there, but at least they
> use DHE, which indicates PFS is used, which is good.

If you're using OpenSSL, then this depends upon the version of OpenSSL
which you're using. I believe that you need at least the OpenSSL 1.0.1
series to get elliptic-curve cryptography.

Running "exim -d --version" will tell you which version of OpenSSL is
being used.

My main server config has:

----------------------------8< cut here >8------------------------------
tls_require_ciphers = ${if INBOUND_MTA_CONDITION {DEFAULT:!SSLv2:!LOW} {TLS_SERVER_SUBMISSION_CIPHERSPEC}}:!aNULL:!eNULL
----------------------------8< cut here >8------------------------------

and the smtp transport uses a condition to decide between
TLS_CLIENT_HIGHSEC_CIPHERSPEC and TLS_CLIENT_DEFAULT_CIPHERSPEC; ignore
the INBOUND_MTA_CONDITION specifics: it boils down to "port 25 or not"
but with some complexity not relevant to this discussion.

These three TLS_* macros are defined as:

----------------------------8< cut here >8------------------------------
# We have a default cipherspec, and a high-sec cipherspec we'll use for known
# good hosts later, typically anyone with it enough to have DANE turned on, so
# we can verify identity. Until you can verify identity, no point worrying too
# much about the cipher choices
# default: we permit aNULL since we don't have anything to test against, but not eNULL
TLS_CLIENT_DEFAULT_CIPHERSPEC=DEFAULT:!SSLv2:!LOW:aNULL:!eNULL
# high: prep for having something to test against
TLS_CLIENT_HIGHSEC_CIPHERSPEC=ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:HIGH:!MD5:!RC4:!aNULL:!ADH:!DES:!EXP:!NULL
TLS_SERVER_SUBMISSION_CIPHERSPEC=ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:HIGH:!MD5:!RC4:!aNULL:!ADH:!DES:!EXP:!NULL
----------------------------8< cut here >8------------------------------

The DANE part isn't there yet; the file which I use to define properties
for remote domains I care a lot about (hard-require TLS, for instance)
has a key to force on high mode.

-Phil