2021-10-11
| ||
04:44 | • Ticket [ad8604520e] Server accept invoked before handshake completed status still Open with 5 other changes artifact: ad00412d8a user: anonymous | |
2021-10-10
| ||
16:46 | • New ticket [ad8604520e]. artifact: e19f4fb8d0 user: anonymous | |
Ticket Hash: | ad8604520ea45d39112209469c9d6cfa3456fdee | |||
Title: | Server accept invoked before handshake completed | |||
Status: | Open | Type: | Code Defect | |
Severity: | Important | Priority: | Immediate | |
Subsystem: | Resolution: | Open | ||
Last Modified: | 2021-10-11 04:44:50 | |||
Version Found In: | 1.7.22 | |||
User Comments: | ||||
anonymous added on 2021-10-10 16:46:37:
Server code: proc accept {so args} { puts $so $args; flush $so; close $so } socket -server accept 10001;# Plain old Tcl socket tls::socket -server accept 10002;# TLS socket On client side: Plain old sockets work % set so [socket localhost 10001]; gets $so ::1 58824 TLS sockets get an error: % set so [tls::socket localhost 10002]; gets $so error reading "sock0000019561DCF4C0": software caused connection abort errorInfo shows: SSL channel "sock0000019561DCF4C0": error: sslv3 alert handshake failure Note that if the client initiates data flow, everything works fine. However, I do not believe this is a requirement for TLS. Client side has to initiate negotiation but the data flow may begin from either end. My feeling is that the server side accept procedure should not be called until TLS negotiation is done AND client should initiate handshake without waiting for application to push user data. /Ashok anonymous added on 2021-10-11 04:44:50: Forgot to mention - tls 1.7.22, Tcl 8.6.11, Windows |