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
Le 24/09/2013 09:38, ianG a écrit :
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
--
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
