Re: Exposing TLS & Certificate Information in Javascript

On Wed, May 29, 2013 at 7:50 PM, Douglas Stebila <stebila@qut.edu.au> wrote:
> On 2013/05/30, at 12:37, Ryan Sleevi wrote:
>
>> What protection does this actually provide in the event of a MITM? I would argue none - hence why I am not terribly convinced its worth the effort.
>>
>> You're relying on JS delivered by an attacker to do the cryptographic binding to the server's cert. The attacker will simply prompt the user (...in JS) for their password, then rebind that to the "real" server's public key.
>>
>> You get absolutely zero of the security value of channel bindings in that scheme - because you are forced to trust the attacker.
>>
>> Solving the "secure delivery of code" is a non-goal of this WG. Trust TLS (which your model, by design, does not) or use SysApps (as I earlier suggested) have been the two responses so far for this problem.
>
> Which is why we deliver code as an extension that has to be installed, not via the HTML page over the channel.  It could also be done as a Javascript bookmarklet, I suppose.
>
> Douglas

Javascript bookmarklet's won't help, because they'll run in the
security context of the attackers page.

If your extension relies on injecting code into the attackers page,
sorry, but it's a flawed security model. They may have done any number
of hijinks (such as replacing object prototypes on objects critical
for your security discussion).

It only makes sense when the script is executed fully outside of the
context of the attackers page (that is, the page you're trying to
secure). That's why I suggest an entirely different API discussion is
needed for such cases.

Received on Thursday, 30 May 2013 16:09:41 UTC