Re: Exposing TLS & Certificate Information in Javascript

On Mar 3, 2014 11:05 PM, "Anders Rundgren" <anders.rundgren.net@gmail.com>
wrote:
>
> On 2014-03-04 07:23, Ryan Sleevi wrote:
> >
> >
> > On Mar 3, 2014 9:23 PM, "Anders Rundgren" <anders.rundgren.net@gmail.com<mailto:
anders.rundgren.net@gmail.com>> wrote:
> > >
> > > On 2014-03-04 06:14, Ryan Sleevi wrote:
> > > >
> > > > How would a mitm with a legitimate cert for example.com <
http://example.com> <http://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.
> > > >
> > >
> > > 100% agreed.
> > > I was only referring to the traditional phishing use-case which at
least previously has been the #1 MITM attack.
> > >
> > > Staying there, couldn't TLS certificate information be useful in a
cross-origin (postMessage) scenario?
> > > I.e. the callee could perform its own checking on the callers' TLS
certificates.  I'm thinking merchants here...
> > >
> > > thanx,
> > > Anders
> > >
> >
> > Again, impossible to do securely for the reason I mentioned.
> >
>
> Securing the authenticity of the primary (callee) domain?  As you say
this is not a task for WebCrypto.
>
> Performing checks on callers' TLS certificates obtained through
postMessage should though be possible if this property is an intrinsic part
of an enhanced postMessage.
> AFAICT channel-ID depends on something similar as well:
> http://developer.chrome.com/extensions/runtime#type-MessageSender
>
> Anders

Not at all the same.

Channel ID is not connection oriented in the way that certificates are, and
as I have already explained (again) just a few messages ago. Nor is this
API without its limitations - limitations acceptable in the context of
extensions, but not at all acceptable for the web.

Regardless, it seems we've reached agreement that there is no actual
security value to be had here, so now we're just discussing things that
maybe nice to have - and without a clear use case, such a conversation is
somewhere between pointless to detrimental.

I can only see harm coming from this - especially from the well-intentioned
but misguided developers who may believe this does actually provide a
security benefit. We owe it to them and ourselves not to give in to feature
creep without clearly defining the purpose of such features and the
security boundaries (to which there is none).

Someone who is motivated for this can always write up a spec proposal and
see if the WG feels it is in charter (I believe it may be listed under
secondary features - ones we've agreed to table for now) and whether such a
spec is something the WG should adopt. If someone wants to put forward a
spec that can actually address the issues rather than sleigh-of-hand them
away, it might be interesting to discuss - but I don't believe such a thing
is possible.

>
> > >
> > > > On Mar 3, 2014 9:00 PM, "Anders Rundgren" <
anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>
<mailto:anders.rundgren.net@gmail.com <mailto: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> <mailto:
lgoldstein@vmware.com <mailto:lgoldstein@vmware.com>> <mailto:
lgoldstein@vmware.com <mailto:lgoldstein@vmware.com> <mailto:
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.
> > > >     >
> > > >
> > >
> >
>