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

other potentially useful resources:
https://www.grc.com/revocation.htm

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

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 ?
WDYT ?

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

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.

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)... 92.243.22.117, 2001:4b98:dc0:45:216:3eff:fe9b:eb2f
Connecting to www.vinc17.net (www.vinc17.net)|92.243.22.117|: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.

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

Notes:

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