When a script attempts to open a WebSocket to a non-TLS-protected server ("ws://"), the attempt should fail if the document was delivered over HTTPS. Since there are basically no existing WebSockets servers, there is no compatibility reason to allow ws:// (as opposed to wss//) WebSockets from an https:// webpage. We would like to move to a stronger policy prohibiting all mixed content, and prohibiting https://+ws:// from the start will help prevent WebSockets from adding to the problem. In addition to addressing this in code, we should make sure the W3C spec notes this.
Created attachment 544854 [details] [diff] [review] patch v1
Comment on attachment 544854 [details] [diff] [review] patch v1 whoops - this is a content code change.. changing reviewer.
Comment on attachment 544854 [details] [diff] [review] patch v1 This is not per spec, but I think we should do this. Please bring this up in Web Apps WG.
pushed to inbound Jonas or Brian - can you bring this to the web apps wg?
Pushed to m-c: http://hg.mozilla.org/mozilla-central/rev/f85107f85c64
6 years ago
Wouldn't the right check be a check for security info from the callsite, not the url scheme? Hardcoding https and assuming that we don't support any other secure schemes seems bad.
Created attachment 546637 [details] [diff] [review] security-info.1 Do you think this is better?
Comment on attachment 546637 [details] [diff] [review] security-info.1 This seems good; just document that since this is in Init() the document associated with this script context is still the same one as associated with mOwner? Or should we add an assert to that effect? Oh, and fix the indent on that return statement, please.
Documentation updated: https://developer.mozilla.org/en/WebSockets/Writing_WebSocket_client_applications#Security_considerations Also referenced on Firefox 8 for developers.
(In reply to Nicholas Wilson from comment #11) > Would it be possible to have a clearer statement of the rationale for this, > please. We don't have any evidence that users understand the lock icon to mean "no non-secure code was loaded but there may be unprotected communication happening behind the scenes." There's no distinction between the case of "no secure communication" and "no secure code loading" in the UI, and adding such a distinction is difficult to justify. > This is a major change This change happened over two years ago. Also, this is the behavior that the specification requires (though, I was one of the people that pushed for that requirement to be added to the spec). > that prevents a number of very reasonable use-cases from happening. I agree. However, it also makes the UI clear in some important use cases. For example, consider an HTML5 email client (that uses mozTCPSocket or some websockets proxy) that has been mis-configured to use the non-TLS-protected communication channel. As IMAP/SMTP/POP/LDAP almost always send your password otherwise unprotected on the wire, it is really important to use TLS. In general, going forward we may need to allow some kinds of mixed content (websockets and/or XHR or whatever), but I suspect in the vast majority of cases the server could "just" switch to HTTPS. Your SSH example is quite unusual case because it is another well-established secure protocol. IMO, the SSH example is better off using mozTCPSocket (at least, once it is in the browser and once it becomes standardized). And, one of the issues with mozTCPSocket is that we probably have to ask for permission. It is possible that, as part of that permission prompt, that we could allow "mixed" mozTCPSocket connections. Or, maybe not; it hasn't been decided either way. Even still, the SSH example suffers (AFAICT) from the inability to use public key authentication instead of password authentication. See http://blog.sucuri.net/2013/07/ssh-brute-force-the-10-year-old-attack-that-still-persists.html.
Also, my mistake: instead of having this discussion in this closed-for-two-years bug, let's please move it to dev-security or dev-tech-networking. Please CC me if you do so.
Brian, thanks very much for replying. It was a bit of an outburst! My surprise is entirely my fault; we should have tested serving the webapp over TLS to firefox when we weren't so far down the line with the product (we did our main testing on Chrome, unfortunately). I'll continue this on the mailing list.