After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 795985 - GZlibCompressor over GSocketConnection sends extra bytes on close
GZlibCompressor over GSocketConnection sends extra bytes on close
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gio
2.50.x
Other Linux
: High normal
: 2.58
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2018-05-09 17:36 UTC by albrecht.dress
Modified: 2018-05-24 20:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test case, containing the C client, the python server, and a pcap with the erroneous tcp packet. (2.74 KB, application/zip)
2018-05-09 17:36 UTC, albrecht.dress
Details

Description albrecht.dress 2018-05-09 17:36:31 UTC
Created attachment 371864 [details]
test case, containing the C client, the python server, and a pcap with the erroneous tcp packet.

Sending data through a GZlibCompressor (format G_ZLIB_COMPRESSOR_FORMAT_RAW) on top of a GSocketConnection client tcp connection will send an extra tcp packet containing a 0x03 0x00 payload when the connections are finalised.  As the remote server does not expect this, it will send a RST tcp packet.  In turn, this may trigger warnings in an IDS (like snort).

As example, I attach a client application and a trivial (Python) server.  The client sends a command to enable compression, and then the (compressed) command to terminate the connection to the server.  This is basically what the IMAP COMPRESS Extension (RFC 4978) does.

When the test application is built with “#define SIM_ERROR 1”, the compressed GOutputStream and the GZlibCompressor are unref'ed before the other components, and the application sends the erroneous extra bytes (see pcap file).

If it is built with “#define SIM_ERROR 0”, i. e. when the compressed GOutputStream and the GZlibCompressor are unref'ed after all other components, the error does not occur.

However, if the connection is TLS encrypted (the typical use case for IMAP), i. e. the “stacking” looks like

GSocketClient
  +-- GSocketConnection
        +-- GIOStream obtained from g_tls_client_connection_new()
              +-- GOutputStream g_converter_output_stream_new(GZlibCompressor)

unref'ing the compressed GOutputStream and the GZlibCompressor after the TLS connection will trigger a

GLib-Net-CRITICAL **: g_tls_output_stream_gnutls_write: assertion 'conn != NULL' failed

So I have the choice to either suppress the erroneous extra packet, at the cost of the GLib-Net-CRITICAL, or to have no warnings from GLib, but the erroneous tcp packet plus the unwanted RST packet.

The bug is reproducible on Ubuntu 16.04 LTS (gio version ) and Debian Stretch (), both 64-bit systems.
Comment 1 albrecht.dress 2018-05-09 17:38:37 UTC
Ooops, forgot the GIO versions - it's 2.48.2 on Ubuntu 16.04, and 2.50.3 on Stretch.
Comment 2 Philip Withnall 2018-05-18 10:46:04 UTC
(In reply to albrecht.dress from comment #1)
> Ooops, forgot the GIO versions - it's 2.48.2 on Ubuntu 16.04, and 2.50.3 on
> Stretch.

Those versions are quite old. Would you be able to re-test on GLib 2.56 or git master? Particularly, make sure that your glib-networking version is up to date, as there have been quite a few changes to how the GnuTLS implementation works in version 2.56.
Comment 3 albrecht.dress 2018-05-20 14:24:06 UTC
I repeated the test on Ubuntu 18.04 LTS which comes with

albrecht@deneb:~/Work/libgsmtp/test$ pkg-config --modversion glib-2.0 gio-2.0
2.56.1
2.56.1

and *both* issues are still present:
- the underlying bug which sends the extra two bytes when GZlibCompressor is finalised and
- the g_tls_output_stream_gnutls_write critical when I unref the compressor and the output stream after the TLS connection.
Comment 4 GNOME Infrastructure Team 2018-05-24 20:31:52 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1375.