ES Native Mode proposal

Mark S. Miller erights at
Thu Sep 26 08:27:06 PDT 2013

On Thu, Sep 26, 2013 at 3:59 AM, David Bruant <bruant.d at> wrote:

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

David, thanks!
Aymeric, yes, what David said ;).

>  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 interesting.
> David
> [1] See**v=Z7Wl2FW2TcA<>(the anecdote about SSL design at ~16' is scary) and other
> work by Moxie Marlinspike on that topic
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list