Fraudulent *.google.com certificate issued

Posted Aug 30, 2011 20:49 UTC (Tue) by paravoid (subscriber, #32869)
In reply to: Fraudulent *.google.com certificate issued by cortana
Parent article: Fraudulent *.google.com certificate issued

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.