- Mark as New
- Bookmark
- Subscribe
- Permalink
- Email to a Friend
- Report Inappropriate Content
TLS 1.0 - TCP RST received instead of "Server Hello" with supported SSL
I never received the TLS 1.0 memo so I was surprised today. However, I'm getting a socket error with "connection reset by peer" which baffled me. Looking at a packet capture I took of the request:
$ tshark -r pycap.pcap -Y 'not tcp.port == 2223 and ip.addr == 23.60.133.171' ... 7312 6.541210 192.168.8.63 -> 23.60.133.171 TCP 78 51058 → 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=256 TSval=94165713 TSecr=0 SACK_PERM=1 7314 6.553873 23.60.133.171 -> 192.168.8.63 TCP 74 443 → 51058 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=3924735112 TSecr=94165713 WS=32 7315 6.554012 192.168.8.63 -> 23.60.133.171 TCP 66 51058 → 443 [ACK] Seq=1 Ack=1 Win=263424 Len=0 TSval=94165725 TSecr=3924735112 7316 6.560440 192.168.8.63 -> 23.60.133.171 SSL 140 Client Hello 7318 6.565805 23.60.133.171 -> 192.168.8.63 TCP 74 [TCP Out-Of-Order] 443 → 51058 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=3924735125 TSecr=94165713 WS=32 7320 6.565974 192.168.8.63 -> 23.60.133.171 TCP 66 [TCP Dup ACK 7315#1] 51058 → 443 [ACK] Seq=75 Ack=1 Win=263424 Len=0 TSval=94165736 TSecr=3924735112 7321 6.572825 23.60.133.171 -> 192.168.8.63 TCP 66 443 → 51058 [ACK] Seq=1 Ack=75 Win=28960 Len=0 TSval=3924735132 TSecr=94165731 7322 6.572992 23.60.133.171 -> 192.168.8.63 TCP 66 443 → 51058 [RST, ACK] Seq=1 Ack=75 Win=28960 Len=0 TSval=3924735132 TSecr=94165731 7323 6.578411 23.60.133.171 -> 192.168.8.63 TCP 60 443 → 51058 [RST] Seq=1 Win=0 Len=0
$ tshark -r pycap.pcap -Y 'frame.number == 7316' -O ssl Frame 7316: 140 bytes on wire (1120 bits), 140 bytes captured (1120 bits) Ethernet II, Src: Apple_c7:3e:a5 (ac:bc:32:c7:3e:a5), Dst: Claviste_13:ea:58 (40:84:93:13:ea:58) Internet Protocol Version 4, Src: 192.168.8.63, Dst: 23.60.133.171 Transmission Control Protocol, Src Port: 51058 (51058), Dst Port: 443 (443), Seq: 1, Ack: 1, Len: 74 Secure Sockets Layer SSL Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 69 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 65 Version: TLS 1.0 (0x0301) Random GMT Unix Time: Oct 17, 2016 09:53:48.000000000 CDT Random Bytes: 8cd464675eeae1655152abf590a873be5c3ef9c36a386678... Session ID Length: 0 Cipher Suites Length: 20 Cipher Suites (10 suites) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 4 Extension: SessionTicket TLS Type: SessionTicket TLS (0x0023) Length: 0 Data (0 bytes)
I should have gotten a Server Hello response, the connection should *not* have been terminated like that.
The problem I'm now facing is that nearly every SOAP client in Python relies on the suds module which has been dead for a long time and the REST API is next to useless for listing records or issuing queries. That puts my project in a very dire place when I need to generate weekly reports but I can no longer do that.
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Email to a Friend
- Report Inappropriate Content
Re: TLS 1.0 - TCP RST received instead of "Server Hello" with supported SSL
There's already some active discussion in our Community forum on this issue including commentary on Python support for TLS 1.1 and higher
From what I understand of the conenction reset error is it happens as a result of the transport layer when the two sides cannot agree upon a common SSL version supported by both sides (in this case TLS 1.1 or 1.2) so the connection is RST. It's been my experience that the actual error received by the end user varries somewhat on the code producting it, with the most common error being something akin to "handshake error"
If you need additional options, please DM me directly.
If you found my answer helpful, please give me a kudo ↑
Help others find answers faster by accepting my post as a solution √
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Email to a Friend
- Report Inappropriate Content
Re: TLS 1.0 - TCP RST received instead of "Server Hello" with supported SSL
Thank you for the response.
> There's already some active discussion in our Community forum on this issue including commentary on Python support for TLS 1.1 and higher
Yes, Python does support TLS 1.1 and better BUT the problem is that the suds module is old and is using urllib2 without giving an interface to allow the user to select a higher SSL method. Using urllib3, one can create a request and pass in the context=ssl.SSLContext(ssl.PROTOCOL_SSLv23) (after importing 'ssl' of course).
But with suds not being maintained nor updated in a number of years, one would need to re-write a Zuora client that uses a different SOAP client like Zeep.
However, it would be really really really handy to simply use the REST interface but that has 10%, or less, of the same functionality offered by the SOAP API.
> It's been my experience that the actual error received by the end user varries somewhat on the code producting it, with the most common error being something akin to "handshake error"
While I understand this, that is not applicable in this instance. I showed you that there is no lack of agreement in the SSL handshake, I showed you that the connection is being reset. The error I received about the "connection reset by peer" is correct because the peer terminated the connection without any attempt at a negotiation.