Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 9:20 UTC (Tue) by slashdot (guest, #22014)
In reply to: Fraudulent *.google.com certificate issued by jwb
Parent article: Fraudulent *.google.com certificate issued

Can CRLs really be blackholed without warning?

If so, that's bad: the browser should connect to it via SSL (using a static certificate) and at least warn if connection fails.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 9:51 UTC (Tue) by cesarb (subscriber, #6266) [Link]

At least for OCSP, there is an option to fail the HTTPS connection if it cannot contact the OCSP server. Go to Preferences>Advanced>Cryptography>Validation and mark the last checkbox.

AFAIK, current browsers prefer to use OCSP instead of CRLs.

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 13:42 UTC (Tue) by cortana (subscriber, #24596) [Link] (5 responses)

This is possible using a process known as OCSP, but it causes its own problems:

* 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!

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 20:49 UTC (Tue) by paravoid (subscriber, #32869) [Link] (4 responses)

I have mandatory OCSP in my Firefox. Since I enabled it I had some hiccups here and there but nothing too important. I have, however, experienced a quite interesting situation:

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

Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 21:51 UTC (Tue) by raven667 (subscriber, #5198) [Link] (2 responses)

As someone who has a hand in a captive portal deployment what we've done is whitelist the IPs of the OCSP servers for the certs we are using to work around this problem so we don't have helpdesk complaints from customers who have OSCP enabled. A cron jobs can check to see if the IPs have changed.

Fraudulent *.google.com certificate issued

Posted Aug 31, 2011 16:34 UTC (Wed) by cesarb (subscriber, #6266) [Link] (1 responses)

Did you also whitelist all the needed DNS servers? When on untrusted networks, I usually run the bind DNS server on my laptop (querying directly the root servers) so it can validate the records using DNSSEC.

Fraudulent *.google.com certificate issued

Posted Aug 31, 2011 18:03 UTC (Wed) by raven667 (subscriber, #5198) [Link]

No, the only dns servers allowed through the captive portal prior to authentication are the recursive ones we maintain, these are what are suggested via DHCP. I imagine your config would break on a lot of captive portals unless they had blanket rules allowing any dns traffic.

Fraudulent *.google.com certificate issued

Posted Sep 1, 2011 7:58 UTC (Thu) by Comet (subscriber, #11646) [Link]

This problem is solved with OCSP stapling.