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

[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

Le 04/10/2013 19:07, Nicholas Wilson a écrit :

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: nicho...@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 vitteayme...@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

___
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security


--
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

___
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

Re: Scope of Dev-Security List

[Daniel Veditz]

On 10/5/2013 4:00 PM, farr...@furcadia.com wrote:
 Well, I was very disappointed not to find any discussion here of the
 issues and challenges that W3C's decision on DRM for HTML5 would
 bring for security.
 
 I sort of expected people to be all over that here, when I saw the
 group name.

The issues around it are not really security issues, it's a policy and
philosophical argument. There will no doubt be unintentional security
bugs in the external DRM plugins--as there is with just about every new
feature we do--but the concern with DRM is that as the EFF (or someone
like that) puts it it is broken by design.

The policy issues go well beyond the limited audience of this security
list and are being discussed elsewhere. I'd imagine either the web
platform group or the governance group (or both).

 DRM in HTML5 - *if* the decision is made to back it - almost
 certainly means: - The end of verifiably-secure, open-source FF. -
 The end of FF as part of security projects like TOR, TAILS, etc,
 since if FF uses closed binary blobs then it cannot be trusted.

Firefox will never require the use of closed binary blobs. Since the
code is licensed to be compatible with GPL it simply must have the
ability to function without such things. I expect that if we implement
this it would be functionally much like plugins are today -- optional,
but without it you lose access to content that requires it.

-Dan Veditz



smime.p7s
Description: S/MIME Cryptographic Signature
___
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security