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

 
 

bug #43799: wget should implement OCSP + OCSP stapling

Submitted by:  Vincent Lefèvre <vinc17>
Submitted on:  Wed 10 Dec 2014 10:51:23 PM UTC  
 
Category: Protocol IssueSeverity: 3 - Normal
Priority: 5 - NormalStatus: None
Privacy: PublicAssigned to: None
Originator Name: Open/Closed: Open
Release: NoneOperating System: None
Reproducibility: NoneFixed Release: None
Planned Release: NoneRegression: No
Work Required: NonePatch Included: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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:
https://www.grc.com/revocation.htm

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

Tim Ruehsen <rockdaboot>
Project 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 http://www.vinc17.net

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

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

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

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.
Vincent Lefèvre <vinc17>

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    No Changes Have Been Made to This Item

    Back to the top


    Powered by Savane 3.1-cleanup1