On 2013-10-01 at 08:38 +0100, Dr Andrew C Aitchison wrote:
> On Mon, 30 Sep 2013, Phil Pennock wrote:
[ quoting an old email from a year or so before ]
> > Fortunately, I suspect that very few people ever actually set
> > tls_require_ciphers, so the fallout won't be too bad. But we do need to
> > figure out the idea behind this test so that we can properly test it in
> > the new world order.
> > ----------------------------8< cut here >8------------------------------
>
> I for one *do* set tls_require_ciphers (though I currently use OpenSSL
> not GnuTLS) - I dropped RC4 a couple of weeks ago after using
> it for a couple of months to protect against the BEAST.
Right, the "fortunately" was about the limited scope of the pain and
disruption caused: "very few", not "none". Because we expect that _any_
feature will be used and set by someone, we call out all breaking
changes in README.UPDATING and work hard to limit the need to break
anything in the first place.
We (I) called out the change in the README.UPDATING when we (I) broke
backwards compat of GnuTLS configuration in 4.80. Nothing new is broken
at this time: we have a test which was never updated to reflect the new
state of affairs.
Further, note that the _context_ of the quoted text adds an implicit
"for GnuTLS". I would broadly expect tls_require_ciphers to be set with
OpenSSL, but for the GnuTLS integration, as it existed prior to 4.80, I
would not, because most tuning would be done with the gnutls_require_*
variables instead.
I changed this because the old integration of GnuTLS into Exim was one
of the earliest GnuTLS integrations, before a lot of the modern GnuTLS
API was in place, and the Exim code had a lot of very specific knowledge
about ciphers and protocol details, which artificially limited how
GnuTLS could work. The old code force-enabled MD5, for instance, while
not allowing many newer algorithms to be used.
For your convenience, I've included the README.UPDATING text in
question:
----------------------------8< cut here >8------------------------------
* The GnuTLS support has been mostly rewritten, to use APIs which don't cause
deprecation warnings in GnuTLS 2.12.x. As part of this, these three options
are no longer supported:
gnutls_require_kx
gnutls_require_mac
gnutls_require_protocols
Their functionality is entirely subsumed into tls_require_ciphers. In turn,
tls_require_ciphers is no longer an Exim list and is not parsed by Exim, but
is instead given to gnutls_priority_init(3), which expects a priority string;
this behaviour is much closer to the OpenSSL behaviour. See:
http://www.gnutls.org/manual/html_node/Priority-Strings.html
for fuller documentation of the strings parsed. The three gnutls_require_*
options are still parsed by Exim and, for this release, silently ignored.
A future release will add warnings, before a later still release removes
parsing entirely and the presence of the options will be a configuration
error.
Note that by default, GnuTLS will not accept RSA-MD5 signatures in chains.
A tls_require_ciphers value of NORMAL:%VERIFY_ALLOW_SIGN_RSA_MD5 may
re-enable support, but this is not supported by the Exim maintainers.
Our test suite no longer includes MD5-based certificates.
This rewrite means that Exim will continue to build against GnuTLS in the
future, brings Exim closer to other GnuTLS applications and lets us add
support for SNI and other features more readily. We regret that it wasn't
feasible to retain the three dropped options.
----------------------------8< cut here >8------------------------------
