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
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
