Re: [TLS] New version of Multiple OCSP mode of Certificate Status

[Marsh Ray <[e-mail]>]

On 08/04/2010 01:01 PM, Adam Langley wrote:
> On Wed, Aug 4, 2010 at 1:47 PM, Martin Rex<[e-mail]>  wrote:
>> Using any information in certificates that have not been verified to
>> perform resource-intensive operations is a security problem.  But
>> accessing an arbitrary URL presented in an completely unverified
>> End-Entity certificate is a "Freddy Krueger" waiting for his next victim.
>
> That seems a little hyperbolic. Accessing completely unverified URLs
> is something that browsers do for every single web page.

So if someone sent you a list of every known attack site you'd see no 
problem with visiting them all?

What if the attacker got to choose just one for you to visit?

Just got back from Defcon, the "top tweet" was "I strongly recommend 
against hitting jailbreakme.com from the #defcon wifi. Modifying that 
payload for malicious pwnage is not hard."
https://twitter.com/esizkur/status/20089522350

This is where the "in theory/practice there is/is not a difference 
between practice/theory" gets real. Probably the best approximation of 
the truth is somewhere in between.

Retrieving a cert via HTTP as part of the validation process is surely 
not as risky as running a web page with all types of active content and 
3rd party plugins, and if there's an exploitable bug in those lower HTTP 
or X509 layers, you're probably already owned.

But this isn't the kind of risk that's statistical, like earthquakes or 
meteors. The attacker gets to choose nearly all of the inputs to the 
transaction. He can thus select the tiniest, most vulnerable, part of 
the possible parameter space and only needs to be right once.

So is seems to me the best design principle is to avoid unnecessary 
interactions with unverified servers and handling unverified data as 
much as practical. When it's done, it should be with at least some 
justification and an acknowledgement it's a risk/benefit tradeoff.

- Marsh