Re: Exposing TLS & Certificate Information in Javascript

Maybe my "spec summary" section for ianonym is not detailed enough or 
you read it too fast, because that's the complete opposite of what you 
interpret, see answers below.

Let's imagine we don't care about what people could do with it and there 
is no technical complexity to do it, as Tom's wrote, basically :

"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)"

Maybe the misunderstanding is that you still think that the examples I 
gave have something to do with the page verifying itself, it does not.

See next answer too.


Le 04/02/2013 01:48, Ryan Sleevi a écrit :
> 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).

I have never said that, browsers are already implementing things where 
DOM properties have some "magic" behavior, for example you can not 
shadow or redefine window.location.href, I mentioned it in the previous 
email and you did not comment, and I said that's it's a defect in fact 
because there are no reasons why DOM attributes should have some magic 
not complying with the standards. As another example I have sketched a 
home made Object.observe for ianonym in the meantime it is available, 
and the results are surprising, each browser has its own behavior, going 
to write something about it one day.

>
> 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.

Well known example, I don't see the relationship with the rest.

>
> 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.

The system I am promoting has (again) nothing to do with compromising 
SOP, the browser does exactly what it has to do with the resources 
loaded except that the domains are hidden, and foreign scripts can not 
attack the ianonym script, probably I should give more details about it 
but it's based on known secure js technics (like SES concepts) and 
context separation.

At the end it's much more secure than whatever exists, because there is 
no point in attacking you on a fake domain and everything that is 
usually bothering you will be removed from the page or controlled.

>
> 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.
That's exactly how I intend to do it, the page will not verify itself, 
it will be verified by the js OP via postMessage (probably)

> [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
>>

-- 
jCore
Email :  avitte@jcore.fr
iAnonym : http://www.ianonym.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Web :    www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com

Received on Monday, 4 February 2013 10:39:47 UTC