Re: Exposing TLS & Certificate Information in Javascript

How would a mitm with a legitimate cert for example.com be thwarted at all
by SOP? They wouldn't. Its the whole definition of same origin, because the
MITM is pretending to be... The same origin.
On Mar 3, 2014 9:00 PM, "Anders Rundgren" <anders.rundgren.net@gmail.com>
wrote:

> It is possible that I'm off here but assuming we are talking about
> network-based
> MITM-attacks rather than a broken platform/browser, wouldn't SOP make it
> impossible
> for a MITM to use the client's key?
>
> Well, if there is an attack on DNS that wouldn't help and I guess that's
> is an inherent
> weakness of the SOP concept which requires other measures to be be
> thwarted, right?
>
> Anders
>
> On 2014-03-03 23:30, Ryan Sleevi wrote:
> >
> >
> > On Mar 3, 2014 3:21 PM, "Lyor Goldstein" <lgoldstein@vmware.com <mailto:
> lgoldstein@vmware.com>> wrote:
> > >
> > > I was wondering about the feasibility of the following feature that
> could
> > > benefit from exposing the TLS certification chain:
> > >
> > > - Server generates a random challenge in the web page
> > > - Client signs a hash of the challenge + the full TLS certification
> chain
> > > - as obtained from the javascript DOM model (the proposed enhancement)
> > > - Server makes sure that the signature matches - using the client's
> > > pre-registered public key and knowledge of its own certificate
> > >
> > > In effect, we are doing a variation on certificate pinning - even if
> the
> > > MITM has obtained a CA certificate and is able to fool the client into
> > > believing that a trusted signed certificate is presented, it cannot
> > > convince the server since (a) it does not have the clients private key
> and
> > > (b) the server "knows" which certificate it provided. Therefore, even
> if
> > > the MITM can create a certificate with its own key, it cannot forge the
> > > server's certificate (but with its own key), thus the client's
> signature
> > > will not match.
> > >
> >
> > What prevents the attacker from directing the client JS to sign the
> original server's certificate chain in script (eg: using RSASSA)?
> >
> > It would need to be an entirely new signature algorithm in order to be
> secured.
> >
> > If we do go down that route, it is functionally identical to what FIDO
> would like to use WebCrypto for (signing a combination of 'untrusted' data
> - the hash - and 'trusted' data only the UA supplies - the origin, channel
> ID, etc)
> >
> > Of course, to evaluate why to expose this, it requires understanding why
> you want to, and whether any proposal can meet those security requirements.
> For reinventing pinning, I think any proposal will be fundamentally flawed,
> but perhaps you were just making the analogy for brevity.
> >
> > To emphasize: I do not believe WebCrypto can or should try to prevent
> MITM.
> >
> > > P.S. Even leaving this aside - I was wondering why is it such an
> effort to
> > > expose currently loaded page certificate chain (for read-only) ? After
> > > all, the browser has this information anyway
> > >
> > >
> >
> > TL;DR - don't reinvent pinning in JS. Use real pinning.
> >
> > Because there is no such concept as "a connection" in a web page. Its an
> artifact of loading, but there is no way to reliably and consistently know
> what the certificate(s) were.
> >
> > There's the connection used to load the HTML. The connection used to
> load the JS (since surely you're not doing inline JS). And any number of
> other connections. And maybe it was cached. Or used ServiceWorker/AppCache.
> And maybe the connection followed a series of redirects that involved
> different servers. Or renegotiations.
> >
> > The Web is connectionless.
> >
> > Certificate information is fundamentally connection oriented.
> >
> > And before anyone says "Use what you show in the UI for the lock", this
> fundamentally ignores the use case of why you want to bind to the cert -
> and how you can fundamentally subvert it.
> >
>
>