ES Native Mode proposal

David Bruant bruant.d at
Thu Sep 26 03:59:35 PDT 2013

Le 26/09/2013 12:16, Aymeric Vitte a écrit :
> Le 26/09/2013 11:43, David Bruant a écrit :
>> Le jeu. 26 sept. 2013 11:11:40 CEST, Aymeric Vitte a écrit :
>>> For those interested I provided in the CSP thread a link to a FF bug
>>> report where it's explained how some security policy (here Websocket
>>> spec) forces me to do insecure things. I don't know what list can take
>>> care of it, there is a discussion in [1] too, for now I did not see
>>> really solid arguments showing that I could be wrong.
>> I answered on the webappsec thread. Firefox blocks mixed content for 
>> good reasons. When receiving an HTTPS page, the browser shows lots of 
>> signs of the page being secure. If the page starts loading 
>> code/style/content with HTTP, these are subject to man in the middle 
>> attacks and suddenly, the browser gives a false sense of security to 
>> the user.
> Mixed content is not blocked today.
It is by IE and Chrome. I don't remember for which version it is for 
Firefox, but it should be deployed or will very soon. It's close enough 
to being a de facto standard. Only the thousands of edge cases need to 
be agreed upon.

> Again, it's difficult to say which one is more insecure between http 
> with https or https with http, the first one is subject to a mitm 
> attack since the begining.
None is secure.

>> Firefox isn't forcing you to do insecure things. Firefox is forcing 
>> you to make a choice: go all the way secure (so that it can shows 
>> strong signal to the user) or use HTTP.
> I am not saying FF is the problem, FF follows the Websocket spec, 
> which does not allow ws with https. I am explaining why I can not use 
> wss (routers can not have trusted certificates)
Sorry, I had miss this info.

> so I am forced to fallback to http. It's easy to deny the issue but 
> that's a real life use case.
I don't know the details for your particular case, but a line has to be 
drawn somewhere. Web standard security is always butchered because of 
these real life use cases. How important are they? How hard would it be 
for real life infrastructure to upgrade? For sure once a standard allows 
to do something insecure (load HTTP content in HTTPS page) it remains 
pretty much forever. This is less true for your router I imagine.
Blocking mixed content has been possible in Firefox because IE and 
Chrome were doing it long ago.

>>> Maybe a solution could be combination of CSP and SES, I think SES
>>> should come now, as far as I remember it is planned for ES8, seems too
>>> late.
>> SES exists now... sort of... with Caja. You don't need to wait, it's 
>> already available. Module loaders are also a major step forward.
> Not very intuitive to use as far as I remember.
Let's go step by step. You were initially asking for "possible", I gave 
you "possible" :-)
I know that the Caja team has been very reactive and patient to my 
questions in the past. If you have intuitiveness and API issues, I'm 
sure they'll be happy to hear about it and will certainly guide you 
through how to use Caja.

>>> Solving the code loading issue is indeed the key point, but is it
>>> feasible?
>> Can you describe ways in which it isn't?
> Do you know a way (even theoretical) to safely load code with web 
> mechanisms that can defeat a mitm? This would necessarly imply another 
> check mechanism on top of SSL/TLS
My knowledge stops at a 2-layer answer.
First layer is: load everything with HTTPS and you'll be fine. For the 
vast majority of people and use cases, this is enough.
Second layer is that HTTPS has some known flaws [1], including in the 
certificate authority mechanism, but it takes some work to exploit them. 
Moxie Marlinspike proposed a solution in the form of the Converge 
Firefox addon ... which is broken since Firefox 
18 (an API changed and the addon wasn't updated). But the idea is 


[1] See (the anecdote about 
SSL design at ~16' is scary) and other work by Moxie 
Marlinspike on that topic

More information about the es-discuss mailing list