Re: Origin-signed responses

On Thu, Sep 07, 2017 at 10:24:35AM -0700, Jeffrey Yasskin wrote:
> On Wed, Sep 6, 2017 at 12:30 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
> 
> > On Wed, Sep 06, 2017 at 11:48:49AM -0700, Jeffrey Yasskin wrote:
> > >

> > Well, being able to replace the certificate with different one with the
> > same key in key exchange is regarded to break the key exchange
> > security.
> >
> > Such certificate replacement is especially bad if client trusts other
> > attributes besides the key and the domain names.
> >
> > TLS does have extension for sending the client certificate as URL. That
> > extension does carry SHA-1 (yeah, I know) hash of the certificate in
> > order to defend against certificate substitution.
> >
> 
> That's an odd threat, but sure, it looks straightforward to include the
> certificate chain in the signed bytes, like TLS does (
> https://tools.ietf.org/html/draft-ietf-tls-tls13-21#section-4.4.3).

Yes, it is odd, but considering key exchange vulernable to similar
issue is considered broken...

> > 2) Is this more sensitive than an attacker's page being able to write an
> > > <img src=https://sensitive.info/>? I don't really see how. I can imagine
> > > that we'll need a failed certificate fetch to have the same result as a
> > > successfully-fetched but untrusted certificate.
> >
> > Not really. I meant more references to resources that are not available
> > in globally routed addresses (especially local LAN addresses).
> >
> > Requiring CORS preflights for external chains would likely take care of
> > most of it.
> >
> 
> An <img> tag can also refer to resources that aren't available in
> globally-routed addresses, and we only require CORS for those if the page
> wants to read the content of the image. Since we're not letting the
> attacker (author of the "signed" response) read the content of the
> certificate, just use it to validate the signature, I don't yet see the
> need for CORS. What's the attack here?
> 
> I think the attacks along these lines in
> https://tools.ietf.org/html/rfc6066#section-11.3 don't apply, since an
> attacker who can get a client to download a package and then retrieve
> certificates referenced from it, can also get the client to perform the
> same fetches in other ways.

I think there are proposals to require (special) CORS for all requests
to local scope (LAN, localhost) from global scope.

> > The last is especially significant if the CA does not actually support
> > CT. And stapling to certificate is technically more difficult to
> > implement than stapling to OCSP (if webservers actually properly
> > supported OCSP stapling, I would think that CAs would much rather
> > staple CT to OCSP than certificates... If they did the stapling at
> > all.)
> >
> 
> I'm not sure it's worth supporting the use case of a CA that doesn't
> support CT, since Chrome's going to require them all to support CT in 7
> months (
> https://groups.google.com/a/chromium.org/d/topic/ct-policy/sz_3W_xKBNY/discussion).
> That said, if we staple OCSP responses using the TLS CertificateEntry
> format, SCTs fit in exactly the same place.

AFAIK, Chrome will accept staples via dedicated TLS extension, which
does not need CA support.

And to extend the argument, if webservers actually properly supported
CT stapling, there would probably be CAs that did not do anything with
CT, even after Chrome switching to require CT for all new certs.



-Ilari

Received on Sunday, 10 September 2017 12:46:39 UTC