Opened 6 years ago

Closed 6 years ago

#4889 defect closed invalid (invalid)

Disable TLS for SSLv3 only server

Reported by: wetherbeei Owned by:
Priority: normal Milestone:
Component: web Keywords:
Cc: Branch:


I have a server that does not correctly support TLSv1 that I can't get twisted to connect to using getPage. I had the same problem trying to use python's default urllib opener, which I fixed by opening with SSLv3 first, then SSLv23 if that failed, but I can't find a way to do that in twisted. As far as I can tell, the startTLS method is hard-coded into any SSL connections, even if SSL.OP_NO_TLSv1 is set on the SSL.Context object.

Specifically, I am trying to access:

The connection is immediately cut:

[Failure instance: Traceback (failure with no frames): <class 'twisted.internet.error.ConnectionDone'>: Connection was closed cleanly. ]

Curl returns:

curl -v
* About to connect() to port 443 (#0)
*   Trying connected
* Connected to ( port 443 (#0)
* Initializing NSS with certpath: /etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -12226
* Error in TLS handshake, trying SSLv3...
> GET /BANPROD1/bwskfcls.P_GetCrse HTTP/1.1
> User-Agent: curl/7.20.1 (x86_64-redhat-linux-gnu) libcurl/7.20.1 NSS/ zlib/1.2.3 libidn/1.16 libssh2/1.2.4
> Host:
> Accept: */*
* Connection died, retrying a fresh connect
* Closing connection #0
* Issue another request to this URL: ''
* About to connect() to port 443 (#0)
*   Trying connected
* Connected to ( port 443 (#0)
* TLS disabled due to previous handshake failure
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using SSL_RSA_WITH_RC4_128_MD5
* Server certificate:
* 	subject:,OU=AITS 20100517-25690,O=University of Illinois,L=Urbana,ST=Illinois,C=US
* 	start date: May 17 00:00:00 2010 GMT
* 	expire date: May 17 23:59:59 2011 GMT
* 	common name:
* 	issuer:,CN=Thawte Premium Server CA,OU=Certification Services Division,O=Thawte Consulting cc,L=Cape Town,ST=Western Cape,C=ZA
> GET /BANPROD1/bwskfcls.P_GetCrse HTTP/1.1
> User-Agent: curl/7.20.1 (x86_64-redhat-linux-gnu) libcurl/7.20.1 NSS/ zlib/1.2.3 libidn/1.16 libssh2/1.2.4
> Host:
> Accept: */*
< HTTP/1.1 302 Found
< Date: Thu, 17 Feb 2011 06:56:53 GMT
< Server: Oracle-Application-Server-10g/ Oracle-HTTP-Server
< Location:
< Connection: close
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=iso-8859-1
<TITLE>302 Found</TITLE>
The document has moved <A HREF="">here</A>.<P>
<ADDRESS>Oracle-Application-Server-10g/ Oracle-HTTP-Server Server at Port 443</ADDRESS>
* Closing connection #0

Change History (5)

comment:1 Changed 6 years ago by wetherbeei

  • Component changed from core to web

comment:2 Changed 6 years ago by exarkun

The SSL method can be controlled using the Context instance returned by the context factory. You can either set the method to SSLv3_METHOD or set the OP_NO_TLSv1 flag you mentioned.

There is some other problem that happens when talking to this server, even after SSLv3 is correctly selected. The connection dies before the handshake completes. It's not clear to me yet how curl manages to talk to it.

comment:3 Changed 6 years ago by exarkun

Actually, the handshake completes, and the server disconnects as soon as the request is sent. ssldump output:

1 7  0.1784 (0.0000)  C>SV3.0(1)  ChangeCipherSpec
1 8  0.1784 (0.0000)  C>SV3.0(64)  Handshake
1 9  0.2219 (0.0435)  S>CV3.0(1)  ChangeCipherSpec
1 10 0.2223 (0.0003)  S>CV3.0(64)  Handshake
1 11 0.2227 (0.0003)  C>SV3.0(24)  application_data
1 12 0.2227 (0.0000)  C>SV3.0(128)  application_data
1 13 0.2633 (0.0406)  S>CV3.0(24)  Alert
1    0.2637 (0.0003)  S>C  TCP FIN
1    0.2639 (0.0001)  C>S  TCP FIN

I can't (easily) see what's in that alert though.

comment:4 Changed 6 years ago by exarkun

Actually, I'm pretty sure it's just a "close alert", which just means the server decided to shutdown the SSL connection, but doesn't provide any additional information as to why.

comment:5 Changed 6 years ago by exarkun

  • Resolution set to invalid
  • Status changed from new to closed

Setting OP_ALL on the context fixes the problem. The remote server has a buggy SSL implementation. OpenSSL can work around the bugs if you set OP_ALL, but not if you don't.

Note: See TracTickets for help on using tickets.