search

scratchfoundation / scratch-link

Device interoperability layer for Windows and MacOS
BSD 3-Clause "New" or "Revised" License
102 stars 83 forks source link

Why does Scratch Link use Secure WebSockets? #137

Closed cwillisf closed 5 years ago

cwillisf commented 5 years ago

This issue is here to explain and possibly discuss the rationale behind choosing Secure WebSockets (WSS, wss://) instead of plain WebSockets (WS, ws://) for Scratch Link communication.

Why WSS?

While plain WebSockets are certainly easier and have less overhead, we're forced to use WSS due to the security model that many web browsers follow:

When a page is loaded over HTTPS many browsers will prevent that page from making connections over HTTP or WS. Often the browser will display a message about "mixed content" when blocking such a connection; a more thorough discussion on this is available here: https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content

Scratch is hosted at https://scratch.mit.edu/ and we anticipate the "HTTPS everywhere" trend to continue across the web, so many of Scratch Link's clients are likely to experience the "mixed content" limitation.

Why is an Internet connection necessary?

In short: this is a side effect of using WSS.

Strictly speaking, a computer doesn't need to be connected to the Internet in order to use Scratch Link. In practical terms, though, using Scratch Link without an Internet connection requires advanced configuration that the Scratch team is not prepared to support. Because of that, we generally tell users that using Scratch Link requires an Internet connection.

When a browser makes a WSS connection one of the first steps is to request the host's cryptographic certificate. Most browsers very several properties of the certificate; notably, the browser checks that the certificate is registered with the same host name that is being used for the connection. That is, if the certificate is registered with the host name device-manager.scratch.mit.edu, as ours is, then the Browser will reject the WSS connection unless it was made using the host name device-manager.scratch.mit.edu.

Because of this, we must use wss://device-manager.scratch.mit.edu instead of (say) wss://localhost to make the connection from Scratch to Scratch Link. Making that connection requires resolving device-manager.scratch.mit.edu to an IP address, which is usually handled through DNS supplied over the Internet.

Advanced users may want to modify a hosts file or register that name locally in some other way but this is not officially supported by the Scratch team.

Are there any alternatives?

While it's possible to adjust the security settings of most browsers to either permit mixed content or trust specific URLs, we didn't want to complicate Scratch Link setup or even risk compromising the browser security of Scratch Link users in this way.

We are not currently aware of any better way to solve all of the problems listed above without modifying system or browser settings. We are certainly open to ideas, though!

cwillisf commented 5 years ago

I've marked this issue as "closed" but feel free to discuss WSS-related issues here!

cwillisf commented 3 years ago

Q: Do browsers exempt 127.0.0.1 and/or localhost from mixed-content restrictions?

A: According to this page on MDN, some browsers do. They mention that recent versions of Firefox and Chrome allow it, but Safari does not.

Naleksuh commented 3 years ago

@cwillisf Question, why not both ws:// and wss:// ?

cwillisf commented 2 years ago

@Naleksuh hmm, that might be a good idea. Scratch Link could listen in both ways, and clients could try to contact ws://127.0.0.1 or ws://localhost then, if blocked, fall back to wss://device-manager.scratch.mit.edu. It would be interesting to give this a try!

Naleksuh commented 2 years ago

Yeah, it sounds like the issue is that it can't be ws;// only, but that doesn't mean wss:// only, there can just be both. Yeah, it'll be interesting to see if it works.