#189 Control TLS socket server errors

[Harald Oehlmann]

Dear Ashok,

thank you for great TWAPI ! May I ask for an enhancement ?

I would appreciate, if I could control background errors thrown in TLS negociation in a TLS server.

Use-case:
Server with twapi tls socket like described in section "Use TWAPI for TLS" of
[https://wiki.tcl-lang.org/page/Embedded+TCL+Web+Server].

When the caller has no tls, just a socket, a bg error is thrown as follows:

2 BGError (::main::bgerror {Unexpected EOF during TLS negotiation (NEGOTIATING)})
> Unexpected EOF during TLS negotiation (NEGOTIATING)
>     while executing
> "throw {TWAPI TLS NEGOTIATE EOF} "Unexpected EOF during TLS negotiation (NEGOTIATING)""
>     (procedure "_negotiate2" line 16)
>     invoked from within
> "_negotiate2 $chan"
>     (procedure "rethrow" line 2)
>     invoked from within
> "rethrow"
>     invoked from within
> "trap {
>         _negotiate2 $chan
>     } onerror {} {
>         variable _channels
>         if {[info exists _channels($chan)]} {
>             if {[dict get..."
>     (procedure "_negotiate" line 3)
>     invoked from within
> "_negotiate $chan"
>     (procedure "twapi::tls::record_background_error" line 9)
>     invoked from within
> "twapi::tls::record_background_error $result $ropts"
>     (procedure "_negotiate_from_handler" line 22)
>     invoked from within
> "_negotiate_from_handler $chan"
>     (procedure "::twapi::tls::_so_read_handler" line 7)
>     invoked from within
> "::twapi::tls::_so_read_handler rc1"
> --Traceback--
> INNER:returnImm {Unexpected EOF during TLS negotiation (NEGOTIATING)} {-errorcode {TWAPI TLS NEGOTIATE EOF}}
> CALL:_negotiate2 rc1
> CALL:_negotiate rc1
> CALL:_negotiate rc1
> CALL:_negotiate rc1
> CALL:_negotiate_from_handler rc1
> CALL:_negotiate_from_handler rc1
> CALL:::twapi::tls::_so_read_handler rc1

In my case, the caller gets a message box "Program error: ..." which is not desired on an error not controlable by the program.

In consequence, I would be glad to separate those errors from other real program errors and attribute them to the server socket.

One possibility is to check error code for "TWAPI TLS".
I found 2 relevant errors issued by the source code:

• TWAPI TLS VERIFYFAIL
• TWAPI TLS NEGOTIATE EOF

Those could be checked. But I suppose, if there are channel errors, they are also thrown on this way.

I would appreciate an option to give a command prefix to the "::twapi::tls_socket" command which is called instead of bg_error.
E.G.
::twapi::tls_socket -errorcmd [namespace code TLSError]

P.S.: the same issue applies to the tcltls package...

Thank you,
Harald

[Anonymous]

It is not entirely clear to me how that would work. The twapi tls is implemented as a reflected channel whose commands are called from within Tcl's reflected channel subsystem. This expects errors to be reported as raised exceptions which it (meaning Tcl reflected channel core) then handles appropriately (by calling bgerror for instance). There is no way that I can see to pass the -errorcmd option to the Tcl reflected channel system.

/Ashok

[Anonymous]

Ashok,
thank you for looking into this and burning your time.
If it is not possible, it is not possible - point.
I just want to state that the current behaviour is anoying for me and a solution would be wonderful.

May I ask Andreas Kupries, designer of the stacked channel, for his opinion?
I think, it was 1999 at ETCL conference in Hamburg/Germany/Europe where Andreas presented it...

Thank you,
Harald

[Anonymous]

I agree about the annoyance.

Yes, I think it would be a good idea to ask Andreas for suggestions. The question is really how to distinguish background errors generated from the virtual channel implementation from other background errors.

[Anonymous]

Dear Ashok,

as there is aparently no direct solution, would the following be a way to handle:

If a bg error is issued by TWAPI, it is made sure that the errorCode start with the following elements:
TWAPI TLS xx xx

It would be great, if the negociation bg-errors would be clearly distinguishable from others by a pattern. In addition, it would be great, if the socket handle would be included in the error message.

Thank you,
Harald

[Anonymous]

Not easily possible I'm afraid. Where twapi itself generates background errors, it already uses the TWAPI TLS error code format iirc. However, when the error is propagated from a lower level call that it makes whether to the chan interface, the underlying socket or sspi, the same error is propagated up. Changing this would require trapping all calls and on error replacing the error code with TWAPI TLS. That's more surgery than I can take on right now. If you see tls.tcl and sspi.tcl, you'll see it is quite convoluted (and I have no idea how to make it simpler because of the multiple callbacks between the event loop, sspi, the channel system and the underlying socket file event handlers)

[Anonymous]

BTW, to get the socket/channel on which an error occurs, the normal read / write handler should fire on errors. That would be the natural way to know which socket had the error rather than through the error/exception handling mechanisms.

[Harald Oehlmann]

Thank you for all your efforts.
I catch now the TWAPI calls.

Normally, I am not to much interested in those errors. If a negociation fails, it is like there is nothing to do. It is just ignored. At maximum, it is logged.

Thank you,
Harald