[gnutls-devel] GnuTLS | gnutls_record_send() fails with GNUTLS_E_INVALID_REQUEST (#823)

[Development of GNU's TLS library]

Michael Catanzaro commented:


> Has this been reported to the software that breaks?

Nope... that'd be glib-networking, you know us by now. :) I just noticed this issue report now by chance.

I agree it probably should have been reported to glib-networking first, especially since the error GNUTLS_E_INVALID_REQUEST indicates API misuse, but in this case it might be good to start here anyway, since I don't see the problem and wouldn't know what to do with it if it was on our issue tracker. :P

> The log simply indicates the call of `gnutls_record_send()` to an already closed session.

So: how do you know the session is closed? I don't see any evidence of this in the logs? If that's happening, I suspect the peer has closed the session and the client hasn't noticed (since GTlsConnection has no API to indicate when the peer has closed the session; attempts to write will just fail). Does that sound plausible? In which case, maybe glib-networking should massage the error a bit so that a nicer error gets presented to the application. (The request may be invalid at the GnuTLS level, but it's not at the GTlsConnection level.)

In any case, the real problem is that the session is closed during the handshake. If github.com is indeed closing the connection during what should be a routine handshake, we should try to figure out why.

What's surprising to me is that the good log uses TLS 1.2 but the bad log uses TLS 1.3, which is pretty suspicious. It seems weird that github.com ever negotiates TLS 1.2 when it usually offers 1.3.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/823#note_221380838
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/20190924/30a1dd6b/attachment.html>