Closed Bug 917829 Opened 11 years ago Closed 11 years ago

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

Categories

(Core :: Networking: WebSockets, defect)

Product:
Core
Component:
Networking: WebSockets
Version:
23 Branch
Platform:
x86
Windows Vista
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: aymeric, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 6.0; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release) Build ID: 20130814063812 Steps to reproduce: This seems to be specific to FF. The use case is the following, script.js is supposed to be loade in a safe way, so the first step is to use SSL/TLS: https://mypage.com: <DOCTYPE...> <script src='script.js'></script> </html> So the page loads https://mypage.com/scripts.js, then script.js tries to do new WebSocket(ws://server:port) And FF does display a security error. The alternative is to do: http://mypage.com <DOCTYPE...> <script src='https://mypage.com/script.js'></script> </html> And this works. Does this mean that the second scenario is more secure than the first one? I don't think so, why are non SSL/TLS Websockets forbidden if the scheme is https?
It looks as though this is intentional. See the "Security considerations" section on this page: https://developer.mozilla.org/en-US/docs/WebSockets/Writing_WebSocket_client_applications "WebSockets should not be used in a mixed content environment; that is, you shouldn't open a non-secure WebSocket connection from a page loaded using HTTPS or vice-versa. In fact, some browsers explicitly forbid this, including Firefox 8 and later."
Component: Untriaged → Networking: WebSockets
Product: Firefox → Core
yes - we prohibit mixed content. Use wss:// and make everyone more secure!
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Sorry no, first the vice-versa does not work here, you can establish a wss connection from a http page with FF. Second, if you trust SSL/TLS then the first case (ie https page) is supposed to be much more secured than the second one, because you have better chances to load the right script. What you are saying is equivalent to say that it's more secure to load a bad script from a http page doing SSL/TLS requests than a good script from a https page doing non SSL/TLS requests. But the second case is common practice, http page loading tons of https stuff. This is the kind of discussion that can happen at the WebCrypto WG, both scenario are unsecured but it's not logical to allow one and forbid another one. The behavior is not coherent with xhr which does not allow SSL/TLS xhr from a http page. This is the kind of rules that are really against security, in my case I can not use wss because the servers are using self signed certificates, for different reasons, and because browsers have decided that SSL/TLS connections involving supposed untrusted certificates should silently fail when not initiated by the main page instead of raising an exception. You (and other browsers) do not prohibit at all mixed content, this seems really like for convenient reasons for major companies' uses (ads, tracking, etc) that what seems more unsecured is allowed (http loading https) and the contrary not, this is protecting the companies, not the users. What other browsers are forbidding ws from https?
(In reply to Aymeric Vitte from comment #3) > Sorry no, first the vice-versa does not work here, you can establish a wss > connection from a http page with FF. yes - you can upgrade the security of a subsresource load, but you can't downgrade it. That's what mixed content means in this context. in your case, the integrity protections your JS has gotten by being loaded over SSL can be dilluted by a MITM attack on the ws://. So we don't allow it. We would rather not allow mixed content xhr or img loads either - that's a genuine vulnerability if you ask me. but at this point backwards compatibility rules the day on that question - we had a chance to start the websockets slate more cleanly and did so. hope that helps. > not use wss because the servers are using self signed certificates, startssl.com might provide a solution for you.
That's not very logical, as I wrote both are insecure but the http page is more subject to MITM than the https one. The behavior is not coherent and forces the users to chose insecure solutions. In my case there is no way the ws connection gets MITMed since there is another secure protocol on top of it (see http://www.peersm.com), but it renders things more easy to potential attackers not to be able to use https to load the main page. Does Mozilla have a paper/spec about these choices (and the fact that https loading http is less secure than http loading https)?
(In reply to Aymeric Vitte from comment #5) If you'd like to suggest we loosen this requirement you should make that argument on the dev.security.policy mailing list - bugzilla is more for tracking implementation decisions and bugs. This bug is wontfix because the algorithm is implemented as intended. That doesn't mean we can't change any decision - its just that bugzilla isn't the right place for that discussion and the right people aren't reading this bug. > In my case there is no way the ws connection gets MITMed since > there is another secure protocol on top of it awesome! of course, we can't base a policy around that. > Does Mozilla have a paper/spec about these choices not to my knowledge.
> awesome! of course, we can't base a policy around that. Unlikely or difficult is better than "no way", OK I write to the list
(In reply to Patrick McManus [:mcmanus] from comment #6) > (In reply to Aymeric Vitte from comment #5) > > If you'd like to suggest we loosen this requirement you should make that > argument on the dev.security.policy mailing list - bugzilla is more for > tracking implementation decisions and bugs. This bug is wontfix because the > algorithm is implemented as intended. dev.security: https://lists.mozilla.org/listinfo/dev-security dev.security.policy is about certificate authority criteria.
(In reply to Aymeric Vitte from comment #0) > This seems to be specific to FF. [....] > > So the page loads https://mypage.com/scripts.js, then script.js tries to do > new WebSocket(ws://server:port) > > And FF does display a security error. Are you saying Chrome does not give the same error? This error is part of the WebSocket specification, step two at http://www.w3.org/TR/websockets/#the-websocket-interface (In reply to Aymeric Vitte from comment #3) > This is the kind of rules that are really against security, in my case I can > not use wss because the servers are using self signed certificates, for > different reasons, and because browsers have decided that SSL/TLS > connections involving supposed untrusted certificates should silently fail > when not initiated by the main page instead of raising an exception. There is no safe way to use an untrusted certificate. If it really must be self-generated then when users want to interact with your site present a way for them to add the certificate to the trusted list. This probably requires a "pop-up" or a new top-level tab where users can add the exception. In Firefox, at least, the exception can be made permanent. If the initial connection can be trusted this then becomes as good as any CA-issued certificate for that user.
>Are you saying Chrome does not give the same error? Yes >This error is part of the WebSocket specification Indeed...So maybe the subject has to be raised to WebApps >There is no safe way to use an untrusted certificate. It depends what you do and how. >If it really must be self-generated then when >users want to interact with your site present a way for them to add the certificate to the trusted >list. This probably requires a "pop-up" or a new top-level tab where users can add the exception. In >Firefox, at least, the exception can be made permanent. If the initial connection can be trusted this >then becomes as good as any CA-issued certificate for that user. You can raise an exception only for the "main" SSL/TLS connexion (ie main page), other SSL/TLS resources (including wss) using different not trusted certificates will silently fail, you can bypass this behavior setting an exception while loading directly the resource (I suppose that's what you are suggesting with pop-up or top-level tab), then loading it again via the initial page will work, but of course that's not really user friendly and you are not going to ask you users to do this. Things are speced/thought only thinking to SSL/TLS behavior, as mentioned above you can use another secure protocol on top of WS (Tor protocol for example) and you should be able to do this from a https page, because using just http is more risky.
You need to log in before you can comment on or make changes to this bug.