GNOME Bugzilla – Bug 636573
TLS CRL support
Last modified: 2018-05-29 06:50:19 UTC
We need to support CRLs (certificate revocation lists) in some way. If there is a standard location for storing CRLs on some distros, we should pick up CRLs there automatically. Likewise, if the GTlsCertificateDB (bug 636572) supports storing CRLs, we should pick those up automatically. It is not clear that there needs to be an API for adding CRLs; adding CRLs is something that a sysadmin would do (eg, by adding a .crl file to a directory), not that an application user would do.
Bug #728141 has more details on revocation.
*** Bug 728141 has been marked as a duplicate of this bug. ***
Here are some things I've said about certificate revocation previously. From bug #728141: "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." The link above is http://arstechnica.com/security/2014/04/how-heartbleed-transformed-https-security-into-the-stuff-of-absurdist-theater/ From https://wiki.gnome.org/Apps/Web/Roadmap/Security I wrote: """We don't currently check for revoked certificates. The problem with certificate revocation is that standard methods for revocation checking are arguably worse than performing no revocation checking at all. CRL causes the browser to take an eternity to download a potentially 40 MB CRL before loading a web page: that's not acceptable. No browser hard enforces OCSP responder failure and there's little value in OCSP unless we do. Plus, OCSP is a big privacy violation, which dramatically outweighs the benefits of using it if it's not hard enforced. OCSP stapling exists, but it's not useful unless we enforce OCSP. We should ship -- guess what -- a preload list of revoked certificates! It should be checked by glib-networking; this shouldn't need any work anywhere else. Guess what: it should be in a separate package, so it can be updated separately from glib-networking. Note that a revoked cert *anywhere* in the chain must invalidate the entire chain. Update: Look into using OneCRL for intermediate certificate revocation. We might have to give up on checking for revocation of individual certificates, though, since every option sucks.""" I haven't looked into this in a while and don't know the right thing to do.
*** Bug 777524 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/380.
Reopening. This bug was migrated to https://gitlab.gnome.org/GNOME/glib, but it should have been migrated to https://gitlab.gnome.org/GNOME/glib-networking.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib-networking/issues/32.