On Fri, 2017-09-08 at 21:44 +0200, Nikos Mavrogiannopoulos wrote: > On Fri, 2017-09-08 at 14:58 +0200, Nikos Mavrogiannopoulos wrote: > > On Fri, Sep 8, 2017 at 11:11 AM, Michael Haubenwallner > > <michael.haubenwallner at ssi-schaefer.com> wrote: > > > > > Same problem here when using GnuTLS 3.5.13, > > > but there is no problem with GnuTLS 3.3.26. > > > > Could you share its IP? Otherwise try I'd recommend using "gnutls- > > cli > > IP -d 6" and try git-bisect on gnutls master to see which commit > > broke > > the connection (if you cannot use git, you may want to use the > > released tarballs). > > That's a very peculiar/broken server and I do not believe it makes > sense even trying fix it on client side. > > You can connect on it only if there is a particular ordering on the > cipher suites and if there are not many ciphersuites advertized. > > fails: gnutls-cli servername --priority NORMAL > ok: gnutls-cli servername --priority NORMAL:-ECDHE-RSA > ok: gnutls-cli servername --priority NORMAL:-DHE-RSA > ok:?gnutls-cli servername --priority NORMAL:-KX-ALL:+ECDHE- > RSA:+RSA:+DHE-RSA > fails:?gnutls-cli servername --priority NORMAL:-KX-ALL:+ECDHE- > RSA:+ECDHE-ECDSA:+RSA:+DHE-RSA Actually, I noticed that if the camellia ciphersuites are removed from the default priority sets of gnutls, it works. So it is really a matter of size of the client hello. I've created a merge request, though I'm not fully convinced that this issue justifies removing a backup cipher. https://gitlab.com/gnutls/gnutls/merge_requests/511 regards, Nikos
