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?
> 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 about this bug go to:
> https://bugs.launchpad.net/openssl/+bug/965371/+subscriptions
>
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] willbradley. name/2012/ 10/workaround- for-php- error-in- ubuntu- 12-04-soapclien t-ssl-crypto- enabling- timeout/ #comment- 804198884think
http://
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 /bugs.launchpad .net/bugs/ 965371 askubuntu. com/questions/ 116020/ python- https-requests- urllib2 sites-fail- on-ubuntu- 12-04-without- proxy/116059# 116059 ) com:443 /bugs.launchpad .net/openssl/ +bug/965371/ +subscriptions
> 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:/
>
> 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://
> -to-some-
> found out this happens using the openssl command line tool too:
>
> $ openssl s_client -connect www.mediafire.
>
> But succeeds if forcing TLS 1 with the -tls1 argument.
>
> To manage notifications about this bug go to:
> https:/
>