[cabfpub] [EXTERNAL] Brazilian bank DNS heist

Ryan Sleevi sleevi at google.com
Thu Apr 6 19:22:10 MST 2017


On Thu, Apr 6, 2017 at 10:09 PM, Ryan Sleevi <sleevi at google.com> wrote:

>
>
> On Thu, Apr 6, 2017 at 7:52 PM, Bruce Morton via Public <
> public at cabforum.org> wrote:
>
>> What if the bank used EV and there was an error if there was no EV
>> certificate?
>>
>>
>>
>> Could this be done by using something like an HSTS header which also
>> stated EV-only? When the Subscriber receives a DV certificate, but has
>> stored a header for EV-only, then there would be a browser error.
>>
>
> That exists already. It's called pinning. It's the only reason EV has any
> value, and doesn't need any UI.
>

It was pointed out that many CAs may not be familiar with this (which was
discussed in the IETF in the past)

Imagine CA "Acme CA" wants to provide value to its customers, by allowing
them to indicate "I only expect certificates that meet this CA's issuance
policies".

The meaningful way to do that is for "Acme CA" to create an intermediate
for each of its policies - e.g. DV, OV, EV (or, if you prefer, "Class 1",
"Class 2", "Class 3", etc) - and provide customers instructions to pin to
the appropriate intermediate for their security need.

That is, if "Foo Bank" wants to ensure that only EV certs are used, it
would pin to Acme CA's EV intermediate.
If "Foo Bank" wanted to ensure that OV or EV certs are used, it would pin
to Acme CA's OV and EV intermediates.

If "Foo Bank" wanted to pin to a variety of CAs, Foo Bank would determine
what each of these CA's intermediates are, and pin to those.

It requires a commitment on behalf of Acme CA to guarantee that its EV
certificate issuance will come from that intermediate. This is,
conceptually, no different than Acme CA guaranteeing that it won't assert
an EV policy OID if it didn't do the EV validation work (although recent
events have shown this does, on occasion, happen)

If CAs believe EV provides value for their customers, this is a way for
them to demonstrate it, by leveraging the existing technical solutions.
This was something discussed in the IETF. This is also why I've remarked
several times in the Forum about the value that CAA attributes could also
bring, to indicate/express such policies.

Absent that, however, EV doesn't provide any meaningful security boundary,
because it's subject to the same origin policy, and does not represent a
distinct origin in the web. This has been known since 2008 (
http://www.adambarth.com/papers/2008/jackson-barth-b.pdf ) as being a
critical flaw to the value proposition. It's also easily and empirically
showable that it would make EV certificates largely unusable. You can also
see both Opera's and Chrome's past attempts in this area (of ensuring EV
provided meaningful security by restricting all resources to EV resources
and/or same origin resources) as further examples of the complete lack of
market interest in this.

In any event, hopefully that clarifies for members how this technology
already exists, so long as pinning exists.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170406/d159f6ac/attachment.html>


More information about the Public mailing list