Re: Exposing TLS & Certificate Information in Javascript

On Sat, Feb 2, 2013 at 7:39 AM, David Dahl <ddahl@mozilla.com> wrote:
> Perhaps one thing that browser vendors can do is make new window or navigator properties like this to be immuntable by the content JS - wouldn't that help with evil scripts spoofing them?
>
> David

Not quite - especially NOT if you're trying to argue it for any
security benefit (as Aymeric is).

Consider for example the grotty "while(1)" hacks that exist out there
( http://stackoverflow.com/questions/4828413/what-does-while1-in-gmail-do
), which due to either older browsers or inherently due to origin
security models, exist to prevent script/JSON from being loaded into a
'hostile' environment. For example, replacement of string or Array
prototypes.

Even if there was a "perfect" system, in which all of the DOM and the
JS runtime was sealed, models such as what is being promoted by
Aymeric are inherently and fundamentally insecure - in that it they
breaks the entirety of SOP and that it relies on JS within a
compromised environment being able to detect that it's within a
compromised environment.

If you want to talk about value-added benefits of exposing TLS
details, I suspect it may make most sense within the context of items
like postMessage, where you may wish to expose more details than just
the requesting origin, such as any channel-bound identities [1]
(provided, of course, that the /requesting/ site opted-in). Those
sorts of properties provide much more interesting security
compositions, and in a way that does not ignore or attempt to bypass
browser security mechanisms.

[1] http://tools.ietf.org/html/draft-balfanz-tls-channelid-00

>
> ----- Original Message -----
> From: "Tom Ritter" <tom@ritter.vg>
> To: "Ryan Sleevi" <sleevi@google.com>
> Cc: public-webcrypto-comments@w3.org
> Sent: Saturday, February 2, 2013 8:51:38 AM
> Subject: Re: Exposing TLS & Certificate Information in Javascript
>
> Well, that's a pretty convincing rebuttal.  It doesn't address use
> case #7 which is "I really really want it" though ;)
>
> Really, it just doesn't really make sense to me why this information
> wouldn't be exposed to javascript (for the main page and all
> subresources), along with things like page loading time, render mode,
> to short circuit all these page performance hacks we have - the answer
> is obvious: ask the browser for the performance times and the ssl
> information.  It should have been there 5 years ago, and when things
> started focusing on SSL all sorts of Browser Plugins and tricks could
> have been deployed.
>
> But today, arguing "You should implement this" with an implicit
> ["instead of HPKP", "instead of TLS 1.2", "instead of something else
> valuable"], it makes less sense.  And you're right - for most of my
> use cases, HPKP does work, and for the major lapse you identify
> neither my proposal nor HPKP work.  And while I can nitpick and rebutt
> individual statements, or say something like "add it as a subproperty
> of every object that could load an external resource" - they're not
> things that ultimately resolve the disconnect between the multi-origin
> issue and the primary use case (detecting maliciousness), or provide
> value that HPKP doesn't.
>
> I still have this nagging sense of "This surely could be used for
> other reasons though", and I'm going to keep thinking about it ;)
> Maybe it'll be my first patch submission to a browser.
>
> -tom
>

Received on Monday, 4 February 2013 00:49:06 UTC