flightaware/Tcl-bounties

Intent to implement improvements for TclTLS

Closed this issue · 17 comments

I'm totally going to work on improvements for TclTLS. I have not started yet. I would like to add support for NSS, since in my experience it has been generally superior to OpenSSL/LibreSSL.

In particular, we have experienced reliability problems with the current TclTLS package hanging during the secure connection negotiation. Since the command does not return control back to Tcl when this occurs, there is no ability to catch this problem other than using a SIGALRM via "alarm" in TclX to terminate the entire process. We've seen this problem with ::http::geturl using a registered https handler, as well as when calling tls::socket -async directly.

I've started by converting it to Fossil and importing all my existing patches to Tcl TLS:

https://chiselapp.com/user/rkeene/repository/tcltls/timeline

@bovine Was that instability with a socket in blocking or non-blocking mode?

This is mostly complete. I've taken over maintainership of TclTLS and moved its hosting to https://tcltls.rkeene.org/ . I have not migrated the bug database yet. Most of the problems should be resolved -- except that it will still use 100% of CPU during protocol negotiation failure with OpenSSL 1.1.0+ (libressl and older versions of OpenSSL are fine, however). This should be resolved soon and TclTLS 1.7.4 should be released with all the things requested (and more) resolved.

With the release of TclTLS 1.7.9 I believe I have completed this.

Requirements:

  • support all TLS versions: SSLv2, SSLv3, TLSv1, TLSv1.1, and TLSv1.2 are detected (SSLv2 and SSLv3 now default to disabled, while TLSv1, TLSv1.1, and TLSv1.2 default to enabled)
  • fix hangs in protocol negotiation: The protocol negotiation is rewritten to avoid hangs in non-blocking sockets -- blocking sockets can still block, of course, but aside from the socket blocking data should flow
  • fix background errors to provide an error message: The only times Tcl_BackgroundError() are called now are immediately following a failed Tcl_EvalObjEx() or a Tcl_SetResult().
  • test and get it working with LibreSSL -- drop SSLv2, SSLv3, etc: It works with LibreSSL (and OpenSSL 1.1.0)
  • plus light maintenance for a year: I'm now the maintainer of this extension, probably for more than a year :-)

Would it be too objectionable to suggest that the official repository be a neutral provider? Perhaps core.tcl.tk (preferred), or chiselapp.com?

Sure -- but I run both of those systems as well... (core.tcl.tk is a VM on the same box as rkeene.org/chiselapp.com)

core.tcl.tk would still be preferable since it would give the impression to users of a more officially supported package, particularly for something that is as important as security/encryption.

It's now at https://core.tcl.tk/tcltls/ -- getting a link added to the home page now

The link is up on core.tcl.tk now and TclTLS 1.7.10 is out to address an I/O issue in 1.7.9 when not using "fast path". "Fast path" is a new optional mode of TclTLS that passes the socket file descriptor is passed to the SSL library for Tcl TCP channels rather than passing it back to TclTLS to write to the socket. It's a compile-time option that is currently disabled by default.

1.7.11 has been released with an "-autoservername true" option to make it useful for http::register handler for HTTPS without a wrapper proc (and the wiki updated)

Is there anything else that needs to be done for this ?

We accept that tcltls 1.7.11 has met our bounty conditions and are now arranging payment.

Closing this issue ! Thanks for the program !

FreeBSD port for tcltls is being updated to 1.7.11 here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216174

It would be good to try to proactively reach out to some of the Linux distros and ensure they are aware of the new hosting location and version release.