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 Also with openssl. fails:?openssl s_client -host servername -port 443 -cipher DHE:RSA:ECDHE ok:?openssl s_client -host servername -port 443 -cipher RSA:ECDHE ok:?openssl s_client -host servername -port 443 -cipher DHE:ECDHE fails:?openssl s_client -host servername -port 443 -cipher DHE:ECDHE:RSA You'd better contact your vendor to fix it. The fact that it works with some implementations seems to be incidental. regards, Nikos
