1

After upgrading a (working) Ubuntu 18.04 webserver to 20.04, I get the following error in the log when making a simple curl request:

[Fri Nov 06 14:46:38.344069 2020] [gnutls:info] [pid xxx] [client <ip addr>] GnuTLS: Handshake Failed (-87) 'No supported cipher suites have been found.'

curl output on the client:

$ curl -v <server>
*   Trying <ip>:443...
* TCP_NODELAY set
* Connected to <server> (<ip>) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, handshake failure (552):
* error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
* Closing connection 0
curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

GnuTLS configuration is as follows:

        GnuTLSEnable on
        GnuTLSSessionTickets on
        GnuTLSPriorities NORMAL
        GnuTLSCertificateFile /etc/ssl/certs/server.cert
        GnuTLSKeyFile /etc/ssl/keys/server.key

Both client and server are up-to-date Ubuntu 20.04 hosts. I've increased the LogLevel to "debug" which shows the following additional log message in the Apache start up log:

[Fri Nov 06 15:07:26.966137 2020] [gnutls:debug] [pid 3849] gnutls_hooks.c(501): set_default_dh_param: Setting DH params for security level 'Low'.

While debugging this, I found what looked like a permissions issue with the TLS private key, but fixing this issue hasn't changed the error message. How else can I debug this?

cqcallaw
  • 163
  • 1
  • 8
  • First I would use other clients to check if the server works at all. – Robert Nov 06 '20 at 23:44
  • Similar issues with wget, Chrome, Brave, and Firefox – cqcallaw Nov 07 '20 at 01:20
  • Mobile Chrome gets past the issue, strangely. – cqcallaw Nov 07 '20 at 01:34
  • _Might_ be related to TLS1.3, which the gnutls ~3.6.13 in focal implements but ~3.5.18 in bionic does not. Try `curl ... --tls-max 1.2` or specifically `... --tlsv1.2` and see if that makes a difference. – dave_thompson_085 Nov 07 '20 at 05:19
  • @dave_thompson_085 Good call, seems that running `curl --tls-max 1.2` surfaced an issue with the certificate chain having 1024 bit keys. I've fixed that issue, and now TLSv1.2 connections work. TLS 1.3 connections still fail to negotiate a cipher suite, however. Any other suggestions? – cqcallaw Nov 07 '20 at 17:51
  • Only thing that springs to mind is if your cert/key is DSA aka DSS, which is no longer supported in TLS1.3. (ECC curves not included in 8422 also aren't supported, but your '1024 bit' rules that out.) You could try running `gnutls-serv` with the same config (on a different port, or while your normal server is stopped) and see if it gives any more detailed info, maybe with `--debug`. Or you could punt and use `NORMAL:-VERS-TLS1.3` :-( – dave_thompson_085 Nov 08 '20 at 04:17

2 Answers2

1

I had the same error "No supported cipher suites have been found". The solution was much easy than I expect (I tried to use different TLS clients, checked that my server and clients really have common cipher suites).

But when I simply run gnutls-serv with cert file and key file parameters and choose a path for them all starts to work normally.

gnutls-serv --priority="NORMAL:-VERS-TLS1.3" --x509certfile ./cert.pem --x509keyfile ./key.pem

ratel
  • 11
  • 1
  • thank you, you really helped. In my case it works even without the priority. Also I have a server.pem file with both cert and key and I just specified it twice and it worked. – Sergey Ponomarev Apr 02 '23 at 22:30
0

While I haven't found a true fix, @dave_thompson_085 gave me the hint I needed to find a workaround, specifically disabling TLSv1.3 with the following setting:

GnuTLSPriorities NORMAL:-VERS-TLS1.3

Disabling TLSv1.3 has security implications, so I'm not certain this workaround will be my final solution.

Debug Process

To debug this issue, I:

  1. Ran curl --tls-max 1.2 -v https://server/ and observed the output. This surfaced an issue with the server using a weak key (1024 bit key; minimum of 2048 bits is currently recommended).
  2. Tried disabling TLSv1.3 in the Apache config. With TLS 1.3 disabled, all requests to Apache behave as expected.
cqcallaw
  • 163
  • 1
  • 8