Bug 5015 - Browsers cause GnuTLS errors in tlwebaccess
Summary: Browsers cause GnuTLS errors in tlwebaccess
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Web Access (show other bugs)
Version: trunk
Hardware: PC All
: P2 Normal
Target Milestone: 4.14.0
Assignee: Pierre Ossman
URL:
Keywords: nikle_tester, prosaic
Depends on:
Blocks:
 
Reported: 2014-03-06 11:03 CET by Samuel Mannehed
Modified: 2021-09-13 12:15 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:
* The browser abruptly closing the connection should not cause a log message with default settings, no matter where in the connection cycle it happens * With debug logging the above incidents should be properly logged


Attachments

Description Samuel Mannehed cendio 2014-03-06 11:03:50 CET
During login in the HTML5 client on Chrome we get a lot of errors in tlwebaccess.log that looks like this:

2014-03-04 14:32:14 ERROR tlwebaccess[3777]: gnutls_record_recv: The TLS connection was non-properly terminated.

These errors do not occur in Firefox or Safari.

This link indicates that this is an peculiarity with Chrome's TLS:
http://lists.gnutls.org/pipermail/gnutls-help/2013-October/003229.html

Since these errors in the log doesn't seem to have any practical implications maybe we should consider changing them to warnings instead.
Comment 1 Pierre Ossman cendio 2014-03-06 11:18:01 CET
These errors indicate a protocol violation that is intended to protect against FIN attacks. So hiding the log messages would mean hiding such attacks.
Comment 2 Pierre Ossman cendio 2020-07-06 10:08:17 CEST
We've also gotten this extra line since we added error handling for gnutls_bye():

> 2020-07-06 10:01:32 ERROR tlwebaccess[2897]: [::ffff:10.47.255.8] gnutls_bye: The specified session has been invalidated for some reason.

Firefox also seems to do this sometimes, but very early so we get an error already in the handshake:

> 2020-07-06 09:54:16 ERROR tlwebaccess[2246]: [::ffff:10.47.1.240] gnutls_handshake: Error in the push function.
Comment 5 Pierre Ossman cendio 2021-03-19 08:46:08 CET
Similarly, if they drop the connection even before a request handler has been spawned, we get:

> 2021-03-17 22:51:50 ERROR tlwebaccess[3837]: [] getpeername: Transport endpoint is not connected
Comment 7 Samuel Mannehed cendio 2021-08-20 09:40:21 CEST
Since most major browsers behave like this now-a-days, it's probably time we move this logging to DEBUG.
Comment 8 Pierre Ossman cendio 2021-09-02 15:40:12 CEST
I'm having trouble reproducing this reliably. I'm getting some "The TLS connection was non-properly terminated." when using Chrome on Android, but I'm not able to systematically get handshake or push/pull errors.

It looks like I'll have to code this and hope for the best.
Comment 12 Pierre Ossman cendio 2021-09-03 11:09:50 CEST
Code written to handle the known cases. Unfortunately I'm only able to reproduce one of them:

> 2021-09-03 09:06:16 DEBUG tlwebaccess[354656]: [::ffff:10.47.1.240] gnutls_record_recv: The TLS connection was non-properly terminated.

Which now works properly as it is on a debug level. There is also no longer a line from gnutls_bye() complaining about an invalid session.

Tested on Ubuntu 20.04.
Comment 13 Niko Lehto cendio 2021-09-13 12:15:45 CEST
I tested server (build 2271) with the changes on Fedora 33.
The browsers I used were:
- Firefox 90
- Chromium 91

I could reproduce following errors on 4.13.0:
- "The TLS connection was non-properly terminated.."
  I Could reproduce this on both Firefox and Chromium.

- "The specified session has been invalidated for some reason"
  I could Reproduce this only on Chromium.

After testing the build containing the fix I could not see the second error and the first one (non-properly terminated) is written in the log only if debug is enabled.

Note You need to log in before you can comment on or make changes to this bug.