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