Closed cwillisf closed 4 years ago
That's a tricky question. I think most browsers will be supporting only >= 1.2 from now on, but I think we should probably support 1.1 at least for the time being to help support older/unupdated equipment. Even with that, I bet we're going to get some feedback at some point that someone needs TLS 1.0...
@colbygk According to caniuse, TLS1.2 is supported on Edge 12+, Firefox 27+, Chrome 29+ and Safari 7+. Since our supported browser versions all support TLS1.2 we shouldn't ever need to enable TLS1.1 or older. I'm sure Scratch Desktop is fine with it too. (We do not have to care about mobiles, this is desktop-only app.)
Given that we only attach to 127.0.0.1 and don't accept connections from outside the host, why shouldn't we let it support TLS 1.1 if it can? There have been 700 sessions coming from Safari users advertising version numbers <= 6.x in the last 45 days. That is verrrry low numbers and now that I'm paying more attention, is this specific to Windows only? If so, then I think there's probably even more reason to support 1.1 if it's simply boolean operation to activate it.
I spoke with @colbygk and we decided to allow TLS 1.0 - 1.2 just in case there might be some clients relying on older protocols. Since the data isn't actually sensitive and the connection is generally a loopback / localhost connection anyway, the security risks of allowing older protocols are minimal.
@colbygk, I'm adding you as a reviewer in case you have thoughts about TLS versions. For example, is there any reason to also enable TLS 1.1 or even 1.0?
Resolves
Resolves #179
Proposed Changes
Explicitly specify TLS 1.2 when starting the WebSocket server.
Reason for Changes
Previously we relied on the default, which turns out to be only the TLS 1.0 protocol (verified with
nmap
). Chrome recently started blocking TLS 1.0 and TLS 1.1 as obsolete, so existing versions of Scratch Link are starting to be blocked. It seems Firefox is doing something similar.It would be nice to also enable TLS 1.3 but our current SSL library doesn't support that. These are the options currently available; they can be combined but I'm not aware of any reason to do so: