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.

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

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).

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

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.

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.

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).

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, at least Iceweasel (which uses something based on OCSP) works
on the example I've given.

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].

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.
(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

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.

I don't see why.

I think that this should actually be part of libcurl. Some apps
could use libcurl to transmit sensitive data...
doesn't need to be updated (well, one may decide the way it is
implemented).

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

On 25 April 2014 19:54, Vincent Lefevre <vincent@vinc17.net> wrote:
[...]

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,

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

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.

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

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

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

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.
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.

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.

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

Control: tags -1 wontfix

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...).

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

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 <put nationality here> CAs, then do the same for every website and ISP.

How does this have anything to do with OCSP?

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.

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