Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#9852 closed defect (not a bug)

[Flash-proxies] - WS with HTTPS

Reported by: Aymeric Owned by: dcf
Priority: Medium Milestone:
Component: Archived/Flashproxy Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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

Is this not an issue for you?

Child Tickets

Change History (6)

comment:1 Changed 4 years ago by dcf

The Mozilla report says that JavaScript running in an HTTPS page cannot open non-secure WebSocket connections (ws:// rather than wss://). This is true. It is a consideration for us, but it is not really a problem. We have a FAQ entry that explains a bit about why things are the way they are:

It's not a problem for us, because there are more than enough plain HTTP pages that host the proxy.

comment:2 Changed 4 years ago by Aymeric

So, you are promoting HTTPS Everywhere but it's not an issue for you not to be able to use the flash proxy tag on https sites? And the Stanford flash proxy presentation site is using https...

That's a kind of strange, even if one might not trust SSL/TLS with browsers.

I brought the issue to different lists, always getting the same answer (security issue to downgrade from https to http but no problem to use https with http...), lists that do not perceive (or don't want) the fact that using ws with something more secure on top of it rather than wss can be better.

Maybe you and other organizations should weigh more in the specification process.

comment:3 in reply to:  2 Changed 4 years ago by dcf

Replying to Aymeric:

So, you are promoting HTTPS Everywhere but it's not an issue for you not to be able to use the flash proxy tag on https sites? And the Stanford flash proxy presentation site is using https...

As I say, it's a consideration, but not really a problem. It is a shame that the proxy doesn't work on HTTPS sites, but we are not aware of any good workaround, and there are enough plain HTTP sites hosting it that it doesn't matter very much. The biggest cost is having to explain to conscientious site owners who run their sites over HTTPS why their badge won't work :(

Censored users using the Tor Browser bundle with HTTPS Everywhere are not affected, because censored users don't need to see or run the proxy badge. Other, uncensored users (who mostly don't run HTTPS Everywhere) are the ones who are running the proxy code.

The demo site also runs over plain HTTP. We don't do anything to try to force HTTPS users onto plain HTTP, because we have enough proxy capacity. As you see, it is kind of a complicated issue to explain anyway.

I brought the issue to different lists, always getting the same answer (security issue to downgrade from https to http but no problem to use https with http...), lists that do not perceive (or don't want) the fact that using ws with something more secure on top of it rather than wss can be better.

Maybe you and other organizations should weigh more in the specification process.

I think that the browsers are doing the right thing here. It's a sensible security decision to disallow non-SSL WebSockets from an SSL page. We just have to work within that restriction. It is at most a slight annoyance, not really a problem.

comment:4 Changed 4 years ago by Aymeric

I am not talking about people using HTTPS Everywhere, but about the fact that you are promoting it, which means that http sites are supposed to disappear.

So, if this works, you will not have any longer http sites.

I don't find anything sensible disallowing ws from a https page (and this still works on Chrome...) compared to allowing https from a (supposedly) least secure http page, both are insecure, the second option is more I believe.

As you know, when a web mistake happens, this is forever, so up to you if you want to react or not.

comment:5 Changed 4 years ago by dcf

Resolution: not a bug
Status: newclosed

I don't think there's any action that can be taken on this ticket. Browser are going to continue to prohibit non-TLS WebSocket from HTTPS pages, and we're going to continue coping with that fact. It doesn't seem to be a problem at all in practice.

comment:6 Changed 4 years ago by Aymeric

It doesn't seem to be a problem at all in practice.

It is, we got some feedback for Peersm like "we are not going to use it because you do not use https", and that's why we must explain it on http://www.peersm.com "Why the main page is not using https".

Google is not using the same policy, what you can do is try to convince Mozilla that the current behavior forces people to do insecure things, people might reply that http with https or the contrary are both insecure, bla, bla, but loading the main page without https is for sure much more insecure than the contrary.

Note: See TracTickets for help on using tickets.