TLS 1.0 - TCP RST received instead of "Server Hello" with supported SSL

[AlmightyOatmeal]

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.

[scottb]

Hi @AlmightyOatmeal

There's already some active discussion in our Community forum on this issue including commentary on Python support for TLS 1.1 and higher

http://community.zuora.com/t5/Zuora-Announcements/Action-Required-Zuora-is-Disabling-TLS-1-0/ba-p/21...

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.

[AlmightyOatmeal]

@scottb,

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.