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.
Another fairly large issue: 6. The code assumes that send() always writes all the data given.
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.
(In reply to comment #0) > > 2. Related to 1, gnutls_handshake() needs to be in a loop. > r28492
(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.
(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.
(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.
(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.
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).
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.
