SSL connection failure: Error in the pull function.
Nikos Mavrogiannopoulos
nmav at gnutls.org
Fri Sep 8 13:05:51 PDT 2017
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
More information about the openconnect-devel
mailing list