Bug#916866: libgnutls30: sslv3 handshake failure with new version 3.6.5-2

[Andreas Metzler]

On 2018-12-20 Lionel Siess <Lionel.Siess at astro.ulb.ac.be> wrote:
> On Thu, 20 Dec 2018 07:36:40 +0100
> Andreas Metzler <ametzler at bebt.de> wrote:

>>On 2018-12-19 Lionel Siess <Lionel.Siess at ulb.ac.be> wrote:
>>> On 19.12.2018 19:33, Andreas Metzler wrote:  
>>>> On 2018-12-19 Lionel <siess at ulb.ac.be> wrote:  
[...]
>>>> Did you update gnutls on the server or on the client side?  
>>> on the client side only.  

>>Hello,

>>Since w3m, links, lynx or elinks do not work anymore I suspect a
>>server-side problem, the server breaking when the client advertises
>>newer TLS features. w3m/links are using OpenSSL, elinks/lynx gnutls.

> Hello Andreas

> Thanks for your support

> I made a test on a machine where the libraries have not been  upgraded
> (version 3.5.19-1+b1).  elinks works on that machine but w3m fails. I
> am sorry for the confusion.  w3m apparently never worked so it is
> apparently not related to OpenSSL.  (when i was connecting to that
> server I was in fact using an alias that was using elinks)  
[...]
> home:> openssl s_client -connect 172.19.73.1:443
> CONNECTED(00000003)
> 22439738049984:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake
> failure:../ssl/record/rec_layer_s3.c:1528:SSL alert number 40 ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 7 bytes and written 303 bytes
> Verification: OK
> ---
> New, (NONE), Cipher is (NONE)
[...]
> I also ran this commands that may be helpful for the expert you are:

> home:> gnutls-cli-debug -p 443 172.19.73.1
> GnuTLS debug client 3.6.5
> Checking 172.19.73.1:443
[...]
>                              for TLS 1.0 (RFC2246) support... yes
>                              for TLS 1.1 (RFC4346) support... no
>                                   fallback from TLS 1.1 to... TLS 1.0
>                              for TLS 1.2 (RFC5246) support... no
>                              for TLS 1.3 (RFC8446) support... no
>                        TLS1.2 neg fallback from TLS 1.6 to... failed (server requires
> fallback dance) for HTTPS server name... Virata-EmWeb/R6_0_1
>                                for certificate chain order... sorted
>                   for safe renegotiation (RFC5746) support... yes
>                     for encrypt-then-MAC (RFC7366) support... no
>                    for ext master secret (RFC7627) support... no
>                            for heartbeat (RFC6520) support... no
>                        for version rollback bug in RSA PMS... no
>                   for version rollback bug in Client Hello... no
>             whether the server ignores the RSA PMS version... no
> whether small records (512 bytes) are tolerated on handshake... yes
>     whether cipher suites not in SSL 3.0 spec are accepted... yes
> whether a bogus TLS record version in the client hello is accepted... yes
>          whether the server understands TLS closure alerts... no
>             whether the server supports session resumption... yes
>                       for anonymous authentication support... no
>                       for ephemeral Diffie-Hellman support... no
>                         for RFC7919 Diffie-Hellman support... no
>                    for ephemeral EC Diffie-Hellman support... no
>                              for curve SECP256r1 (RFC4492)... no
>                              for curve SECP384r1 (RFC4492)... no
>                              for curve SECP521r1 (RFC4492)... no
>                                 for curve X25519 (RFC8422)... no
>                       for AES-GCM cipher (RFC5288) support... no
>                       for AES-CCM cipher (RFC6655) support... no
>                     for AES-CCM-8 cipher (RFC6655) support... no
>                       for AES-CBC cipher (RFC3268) support... no
>                  for CAMELLIA-GCM cipher (RFC6367) support... no
>                  for CAMELLIA-CBC cipher (RFC5932) support... no
>                      for 3DES-CBC cipher (RFC2246) support... yes
>                   for ARCFOUR 128 cipher (RFC2246) support... no
>             for CHACHA20-POLY1305 cipher (RFC7905) support... no
>                                        for MD5 MAC support... no
>                                       for SHA1 MAC support... yes
>                                     for SHA256 MAC support... no
>                      for max record size (RFC6066) support... no
>                 for OCSP status response (RFC6066) support... no

[...]

Well, since OpenSSL also does not manage to make a encrypted connection
and the server in question seems to be lacking any non weak (by today's
standards) ciphers I would not consider this to be a GnuTLS or OpenSSL
bug, but a hint for a server software update. Googling suggests that
Virata-EmWeb/R6_0_1 is ancient (earlier than 2006).

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'