Ubuntu

HTTPS requests fail on sites which immediately close the connection if TLS 1.1 negotiation is attempted, on Ubuntu 12.04

Reported by Pablo Almeida on 2012-03-26
900
This bug affects 188 people
Affects Status Importance Assigned to Milestone
OpenSSL
Confirmed
Unknown
openssl (Debian)
Fix Released
Unknown
openssl (Ubuntu)
Medium
Colin Watson
Precise
Medium
Colin Watson

Bug Description

This week, HTTPS connections from a Python script I wrote started giving me this error:

urllib2.URLError: <urlopen error [Errno 8] _ssl.c:497: EOF occurred in violation of protocol>

This used to work up until some three days ago and still works on other Ubuntu versions, but not in other Python versions on Precise. I was suspecting this was a bug in Python, but a guy on AskUbuntu ( http://askubuntu.com/questions/116020/python-https-requests-urllib2-to-some-sites-fail-on-ubuntu-12-04-without-proxy/116059#116059 ) found out this happens using the openssl command line tool too:

$ openssl s_client -connect www.mediafire.com:443

But succeeds if forcing TLS 1 with the -tls1 argument.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in openssl (Ubuntu):
status: New → Confirmed
Eadz (eadz) wrote :

same

openssl s_client -connect cs3-api.salesforce.com:443 # Fails

write:errno=104
---
no peer certificate available

openssl s_client -tls1 -connect cs3-api.salesforce.com:443 # Succeeds

Yann Klis (strass) wrote :

Same problem with graph.facebook.com...

Kees Cook (kees) wrote :

For anyone using LWP::Protocol::https based Perl tools, TLSv1 can be forced with:

my $thing = whatever->new(
                ssl_opts => { SSL_version => 'TLSv1' },
        );

Another site that fails is paypal:

$ openssl s_client -connect www.paypal.com:443
CONNECTED(00000003)
write:errno=104

vs

$ openssl s_client -tls1 -connect www.paypal.com:443
CONNECTED(00000003)
depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5
...

Kees Cook (kees) wrote :

Other work-arounds:

wget --secure-protocol=TLSv1 ...

curl --tlsv1 ...

Steve Langasek (vorlon) wrote :

This may be the intended behavior, but we should determine for sure.

Changed in openssl (Ubuntu Precise):
assignee: nobody → Colin Watson (cjwatson)
importance: Undecided → High
tags: added: rls-p-tracking

If this is the intended behaviour, it sure will break a lot of programs.

Anyone knows if there's a way to force Python's urllib2.urlopen().read() to
use TLS1?

2012/3/29 Steve Langasek <email address hidden>

> This may be the intended behavior, but we should determine for sure.
>
> ** Changed in: openssl (Ubuntu Precise)
> Importance: Undecided => High
>
> ** Changed in: openssl (Ubuntu Precise)
> Assignee: (unassigned) => Colin Watson (cjwatson)
>
> ** Tags added: rls-p-tracking
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/965371
>
> Title:
> HTTPS requests fail on some sites on Ubuntu 12.04
>
> Status in “openssl” package in Ubuntu:
> Confirmed
> Status in “openssl” source package in Precise:
> Confirmed
>
> Bug description:
> This week, HTTPS connections from a Python script I wrote started
> giving me this error:
>
> urllib2.URLError: <urlopen error [Errno 8] _ssl.c:497: EOF occurred in
> violation of protocol>
>
> This used to work up until some three days ago and still works on
> other Ubuntu versions, but not in other Python versions on Precise. I
> was suspecting this was a bug in Python, but a guy on AskUbuntu (
> http://askubuntu.com/questions/116020/python-https-requests-urllib2
> -to-some-sites-fail-on-ubuntu-12-04-without-proxy/116059#116059 )
> found out this happens using the openssl command line tool too:
>
> $ openssl s_client -connect www.mediafire.com:443
>
> But succeeds if forcing TLS 1 with the -tls1 argument.
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/965371/+subscriptions
>

--
Pablo Almeida
http://www.google.com/profiles/pabloalmeidaff9

Changed in openssl (Debian):
status: Unknown → New

Lamont says in a duplicate "And it works on precise with 1.0.0g-1ubuntu1."

Colin Watson (cjwatson) on 2012-03-30
Changed in openssl (Ubuntu Precise):
milestone: none → ubuntu-12.04
Changed in openssl:
status: Unknown → Confirmed
ryan.smith (rqsmith) wrote :

Until this bug is fixed I thought this hack might be helpful for affected Python users. Not sure what problems this creates but this allowed my scripts to work again. Might be good until a proper fix is implemented.

I changed /usr/lib/python2.6/httplib.py as follows:

1116c1116
< self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file)
---
> self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file, ssl_version=ssl.PROTOCOL_TLSv1)

Colin Watson (cjwatson) wrote :

I've uploaded upstream's suggested workaround for most of the problems here. It isn't complete, and in particular it doesn't deal with the server in the bug description (see the Debian bug for a categorisation of the problems here), which is why I've left this bug open at a lowered importance.

openssl (1.0.1-2ubuntu3) precise; urgency=low

  * Temporarily work around TLS 1.2 failures as suggested by upstream
    (LP #965371):
    - Use client version when deciding whether to send supported signature
      algorithms extension.
    - Experimental workaround to large client hello issue: if
      OPENSSL_NO_TLS1_2_CLIENT is set then TLS v1.2 is disabled for clients
      only.
    - Compile with -DOPENSSL_NO_TLS1_2_CLIENT.
    This fixes most of the reported problems, but does not fix the case of
    servers that reject version numbers they don't support rather than
    trying to negotiate a lower version (e.g. www.mediafire.com).

 -- Colin Watson <email address hidden> Fri, 30 Mar 2012 17:11:45 +0100

Changed in openssl (Ubuntu Precise):
importance: High → Medium
status: Confirmed → Triaged

Hey! After the update that introduced the workaround, my python program
(which uses mediafire) works again, even though the openssl command doesn't
yet.

2012/3/30 Colin Watson <email address hidden>

> I've uploaded upstream's suggested workaround for most of the problems
> here. It isn't complete, and in particular it doesn't deal with the
> server in the bug description (see the Debian bug for a categorisation
> of the problems here), which is why I've left this bug open at a lowered
> importance.
>
> openssl (1.0.1-2ubuntu3) precise; urgency=low
>
> * Temporarily work around TLS 1.2 failures as suggested by upstream
> (LP #965371):
> - Use client version when deciding whether to send supported signature
> algorithms extension.
> - Experimental workaround to large client hello issue: if
> OPENSSL_NO_TLS1_2_CLIENT is set then TLS v1.2 is disabled for clients
> only.
> - Compile with -DOPENSSL_NO_TLS1_2_CLIENT.
> This fixes most of the reported problems, but does not fix the case of
> servers that reject version numbers they don't support rather than
> trying to negotiate a lower version (e.g. www.mediafire.com).
>
> -- Colin Watson <email address hidden> Fri, 30 Mar 2012 17:11:45 +0100
>
> ** Changed in: openssl (Ubuntu Precise)
> Importance: High => Medium
>
> ** Changed in: openssl (Ubuntu Precise)
> Status: Confirmed => Triaged
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/965371
>
> Title:
> HTTPS requests fail on some sites on Ubuntu 12.04
>
> Status in OpenSSL cryptography and SSL/TLS toolkit:
> Confirmed
> Status in “openssl” package in Ubuntu:
> Triaged
> Status in “openssl” source package in Precise:
> Triaged
> Status in “openssl” package in Debian:
> New
>
> Bug description:
> This week, HTTPS connections from a Python script I wrote started
> giving me this error:
>
> urllib2.URLError: <urlopen error [Errno 8] _ssl.c:497: EOF occurred in
> violation of protocol>
>
> This used to work up until some three days ago and still works on
> other Ubuntu versions, but not in other Python versions on Precise. I
> was suspecting this was a bug in Python, but a guy on AskUbuntu (
> http://askubuntu.com/questions/116020/python-https-requests-urllib2
> -to-some-sites-fail-on-ubuntu-12-04-without-proxy/116059#116059 )
> found out this happens using the openssl command line tool too:
>
> $ openssl s_client -connect www.mediafire.com:443
>
> But succeeds if forcing TLS 1 with the -tls1 argument.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openssl/+bug/965371/+subscriptions
>

--
Pablo Almeida
http://www.google.com/profiles/pabloalmeidaff9

Isn't there a better solutution than disabling TLS 1.2 completely in openssl?
I need TLS 1.1 and 1.2 to monitor my servers with icinga... Better force the admins of the broken servers to fix their stuff...

I'm awaiting advice from upstream on something better. See the upstream
bug linked from this one.

Regarding #12
I'ld also suggest, to wait for an upstream solution. The side-effects of non-working SSL are far too big to be ignored or being addressed to the other end of the SSL connection.
One can't argue to a customer running webshops, that "paypal has an invalid implementation of TLS".

Saivann Carignan (oxmosys) wrote :

Enom API servers are also affected, even with the partial fix (1.0.1-2ubuntu4). PHP continues to throws : fsockopen(): SSL: crypto enabling timeout

Colin Watson (cjwatson) wrote :

I've applied some more upstream fixes in openssl 1.0.1-4ubuntu2 in precise-proposed. Could people affected by this bug please report whether it makes things worse, improves them, or leaves them the same, and for which sites? If I hear positive reports and don't hear of regressions then it may be possible to squeeze this into 12.04.

Saivann Carignan (oxmosys) wrote :

I've just tested 1.0.1-4ubuntu2 against Enom API server and paypal using fsockopen / PHP and it just... worked flawlessly!

openssl s_client -connect cs3-api.salesforce.com:443 now works but

openssl s_client -connect www.mediafire.com:443 still doesn't.

Kees Cook (kees) wrote :

Confirmed that paypal works as expected for me again via multiple methods. Thanks!

I tried the 1.0.1-4ubuntu2 release which seems to work as expected!

Maarten Kossen (mpkossen) wrote :

Works for php fsockopen :) Thanks!

Paul Graydon (twirrim) wrote :

That worked for my peculiar case too. Mahalo!

As Pablo commented, still seems to fail on mediafire.com but I'm not certain mediafire's end point is working correctly as it fails in both openssl (1.0.1-4ubuntu3) AND gnutls (3.0.11+really2.12.14-5ubuntu3) :

$ openssl s_client -connect www.mediafire.com:443
CONNECTED(00000003)
140199672272544:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 174 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

$ gnutls-cli www.mediafire.com -p 443

Resolving 'www.mediafire.com'...
Connecting to '205.196.120.8:443'...
*** Fatal error: A TLS packet with unexpected length was received.
*** Handshake has failed
GnuTLS error: A TLS packet with unexpected length was received.

I should point out that it seems to work with the openssl 1.0.0e-2ubuntu4.2 from 11.10, but doesn't with the gnutls 2.10.5-1ubuntu3.1 from 11.10.

André Lopes (zipatei) wrote :

Yesterday, the same happened on Emesene https://github.com/emesene/emesene/issues/1184:

[02:02:16 ERROR e3.common.Collections] [Errno socket error] [Errno 8] ssl.c:504: EOF occurred in violation of protocol
 Traceback (most recent call last):
 File "/home/andre/emesene/emesene/e3/common/Collections.py", line 181, in fetch_metadata
 rq = self.github.get_raw(self.theme, current_ext.files[path])
 File "/home/andre/emesene/emesene/e3/common/Github.py", line 42, in get_raw
 response = urlopen(API_GITHUB_GETRAW % (self._org, repo, sha))
 File "/usr/lib/python2.7/urllib.py", line 86, in urlopen
 return opener.open(url)
 File "/usr/lib/python2.7/urllib.py", line 207, in open
 return getattr(self, name)(url)
 File "/usr/lib/python2.7/urllib.py", line 436, in open_https
 h.endheaders(data)
 File "/usr/lib/python2.7/httplib.py", line 954, in endheaders
 self._send_output(message_body)
 File "/usr/lib/python2.7/httplib.py", line 814, in _send_output
 self.send(msg)
 File "/usr/lib/python2.7/httplib.py", line 776, in send
 self.connect()
 File "/usr/lib/python2.7/httplib.py", line 1161, in connect
 self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file)
 File "/usr/lib/python2.7/ssl.py", line 381, in wrap_socket
 ciphers=ciphers)
 File "/usr/lib/python2.7/ssl.py", line 143, in __init_
 self.do_handshake()
 File "/usr/lib/python2.7/ssl.py", line 305, in do_handshake
 self._sslobj.do_handshake()
 IOError: [Errno socket error] [Errno 8] _ssl.c:504: EOF occurred in violation of protocol

Download full text (3.4 KiB)

I don't know who decides this kind of thing but I believe that, if a
definitive fix doesn't get done, this version of the package should not go
into the final version of Ubuntu, as it will break too many things that
simply work on Oneiric. Or, if released, it should force all connections to
be TLS1 at least for a while.

Again, I don't know who decides this and using which standards, but LTS is
about stability, and not knowing if a connection will work or not is not
what I would call stable.

Em 20 de abril de 2012 10:09, André Lopes <email address hidden>escreveu:

> Yesterday, the same happened on Emesene
> https://github.com/emesene/emesene/issues/1184:
>
> [02:02:16 ERROR e3.common.Collections] [Errno socket error] [Errno 8]
> ssl.c:504: EOF occurred in violation of protocol
> Traceback (most recent call last):
> File "/home/andre/emesene/emesene/e3/common/Collections.py", line 181, in
> fetch_metadata
> rq = self.github.get_raw(self.theme, current_ext.files[path])
> File "/home/andre/emesene/emesene/e3/common/Github.py", line 42, in
> get_raw
> response = urlopen(API_GITHUB_GETRAW % (self._org, repo, sha))
> File "/usr/lib/python2.7/urllib.py", line 86, in urlopen
> return opener.open(url)
> File "/usr/lib/python2.7/urllib.py", line 207, in open
> return getattr(self, name)(url)
> File "/usr/lib/python2.7/urllib.py", line 436, in open_https
> h.endheaders(data)
> File "/usr/lib/python2.7/httplib.py", line 954, in endheaders
> self._send_output(message_body)
> File "/usr/lib/python2.7/httplib.py", line 814, in _send_output
> self.send(msg)
> File "/usr/lib/python2.7/httplib.py", line 776, in send
> self.connect()
> File "/usr/lib/python2.7/httplib.py", line 1161, in connect
> self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file)
> File "/usr/lib/python2.7/ssl.py", line 381, in wrap_socket
> ciphers=ciphers)
> File "/usr/lib/python2.7/ssl.py", line 143, in __init_
> self.do_handshake()
> File "/usr/lib/python2.7/ssl.py", line 305, in do_handshake
> self._sslobj.do_handshake()
> IOError: [Errno socket error] [Errno 8] _ssl.c:504: EOF occurred in
> violation of protocol
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/965371
>
> Title:
> HTTPS requests fail on some sites on Ubuntu 12.04
>
> Status in OpenSSL cryptography and SSL/TLS toolkit:
> Confirmed
> Status in “openssl” package in Ubuntu:
> Triaged
> Status in “openssl” source package in Precise:
> Triaged
> Status in “openssl” package in Debian:
> New
>
> Bug description:
> This week, HTTPS connections from a Python script I wrote started
> giving me this error:
>
> urllib2.URLError: <urlopen error [Errno 8] _ssl.c:497: EOF occurred in
> violation of protocol>
>
> This used to work up until some three days ago and still works on
> other Ubuntu versions, but not in other Python versions on Precise. I
> was suspecting this was a bug in Python, but a guy on AskUbuntu (
> http://askubuntu.com/questions/116020/python-https-requests-urllib2
> -to-some-sites-fail-on-ubuntu-12-04-without-proxy/116059#116059 )
> found out this happens using the openssl command li...

Read more...

I agree with Paulo Almeida.
This shouldn't be at the final release.
I'm having to use the workround of changing the httplib.py but it's not very safe to do so.

Well, it IS on the final release. 12.04 is out and there's no rolling back
versions now. So now we have to hope for a (quick) fix.

2012/4/27 nuk <email address hidden>

> I agree with Paulo Almeida.
> This shouldn't be at the final release.
> I'm having to use the workround of changing the httplib.py but it's not
> very safe to do so.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/965371
>
> Title:
> HTTPS requests fail on some sites on Ubuntu 12.04
>
> Status in OpenSSL cryptography and SSL/TLS toolkit:
> Confirmed
> Status in “openssl” package in Ubuntu:
> Triaged
> Status in “openssl” source package in Precise:
> Triaged
> Status in “openssl” package in Debian:
> New
>
> Bug description:
> This week, HTTPS connections from a Python script I wrote started
> giving me this error:
>
> urllib2.URLError: <urlopen error [Errno 8] _ssl.c:497: EOF occurred in
> violation of protocol>
>
> This used to work up until some three days ago and still works on
> other Ubuntu versions, but not in other Python versions on Precise. I
> was suspecting this was a bug in Python, but a guy on AskUbuntu (
> http://askubuntu.com/questions/116020/python-https-requests-urllib2
> -to-some-sites-fail-on-ubuntu-12-04-without-proxy/116059#116059 )
> found out this happens using the openssl command line tool too:
>
> $ openssl s_client -connect www.mediafire.com:443
>
> But succeeds if forcing TLS 1 with the -tls1 argument.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openssl/+bug/965371/+subscriptions
>

--
Pablo Almeida
http://www.google.com/profiles/pabloalmeidaff9

precise current

gnutls-cli -p 443 info.vsu.ru is working ok.

openssl s_client -connect info.vsu.ru:443 -CApath /etc/ssl/certs
CONNECTED(00000003)
140277691872928:error:14092073:SSL routines:SSL3_GET_SERVER_HELLO:bad packet length:s3_clnt.c:1062:

the fixes from openssl 1.0.1b should go into 12.04 - it looks like otherwise TLS 1.1 will not work...

Changed in openssl (Debian):
status: New → Fix Released
Dave Vree (hdave) wrote :

Looks like this bug could be the cause of Evernote failing to connect:

openssl s_client -connect www.evernote.com:443

Dave Vree (hdave) wrote :

Updated my 12.04 system this morning that included a new libssl. Unfortunately, the update did not fix this problem, at least not for evernote:

openssl s_client -connect www.evernote.com:443

still fails.

I've also just updated to try query a box using python urllib and same error.

<urlopen error [Errno 8] _ssl.c:504: EOF occurred in violation of protocol>

Dave Vree (hdave) wrote :

Upon closer examination of the change log of libssl, the update we all received fixed a different issue and was not intended to fix this issue. The issue that was fixed is here:

https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/986147

Max Bowsher (maxb) on 2012-05-14
summary: - HTTPS requests fail on some sites on Ubuntu 12.04
+ HTTPS requests fail on sites which immediately close the connection if
+ TLS 1.1 negotiation is attempted, on Ubuntu 12.04
Jaakko (jaakko-salonen) wrote :

Any progress on this? The bug is still present in Ubuntu 12.04.

Anyone knows a way to downgrade only openssl without breaking things and
without having to downgrade to 11.10? This is not an option for me,
unfortunely, and I really need this program.

2012/5/27 Jaakko <email address hidden>

> Any progress on this? The bug is still present in Ubuntu 12.04.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/965371
>
> Title:
> HTTPS requests fail on sites which immediately close the connection if
> TLS 1.1 negotiation is attempted, on Ubuntu 12.04
>
> Status in OpenSSL cryptography and SSL/TLS toolkit:
> Confirmed
> Status in “openssl” package in Ubuntu:
> Triaged
> Status in “openssl” source package in Precise:
> Triaged
> Status in “openssl” package in Debian:
> Fix Released
>
> Bug description:
> This week, HTTPS connections from a Python script I wrote started
> giving me this error:
>
> urllib2.URLError: <urlopen error [Errno 8] _ssl.c:497: EOF occurred in
> violation of protocol>
>
> This used to work up until some three days ago and still works on
> other Ubuntu versions, but not in other Python versions on Precise. I
> was suspecting this was a bug in Python, but a guy on AskUbuntu (
> http://askubuntu.com/questions/116020/python-https-requests-urllib2
> -to-some-sites-fail-on-ubuntu-12-04-without-proxy/116059#116059 )
> found out this happens using the openssl command line tool too:
>
> $ openssl s_client -connect www.mediafire.com:443
>
> But succeeds if forcing TLS 1 with the -tls1 argument.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openssl/+bug/965371/+subscriptions
>

--
Pablo Almeida
http://www.google.com/profiles/pabloalmeidaff9

Robert Schanafelt (robertds) wrote :

The upstream Debian bug is fixed.

Is there an ETA for an Ubuntu release with this fix?

Jason Harman (apollyon-direct) wrote :

I see from some of the comments that this is the Evernote "Can't connect to server" bug. Is that so? Will there be a fix released soon - it seems progress has stalled on this.

Voronin Kirill (kirvoronin) wrote :

If you use Evernote API or other service that requires TLSv1, you can use next monkey patch http://pastebin.com/PdfQAJQ8 and call it like:
from opensslpatch import HTTPSConnection
http.client.HTTPSConnection = HTTPSConnection
I apologize if it was the obvious solution, but one man ask me how to fix this bug in his script, so it can be useful, i hope

Kiril: where do you put this?

Adam Porter (alphapapa) wrote :

In Ubuntu 11.10, Evernote works correctly in Wine. In Ubuntu 12.04, it fails to sync because of this bug:

err:wininet:NETCON_secure_connect SSL_connect failed: 12157

According to <https://groups.google.com/d/msg/mailing.postfix.users/75pH1hGb1P8/bw_P6V5U_boJ>:

"The OpenSSL API does not provide an interface to allow older programs to disable new protocol versions defined in later versions of the API. Therefore, to disable TLS 1.1 or 1.2 one has to add code that uses the new constants introduced with OpenSSL 1.0.1." The author goes on to provide a patch to Postfix, but I doubt it would be feasible to patch Wine for this bug.

There is apparently no way to disable TLS or any protocols in /etc/ssl/openssl.cnf. I can't find any information about disabling or controlling such features in Wine.

Apparently users such as myself have no recourse, other than running a virtual machine for a single app. Since the app in question works fine on the previous version of Ubuntu, that seems quite silly. Downgrading OpenSSL seems unwise, if not totally impractical (perhaps requiring recompiling all software that uses it).

This is very poor, especially for an LTS release. Such a glaring regression deserves more than "Medium" priority, even if it's not Ubuntu's fault per se. Ubuntu, OpenSSL, and all developers would be wise to follow Linus's advice: "Don't break userspace!" Even though OpenSSL may be adhering to the standard and exposing bugs in proprietary implementations, the end result is still broken FOSS software, while proprietary software continues working. Bugs like this deserve high priority.

Adam Porter (alphapapa) wrote :

Here is a thread on Evernote's developer forum about this bug: http://discussion.evernote.com/topic/26872-ssl-issue-with-evernotes-servers/ On June 11, an Evernote developer said they were aware of the issue. No fix yet.

Marc Deslauriers (mdeslaur) wrote :

So the whole world is moving to TLS 1.1 and 1.2, and Evernote's server isn't compatible. How is this a Ubuntu bug?

What do you propose we do? Disable TLS 1.1 and 1.2, which will prevent Ubuntu from working with newer sites that will start requiring it, just to fix Evernote's broken server?

Jeff Utter (jeffutter) wrote :

I think it is important to point out that Evernote is not the only issue here. I am having problems with the new OpenSSL and connecting to at least one credit processing gateway (Try and get banking systems to update their SSL implementations). Here is a link to a simple ruby script that is supposed to do a test request to a gateway: https://gist.github.com/eecccaeb8d43df3f7909#file_https_get.rb

It fails unless i downgrade all my ssl stuff to packages from Oneiric.

This issue should be high priority.

Marc Deslauriers (mdeslaur) wrote :

@Jeff: Your ruby script works for me on precise with the openssl version in -proposed. I think you have a different issue that was fixed with the openssl update.

mdeslaur@mdlinux:/tmp$ ruby https_get.rb
opening connection to secure.mmoagateway.com...
opened
<- "POST /api/transact.php HTTP/1.1\r\nContent-Length: 347\r\nAccept: */*\r\nContent-Type: application/x-www-form-urlencoded\r\nConnection: close\r\nHost: secure.mmoagateway.com\r\n\r\n"
<- "orderid=ae5dd847d9f31209cbffeeea076ed966&orderdescription=Active+Merchant+Remote+Test+Purchase&ccnumber=4111111111111111&ccexp=0913&cvv=123&company=Widgets+Inc&address1=1234+My+Street&address2=Apt+1&city=Ottawa&state=ON&zip=K1C2N6&country=CA&phone=%28555%29555-5555&firstname=&lastname=&email=&amount=1.00&type=auth&username=demo&password=password"
-> "HTTP/1.1 200 OK\r\n"
-> "Date: Sat, 07 Jul 2012 15:38:26 GMT\r\n"
-> "Server: Apache\r\n"
-> "Content-Length: 240\r\n"
-> "Connection: close\r\n"
-> "Content-Type: text/html\r\n"
-> "\r\n"
reading 240 bytes...
-> "response=1&responsetext=SUCCESS&authcode=123456&transactionid=1650916521&avsresponse=N&cvvresponse=N&orderid=ae5dd847d9f31209cbffeeea076ed966&type=auth&response_code=100&merchant_defined_field_6=&merchant_defined_field_7=&customer_vault_id="
read 240 bytes
Conn close
#<Net::HTTPOK:0x7f1979324800>
response=1&responsetext=SUCCESS&authcode=123456&transactionid=1650916521&avsresponse=N&cvvresponse=N&orderid=ae5dd847d9f31209cbffeeea076ed966&type=auth&response_code=100&merchant_defined_field_6=&merchant_defined_field_7=&customer_vault_id=
mdeslaur@mdlinux:/tmp$

Marc Deslauriers (mdeslaur) wrote :

Actually, it's working for me with the openssl version that released with precise, as well as the version currently in -updates.

@Jeff: what version is your script failing on?

Marat Khayrullin (xmm) wrote :

Here is a my warkaround patch for evernote's thrift lib (python2.7, ubuntu 12.04)
http://goo.gl/N0KIm

Another server this fails for is Google Appengine. If Ubuntu aren't going to fix openssl then please at least change Python standard libraries to work around it.

Adam Porter (alphapapa) wrote :

On Sat, Jul 7, 2012 at 8:50 AM, Marc Deslauriers
<email address hidden> wrote:
> So the whole world is moving to TLS 1.1 and 1.2, and Evernote's server
> isn't compatible. How is this a Ubuntu bug?

I'm no expert on TLS, but surely it's an exaggeration to say that the
whole world is moving to 1.1 and 1.2. This exact issue can be found
in reports on mailing lists (including openssl's) going back at least
two years. The whole issue arises because of a failed backward
negotiation by the server. When are these servers (Apache and PHP, in
Evernote's case), which currently fail to fall backwards, going to
start rejecting clients who do the same? Are they really going to
drop like a hot rock browsers which can't even request TLS 1.1 or 1.2,
browsers which will necessarily be in use for many more years? (You
must consider enterprise installations, proprietary software, and
embedded software which won't be even upgraded until the hardware is
replaced.) Last I checked, HTTP 1.1 was not required on any web
sites--1.0 works fine. SSL still works too, so why would TLS 1.0 be
dropped?

> What do you propose we do? Disable TLS 1.1 and 1.2, which will prevent
> Ubuntu from working with newer sites that will start requiring it, just
> to fix Evernote's broken server?

If there are servers which commonly refuse SSLv3 and TLS 1.0 and
require TLS 1.1 or 1.2, please let me know--again, I'm no expert. Or
are users actually at risk by not having support for protocols which
may not even work? Are there such serious security flaws in TLS 1.0?
(If so, why do servers support it and even SSL?)

Lacking examples of such, what we have is a known problem in which
user software utterly fails after upgrading the OS, in which the only
workaround is to reinstall and downgrade the entire OS--versus a
potential benefit of supporting newer versions of a protocol which
many servers don't even support yet, and indeed fail on.

If it's not that clear-cut, please explain why. Otherwise, the choice
seems obvious to me: disable TLS 1.1 and 1.2 by default so that Ubuntu
users who have upgraded to "Precise 12.04 Long Term Support" will not
have their software mysteriously fail without recourse. If the
situation changes at a later time, whether by an upgrade to OpenSSL
which works around broken servers, or if broken servers truly
disappear from the Internet, then 1.1 and 1.2 could be reenabled.

As I have always understood it, the point of a distro is to make
software work for the user. So, yes, I propose that you disable TLS
1.1 and 1.2 by default.

Jeff Utter (jeffutter) wrote :

@Marc One distinction that I forgot to mention is that I am using ruby 1.9.2 (from either rbenv or rvm). Here are the following situations where the script works and fails.

Ubuntu 12.04 + openssl in updates + stock ruby 1.8.7: Pass
Ubuntu 12.04 + openssl in updates + compiled ruby 1.9.3: Fail
Ubuntu 12.04 + openssl manually installed from ubuntu 11.10 + compiled ruby 1.9.3: Pass

There is some specific problem with the latest openssl and ruby 1.9.3.

as Adam said "Otherwise, the choice
seems obvious to me: disable TLS 1.1 and 1.2 by default so that Ubuntu
users who have upgraded to "Precise 12.04 Long Term Support" will not
have their software mysteriously fail without recourse."

This is what happened to me. I upgraded a server from 11.10 to 12.04 to get on a recent LTS release. Next thing I know credit card processing is failing. It took me a long time to track down that the new openssl libs were the problem. Now that I know i can manually downgrade them. However, problems like this should not magically pop up.

Robert Schanafelt (robertds) wrote :

I wrote to Colin about this, but I haven't received a response.

Does anyone know if we can escalate this to someone else at Ubuntu?

Adam Porter (alphapapa) wrote :

I've long wondered how to escalate important bugs that are neglected. My best guess would be to choose some responsive Ubuntu maintainers or project leaders and subscribe them to the bug, but I suppose that could end up annoying some people who can't do anything about it.

Frankly, I think Bug #1 depends directly on bugs like this. People used to email <email address hidden> and ask about specific features--should someone email Mark Shuttleworth about specific bugs, too?

Clint Byrum (clint-fewbar) wrote :

Fixed in quantal with recent syncs with Debian

Changed in openssl (Ubuntu):
status: Triaged → Fix Released
Changed in openssl (Ubuntu):
milestone: ubuntu-12.04 → none
Clint Byrum (clint-fewbar) wrote :

Just to clarify, www.mediafire.com port 443 still fails in quantal, but as has been suggested before, this is the server's problem by crashing the connection rather than backward negotiating it.

Adam Porter (alphapapa) wrote :

The server is at fault for failing to negotiate correctly.

However, from the user experience perspective, the problem happens because of upgrading Ubuntu. The problem doesn't exist in Oneiric. The problem does exist in > Oneiric. Also, Precise is a Long Term Support release. LTS releases are not supposed to break software that works. It doesn't matter where the fault ultimately lies--ultimately it's the Ubuntu user experience that is broken. If a user can switch to another distro, or to Windows, and avoid the bug, then Ubuntu has failed, and Bug #1 has regressed.

Linus Torvalds understands this: he's famous for saying "Don't break userspace!" even if it's ultimately userspace's fault. Why doesn't Ubuntu understand this?

The solution is simple: disable TLS 1.1 and 1.2 by default until servers are fixed.

Doing this will not cause any problems. There is no data to support not doing this.

Doing this will fix a real problem for real people. There is plenty of data to support doing this.

What is Ubuntu waiting for? What does it take to get Ubuntu to do the right thing?

LoCusF (suomalainen-aleksi) wrote :

Manually installing Quantal packages on Precise do not fix the issue with Evernote not being able to connect to the server.

Hiroshi Miura (miurahr) wrote :

For Wine, https://github.com/miurahr/wine/commits/wininet-submit and http://bugs.winehq.org/show_bug.cgi?id=30598 may help. I'm also using Evernote and can use it now with my patch.

I proposed disabling TLS1.1/1.2 by defaut in Wine as same behavior as Windows and support switch to enable it.
This is not a fix for issue here but escaping it.

Renegotiation disability on some servers is not issue for openssl itself. Issue for server administrator who need to maitain ssl library and configuration up-to-date, especially for things related to RFC 5746.

Applications for specific web service can disable TLS 1.1/1.2 with openssl/gnutls options in their program codes.

jedix (howlett) wrote :

This bug stops gerrit 2.4.2 from working on 12.04. I receive the error:

<urlopen error [Errno 8] _ssl.c:504: EOF occurred in violation of protocol>

(posted due to the slight variation in line number)

I have tried updating to the 1.0.1-4ubuntu5.5 proposed package, but that doesn't help.

jedix (howlett) wrote :

gerrit 2.4.2 with the repo command still fails with the upstream Debian package of libssl1.0.0_1.0.1c-4_amd64.deb and openssl_1.0.1c-4_amd64.deb I also tried the 1.0.1-4ubuntu3 packages and they don't work for this either.

Does this mean gerrit is broken or the apache in ubuntu 12.04 or both?

Don't now if it's related or not (but it seems).

Our 12.04.1 server up-to-date can't connect to graph.facebook.com :

$ curl -v https://graph.facebook.com/oauth/access_token
* About to connect() to graph.facebook.com port 443 (#0)
* Trying 69.63.189.71... connected
* successfully set certificate verify locations:
* CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
* Closing connection #0
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

$ curl -v3 https://graph.facebook.com/oauth/access_token
* About to connect() to graph.facebook.com port 443 (#0)
* Trying 69.63.189.71... connected
* successfully set certificate verify locations:
* CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS alert, Server hello (2):
* error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
* Closing connection #0
curl: (35) error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number

Both work fine under a 10.04.4 server.

AquaQuieta (aqua-quieta) wrote :

Like the bug says:

openssl s_client -connect soap.example.org:443
fails because "Secure Renegotiation IS NOT supported"
but I can connect with :
 openssl s_client -tls1 -connect soap.example.org:443

Unfortunately, this doesn't help me at all. I have a PHP script using SoapClient, and although I found several
suggestions for forcing tls1 when using SoapClient, none of them work.

Seems to me that what is really needed is some way to force the use of a specific protocol per server, rather than relying on renegotiation, which can obviously be disabled. Sure, you might argue that server itself is the problem ( I don't necessarily disagree) but in the real world, we have to have some way of working around it....which currently, I don't.

 It would be awesome if, in openssl.cnf we could say something like:

[connection_opts]
server=soap.example.org
protocol=tls1

Of course, I'd be happy if PHP had a way to do this within SoapClient....but something like that in openssl would fix this issue for everyone.

ferrouswheel (joel-pitt) wrote :

This affects me too.

AquaQuieta seems to suggest a good interim solution. I'm surprised openssl.cnf doesn't already allow this functionality.

Will Bradley (bradley-will) wrote :

Congratulations, all! This consumed ~20 hours of time isolating and fixing a bug in what's supposed to be 6-month-old "LTS" release. I see it's supposedly got a fix released and triaged, but the milestone is 6 months old and Colin doesn't seem sure if this is still an issue. I can confirm it is on the two 12.04 machines I have access to and am happy to do further troubleshooting or supply sample scripts if necessary.

There are unfortunately few workarounds for those (two?) of us trying to use SoapClient in PHP. The above fixes work for me, but don't handle PHP's SoapClient, and it was quite a journey triaging that.

I finally got the below PHP code to work for my use case, which is communicating with remote SSL SOAP services that only support SSLv2, SSLv3, or TLS1.0 (and not TLS 1.1, TLS 1.2) especially using RC4-SHA ciphers. The ciphers option in a new stream_context is the necessary bit to make the code work on 12.04:

  $opts = array(
    'ssl' => array('ciphers'=>'RC4-SHA')
  );

  ini_set( "soap.wsdl_cache_enabled", "0" );
  $objSoapClient = new SoapClient(
    'https://EXAMPLE.COM/EXAMPLEWSDLPATH',
    array ( "encoding"=>"ISO-8859-1",
    'stream_context' => stream_context_create($opts),
    "trace"=>1,
    "exceptions"=>0,
    "connection_timeout"=>2000 ));

The trick is to substitute SoapClient's normal context with your own context + SSL options: http://www.php.net/manual/en/soapclient.soapclient.php
http://www.php.net/manual/en/context.php
http://www.php.net/manual/en/function.stream-context-create.php

This site was invaluable in testing what exact ciphers/technologies are actually supported by the remote server: https://www.ssllabs.com/ssltest/index.html

Are there any plans on fixing this issue? I have a new Nagios server I am trying to get all setup and can't get it completed until this fix is implemented. I tried the editing of the python file but it does not seem to work for my nagios plugin to monitor osx server services. This is an LTS release and this should have never made it into production. Its been out for 6 months now, this should be fixed asap. Just saying.

Marc Deslauriers (mdeslaur) wrote :

No, there are no current plans on fixing this issue. This is an issue with certain servers that don't support tls 1.1 negotiation. Please either update your server, or disable tls 1.1 in your client.

Marc Deslauriers (mdeslaur) wrote :

This is an LTS release, as such it is very important that TLS 1.1 support remain enabled.

KillerKellerjr are you refering to http://code.google.com/p/libsrvrmgrd-osx/ ? That's my plugin. I've had someone edit the file to fix the issue http://code.google.com/p/libsrvrmgrd-osx/issues/detail?id=16

If you want to join in to that bug I can try help you there...

Marc, I think the issue is the fact that there is no way to update Servers to get around this or disable it in the client, it is Apple, not renowned for being open/responsive to external factors. While I agree they should all handle TLS correctly the fact is they don't and userspace appears to be broken.

Diego (panda84) wrote :

Those having problems with "repo upload" on Gerrit can workaround the bug by doing a change similar to comment #9 but using ssl_version=ssl.PROTOCOL_SSLv3

kylea (kylea) wrote :

I have replaced my calls to

$content = file_get_contents($url);

with a curl call...

    $curl = curl_init($url);

    if (is_resource($curl) === true)
    {
        curl_setopt($curl, CURLOPT_FAILONERROR, true);
        curl_setopt($curl, CURLOPT_FOLLOWLOCATION, true);
        curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
        curl_setopt($curl, CURLOPT_SSLVERSION, 3);
        curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, true);
        curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, 2);

        if (isset($post) === true)
        {
            curl_setopt($curl, CURLOPT_POST, true);
            curl_setopt($curl, CURLOPT_POSTFIELDS, (is_array($post) === true) ? http_build_query($post, '', '&') : $post);
        }

            $content = curl_exec($curl);

        curl_close($curl);
    }

Key point here is ----> curl_setopt($curl, CURLOPT_SSLVERSION, 3);

This seems to work on http and https sites.

this seems to be related:

http://rt.openssl.org/Ticket/Display.html?id=2811

Changes between 1.0.1c and 1.0.1d [xx XXX xxxx]

  *) Fix possible deadlock when decoding public keys.
     [Steve Henson]

  *) Don't use TLS 1.0 record version number in initial client hello
     if renegotiating.
     [Steve Henson]

JDS (jeff-newtnotes) wrote :

This bug still exists in 12.04. My understanding of the technical details of this bug is a bit shallow, so some of my questions, below, may reflect that.

It affects other libraries which use or are recompiled against this library.

In my case, I am having an issue with the OpenLDAP libs which suffer from a similar bug that affects the GnuTLS libs. In earlier versions of Ubuntu, I recompiled the libldap packages using OpenSSL libs. Now, that is no longer successful.

What can be done as a workaround on a firewall or other SSL-enabled service to make clients using this library work? Unfortunately, forcing ldapsearch to use TLSv1.0 is not a configurable option that I could find in either in GnuTLS, OpenLDAP, or OpenSSL.

So, to sum up, my questions are:

1) Is there any hope of having this be fixed "properly", where "properly" follows the "don't break userspace" philosophy?
2) What workarounds are there on the server end? What, for example, would have to happen to make a broken server work? Why do some SSL-enabled services work and some don't?
3) *Is* there a way to configure client libs to force TLSv1.0? The OpenSSL s_client has a CLI option, but I'm asking what can I put in, say, /etc/ldap/ldap.conf or /opt/ssl/ssl.conf or the like to force this?

I'm happy to provide additional debugging data as requested.

Thank you,
JDS

Will Bradley (bradley-will) wrote :
Download full text (3.2 KiB)

Lately I've been getting more comments calling me a lifesaver[1] for
posting a workaround related to this bug; it's obviously getting more
attention as more people get "up to date." Maybe it's time for one of us to
climb upstream and bang on some patches?

[1]
http://willbradley.name/2012/10/workaround-for-php-error-in-ubuntu-12-04-soapclient-ssl-crypto-enabling-timeout/#comment-804198884think
of the children!
On Feb 19, 2013 8:16 PM, "JDS" <email address hidden> wrote:

> This bug still exists in 12.04. My understanding of the technical
> details of this bug is a bit shallow, so some of my questions, below,
> may reflect that.
>
> It affects other libraries which use or are recompiled against this
> library.
>
> In my case, I am having an issue with the OpenLDAP libs which suffer
> from a similar bug that affects the GnuTLS libs. In earlier versions of
> Ubuntu, I recompiled the libldap packages using OpenSSL libs. Now, that
> is no longer successful.
>
> What can be done as a workaround on a firewall or other SSL-enabled
> service to make clients using this library work? Unfortunately, forcing
> ldapsearch to use TLSv1.0 is not a configurable option that I could find
> in either in GnuTLS, OpenLDAP, or OpenSSL.
>
> So, to sum up, my questions are:
>
> 1) Is there any hope of having this be fixed "properly", where "properly"
> follows the "don't break userspace" philosophy?
> 2) What workarounds are there on the server end? What, for example, would
> have to happen to make a broken server work? Why do some SSL-enabled
> services work and some don't?
> 3) *Is* there a way to configure client libs to force TLSv1.0? The OpenSSL
> s_client has a CLI option, but I'm asking what can I put in, say,
> /etc/ldap/ldap.conf or /opt/ssl/ssl.conf or the like to force this?
>
> I'm happy to provide additional debugging data as requested.
>
> Thank you,
> JDS
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/965371
>
> Title:
> HTTPS requests fail on sites which immediately close the connection if
> TLS 1.1 negotiation is attempted, on Ubuntu 12.04
>
> Status in OpenSSL cryptography and SSL/TLS toolkit:
> Confirmed
> Status in “openssl” package in Ubuntu:
> Fix Released
> Status in “openssl” source package in Precise:
> Triaged
> Status in “openssl” package in Debian:
> Fix Released
>
> Bug description:
> This week, HTTPS connections from a Python script I wrote started
> giving me this error:
>
> urllib2.URLError: <urlopen error [Errno 8] _ssl.c:497: EOF occurred in
> violation of protocol>
>
> This used to work up until some three days ago and still works on
> other Ubuntu versions, but not in other Python versions on Precise. I
> was suspecting this was a bug in Python, but a guy on AskUbuntu (
> http://askubuntu.com/questions/116020/python-https-requests-urllib2
> -to-some-sites-fail-on-ubuntu-12-04-without-proxy/116059#116059 )
> found out this happens using the openssl command line tool too:
>
> $ openssl s_client -connect www.mediafire.com:443
>
> But succeeds if forcing TLS 1 with the -tls1 argument.
>
> To manage notifications a...

Read more...

JDS (jeff-newtnotes) wrote :

@bradley-will: I appreciate the helpful suggestion, but the PHP libs I am interested in are not in any way related to SOAP or PHP's implementation of SoapClient.

The thing I'm interested in is LDAP. There is a chain of libraries that PHP uses to get LDAPS working.

 PHP -> uses OpenLDAP -> which uses GnuTLS (On Ubuntu)

In the past, I tried recompiling OpenLDAP against OpenSSL, and this fixed PHP, so I know that the chain I described is correct (well, is correct for Ubuntu 10.04. I'm assuming it is true for 12.04 as well)

In any case, when OpenLDAP is recompiled against OpenSSL, the chain of libs I'm interested in is:

 PHP -> uses OpenLDAP -> which uses OpenSSL

Is there a system-wide configuration way to force PHP's LDAP libs to use TLSv1.0? So far I have not found an answer.

Finally, is there a way to get GnuTLS to work against the above described SSL services? GnuTLS has similar problems connecting to SSL services as described in this bug for OpenSSL. Is there a bug open for GnuTLS somewhere about this?

Thanks

Neil Vergottini (nvergottini) wrote :

It appears now I've been bitten by this bug in Apache. I run a pair of reverse proxy servers on 12.04 using Apache. I built these servers last year and they were working fine up until last week when I ran a dist-upgrade to update some packages (specifically apache2 and openssl) to clear up some vulnerabilities identified in a PCI scan. Since then, one of the reverse proxies is unable to connect to an internal WebLogics server due to SSL errors. Using openssl s_client -connect fails, but adding -tls1 works.

According to the Apache 2.2 documentation, I should be able to add "SSLProxyProtocol All -SSLv2 -TLSv1.1 -TLSv1.2" to my reverse proxy virtual server config, but it doesn't like the "-TLSv1.1 -TLSv1.2". I've read that those options are only supported in Apache 2.4.

Now I'm basically stuck. It appears Ubuntu 12.04 has made a change in openssl that is impossible to workaround in the version of Apache provided in Ubuntu 12.04. Downgrading openssl is not an option because I specifically needed the current version to pass the PCI scan. I've asked about updating the WebLogics server, but considering it is a PeopleSoft server, I suspect that is going to be a challenge.

Adam Porter (alphapapa) wrote :

This bug's scope is definitely wider than PHP and Python. The simple
fix is to disable TLS 1.1. This would provide a real fix to a real
problem; on the other hand, it would create a theoretical problem with
a protocol that isn't even universally supported and isn't required
anywhere. Until this is fixed, people will upgrade Ubuntu and find
that their userspace breaks. This is obviously a black eye for
Ubuntu. The logical thing to do seems clear to me.

Ben McCann (benjamin-j-mccann) wrote :

This is happening when connecting to SoftLayer as well. I've filed a bug with them here: https://github.com/softlayer/softlayer-object-storage-python/issues/17

Cerin (chrisspen) wrote :

Is anyone aware of a workaround to make Python's urllib/urllib2 use tls1?

Edward Betts (edwardbetts) wrote :

@chrisspen: Python workaround

import httplib
import socket
import ssl

def connect(self):
    "Connect to a host on a given (SSL) port."
    sock = socket.create_connection((self.host, self.port),
                                        self.timeout, self.source_address)
    if self._tunnel_host:
        self.sock = sock
        self._tunnel()
    self.sock = ssl.wrap_socket(sock, self.key_file,
                                self.cert_file,
                                ssl_version=ssl.PROTOCOL_TLSv1)

httplib.HTTPSConnection.connect = connect
import urllib2

Cerin (chrisspen) wrote :

Thanks Edward. Now I'm getting a BadStatusLine error, but that might be caused by a different problem.

Hello! I'd like to know if there's a workaround for Python 3.2. I have searched the entire web for the past days and I haven't found a straightforward answer to my problem.

The only thing I know is that Python 3.4 tackles the problem (but it is still in beta).

WHAT'S NEW IN PYTHON 3.4
http://docs.python.org/dev/whatsnew/3.4.html

Significantly Improved Library Modules:
TLSv1.1 and TLSv1.2 support for ssl (issue 16692).

Thanks in advance!

Nevermind. I installed Ubuntu 13.04 and now everything works fine (ran successfully my scripts using the pre-installed Python 3.3). Thanks!

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.