Security error when trying to set a non SSL/TLS Websocket from a https page

[Aymeric Vitte]

Please see: https://bugzilla.mozilla.org/show_bug.cgi?id=917829

I think I have detailed already in the bug report why it does not
necessary make sense to forbid ws from a https page, for your review and
comments.

Regards,

Aymeric

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

[ianG]

On 23/09/13 11:21 AM, Aymeric Vitte wrote:
> Please see: https://bugzilla.mozilla.org/show_bug.cgi?id=917829
>
> I think I have detailed already in the bug report why it does not
> necessary make sense to forbid ws from a https page, for your review and
> comments.

The problem might be that when you switch across to webservices, there
seems no way to say "use webservices, but I won't tell you which
security level to use."

That is, "wsa:/...." where 'wsa' could mean webserversagnostic, either
ws or wss.



(fwiw, this is a core flaw in the HTTPS model, that the coder can
choose. And yes, once HTTPS is indicated on the original request, it
has to maintain SSL/TLS protection across the lot, otherwise the
security claim is broken.)



iang

[Aymeric Vitte]

Le 23/09/2013 10:42, ianG a écrit :
> And yes, once HTTPS is indicated on the original request, it has to
> maintain SSL/TLS protection across the lot, otherwise the security
> claim is broken.

That's not the case already, so there should not be an exception for
WebSockets.

In my case this forces me to use http instead of https to load the main
page, and this is of course more insecure.

The case of someone not trusting SSL/TLS should be considered too.

While both are insecure this looks to me a non sense to allow insecure
http page loading https and not the contrary (or partially)

Regards

[ianG]

On 23/09/13 12:16 PM, Aymeric Vitte wrote:
>
> Le 23/09/2013 10:42, ianG a écrit :
>> And yes, once HTTPS is indicated on the original request, it has to
>> maintain SSL/TLS protection across the lot, otherwise the security
>> claim is broken.
>
> That's not the case already,

I agree. The situation is that HTTPS-everywhere is becoming the case,
and this movement is probably unstoppable.

> so there should not be an exception for
> WebSockets.

I don't see why there would be any exception for any particular thing,
websockets or other?

> In my case this forces me to use http instead of https to load the main
> page, and this is of course more insecure.

Yes -- in your circumstance, because you've already fixed up the other
channel. But the HTTPS model is that "we know best" and HTTPS is the
only and all security.

We are kind of stuck in our own hubris on this one; if we want people
to move to HTTPS Everywhere, then that's what we have to do.

> The case of someone not trusting SSL/TLS should be considered too.

Mmmph... Don't get me started ... :)

> While both are insecure this looks to me a non sense to allow insecure
> http page loading https and not the contrary (or partially)

It makes sense to me, in isolation: The http promise is maintained with
either http or with https. The https promise is only maintained with https.



iang

[Aymeric Vitte]

I don't want to get you started but look:

From your own site (!! probably a mistake in the link)
https://www.financialcryptography.com/ :-) or https://iang.org/

And maybe when you have time http://www.ianonym.com where it's explained
why you might not trust SSL/TLS

But I don't want to debate about this, I have answered again to the bug
following some questions, showing that Chrome is allowing ws with https
and reexplaining why it's not inept to have ws with https in the case
you are using a different secure protocol for example.

In general I agree that https everywhere should be the standard, but
certificates policy inside browser should be more transparent, I have
tried for example to push in WebCrypto the feature of exposing
certificates, but with no success until now.

The problem I see with http allowing https is that you allow the
untrusted page to send things that you can potentially not even decrypt,
so it's maybe more insecure than using http with https, but again both
are insecure, the issue in general is that everything is done to protect
the sites, not the users, and things like forbidding ws with https does
not enforce necessarly security (I don't understand what you mean
exactly by "already fixed up the other channel", the fact here is that
you connect to routers that can not have a trusted certificate).

Regards,

Aymeirc

> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security

--
Peersm : http://www.peersm.com

[Nicholas Wilson]

Dear Aymeirc,

(public reply for the list)

The similar discussion on this list last month about mixed-content
websocket connections had the subject "Mixed-content XHR &
Websockets".

I have an application which is similar to yours, where the JS does its
own crypto using a combination of WebCrypto and emscripten-compiled
OpenSSL. (The peers are dynamic and don't have globally-known
certificates that a browser's chain-of-trust recognises for TLS, and
the webapp has to be served over HTTPS to be secure.) So, we both have
a legitimate use of plain (mixed) ws from an HTTPS context.

I won't repeat the arguments for mixed-content blocking in Firefox,
which is well-documented - Tanvi's blog post is a good place to start
(https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/)

Last month, I proposed a new CORS-style header that would solve our
problem in a generic way. I have a new solution this week though,
which is less generic and feels a bit bad, but should hopefully make
everyone happy. Why can't we just whitelist known (or declared secure)
WebSocket subprotocols? The idea is simple: a WebSocket connection
which is actually encrypted isn't really mixed at all because of the
protocol being used. If a 'secure' subprotocol is negotiated, then
we're OK to let it through in a mixed context.

I have a spec for this up on github:
http://nwilson.github.io/websockets-mixed-context/. I'll post a
Firefox patch implementing this soon.

I think the next step is going to the appropriate WHATWG list and
pestering there? Basically, Firefox is the odd browser out (Chrome
doesn't block mixed WebSockets), and Firefox drove the addition of the
clause to the spec I'm trying to get tweaked. Is there anyone
particularly I should be looking for in Mozilla to review this
proposal? Pragmatically, I think it's acceptably small and opens up
some cool new webapps that aren't currently possible in Fx.

Best,
Nicholas

-----
Nicholas Wilson: nich...@nicholaswilson.me.uk
Site and blog: www.nicholaswilson.me.uk
28 St Stephens Place, CB3 0JE
07845 182898

On 23 September 2013 09:21, Aymeric Vitte <vittea...@gmail.com> wrote:
> Please see: https://bugzilla.mozilla.org/show_bug.cgi?id=917829
>
> I think I have detailed already in the bug report why it does not necessary
> make sense to forbid ws from a https page, for your review and comments.
>

> Regards,

>
> Aymeric
>
> --
> jCore
> Email : avi...@jcore.fr
> Peersm : http://www.peersm.com
> iAnonym : http://www.ianonym.com

> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms

> Web : www.jcore.fr
> Extract Widget Mobile : www.extractwidget.com
> BlimpMe! : www.blimpme.com
>

[Aymeric Vitte]

The fact of having SSL/TLS inside ws is of course OK for me, that's what
I am doing too, but let's say I am against it (which is not the case) I
would argue that the issue remains the same: why should it be allowed to
work with "insecure" certificates while SSL/TLS on top of ws don't allow
it, and how do you classify a "secure" subprotocol?

I have tried to motivate the Tor fundation about this topic for their
flash proxies and ws transport, without success.

I still think the current behavior is a serious limitation for ws use
that forces you to do insecure things, so the contrary of the intend,
but I don't know how to convince Mozilla.

Regards,

Aymeric

--
Peersm : http://www.peersm.com

[Devdatta Akhawe]

Hi Nicholas

Thanks for bringing this up. I think you bring up an important
application scenario that is not at all handled well by the web
platform today.

> everyone happy. Why can't we just whitelist known (or declared secure)
> WebSocket subprotocols? The idea is simple: a WebSocket connection
> which is actually encrypted isn't really mixed at all because of the
> protocol being used. If a 'secure' subprotocol is negotiated, then
> we're OK to let it through in a mixed context.

I disagree. A secure channel is hard to create. As a Firefox user, I
only trust my browser to get it right; to disable MD5 when it becomes
old; to fix the padding oracle attacks; and [on and on]. To take an
extreme case, what stops a site from just using the null cipher and
calling it secure (many sites actually do support the null cipher as
part of https!).

The core problem is: the application author wants to implement a
secure channel whereas the browser only trusts its own implementation.
I don't know what the solution is: maybe allow insecure XHR and WS if
document has CSP turned on with eval/inline-script disabled (thus, no
way to convert data to code)


thanks
dev

[Nicholas Wilson]

Devdatta,

Thanks for your comments. These sorts of concerns about which
implementors users trust can be tricky! The reality is that Firefox
isn't the only person we trust to do crypto right: for a start, you're
trusting every company you give your data to (personal data, credit
card details) to store those securely. You have other applications on
your computer: you trust OpenSSH and numerous other vendors, both
installed on your machine and in the infrastructure that's installed
by your bank, ISP, and others.

On 10 October 2013 16:16, Devdatta Akhawe <dev.a...@gmail.com> wrote:
> I disagree. A secure channel is hard to create. As a Firefox user, I
> only trust my browser to get it right; to disable MD5 when it becomes
> old; to fix the padding oracle attacks; and [on and on].

We're in the position at my company of having a very large number of
enterprise customers (a lot of big tech companies and government IT
departments). They've trusted us for a long time to write a secure
desktop app, and now we want to move that app into the browser,
they'll extend the same trust to us there.

A secure channel is hard to create, as you say, but the desktop app
developers have working on their protocols and implementations just as
long as browsers have been doing TLS or designing WebRTC.

I think the big factor is WebCrypto: what was the point of it if the
browsers aren't going to trust JavaScript to actually doing some
meaningful encryption with it? It's an API to expose the same native
crypto primitives the browser itself uses for the benefit of
JavaScript, so that web authors get secure, audited, and updated
implementations of the primitives that are resistant to fiendish
attacks (eg timing attacks) that a JavaScript implementation could
never defend against. As well as getting fast updates to the crypto
primitives by browser vendors, with webapps we'd get immediate updates
of the client software too compared to long upgrade times for
traditional desktop apps we're currently selling.

Using WebSockets with encryption added using WebCrypto I would have
thought is a pretty canonical use-case for the API!

> The core problem is: the application author wants to implement a
> secure channel whereas the browser only trusts its own implementation.
> I don't know what the solution is: maybe allow insecure XHR and WS if
> document has CSP turned on with eval/inline-script disabled (thus, no
> way to convert data to code)

So, Devdatta, if we added some extra restrictions would that be enough
to make you happy, like CSP to prevent execution of unsigned content
the browser hasn't verified? That only protects one-way though - it
doesn't do anything to stop sensitive data leaving the page
unencrypted. Ultimately, there's a whole class of webapps that can't
be written unless 1) browsers implement each protocols themselves, the
kitchen sink model, or 2) trust software vendors to run these sorts of
apps in their browsers.

Even using TLS end-to-end doesn't stop web developers from doing
something stupid and leaving SQL injection attacks wide open. There
comes a point where a webapp or service needs the trust of its users,
because no browser can check what the backend is doing with the data,
anymore than it can verify every single thing the JavaScript is doing.

I don't think the proposal is asking for the browser to trust site
authors any more than they already do. My proposal uses WebSocket
subprotocols because they're virtually unused at the moment, so the
mixed content blocking is still there for WebSockets except for all
but the most dedicated web authors, who'd have to be writing their own
WebSocket server and backend already too.

[Devdatta Akhawe]

Nicholas,

I am sure the protocol and encryption you have written is solid and
secure. The concern is that once this is opened up, it will be open
for all and others won't be so careful. There are lots of examples of
people not implementing the crypto correctly.

Re the leaking of sensitive data: browsers already make a practical
decision to let some of that data leak by e.g., allowing passive
content over HTTP on HTTPS pages (last I checked). I was arguing that
once a strong CSP policy is enforced, one can reasonably be certain
that arbitrary code won't execute.* In that case, the insecure XHR/WS
data can't convert to code (which is presumably the reason it was
treated as active content originally) and thus should be treated as
passive content and allowed.

~Dev

* Well, you can still write a JS interpreter in JS and run arbitrary code.

[Nicholas Wilson]

Dev,

Indeed, I'm worried about what other people could do with the feature
too. I'm much more worried though about the bad stuff that they're
already doing in their PHP that the browser can't check it in any way.
I think the nice thing about my patch is that it's not enough just to
set a flag in the JavaScript, you have to write some server-side code
for the browser to receive the right WebSocket headers. That's enough
to prevent anyone stumbling across the feature by accident. There
might still be people who aren't careful, but by this stage, they've
jumped through enough hoops and written enough server-side code (which
the browser can't verify) that we may as well stop worrying. There's
little practical difference in security from the browser's point of
view.

I added some comments about CSP to the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=924957 Could you comment
there if you'd want to say more?

I'm only interested in opening up a very small loophole for really
dedicated webapp developers, so I'm in favour of requiring a strict
CSP. It's a sensible addition to the mixed-content heuristic, and
addresses one of the big security concerns with allowing these sorts
of WebSocket connections. Hopefully that will Mozilla happier with the
patch.

Nick

-----
Nicholas Wilson: nich...@nicholaswilson.me.uk

[Kevin Chadwick]

> I'm much more worried though about the bad stuff that they're
> already doing in their PHP that the browser can't check it in any way.

?. The only thing PHP which is server side can do is with information
your browser has sent and hopefully just what you have input into a
form (but that line is being eroded with 'apps' and the like). In fact
it would be a far nicer world if much more was done with PHP rather
than javascript although suhosin (function whitelists) no longer works
so PHP is actually far more difficult to secure these days.

p.s. I disable webapps and sockets completely!

--
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
_______________________________________________________________________