using 3.5.1, latest is 3.5.4. As far as I can tell from http://www.gnutls.org/security.html, there are no critical bugs affecting us.
Updating to 3.5.6 which are a bugfix release just like 3.5.5.
tlwebaccess and tlwebadm work fine with both Firefox and Chrome. The generated GnuTLS appendix in the TAG also look fine. > The connection to this site is encrypted and authenticated using > a strong protocol (TLS 1.2), a strong key exchange (ECDHE_RSA), > and a strong cipher (AES_128_GCM).
I can't connect to tlwebadm/tlwebaccess in nightly builds. tlstunnel responds with a "TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Unexpected Message)" to a ClientHello msg. Browsers report this as: > This site can’t be reached > localhost unexpectedly closed the connection. > ERR_CONNECTION_CLOSED
Urgh. This was a fun one. This is caused by a lovely quirk in libc. It has stubs for most pthread functions that just return success. If the real libpthread is pulled in then those stubs are replaced by the real thing. This can easily go south if this happens after a while, rather than when the process is started. A mutex you initialised with the stub routines is a poor fit for the real pthread_mutex_lock(). And this is precisely what happened here. pthread_mutex_lock() returned an error on the bogus mutex, and GnuTLS called abort() when it couldn't grab the mutex. The fix is to always link to libpthread when using pthread functions. Upstream has also gotten this wrong, so I filed a bug there: https://gitlab.com/gnutls/gnutls/issues/154 This issue is old and should theoretically be happening on most versions of ThinLinc. However we seem to be getting lucky and getting zeroed out memory from malloc() when initialising these early mutexes. And as it happens, glibc's implementation of pthread_mutex_init() also results in a zeroed out structure. So these mutexes work despite only the stubs being loaded. The new version of GnuTLS is causing some reordering of calls, and we're not getting clean memory from malloc() anymore. Hence things are now crashing instead.
Should be all done now. The new tests found three components for which we didn't properly link to libpthread; tlstunnel, mesa, and opensc. Whereof tlstunnel was the only one where we observed an actual problem (comment #4), however all these three components have been fixed now. The tests pass and I have verified that tlwebaccess and tlwebadm works with build 5310.
The tests for linkage of pthread added in commit r31918, does no run with success at nightly build.
(In reply to comment #4) > I can't connect to tlwebadm/tlwebaccess in nightly builds. > > tlstunnel responds with a "TLSv1.2 Record Layer: Alert (Level: Fatal, > Description: Unexpected Message)" to a ClientHello msg. > > Browsers report this as: > > This site can’t be reached > > localhost unexpectedly closed the connection. > > ERR_CONNECTION_CLOSED Verified that tlwebadm and tlwebacces works as expected using ThinLinc build 5312
The new test for correct linkage and the fixes for few comoponents looks good. Closing.
