[gnutls-devel] GnuTLS | gnutls_priority_set in post client hello function breaks handshake for clients with TLS versions < 1.3 (#580)

[Development of GNU's TLS library]

New Issue was created.

Issue 580: https://gitlab.com/gnutls/gnutls/issues/580
Author:    Airtower
Assignee:  

If a server calls `gnutls_priority_set` in a post client hello function the handshake breaks unless both peers support TLS 1.3. This breaks servers that allow virtual hosts (using SNI) that may have different priority settings because they have to load the right priorities after parsing the SNI.

I discovered the problem while testing mod_gnutls with **GnuTLS 3.6.4** (at commit 1c0b4baa6a88bfb79a30eb6fb7c579688d40034e).

## Steps to Reproduce:

1. Compile [prio-issue-repro.c](/uploads/ea95edee70927b2d3315e53fd007a020/prio-issue-repro.c) (slightly modified version of the echo server example `doc/examples/ex-serv-x509.c`)
2. Run the binary (expects a certificate `server/x509.pem` and private key `server/secret.key`) and try the following client commands.
3. `gnutls-cli -p 5556 localhost --insecure --priority=NORMAL`
4. `gnutls-cli -p 5556 localhost --insecure --priority=NORMAL:-VERS-TLS1.3`

(`--insecure` just to ignore certificate validation)

## Actual results:

The first `gnutls-cli` call connects successfully and you can use the echo server. The second one fails, the server logs `Handshake has failed (No supported cipher suites have been found.)`

## Expected results:

Both client commands should work. If you comment the `CHECK(gnutls_priority_set(session, *p));` line in the `hello_prio` function they do, which is why I believe the issue is triggered by `gnutls_priority_set`.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/580
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20180928/a39ab693/attachment.html>