Hello, I'd like to ask about the possibility of changes to the way mixed-content XHR and WebSockets are flagged up.
(I should start by saying that the new mixed-content blocker is great and that tightening restrictions on these sorts of things is in general excellent.) Firstly, I think it's a problem that we can't make mixed-content WebSocket connections. I realise this has in been in Firefox for a while, but I haven't written any Firefox patches for a few years and missed the change. Now that XHR is being blocked, it might be a suitable point to gently revisit this? I think the security issues for mixed-content WebSockets and XHR are essentially the same, so it would be good to use the same checks for both. That is, we now have UI in firefox for approving a mixed-content XHR: I'd like that same UI to be pulled in for the WebSockets case. I made a patch for that today (it's small). It's not really acceptable for us to ask our customers to twiddle the network.websocket.allowInsecureFromHTTPS preference, but the UI in the address bar is just about bearable for a product to require users to click through. I think having uniformity here is clearly helpful. I do recognise that the WebSocket API spec requires mixed-content connections to be blocked, but there might still be room for discussion on the benefits of it, especially while you're adjusting the model for XHR at the same time. Without this change, we're going to have to release our product with long polling in Firefox just because we can't create a WebSocket! It's my fault I guess that we got quite far in our development before testing over HTTPS with Firefox and noticing the problem with a shock. Our webapp is a client that does its own crypto: imagine if you wanted to do a webapp version of an SSH or VNC client. We've got asm.js to work with OpenSSL, and also use WebCrypto. This is exactly what rich webapps should be like: without downloading OpenSSH, you can run the client in your browser as part of a web dashboard. WebSockets were created to enable exactly these sorts of use cases, surely! It's clear though that the app has to be served over HTTPS. And, it makes connections to WebSocket-enabled servers on your local network that aren't on the wide internet, so it's infeasible to roll out a globally-recognised TLS certificate to each machine that the dashboard manages. So, we can't do the WebSockets over TLS, the hosting page has to be HTTPS, and Firefox currently doesn't permit that use-case. So, the first request was small: would you accept the patch to pull in the mixed-content UI for WebSockets, the same as for XHR, so that at least there's some way for our customers to use Firefox without having to edit about:config. (Larry still says, "Other people can view or modify the website's behaviour", which is untrue... but we can live with that.) The second request is a bigger discussion: I think we need a fuller, proper way to allow mixed-content XHR/WebSocket. Not all mixed-content requests, just some. I recognise the value that browsers provide to website developers flagging up when their site is misconfigured, and we want these warnings to be on by default. What some webapps need is a way for the warning to be turned off selectively. I remember the coverage when noVNC first came out and people were saying how cool it was. It's a shame that sort of webapp can't be served over HTTPS to Firefox. The mixed-content diagnostic is intended to "motivate" site admins to fix their site, in the common case the resource loading is unsafe, but for us it's getting in the way of providing an application to customers which is actually secure. The general principle is that both XHR and WebSockets can be used virtuously and securely in mixed-content scenarios, and these are use-cases you aren't yet enabling. (To be fair, the only examples of mixed-content XHR I can think of are fairly contrived: an HTTPS page that loads some resources over HTTP and checks their hashes against a list served with the HTTPS page before executing them. This could very substantially reduce load on a CDN.) I tentatively suggest a new header: "Access-Control-Security: externally-verifiable" (or anything similar). If set on a response, we allow it even in a mixed-content context, and trust the JavaScript to do the verification. It's simple and should keep everyone happy: the default case still produces the warnings, but authors with a genuine use-case can take on the responsibility of validating the content. It could perhaps be set only on replies if the header "Access-Control-Request-Security: tls-context" is set. (These are probably rubbish header names, but that's not relevant to the idea.) The connection is over unsecured HTTP, so an attacker can modify these headers at will. That's OK though; the security model doesn't rely on the integrity of the request headers. Thanks for reading a long email, Nick Wilson On a related note, in #662692, Brian Smith said "IMO, the SSH example is better off using mozTCPSocket" I'm not sure about that; while it's clearly great for chrome-context code or browser extensions, I still don't see how Mozilla could open this up to the webpages more generally. For geolocation, the "share your location" prompt is readily understandable, but you'll struggle to come up with suitable wording for mozTCPSocket. If even 5% of users misunderstand it and grant the permission to a drive-by intranet scanner, it'll send IT admins crazy. You may find it's just too powerful to give to webpages, and that the mandatory server-side Origin control for WebSockets makes it the right choice of API to offer webapps. In any case, that's another discussion, but to me it looks like providing some UI to relax the mixed-content restriction is much smaller than providing a UI for ordinary webapps to elevate themselves to full local network access. ----- Nicholas Wilson: nicho...@nicholaswilson.me.uk Cambridge, CB4 2TU _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
