View Ticket
Bounty program for improvements to Tcl and certain Tcl packages.
Ticket Hash: 2c7b7487966f65976f46c44fe7c4b5aafd93d9ae
Title: Control TLS socket server errors
Status: Open Type: Feature Request
Severity: Minor Priority: Immediate
Subsystem: Resolution: Open
Last Modified: 2021-05-12 10:12:24
Version Found In: trunk
User Comments:
oehhar added on 2020-09-28 15:26:46:
Currently, a failed TLS negociation for a server socket calles bgerror.

I would appreciate, if there would be an option to pass a command prefix to be called in case of an error:

::tcltls::tls_socket -errorcmd [namespace code TLSError]

More information and proposal may be seen in the linked TWAPI ticket:


Thank you,

aspect added on 2021-03-02 05:34:06:
This was discussed on the chat yesterday.  Errors in negotiation can be received 
by [tls::handshake], but a bgerror is still produced.  This short example 

package require tls

tls::init -cadir /etc/ssl/certs -require true -ssl2 0 -ssl3 0 -tls1 0 -tls1.1 0

proc bgerror {err} {
    puts "bgerror: $err"

proc do_connect {} {
    set chan [tls::socket 9999]

    # ensure handshake completes
    try {
        while {![tls::handshake $chan]} {puts handshake}
    } on error {err opts} {
        puts "handshake error: $err"
        return false

    return true

puts "synchronous code done"


handshake error: handshake failed: certificate verify failed
synchronous code done
bgerror: SSL channel "sock556449741e30": error: certificate verify failed

Note that without the call to tls::handshake, the same error will be produced 
on first attempt to read or write the socket.

There are calls to Tcl_BackgroundError() in both Tls_Error() and
VerifyCallback().  The Tls_Error() invocations all come through stacked channel 
machinery, so it *may* be possible to instead pass the error back to Tcl.  Note 
the twapi ticket says this isn't an option there, but refers to reflected 
channels.  I'm not sure if transchans will propagate errors from callbacks
VerifyCallback() is called by openssl so probably not so simple.

If extra plumbing is needed, one suggestion was to use a hash table keyed by 
the channel ID to mark the presence of a synchronous operation that can return 
the error.  This may need mutex protection.

Another question when looking at the code:  it seems like tcltls requires/assumes 
that the tls channel is the top of a channel stack.  I'm not sure this is 
correct, since it might make sense to push another transform on top of tls.  It 
may be worth investigating this.

tombert added on 2021-05-12 10:12:24:

I can confirm. The BGERROR messages also appear when running the original test examples simpleClient.tcl and simpleServer.tcl.