3
Posts
1
Kudos
0
Solutions
Happy Business Starts Here
10-17-2016
02:02 PM
1 Kudo
A NOTE TO PYTHON DEVELOPERS All of the Zuora Python libraries I've seen, that use the SOAP API, are based on a single module: 'suds'. This module has been dead for almost 7 years and it relies on urllib2 but the suds developers never thought to build in a way for you to specify what SSL version you want to use. For example, in Python 2.7.9+, you can do something like: import ssl import urllib2
context = ssl . SSLContext ( ssl . ssl.PROTOCOL_SSLv23 )
urllib2 . urlopen ( 'https://example.com' , context = context ).close() Doing something like the above would require modification of the suds module which looks like is my only option until the REST API becomes useful. Python 2.7.8 and earlier is more complicated as you would have to ssl.wrap_socket() but I won't go into details there as you probably should have upgraded by now anyway. For more information on the SSL implimentation of Python, please visit https://docs.python.org/2/library/ssl.html#security-considerations
... View more
10-17-2016
12:51 PM
@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.
... View more
10-17-2016
11:32 AM
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.
... View more
