Autore: Phil Pennock Data: To: Lena CC: exim-users Oggetto: Re: [exim] TLSv1.1, TLSv1.2
On 2012-04-27 at 20:08 +0300, Lena@??? wrote: > After upgrade to openssl 1.0.1, my Perl script using Crypt::SSLeay
> was unable to connect as a client to a web server (https),
> I had to downgrade openssl to 1.0.0h on that machine (it runs Exim too).
Can you identify why this failed? TLS protocol negotiation should be
robust to this sort of thing, shouldn't it? Or did the SSLv3-compatible
hack for TLS1.0 not get carried forward, so that you can only negotiate
TLS1.1+ if you're not also requesting SSLv3?
> Is the following (from Postfix 2.9.2 release notes) relevant to Exim?
> If yes, should we specify
> tls_require_ciphers main configuration option (Exim as server) or
> tls_require_ciphers smtp transport option (Exim as client)?
Both, since they're independent. At present, we can only do this via
the "tls_require_ciphers" option for OpenSSL, which really only affects
the available ciphers and I'm not clear on how something like !SSLv2
(disable the SSLv2 ciphersuite) in the ciphers spec affects
advertisement of support for SSLv2 by OpenSSL at the protocol
negotiation level.
For GnuTLS, see the "gnutls_require_protocols" option. That's direct
protocol selection. Note that GnuTLS has supported TLS1.1 & 1.2 for
some time, and Exim has supported using those since 4.77.
Are you able to test an Exim build on a different port, using GnuTLS, to
see if TLS1.1 in GnuTLS works with your script?
In OpenSSL, the global "openssl_options" option can do the same thing,
but when I was last updating the list of options, OpenSSL didn't yet
have TLS1.1 support, so those options couldn't be added. This also
requires that Exim be built _after_ installing the headers for the new
version of OpenSSL. See "tls-openssl.c", and the bits of code like this:
