Bug 4993 - tlstunnel doesn't use the GnuTLS API properly
Summary: tlstunnel doesn't use the GnuTLS API properly
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Misc (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.2.0
Assignee: Pierre Ossman
URL:
Keywords: hean01_tester, prosaic
Depends on:
Blocks:
 
Reported: 2014-02-18 09:57 CET by Pierre Ossman
Modified: 2014-04-02 15:49 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:


Attachments

Description Pierre Ossman cendio 2014-02-18 09:57:55 CET
There are a few things that tlstunnel doesn't do correctly with regards to the GnuTLS API:

 1. Most GnuTLS calls can return non-fatal "errors". These should merely be logged and the system should continue.

 2. Related to 1, gnutls_handshake() needs to be in a loop.

 3. Read/write can return with a code indicating a renegotiation is needed.

 4. Asynchronous handling with GnuTLS is a bit more difficult than regular sockets as there can be multiple reads/writes for each TLS layer read/write. There are a bunch of details, but this page describes most of it:

http://www.gnutls.org/manual/html_node/Asynchronous-operation.html#Asynchronous-operation

    Currently we could end up hanging on reading data on the TCP side, and fail to read data from the Unix socket side.

 5. (minor) we have a few global variables and functions that are only used in one place. Could probably merge all of it.
Comment 1 Pierre Ossman cendio 2014-02-18 12:07:02 CET
Another fairly large issue:

 6. The code assumes that send() always writes all the data given.
Comment 2 Pierre Ossman cendio 2014-02-26 12:34:34 CET
I'm going to have to fix this now. I'm consistently seeing truncated data because of the poor handling and it is screwing up things left and right.
Comment 3 Pierre Ossman cendio 2014-02-26 14:00:56 CET
(In reply to comment #0)
> 
>  2. Related to 1, gnutls_handshake() needs to be in a loop.
> 

r28492
Comment 4 Pierre Ossman cendio 2014-02-26 14:11:47 CET
(In reply to comment #0)
>  4. Asynchronous handling with GnuTLS is a bit more difficult than regular
> sockets as there can be multiple reads/writes for each TLS layer read/write.
> There are a bunch of details, but this page describes most of it:
> 
> http://www.gnutls.org/manual/html_node/Asynchronous-operation.html#Asynchronous-operation
> 
>     Currently we could end up hanging on reading data on the TCP side, and fail
> to read data from the Unix socket side.
> 
>  6. The code assumes that send() always writes all the data given.

r28526.
Comment 5 Pierre Ossman cendio 2014-02-26 16:30:54 CET
(In reply to comment #0)
> 
>  3. Read/write can return with a code indicating a renegotiation is needed.
> 

Seems to be just read. Fixed in r28528.
Comment 6 Pierre Ossman cendio 2014-02-26 16:37:06 CET
(In reply to comment #0)
> 
>  5. (minor) we have a few global variables and functions that are only used in
> one place. Could probably merge all of it.

r28529.
Comment 7 Pierre Ossman cendio 2014-02-26 17:02:35 CET
(In reply to comment #0)
>  1. Most GnuTLS calls can return non-fatal "errors". These should merely be
> logged and the system should continue.

r28530. It's not clear how to treat these non-fatal errors though. Are they warnings, or more of debug stuff? I've logged them at an INFO level for now. We'll see if it's a problem.
Comment 8 Pierre Ossman cendio 2014-02-26 17:04:13 CET
Bug all done. Tester should verify that everything works. Known symptoms before the fix was truncated output, which could be seen in broken images and lower portions of large pages missing (like some of the webaccess javascript).
Comment 9 Henrik Andersson cendio 2014-04-02 14:54:34 CEST
I wasn't able to create a test case so i tested a lot of browser against linux / solaris server, both tlwebadm and tlwebaccess.

Midori, lynx, IE8, IE11, Safari, Firefox works as expected against solaris and linux services with no trace of TLS errors in the log file.

IE10 works as expected against linux but fails to connect to solaris server, something bails out early in handshake. Server log shows a "gnutls_handshake: Error in the pull function." corresponding to each connect made.

Chrome works as expected against linux but fails against solaris, it looks like data is not transmitted correctly and that chrome disconnects before all data transmitted. A few refresh to actual load and cache of content will take you steps further to a success. The server log file shows sporadic "gnutls_record_recv: The TLS connection was non-properly terminated." messages and chrome tries to reload until it success.
Those log messages also shows up in a linux server but the client works as expected.

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