www.cendio.com
Bug 4993 - tlstunnel doesn't use the GnuTLS API properly
: tlstunnel doesn't use the GnuTLS API properly
Status: CLOSED FIXED
: ThinLinc
Misc
: trunk
: PC Unknown
: P2 Normal
: 4.2.0
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2014-02-18 09:57 by
Modified: 2014-04-02 15:49 (History)


Attachments


Note

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


Description From cendio 2014-02-18 09:57:55
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 From cendio 2014-02-18 12:07:02 -------
Another fairly large issue:

 6. The code assumes that send() always writes all the data given.
------- Comment #2 From cendio 2014-02-26 12:34:34 -------
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 From cendio 2014-02-26 14:00:56 -------
(In reply to comment #0)
> 
>  2. Related to 1, gnutls_handshake() needs to be in a loop.
> 

r28492
------- Comment #4 From cendio 2014-02-26 14:11:47 -------
(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 From cendio 2014-02-26 16:30:54 -------
(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 From cendio 2014-02-26 16:37:06 -------
(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 From cendio 2014-02-26 17:02:35 -------
(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 From cendio 2014-02-26 17:04:13 -------
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 From cendio 2014-04-02 14:54:34 -------
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.