#795958 lynx-cur: certificate revocation checking is buggy

Package:
lynx-cur
Source:
lynx
Submitter:
Vincent Lefevre
Date:
2023-04-26 10:03:03 UTC
Severity:
important
Tags:
#795958#5
Date:
2015-08-18 11:32:19 UTC
From:
To:
If I run

  lynx https://www.vinc17.net:4434/

I get

  SSL error:The certificate is NOT trusted. The certificate chain is revoked.
  -Continue? (n)

as expected. But If I set up a test server with the same certificate
with:

  openssl s_server -CAfile old.crt -key old.key -cert old.crt -www

(the default port being 4433) and run

  lynx https://www.vinc17.net:4433/

I don't get any error.

No such problem with Iceweasel, which says:

  Secure Connection Failed

  An error occurred during a connection to www.vinc17.net:4433. Peer's
  Certificate has been revoked. (Error code: sec_error_revoked_certificate)

With curl, I get:

$ curl --cert-status https://www.vinc17.net:4434/
curl: (91) Server certificate was revoked: unspecified reason
$ curl --cert-status https://www.vinc17.net:4433/
curl: (91) No OCSP response received

I wonder why curl doesn't get an OCSP response in the 4433 case,
but at least one gets an error.
#795958#10
Date:
2015-08-18 11:48:33 UTC
From:
To:
Try adding the "-status" option here.

I think the problem is that both lynx and curl only support OCSP stapling,
while firefox also does full-blown OCSP. So, if you don't enable OCSP stapling
in s_server (with the -status option), lynx and curl won't receive any response,
while firefox will also try to contact the CA's OCSP server and receive a
response from that.

It's more like lack of a feature than an actual bug (hardly RC material though,
IMO).

Hope this helps.

Cheers
#795958#15
Date:
2015-08-18 12:27:39 UTC
From:
To:
This doesn't change anything.

Supporting OCSP stapling only without an error in case of no response
is completely useless, and worse, this gives a false sense of security,
because an attacker won't provide OCSP stapling in his own fake server.

Full OCSP is a lack of feature. Not giving an error (possibly with
whitelists/blacklists of known sites) is a bug. Ideally there would
be 4 choices in case of lack of OCSP response:

1. Accept and whitelist.
2. Accept.
3. Reject.
4. Reject and blacklist.

The whitelist/blacklist is there to remember the answer for future
connections.

(When/if full OCSP is implemented, there should be the same kind of
choices in case the OCSP server cannot be reached.)