Bug#745837: curl should use a Certificate Revocation List by default

[Alessandro Ghedini]

Control: tags -1 wontfix

On mar, mag 05, 2015 at 01:23:46 +0200, Vincent Lefevre wrote:
> On 2015-05-04 19:57:25 +0200, Alessandro Ghedini wrote:
> > On lun, mag 04, 2015 at 12:28:02 +0200, Vincent Lefevre wrote:
> > > OK, if I understand, it just supports OCSP stapling, not plain OCSP.
> > > So, why not using plain OCSP if no OCSP stapling information is
> > > received?
> > 
> > Plain OCSP has several problems
> 
> This is FUD. The possible problems are very minor compared to other
> problems, in particular compared to the potential security probems.
> 
> > (increased latency,
> 
> Only for the first request to the server. So, in average, I doubt that
> this is noticeable. Adverts and images on web sites are much worse.

You seem to keep confusing libcurl for a web browser. It's not (unless you
decide for whatever reason to build one yourself on top of it). "Adverts and
images on web sites" are of no concern to curl developers (not to mention that
adverts would probably require their own additional OCSP requests...).

> > privacy concerns,
> 
> Well, at worse, the OCSP responder just gets the domain and the IP of
> the user, right?

At worse, major certificate authorities get The IP address of every user
connecting to most websites using TLS.

> There are similar privacy concerns with the DNS, and even worse with the ISP
> (which can get much more information on the user).

And? Just because there are other ways to fuck you over it doesn't mean it's ok
to add yet another one. Not to mention that it's much easier for, say, law
enforcement, to randomly fish for "criminals" by requesting information from a
few big  CAs, then do the same for every website and ISP.

> And with Google and Facebook too.

How does this have anything to do with OCSP?

> > and general unreliability)
> 
> Very rare. I've been using security.OCSP.require = true with Firefox
> for one year now

So? No one is going to make a decision based on what you, a single user out of
a few million ones, do.

Anyway, you forgot the part where the OCSP server is not responding because
someone is intercepting and blocking your OCSP requests. Or actively DDoSing
the OCSP server.

> > so there's little chance it will be implemented, let alone enabled
> > by default.
> 
> If curl were built against GnuTLS, it would have it automatically
> (like lynx and wget).

curl *is* built againt GnuTLS as of a couple of days ago, and no, this didn't
magically add support for OCSP as you seem to think.

GnuTLS (like most other TLS libraries) supports creating OCSP requests, but you
also need to send them (e.g. ocsptool in gnutls-bin implements its own HTTP
client) and then verify that the response is valid. None of this is automatic.

Also, how exactly do wget and lynx support OCSP? Because AFAICT they don't (they
don't even support OCSP stapling).

Cheers


signature.asc
Description: Digital signature

Bug#745837: curl should use a Certificate Revocation List by default

[Vincent Lefevre]

On 2015-05-04 19:57:25 +0200, Alessandro Ghedini wrote:
> On lun, mag 04, 2015 at 12:28:02 +0200, Vincent Lefevre wrote:
> > OK, if I understand, it just supports OCSP stapling, not plain OCSP.
> > So, why not using plain OCSP if no OCSP stapling information is
> > received?
> 
> Plain OCSP has several problems

This is FUD. The possible problems are very minor compared to other
problems, in particular compared to the potential security probems.

> (increased latency,

Only for the first request to the server. So, in average, I doubt that
this is noticeable. Adverts and images on web sites are much worse.

> privacy concerns,

Well, at worse, the OCSP responder just gets the domain and the IP of
the user, right? There are similar privacy concerns with the DNS, and
even worse with the ISP (which can get much more information on the
user). And with Google and Facebook too. This doesn't prevent users
from using them.

Note: the importance of privacy concerns depend on the web site.
But the web sites for which this is really important probably already
provide OCSP stapling information, or the user can complain at them.

> and general unreliability)

Very rare. I've been using security.OCSP.require = true with Firefox
for one year now, and the only problems I could see were:

1. A failure with some OCSP server for a couple of hours (failures
   with common websites occur much more often).

2. The problem with captive portals, but the user should be able to
   deactivate OCSP easily for such cases; so, that's basically a UI
   problem at most.
   Note that for curl and other non-browser clients, having plain OCSP
   is an advantage: instead of getting wrong contents, the user would
   get an error.

3. Plain OCSP fails when there are many requests at the same time
   (this could happen in the past when starting Firefox with 50 tabs
   in the saved session). But this isn't much different from a failure
   with the website itself one would get if plain OCSP were not used.

> so there's little chance it will be implemented, let alone enabled
> by default.

If curl were built against GnuTLS, it would have it automatically
(like lynx and wget).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#745837: curl should use a Certificate Revocation List by default

[Alessandro Ghedini]

On lun, mag 04, 2015 at 12:28:02 +0200, Vincent Lefevre wrote:
> On 2015-05-04 10:57:36 +0200, Alessandro Ghedini wrote:
> > --cert-status only checks for the status_request TLS extension which is not
> > supported by most servers (which means curl will fail by default on most
> > requests). So no, curl will not enable the option by default, at least until
> > status_request catches on.
> 
> OK, if I understand, it just supports OCSP stapling, not plain OCSP.
> So, why not using plain OCSP if no OCSP stapling information is
> received?

Plain OCSP has several problems (increased latency, privacy concerns, and
general unreliability) so there's little chance it will be implemented, let
alone enabled by default.

CHeers


signature.asc
Description: Digital signature

Bug#745837: curl should use a Certificate Revocation List by default

[Vincent Lefevre]

On 2015-05-04 10:57:36 +0200, Alessandro Ghedini wrote:
> --cert-status only checks for the status_request TLS extension which is not
> supported by most servers (which means curl will fail by default on most
> requests). So no, curl will not enable the option by default, at least until
> status_request catches on.

OK, if I understand, it just supports OCSP stapling, not plain OCSP.
So, why not using plain OCSP if no OCSP stapling information is
received?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#745837: curl should use a Certificate Revocation List by default

[Alessandro Ghedini]

On Mon, May 04, 2015 at 03:15:19AM +0200, Vincent Lefevre wrote:
> Control: retitle -1 curl should check certificate revocation status by default
> 
> On 2014-04-26 13:19:35 +0200, Alessandro Ghedini wrote:
> > TL;DR: let's do OCSP instead of downloading CRLs. It would still
> > need someone to actually write the code though (ideally for all
> > OpenSSL, GnuTLS and NSS).
> 
> Well, I can see that curl now has a --cert-status option, which works:
> 
> xvii:~> curl --cert-status https://www.vinc17.net:4434/
> curl: (91) SSL certificate revocation reason: (UNKNOWN) (-1)
> 
> Without it, no errors. :(
> 
> But most users and scripts don't use it (because it is new and/or they
> don't know it?), thus are potentially vulnerable to MITM attack.
> 
> Checking the certificate revocation status should be done by default
> for security reasons, like what lynx and wget now do thanks to the new
> GnuTLS version.

--cert-status only checks for the status_request TLS extension which is not
supported by most servers (which means curl will fail by default on most
requests). So no, curl will not enable the option by default, at least until
status_request catches on.

Cheers


signature.asc
Description: Digital signature

Bug#745837: curl should use a Certificate Revocation List by default

[Vincent Lefevre]

On 2014-04-28 09:46:10 +0200, Raphael Geissert wrote:
> [oh, so this was an MBF without discussing it on -devel, nice]

Please, stop your stupid remarks. This was not a MBF.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#745837: curl should use a Certificate Revocation List by default

[Vincent Lefevre]

Control: retitle -1 curl should check certificate revocation status by default

On 2014-04-26 13:19:35 +0200, Alessandro Ghedini wrote:
> TL;DR: let's do OCSP instead of downloading CRLs. It would still
> need someone to actually write the code though (ideally for all
> OpenSSL, GnuTLS and NSS).

Well, I can see that curl now has a --cert-status option, which works:

xvii:~> curl --cert-status https://www.vinc17.net:4434/
curl: (91) SSL certificate revocation reason: (UNKNOWN) (-1)

Without it, no errors. :(

But most users and scripts don't use it (because it is new and/or they
don't know it?), thus are potentially vulnerable to MITM attack.

Checking the certificate revocation status should be done by default
for security reasons, like what lynx and wget now do thanks to the new
GnuTLS version.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#745837: curl should use a Certificate Revocation List by default

[Raphael Geissert]

[oh, so this was an MBF without discussing it on -devel, nice]

On 25 April 2014 19:54, Vincent Lefevre  wrote:
[...]
> I suppose that though this is documented in the curl(1) man page
> (quite poorly), most users don't know that curl doesn't have any
> check for certificate revocation by default. Before the Heartbleed
> bug, this could be regarded a not very important. But now there
> may have been much more leaks than before. So, curl should use an
> up-to-date Certificate Revocation List by default (which it supports)
> or some other alternate method like Firefox.

I'm afraid that what you are asking is just a dream. CRLs aren't
usually used because there is no central mechanism to fetch and keep
them up to date on a system. Moreover, not all CAs provide them, which
causes sites using them to be broken - because no CRL + CRL checking =
verify error. OCSP transponder support and/or OCSP stapling support
would be nice but they are false solutions.

Please bring up the subject on -devel before mass bug filing, it would
have avoided it (in its current form at least).

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#745837: curl should use a Certificate Revocation List by default

[Vincent Lefevre]

On 2014-04-26 13:19:35 +0200, Alessandro Ghedini wrote:
> On sab, apr 26, 2014 at 09:05:25 +0200, Vincent Lefevre wrote:
> > On 2014-04-25 21:52:38 +0200, Alessandro Ghedini wrote:
> > > or 2) curl dowloads such list from the internet every time it opens
> > > an HTTPS connection.
> > 
> > not every time. It doesn't really make sense to download a list
> > again after a few seconds. There could be some "expire" setting of
> > a downloaded list (IMHO, the order of magnitude would be the day).
> > The user should also have the possibility to force a download
> > (like he can force a reload of a cached page).
> 
> curl is not a browser and it doesn't have a cache,

All applications can use a cache, and the place to store such data
is even standardized: look at the .cache directory. That's for users.
Or /var/cache at the system level.

> so it would need to be configured to save the CRLs somewhere.
> Picking a default for this kind of thing is hard, because people use
> curl in the weirdest ways (and they will complain).

I don't see why.

> Also, what about libcurl users?

I think that this should actually be part of libcurl. Some apps
could use libcurl to transmit sensitive data...

> Well, CRLs have an "expire date" (or "Next Update" date), which I think 
> clients
> are supposed to check that it's not in the past, and some (most?) CAs set it 
> to
> be after about a day after the date in which the CRL was last updated. If the
> local CRL is not updated accordingly, the clients would always fail. The 
> update
> would also be needed for stable releases, which is a huge PITA on its own.

I don't think that's a problem for stable: the package itself
doesn't need to be updated (well, one may decide the way it is
implemented).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#745837: curl should use a Certificate Revocation List by default

[Alessandro Ghedini]

On sab, apr 26, 2014 at 09:05:25 +0200, Vincent Lefevre wrote:
> On 2014-04-25 21:52:38 +0200, Alessandro Ghedini wrote:
> > or 2) curl dowloads such list from the internet every time it opens
> > an HTTPS connection.
> 
> not every time. It doesn't really make sense to download a list
> again after a few seconds. There could be some "expire" setting of
> a downloaded list (IMHO, the order of magnitude would be the day).
> The user should also have the possibility to force a download
> (like he can force a reload of a cached page).

curl is not a browser and it doesn't have a cache, so it would need to be
configured to save the CRLs somewhere. Picking a default for this kind of thing
is hard, because people use curl in the weirdest ways (and they will complain).
Also, what about libcurl users?

OCSP is better from this point of view, because it doesn't need anything to be
saved locally, but it still poses other problems (privacy, performance, ...).

FWIW, I think that firefox, as of v28, doesn't use CRLs anymore and only does
OCSP (and not even for all certificates) [0].

> > The "ca-crls" package would need someone to make it and keep it
> > updated daily to be of any use, and downloading random stuff from
> > internet for each connection doesn't sound too good either.
> 
> Even if it's not daily and if downloading a CRL is not done for each
> connection, it could be quite good. And if done in combination with
> another method such as OSCP / OCSP stapling, it would be even better.

Well, CRLs have an "expire date" (or "Next Update" date), which I think clients
are supposed to check that it's not in the past, and some (most?) CAs set it to
be after about a day after the date in which the CRL was last updated. If the
local CRL is not updated accordingly, the clients would always fail. The update
would also be needed for stable releases, which is a huge PITA on its own.

> > > or some other alternate method like Firefox.
> > 
> > If you mean OCSP, most browsers don't even bother using that by
> > default, not in a way that would make the user safe anyway [1]. The
> > alternative (OCSP stapling) is probably not supported by enough
> > servers to be useful (but I may be wrong).
> 
> Well, at least Iceweasel (which uses something based on OCSP) works
> on the example I've given.

The problems really start when the client is not able to contact the OCSP server
(as explained in the blog post I linked, browsers usually just ignore those
failures and proceed like everything is ok).

TL;DR: let's do OCSP instead of downloading CRLs. It would still need someone to
actually write the code though (ideally for all OpenSSL, GnuTLS and NSS).

[0] 
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/85MV81ch2Zo


signature.asc
Description: Digital signature

Bug#745837: curl should use a Certificate Revocation List by default

[Vincent Lefevre]

On 2014-04-25 21:52:38 +0200, Alessandro Ghedini wrote:
> On ven, apr 25, 2014 at 07:54:36 +0200, Vincent Lefevre wrote:
> > most users don't know that curl doesn't have any
> > check for certificate revocation by default. Before the Heartbleed
> > bug, this could be regarded a not very important. But now there
> > may have been much more leaks than before. So, curl should use an
> > up-to-date Certificate Revocation List by default (which it supports)
> 
> The problem with this kind of lists is that they need to be
> frequently updated,

Yes, that's the current problem with Chromium. The current one
distributed with Debian still doesn't have the certificates revoked
after the Heartbleed bug.

> so either 1) someone makes a package (like ca-certificates) that
> provides a crl,

and the data of such a package could be shared (like ca-certificates)
by various user agents that use CRL's. Such a list is currently needed
for Chromium.

> or 2) curl dowloads such list from the internet every time it opens
> an HTTPS connection.

not every time. It doesn't really make sense to download a list
again after a few seconds. There could be some "expire" setting of
a downloaded list (IMHO, the order of magnitude would be the day).
The user should also have the possibility to force a download
(like he can force a reload of a cached page).

> The "ca-crls" package would need someone to make it and keep it
> updated daily to be of any use, and downloading random stuff from
> internet for each connection doesn't sound too good either.

Even if it's not daily and if downloading a CRL is not done for each
connection, it could be quite good. And if done in combination with
another method such as OSCP / OCSP stapling, it would be even better.

> > or some other alternate method like Firefox.
> 
> If you mean OCSP, most browsers don't even bother using that by
> default, not in a way that would make the user safe anyway [1]. The
> alternative (OCSP stapling) is probably not supported by enough
> servers to be useful (but I may be wrong).

Well, at least Iceweasel (which uses something based on OCSP) works
on the example I've given.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#745837: curl should use a Certificate Revocation List by default

[Alessandro Ghedini]

On ven, apr 25, 2014 at 07:54:36 +0200, Vincent Lefevre wrote:
> Package: curl
> Version: 7.36.0-1+b1
> Severity: important
> Tags: security
> 
> I suppose that though this is documented in the curl(1) man page
> (quite poorly),

How would you improve it? It looks pretty clear to me.

> most users don't know that curl doesn't have any
> check for certificate revocation by default. Before the Heartbleed
> bug, this could be regarded a not very important. But now there
> may have been much more leaks than before. So, curl should use an
> up-to-date Certificate Revocation List by default (which it supports)

The problem with this kind of lists is that they need to be frequently updated,
so either 1) someone makes a package (like ca-certificates) that provides a crl,
or 2) curl dowloads such list from the internet every time it opens an HTTPS
connection.

The "ca-crls" package would need someone to make it and keep it updated daily
to be of any use, and downloading random stuff from internet for each
connection doesn't sound too good either.

In any case the problem of which list to use remains. We'd need to maintain a
crl for each CA in ca-certificates, and I don't see why that should be curl's
job (or we could use Google's crlset thingy [0], which is far from perfect).

> or some other alternate method like Firefox.

If you mean OCSP, most browsers don't even bother using that by default, not in
a way that would make the user safe anyway [1]. The alternative (OCSP stapling)
is probably not supported by enough servers to be useful (but I may be wrong).

Though I guess that it wouldn't hurt if curl supported it, and since most TLS
libraries provide the functionality it shouldn't be too hard to implement.

Cheers

[0] http://dev.chromium.org/Home/chromium-security/crlsets
[1] https://www.imperialviolet.org/2014/04/19/revchecking.html


signature.asc
Description: Digital signature

Bug#745837: curl should use a Certificate Revocation List by default

[Vincent Lefevre]

Package: curl
Version: 7.36.0-1+b1
Severity: important
Tags: security

I suppose that though this is documented in the curl(1) man page
(quite poorly), most users don't know that curl doesn't have any
check for certificate revocation by default. Before the Heartbleed
bug, this could be regarded a not very important. But now there
may have been much more leaks than before. So, curl should use an
up-to-date Certificate Revocation List by default (which it supports)
or some other alternate method like Firefox.

As an example, https://www.cloudflarechallenge.com/ could be tried.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages curl depends on:
ii  libc6 2.18-4
ii  libcurl3  7.36.0-1+b1
ii  zlib1g1:1.2.8.dfsg-1

curl recommends no packages.

curl suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org