Bug#658276: libcurl3: Doesn't work for all sites anymore
* Alessandro Ghedini: Anyway, you can upload to security-master when ready. You must build the package with specifying the -sa flag, on a squeeze system. Ok, thank you. Thanks for uploading. I'm a bit confused--is this an interoperability issue introduced by DSA-2398-1? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658276: libcurl3: Doesn't work for all sites anymore
On Sat, Mar 31, 2012 at 07:12:36PM +0200, Florian Weimer wrote:
* Alessandro Ghedini:
Anyway, you can upload to security-master when ready. You must build
the package with specifying the -sa flag, on a squeeze system.
Ok, thank you.
Thanks for uploading. I'm a bit confused--is this an interoperability
issue introduced by DSA-2398-1?
Yes, the fix for the CVE-2011-3389 related issue broke backwards compatibility
with older SSL implementations.
Cheers
--
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
signature.asc
Description: Digital signature
Bug#658276: libcurl3: Doesn't work for all sites anymore
On Wed, Mar 28, 2012 at 10:51:53PM +0200, Florian Weimer wrote:
* Alessandro Ghedini:
We should fix this through stable-security. Please send a debdiff once
the fix has been testing in unstable for a few days.
Attached is the debdiff for stable-security.
Looks good.
If everything's ok I will upload it (I'm a DD since a few hours) in
a few days, once the sid version has been tested more.
Do you really think this option will actually be used in practice,
except if there's a failure?
Well... not really. I'm doing some tests on my own though.
Anyway, you can upload to security-master when ready. You must build
the package with specifying the -sa flag, on a squeeze system.
Ok, thank you.
Cheers
--
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
signature.asc
Description: Digital signature
Bug#658276: libcurl3: Doesn't work for all sites anymore
On Sun, Feb 12, 2012 at 08:23:02PM +0100, Moritz Mühlenhoff wrote:
On Sat, Feb 11, 2012 at 02:04:01PM +0100, Alessandro Ghedini wrote:
On Fri, Feb 10, 2012 at 08:23:24PM +0100, Kurt Roeckx wrote:
On Fri, Feb 10, 2012 at 10:15:44AM +0100, Alessandro Ghedini wrote:
On Sat, Feb 04, 2012 at 10:45:59PM +0100, Kurt Roeckx wrote:
Having SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS disabled by default
would be fine if I had the option to turn it on. In that case
it's my decision to ignore the security consequences.
This has been fixed upstream now (commits 2a699bc6 and 62d15f15).
Do you plan to upload this to stable-proposed-updates?
Yep, once curl 7.25.0 is released and uploaded to unstable (as Julian said
I'll prepare another upload for security).
We should fix this through stable-security. Please send a debdiff once
the fix has been testing in unstable for a few days.
Attached is the debdiff for stable-security. If everything's ok I will upload
it (I'm a DD since a few hours) in a few days, once the sid version has been
tested more.
Cheers
--
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
diff -Nru curl-7.21.0/debian/changelog curl-7.21.0/debian/changelog
--- curl-7.21.0/debian/changelog2012-01-24 20:52:47.0 +0100
+++ curl-7.21.0/debian/changelog2012-03-24 15:02:23.0 +0100
@@ -1,3 +1,10 @@
+curl (7.21.0-2.1+squeeze2) stable-security; urgency=low
+
+ * Non-maintainer upload
+ * Add --ssl-allow-beast and CURLOPT_SSL_OPTIONS (Closes: #658276)
+
+ -- Alessandro Ghedini al3x...@gmail.com Sat, 24 Mar 2012 15:01:45 +0100
+
curl (7.21.0-2.1+squeeze1) stable-security; urgency=high
* Non-maintainer upload
diff -Nru curl-7.21.0/debian/patches/CURLOPT_SSL_OPTIONS_added
curl-7.21.0/debian/patches/CURLOPT_SSL_OPTIONS_added
--- curl-7.21.0/debian/patches/CURLOPT_SSL_OPTIONS_added1970-01-01
01:00:00.0 +0100
+++ curl-7.21.0/debian/patches/CURLOPT_SSL_OPTIONS_added2012-03-24
15:32:56.0 +0100
@@ -0,0 +1,158 @@
+From 2a699bc6e94b8223d900e8880ad628aebf17ab6d Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg dan...@haxx.se
+Date: Mon, 6 Feb 2012 22:12:06 +0100
+Subject: [PATCH 1/2] CURLOPT_SSL_OPTIONS: added
+
+Allow an appliction to set libcurl specific SSL options. The first and
+only options supported right now is CURLSSLOPT_ALLOW_BEAST.
+
+It will make libcurl to disable any work-arounds the underlying SSL
+library may have to address a known security flaw in the SSL3 and TLS1.0
+protocol versions.
+
+This is a reaction to us unconditionally removing that behavior after
+this security advisory:
+
+http://curl.haxx.se/docs/adv_20120124B.html
+
+... it did however cause a lot of programs to fail because of old
+servers not liking this work-around. Now programs can opt to decrease
+the security in order to interoperate with old servers better.
+---
+ docs/libcurl/curl_easy_setopt.3 | 10 ++
+ docs/libcurl/symbols-in-versions |2 ++
+ include/curl/curl.h | 12
+ lib/ssluse.c |5 -
+ lib/url.c| 15 ++-
+ lib/urldata.h|2 ++
+ 6 files changed, 40 insertions(+), 6 deletions(-)
+
+--- a/docs/libcurl/curl_easy_setopt.3
b/docs/libcurl/curl_easy_setopt.3
+@@ -1964,6 +1964,16 @@
+ cache. While nothing ever should get hurt by attempting to reuse SSL
+ session-IDs, there seem to be broken SSL implementations in the wild that may
+ require you to disable this in order for you to succeed. (Added in 7.16.0)
++.IP CURLOPT_SSL_OPTIONS
++Pass a long with a bitmask to tell libcurl about specific SSL behaviors.
++
++CURLSSLOPT_ALLOW_BEAST is the only supported bit and by setting this the user
++will tell libcurl to not attempt to use any work-arounds for a security flaw
++in the SSL3 and TLS1.0 protocols. If this option isn't used or this bit is
++set to 0, the SSL layer libcurl uses may use a work-around for this flaw
++although it might cause interoperability problems with some (older) SSL
++implementations. WARNING: avoiding this work-around loosens the security, and
++by setting this option to 1 you ask for exactly that. (Added in 7.25.0)
+ .IP CURLOPT_KRBLEVEL
+ Pass a char * as parameter. Set the kerberos security level for FTP; this also
+ enables kerberos awareness. This is a string, \'clear', \'safe',
+--- a/docs/libcurl/symbols-in-versions
b/docs/libcurl/symbols-in-versions
+@@ -368,6 +368,7 @@
+ CURLOPT_SSL_CIPHER_LIST 7.9
+ CURLOPT_SSL_CTX_DATA7.10.6
+ CURLOPT_SSL_CTX_FUNCTION7.10.6
++CURLOPT_SSL_OPTIONS 7.25.0
+ CURLOPT_SSL_SESSIONID_CACHE 7.16.0
+ CURLOPT_SSL_VERIFYHOST 7.8.1
+ CURLOPT_SSL_VERIFYPEER 7.4.2
+@@ -430,6 +431,7 @@
+ CURLSSH_AUTH_NONE 7.16.1
+ CURLSSH_AUTH_PASSWORD 7.16.1
+ CURLSSH_AUTH_PUBLICKEY 7.16.1
++CURLSSLOPT_ALLOW_BEAST 7.25.0
+
Bug#658276: libcurl3: Doesn't work for all sites anymore
* Alessandro Ghedini: We should fix this through stable-security. Please send a debdiff once the fix has been testing in unstable for a few days. Attached is the debdiff for stable-security. Looks good. If everything's ok I will upload it (I'm a DD since a few hours) in a few days, once the sid version has been tested more. Do you really think this option will actually be used in practice, except if there's a failure? Anyway, you can upload to security-master when ready. You must build the package with specifying the -sa flag, on a squeeze system. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658276: libcurl3: Doesn't work for all sites anymore
Hi Kurt,
curl 7.25.0 was released yesterday and I'm now working on updating the
Debian package. A problem come up though with the --ssl-enable-beast
new option of curl (which should fix the bug that you have reported)
and the new version of openssl. If I build curl against the current
version 1.0.1-2 (uploaded a few days ago) of libssl the option has no
effect with the URL you posted above and curl fails with the error:
curl: (35) error:140773F2:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert
unexpected message
(the 35 means that the error happened in the SSL handshake).
But if I build with a slightly older libssl (1.0.0h-1) the option works
as expected and if the option is not used at all the error is the same
that you reported (Empty reply from server).
Now, since you did the openssl uploads, do you know of any change in
openssl that may have caused this problem and if there's anything that
can be done on the curl's side to fix it?
Cheers
--
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
signature.asc
Description: Digital signature
Bug#658276: libcurl3: Doesn't work for all sites anymore
On Fri, Mar 23, 2012 at 06:38:40PM +0100, Alessandro Ghedini wrote: Hi Kurt, curl 7.25.0 was released yesterday and I'm now working on updating the Debian package. A problem come up though with the --ssl-enable-beast new option of curl (which should fix the bug that you have reported) and the new version of openssl. If I build curl against the current version 1.0.1-2 (uploaded a few days ago) of libssl the option has no effect with the URL you posted above and curl fails with the error: curl: (35) error:140773F2:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert unexpected message (the 35 means that the error happened in the SSL handshake). But if I build with a slightly older libssl (1.0.0h-1) the option works as expected and if the option is not used at all the error is the same that you reported (Empty reply from server). Now, since you did the openssl uploads, do you know of any change in openssl that may have caused this problem and if there's anything that can be done on the curl's side to fix it? So I see: openssl s_client -connect www.eboekhuis.nl:443 CONNECTED(0003) 140090768766632:error:140773F2:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert unexpected message:s23_clnt.c:708: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 324 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- But it works when I use: openssl s_client -no_tls1_2 -no_tls1_1 -connect www.eboekhuis.nl:443 Tls1.1 and 1.2 support is new since openssl 1.0.1. I'm not sure what to do about this. I can at least let them know that that is an issue too. But maybe I should contact upstream openssl so they can take a look too that it's not a bug in openssl. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658276: libcurl3: Doesn't work for all sites anymore
On Fri, Mar 23, 2012 at 07:02:34PM +0100, Kurt Roeckx wrote: On Fri, Mar 23, 2012 at 06:38:40PM +0100, Alessandro Ghedini wrote: Hi Kurt, curl 7.25.0 was released yesterday and I'm now working on updating the Debian package. A problem come up though with the --ssl-enable-beast new option of curl (which should fix the bug that you have reported) and the new version of openssl. If I build curl against the current version 1.0.1-2 (uploaded a few days ago) of libssl the option has no effect with the URL you posted above and curl fails with the error: curl: (35) error:140773F2:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert unexpected message (the 35 means that the error happened in the SSL handshake). But if I build with a slightly older libssl (1.0.0h-1) the option works as expected and if the option is not used at all the error is the same that you reported (Empty reply from server). Now, since you did the openssl uploads, do you know of any change in openssl that may have caused this problem and if there's anything that can be done on the curl's side to fix it? So I see: openssl s_client -connect www.eboekhuis.nl:443 CONNECTED(0003) 140090768766632:error:140773F2:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert unexpected message:s23_clnt.c:708: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 324 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- But it works when I use: openssl s_client -no_tls1_2 -no_tls1_1 -connect www.eboekhuis.nl:443 Tls1.1 and 1.2 support is new since openssl 1.0.1. I'm not sure what to do about this. I can at least let them know that that is an issue too. But maybe I should contact upstream openssl so they can take a look too that it's not a bug in openssl. gnutls-cli also has problems with the site if tls1.1 and 1.2 are enabled. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658276: libcurl3: Doesn't work for all sites anymore
On Fri, Mar 23, 2012 at 07:02:34PM +0100, Kurt Roeckx wrote:
On Fri, Mar 23, 2012 at 06:38:40PM +0100, Alessandro Ghedini wrote:
Hi Kurt,
curl 7.25.0 was released yesterday and I'm now working on updating the
Debian package. A problem come up though with the --ssl-enable-beast
new option of curl (which should fix the bug that you have reported)
and the new version of openssl. If I build curl against the current
version 1.0.1-2 (uploaded a few days ago) of libssl the option has no
effect with the URL you posted above and curl fails with the error:
curl: (35) error:140773F2:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert
unexpected message
(the 35 means that the error happened in the SSL handshake).
But if I build with a slightly older libssl (1.0.0h-1) the option works
as expected and if the option is not used at all the error is the same
that you reported (Empty reply from server).
Now, since you did the openssl uploads, do you know of any change in
openssl that may have caused this problem and if there's anything that
can be done on the curl's side to fix it?
So I see:
openssl s_client -connect www.eboekhuis.nl:443
CONNECTED(0003)
140090768766632:error:140773F2:SSL routines:SSL23_GET_SERVER_HELLO:sslv3
alert unexpected message:s23_clnt.c:708:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 324 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
But it works when I use:
openssl s_client -no_tls1_2 -no_tls1_1 -connect www.eboekhuis.nl:443
Tls1.1 and 1.2 support is new since openssl 1.0.1.
I'm not sure what to do about this. I can at least let them know that that
is an issue too.
But maybe I should contact upstream openssl so they can take a look too that
it's not a bug
in openssl.
Indeed, explicitly setting TLSv1 (--tlsv1 option in curl) works. I was afraid
this was a new bug in curl's OpenSSL code but apparently it's not (or at least
it is not as grave as I thought). I'll go on with the curl uploads then.
Thanks
--
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
signature.asc
Description: Digital signature
Bug#658276: libcurl3: Doesn't work for all sites anymore
On Sat, Feb 11, 2012 at 02:04:01PM +0100, Alessandro Ghedini wrote: On Fri, Feb 10, 2012 at 08:23:24PM +0100, Kurt Roeckx wrote: On Fri, Feb 10, 2012 at 10:15:44AM +0100, Alessandro Ghedini wrote: On Sat, Feb 04, 2012 at 10:45:59PM +0100, Kurt Roeckx wrote: Having SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS disabled by default would be fine if I had the option to turn it on. In that case it's my decision to ignore the security consequences. This has been fixed upstream now (commits 2a699bc6 and 62d15f15). Do you plan to upload this to stable-proposed-updates? Yep, once curl 7.25.0 is released and uploaded to unstable (as Julian said I'll prepare another upload for security). We should fix this through stable-security. Please send a debdiff once the fix has been testing in unstable for a few days. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658276: libcurl3: Doesn't work for all sites anymore
On Fri, Feb 10, 2012 at 20:23:24 +0100, Kurt Roeckx wrote: On Fri, Feb 10, 2012 at 10:15:44AM +0100, Alessandro Ghedini wrote: On Sat, Feb 04, 2012 at 10:45:59PM +0100, Kurt Roeckx wrote: Having SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS disabled by default would be fine if I had the option to turn it on. In that case it's my decision to ignore the security consequences. This has been fixed upstream now (commits 2a699bc6 and 62d15f15). Do you plan to upload this to stable-proposed-updates? In general, regressions on security should be fixed on security, not spu. Cheers, Julien signature.asc Description: Digital signature
Bug#658276: libcurl3: Doesn't work for all sites anymore
On Fri, Feb 10, 2012 at 08:23:24PM +0100, Kurt Roeckx wrote:
On Fri, Feb 10, 2012 at 10:15:44AM +0100, Alessandro Ghedini wrote:
On Sat, Feb 04, 2012 at 10:45:59PM +0100, Kurt Roeckx wrote:
Having SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS disabled by default
would be fine if I had the option to turn it on. In that case
it's my decision to ignore the security consequences.
This has been fixed upstream now (commits 2a699bc6 and 62d15f15).
Do you plan to upload this to stable-proposed-updates?
Yep, once curl 7.25.0 is released and uploaded to unstable (as Julian said
I'll prepare another upload for security).
Cheers
--
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658276: libcurl3: Doesn't work for all sites anymore
tags 658276 fixed-upstream
kthxbye
On Sat, Feb 04, 2012 at 10:45:59PM +0100, Kurt Roeckx wrote:
On Sat, Feb 04, 2012 at 10:11:31PM +0100, Alessandro Ghedini wrote:
AFAIU, the problem is that the SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS option is
meant to keep compatibility with some older and broken SSL implementations
that don't support empty fragments, but it also re-introduces a security
issue.
That's why such option was disabled in curl 7.24.0 (and backported to
stable-security). It was a mistake on the curl developers side to enable it
in the first place (it was done by accident because of the not-so-clear
OpenSSL documentation, according to upstream).
I understand that this may cause problems (the incompatibility didn't show
up in my tests with live SSL servers though), but leaving a security issue
open *by default* is not a better solution IMO.
Maybe an option, for both libcurl and curl, to explicitly enable the
SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS would do the trick?
Alternative solutions/opinions would be welcome, if you happen to have any.
Having SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS disabled by default
would be fine if I had the option to turn it on. In that case
it's my decision to ignore the security consequences.
This has been fixed upstream now (commits 2a699bc6 and 62d15f15).
Cheers
--
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658276: libcurl3: Doesn't work for all sites anymore
On Fri, Feb 10, 2012 at 10:15:44AM +0100, Alessandro Ghedini wrote: On Sat, Feb 04, 2012 at 10:45:59PM +0100, Kurt Roeckx wrote: Having SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS disabled by default would be fine if I had the option to turn it on. In that case it's my decision to ignore the security consequences. This has been fixed upstream now (commits 2a699bc6 and 62d15f15). Do you plan to upload this to stable-proposed-updates? Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658276: libcurl3: Doesn't work for all sites anymore
retitle 658276 libcurl3: No more compatible with older SSL implementations
forwarded 658276 http://curl.haxx.se/mail/lib-2012-02/0001.html
kthxbye
On Wed, Feb 01, 2012 at 07:27:06PM +0100, Kurt Roeckx wrote:
Package: libcurl3
Version: 7.21.0-2.1+squeeze1, 7.24.0-1
Severity: grave
Hi,
Hi,
After the upgrade from 7.21.0-2 or 7.23.1-3 some sites stop to
work while others continue to work.
My guess is that this is related to the CVE-2011-3389 change.
If my memory is any good, the reason why openssl still does
something with that option is because not all implementations
work without it. I think I at least saw a blog post about
the state of that issue a few months ago.
AFAIU, the problem is that the SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS option is
meant to keep compatibility with some older and broken SSL implementations
that don't support empty fragments, but it also re-introduces a security
issue.
That's why such option was disabled in curl 7.24.0 (and backported to
stable-security). It was a mistake on the curl developers side to enable it
in the first place (it was done by accident because of the not-so-clear
OpenSSL documentation, according to upstream).
I understand that this may cause problems (the incompatibility didn't show
up in my tests with live SSL servers though), but leaving a security issue
open *by default* is not a better solution IMO.
Maybe an option, for both libcurl and curl, to explicitly enable the
SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS would do the trick?
Alternative solutions/opinions would be welcome, if you happen to have any.
Cheers
--
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658276: libcurl3: Doesn't work for all sites anymore
On Sat, Feb 04, 2012 at 10:11:31PM +0100, Alessandro Ghedini wrote: AFAIU, the problem is that the SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS option is meant to keep compatibility with some older and broken SSL implementations that don't support empty fragments, but it also re-introduces a security issue. That's why such option was disabled in curl 7.24.0 (and backported to stable-security). It was a mistake on the curl developers side to enable it in the first place (it was done by accident because of the not-so-clear OpenSSL documentation, according to upstream). I understand that this may cause problems (the incompatibility didn't show up in my tests with live SSL servers though), but leaving a security issue open *by default* is not a better solution IMO. Maybe an option, for both libcurl and curl, to explicitly enable the SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS would do the trick? Alternative solutions/opinions would be welcome, if you happen to have any. Having SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS disabled by default would be fine if I had the option to turn it on. In that case it's my decision to ignore the security consequences. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658276: libcurl3: Doesn't work for all sites anymore
Package: libcurl3 Version: 7.21.0-2.1+squeeze1, 7.24.0-1 Severity: grave Hi, After the upgrade from 7.21.0-2 or 7.23.1-3 some sites stop to work while others continue to work. My guess is that this is related to the CVE-2011-3389 change. If my memory is any good, the reason why openssl still does something with that option is because not all implementations work without it. I think I at least saw a blog post about the state of that issue a few months ago. I can reproduce this with: $ curl https://www.eboekhuis.nl curl: (52) Empty reply from server Downgrading libcurl3 fixes my issue. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
