After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 728141 - Consider checking certificate revocation status
Consider checking certificate revocation status
Status: RESOLVED DUPLICATE of bug 636573
Product: glib
Classification: Platform
Component: network
2.40.x
Other Linux
: Normal enhancement
: ---
Assigned To: gtkdev
gtkdev
: 733228 (view as bug list)
Depends on:
Blocks: 721283
 
 
Reported: 2014-04-14 00:49 UTC by Michael Catanzaro
Modified: 2015-12-22 20:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
visiting website with gnutls-cli (3.06 KB, text/plain)
2014-04-14 00:49 UTC, Michael Catanzaro
Details

Description Michael Catanzaro 2014-04-14 00:49:03 UTC
Created attachment 274222 [details]
visiting website with gnutls-cli

When visiting [1] I noticed some disturbing text: "Can you see this site? You shouldn't be able to, we have revoked the certificate. If you can still see this message, Certificate Revocation may be broken in your browser."

This may be an issue in gnutls. If I run 'gnutls-cli --ocsp www.cloudflarechallenge.com' (output attached) I see the following in the middle of the result, which looks bad:

Cannot find URL from issuer: The specified algorithm or protocol is unknown.
Cannot contact OCSP server
*** OCSP response ignored

Firefox won't let me visit the page: "Peer's Certificate has been revoked. (Error code: sec_error_revoked_certificate)"

I'm using Epiphany 3.12.0, glib-networking 2.40.0, and gnutls 3.1.20.

[1] https://www.cloudflarechallenge.com/heartbleed
Comment 1 Michael Catanzaro 2014-04-14 03:17:49 UTC
I think glib-networking simply does not support certificate revocation, independent of the error I'm getting above.
Comment 2 Michael Catanzaro 2014-04-16 00:38:27 UTC
Another site Epiphany happily displays is [1]

I see that GLib has a G_TLS_CERTIFICATE_REVOKED flag, so Epiphany is probably right to assume that this is handled for us?  That flag will be set by g_tls_certificate_gnutls_verify() if gnutls_x509_crt_list_verify() returns GNUTLS_CERT_REVOKED, but that can never happen since no certificate revocation list is passed to gnutls_x509_crt_list_verify().

Dan, I think you're the expert here -- any recommendations as to the best path forward?  Looks like gnutls 2 supports PKIX CRLs, and it can also do OCSP if we require version 3 (I think there turned out to be no legal issues with that, correct?). [2]

[1] https://revoked.grc.com/
[2] http://www.gnutls.org/manual/html_node/More-on-certificate-authentication.html#More-on-certificate-authentication
Comment 3 Dan Winship 2014-04-16 01:05:26 UTC
Yeah, I think the fix is to redo the verification code to let gnutls handle more of it, so we get OCSP.
Comment 5 Michael Catanzaro 2014-07-16 03:31:29 UTC
*** Bug 733228 has been marked as a duplicate of this bug. ***
Comment 6 Michael Catanzaro 2015-02-21 23:14:14 UTC
Anyone implementing this should research Chrome's CRLSet method of revocation checking. Please, do not implement standard CRL or OCSP. There is no shortage of articles on the Internet about why these both suck, but the link above is a place to start.
Comment 7 Michael Catanzaro 2015-12-22 20:55:55 UTC

*** This bug has been marked as a duplicate of bug 636573 ***