bugGNU Wget - Bugs: bug #43799, wget should implement OCSP + OCSP...


bug #43799: wget should implement OCSP + OCSP stapling

Submitter:  Vincent Lefèvre <vinc17>
Submitted:  Wed 10 Dec 2014 10:51:23 PM UTC
Category:  Protocol Issue Severity:  3 - Normal
Priority:  5 - Normal Status:  None
Privacy:  Public Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  None Operating System:  None
Reproducibility:  None Fixed Release:  None
Planned Release:  None Regression:  No
Work Required:  None Patch Included:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Thu 14 Jul 2016 01:02:45 PM UTC, comment #12: 

fyi, this bug can be tested with https://revoked.grc.com/

other potentially useful resources:

Wed 19 Aug 2015 03:52:38 PM UTC, comment #11: 

Concerning the OCSP responder, I suppose that the response has some sort of signature, in which case there would be no insecurity.

Vincent Lefèvre <vinc17>
Wed 19 Aug 2015 03:37:06 PM UTC, comment #10: 

Wget does not have 'normal' OCSP built in.
Well, OCSP stapling works transparently within GnuTLS and is turned on by default.

When GnuTLS comes back with GNUTLS_CERT_REVOKED and all we can do is to say "The certificate of %s has been revoked". Because I know of now way to say if this is because of OCSP stapling or due to loaded CRL files.

But OCSP stapling only holds the OCSP response for one (the server's) certificate. Most servers today seem to have a chain of certs... OCSP stapling alone gives one more check but no security.

Regarding MITM and other attacks... did you notice that OCSP responder URLs are HTTP (plain text) will all the insecurity ? I never saw a HTTPS URL, did you ?

BTW, https://www.google.de still has a 3 cert chain, one of them without AIA element (so no possibility for OCSP / rervokcation checking).

Tim Ruehsen <rockdaboot>
Group administrator
Wed 19 Aug 2015 11:14:21 AM UTC, comment #9: 

I tested only wget 1.16.3 (the Debian/unstable package) for the moment. The error comes from OCSP stapling. If I do the same tests with port 4433 (where I have a temporary test server with "openssl s_server -CAfile old.crt -key old.key -cert old.crt -www", without OCSP stapling support), I don't get the revocation error. A clearer message would be better.

If OCSP responder information is missing, there should be an error because in case of MITM attack (which is the main reason why certificates are used), the attacker will probably try to block OCSP responders if the attack occurs at the Internet access point of the user (e.g. wifi hotspot) or on the local network. But this could be configurable via an option.

Vincent Lefèvre <vinc17>
Wed 19 Aug 2015 10:14:34 AM UTC, comment #8: 

Vincent, or is the revocation due to OCSP stapling ?
I guess it is... so the OCSP responder has been asked by the server and the answer has been included in the TLS handshake.
That's why we get "The certificate has been revoked.".

Should we amend this message to "The certificate has been revoked via OCSP stapling." ?

Well, when I implemented OCSP, Google was missing an OCSP responder information in one of their certs. I wasn't sure what was going on, so I let wget2 continue in this case.
I just saw, the google cert chain seems to be fixed now.

Should stop/error in case OCSP responder information is missing ?

Tim Ruehsen <rockdaboot>
Group administrator
Wed 19 Aug 2015 09:57:55 AM UTC, comment #7: 

Thanks for testing wget2 (to correct myself: it is branch 'tim/wget2').

Some part of your cert chain has been revoked. GnuTLS determines that even before asking any OSCP responder.
So, the message from GnuTLS is somewhat wrong, maybe a GnuTLS bug ?

I can't see any better from
gnutls-cli -d3 -V -p 4434 www.vinc17.net

I guess, someone has to dig into the GnuTLS code.

Tim Ruehsen <rockdaboot>
Group administrator
Tue 18 Aug 2015 01:49:06 PM UTC, comment #6: 

If I understand correctly, the "revoked" error I get with

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

is due to some check done by GNUTLS, but this is not sufficient. Wget doesn't report anything in case of lack of OCSP response (which would typically be the case in an attack).

Vincent Lefèvre <vinc17>
Thu 13 Aug 2015 07:49:57 AM UTC, comment #5: 

OCSP Stapling is available in git branch 'wget2'.
So Wget2 is in work (experimental, but working), but not yet publically promoted. A backport of OCSP code to Wget1.x will come sooner or later...

Tim Ruehsen <rockdaboot>
Group administrator
Thu 13 Aug 2015 03:48:41 AM UTC, comment #4: 

GnuTLS supports OCSP since Version 3.0.12 (released 2012-01-20) according to its NEWS file:

** libgnutls: Added OCSP support.

In Debian, with the wget 1.15-1 package (which was already built with GNUTLS 3.2+), the revocation was not checked. According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745835#104 (about lynx), the actual fix in GnuTLS was done in the 3.3.14-2 Debian package, which was upgraded from 3.3.8-7, and this is what I observed. But I don't know what changed exactly.

Vincent Lefèvre <vinc17>
Wed 12 Aug 2015 11:31:30 PM UTC, comment #3: 

Starting from which versions of wget and GnuTLS is OCSP supported?

Deborah <eezzubre>
Mon 04 May 2015 12:33:23 AM UTC, comment #2: 

OK, it wasn't clear that GnuTLS had to implement OCSP, which is actually better since all software linked with GnuTLS can benefit from it. So, now I can see in Debian/unstable (which now has a new GnuTLS version):

$ wget https://www.vinc17.net:4434/
--2015-05-04 02:21:07--  https://www.vinc17.net:4434/
Resolving www.vinc17.net (www.vinc17.net)..., 2001:4b98:dc0:45:216:3eff:fe9b:eb2f
Connecting to www.vinc17.net (www.vinc17.net)||:4434... connected.
ERROR: The certificate of ‘www.vinc17.net’ has been revoked.

I suggest that the wget man page says that OCSP support is done by GnuTLS. Well, something like that.

Vincent Lefèvre <vinc17>
Thu 11 Dec 2014 03:42:03 PM UTC, comment #1: 

Thanks, Vincent.

I already put some time into it (GnuTLS OCSP stapling doesn't work correctly for most servers that elsewise support it - will be fixed in next GnuTLS version).

I continue on it when the reports for Wget 1.16.1 calm down...

Tim Ruehsen <rockdaboot>
Group administrator
Wed 10 Dec 2014 10:51:23 PM UTC, original submission:  

CRL checking has been implemented, but except in some particular cases, it is not very useful in practice as there seems to be no way to get a comprehensive CRL file.

So, OCSP + OCSP stapling should be implemented. There should be an option allowing the user to choose what to do if no stapling information is provided: either return a failure, or use conventional OCSP (with a failure if this fails too).


  • OCSP stapling isn't implemented on every server, but neither is https anyway. Users should be encourage to complain at server admins if this is not the case.
  • Conventional OCSP has (minor) privacy issues, hence the choice to get a failure instead of using conventional OCSP as a fallback. Unchecked certificate revocation could lead to much more critical privacy leak in case of MITM attack. And also note that DNS and e-mail also have privacy issues (but people still use them) and most users leave more important private data so that they probably don't care.
Vincent Lefèvre <vinc17>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by eezzubre (Posted a comment)
  • -email is unavailable- added by rockdaboot (Posted a comment)
  • -email is unavailable- added by vinc17 (Submitted the item)

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.12.
    Corresponding source code