Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Fraudulent *.google.com certificate issued
Posted Aug 30, 2011 4:59 UTC (Tue) by butlerm (subscriber, #13312)
The advantage of doing it in the client software is that no one can block it unless they can compromise the software itself. The disadvantage is that it takes a software update or upgrade to become effective.
On the other hand, the CRL server or distribution point is generally operated by the corresponding CA, so if you don't trust the CA you have no alternative than to remove it from your trust list.
Posted Aug 30, 2011 5:18 UTC (Tue) by butlerm (subscriber, #13312)
Posted Aug 30, 2011 9:20 UTC (Tue) by slashdot (guest, #22014)
If so, that's bad: the browser should connect to it via SSL (using a static certificate) and at least warn if connection fails.
Posted Aug 30, 2011 9:51 UTC (Tue) by cesarb (subscriber, #6266)
AFAIK, current browsers prefer to use OCSP instead of CRLs.
Posted Aug 30, 2011 13:42 UTC (Tue) by cortana (subscriber, #24596)
* It's up to the CA whether to use OCSP or not. Most don't.
* There is a performance hit associated with doing the OCSP query. You don't want every outgoing connection you make to trigger a query, so you have to cache the responses.
* You disclose to the CA which web sites you visit, how often you visit them and how long you remain there. I don't think the connection to the OCSP server is itself encrypted, so anyone between you and the server will also become privy to this information.
* If the OCSP server is down and your browser is configured to ignore the failure, then a DOS attack on the OCSP server could compromise your security as you wouldn't know that a server's certificate has been revoked.
* If the OCSP server is down and your browser is configured to fail the connection, a DOS attack on the OCSP server becomes a DOS attack on all the web sites that use it.
If browser makers were serious about security then they would insist that every CA certificate they ship either:
* maintain an OCSP server; if so, connections to a web site must fail if an OCSP response can not be obtained
* publish CRLs; if so, the browser must be pre-configured to update each CA's CRL at regular intervals and refuse to connect to a web site if a recent CRL for the site's CA is not present.
I just checked Firefox, and it doesn't know about CRLs for *any* of the CAs whose certificates it ships, let alone automatically update them. I also checked Chrome, and it doesn't even have a UI for managing CRLs!
Posted Aug 30, 2011 20:49 UTC (Tue) by paravoid (subscriber, #32869)
Commercial Wi-Fi hotspots usually redirect your traffic to their own website where you can buy a short-term pass or a subscription.
Since a) those WiFi networks are non-encrypted, b) they require either a short code that's equivalent to some money paid or your credit card, it's frequent to see HTTPS being used on their captive portal.
But the hotspot doesn't allow any kind of traffic besides connecting to the captive portal and even redirects HTTP requests that try to connect elswhere.
which breaks OCSP. And present you with a nice chicken-and-egg problem.
(yes, they're broken by design, and yes I know about iodine :))
Posted Aug 30, 2011 21:51 UTC (Tue) by raven667 (subscriber, #5198)
Posted Aug 31, 2011 16:34 UTC (Wed) by cesarb (subscriber, #6266)
Posted Aug 31, 2011 18:03 UTC (Wed) by raven667 (subscriber, #5198)
Posted Sep 1, 2011 7:58 UTC (Thu) by Comet (subscriber, #11646)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds