On Fri, Sep 30, 2022 at 07:05:52PM +0100, Jeremy Harris via Exim-users wrote:
> On 30/09/2022 18:34, Viktor Dukhovni via Exim-users wrote:
> > Do you also have a TLS version floor? "protocol version" sure sounds
> > like it.
>
> Not as far as I know, and
> openssl_options = -no_sslv3 -no_tlsv1_1 -no_tlsv1
> doesn't change the result.
That sets a floor, rather than clearing it. You're explicitly
turning off SSL 3.0, TLS 1.0 and TLS 1.1.
> There is indeed a "protocol version" fatal alert sent according to
> wireshark.
That's what it looks like.
> > Anyway, this is perhaps a distraction from the GnuTLS issue,
> > which you've identifies IIRC (SSL 3.0-compatible handshake with no TLS
> > extensions fails against Exim + GnuTLS as reported).
>
> While it's true the Exim bug with GnuTLS is now fixed, having the
> regression test passing for both the TLS libraries we claim to support
> would be good. $subject changed to reflect that.
Do you have a test server reachable from the Internet that's running the
version of Exim in question over OpenSSL? Does its cipherlist end with
":@SECLEVEL=0" (or does it explicitly set the security level via the
OpenSSL API).
The Postfix server on the DANE survey host linked with OpenSSL 3.0.5
(Fedora 36) completes a TLS 1.1 handshake just fine:
$ openssl s_client -quiet -starttls smtp -tls1_1 -cipher "ALL:@SECLEVEL=0" -connect $(uname -n):25
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = dnssec-stats.ant.isi.edu
verify return:1
250 CHUNKING
quit
221 2.0.0 Bye
An Exim server linked with OpenSSL 3.0.5 should be able to do likewise,
barring protocol version floors, cipherlists that exclude SHA1, ...
--
Viktor.
