[SSL Observatory] State of SSL-brokenness: Google wants to disable CRL/OCSP

Adam Langley agl at google.com
Mon Feb 6 15:38:49 PST 2012


On Mon, Feb 6, 2012 at 4:47 PM, Ralph Holz <holz at net.in.tum.de> wrote:
> Unless your attacker is so strong he can control and suppress your IP
> traffic right at your gateway, OCSP will still work.

It's actually a little tough to imagine an attacker who can MITM your
SSL traffic, but not your OCSP traffic. Your ISP obviously gets both,
but there comes a point where your ISP probably routes the two traffic
flows to different backbones. But a backbone provider can BGP poison
your ISP and grab the OCSP traffic too.

So, if you continue the exercise, you get to the point where the
attacker is on a more minor network, in front of the server. But then
they can probably pass DV checks for that server and so, effectively
are the server to any CA who checks and can get a stream of
certificates issued.

It is possible to some up with some situations where soft-fail checks
might be effective (perhaps "what if you're in front of one instance
of a multi-homed server, which no CA happens to hit?"), but doing so
simply highlights the fact that it's basically worthless.

> I also hesitate because moving the revocation part into the browser
> updates doesn't seem very scalable. It will help by adding revocation
> info for important sites, sure, but where do you draw the line? How many
> sites do you want to add and monitor as a browser vendor? What about
> open source browsers - are they supposed to follow this lead and track
> revocations for x sites, by crawling the Web as Google can do? What
> about the many revocations that come without a reason (that might
> actually be the majority) - how should they be treated? And finally,
> will CAs be happy to comply here?

The first part of the argument was intended to convince one that we
have no effective revocation scheme at the moment. At that point,
anything is an improvement.

I suspect that, if we could actually just get the revocations with a
security impact, it would be manageable. But we are likely to end up
carrying more than that and will have to make a decision about where
to cut. That's not great and we would welcome an effective, deployable
revocation scheme. But I don't believe that carrying on with soft-fail
checking is on the path towards that.


Cheers

AGL



More information about the Observatory mailing list