[gnutls-devel] GnuTLS | Nonblocking Sockets and GNUTLS_E_AGAIN (#1251)

[Read-only notification of GnuTLS library development activities]

Pierre Ossman (Work account) commented:


I agree and we've been bitten by this in TigerVNC as well. A brief glance of the GnuTLS code suggests this can happen in a lot of different scenarios, so fixing the implementation seems to be non-trivial.

A more reasonable short term goal is to update the documentation to warn about this. Right now the documentation implies that you will only get `GNUTLS_E_AGAIN` if the underlying pull function sets `errno` to `EAGAIN`, which is obviously not true.

In our case we got this problem when interoperating with x11vnc, using OpenSSL. The issue seems to be reception of a session ticket that contains no data. Debug output from GnuTLS for this:

```
gnutls[10]: READ: Got 5 bytes from 0x2765530
gnutls[10]: READ: read 5 bytes from 0x2765530
gnutls[10]: RB: Have 0 bytes into buffer. Adding 5 bytes.
gnutls[10]: RB: Requested 5 bytes
gnutls[5]: REC[0x2756ee0]: SSL 3.3 Application Data packet received. Epoch 2, length: 250
gnutls[5]: REC[0x2756ee0]: Expected Packet Application Data(23)
gnutls[5]: REC[0x2756ee0]: Received Packet Application Data(23) with length: 250
gnutls[10]: READ: Got 250 bytes from 0x2765530
gnutls[10]: READ: read 250 bytes from 0x2765530
gnutls[10]: RB: Have 5 bytes into buffer. Adding 250 bytes.
gnutls[10]: RB: Requested 255 bytes
gnutls[5]: REC[0x2756ee0]: Decrypted Packet[1] Handshake(22) with length: 233
gnutls[3]: ASSERT: buffers.c[get_last_packet]:1169
gnutls[4]: HSK[0x2756ee0]: NEW SESSION TICKET (4) was received. Length 229[229], frag offset 0, frag length: 229, sequence: 0
gnutls[3]: ASSERT: buffers.c[_gnutls_handshake_io_recv_int]:1429
gnutls[4]: HSK[0x2756ee0]: parsing session ticket message
gnutls[3]: ASSERT: record.c[_gnutls_recv_in_buffers]:1577
gnutls[3]: ASSERT: record.c[_gnutls_recv_int]:1775
```

At this point we go back to doing `select()` on the socket, which never completes as we've already read the data and we have more records in our buffer ready to be pulled by GnuTLS.

Downstream bug report, with references to workaround:

https://github.com/TigerVNC/tigervnc/issues/1450

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1251#note_902836387
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/20220406/bd745285/attachment-0001.html>