Old SSL & TLS deprecation

[Frooxius]

Hello everyone!

We are in need of help with some testing for a potentially breaking change. This one should generally not affect anything, but we want to be sure before we push it out.

Build version

TESTING IS OVER

What is being tested

We are removing support for old SSL & TLS protocols (SSL3, TLS 1.0, TLS 1.1). This is due to the protocols being outdated and vulnerable, so they generally shouldn't be used for anything anymore.

With modern .NET runtime (which we are moving towards), the support for these protocols is completely removed as well, which means it won't be possible to support them at all.

How to test

TESTING IS OVER

• On Steam, switch to the prerelease branch and make sure the build updates before you run it
• Make sure your build number is exactly Beta 2024.6.11.1041

Since the build is compatible, please switch to this build if you can and try to daily drive it. Focus on particular areas to see if anything got broken:

• Any WebSocket functionality
• Any HTTP(s) request functionality (e.g. interacting with API's)

If you find something that got broken

• If you found something that seems to have broken with this release, please verify it's specific to this build first
• Switch back to the default public build and re-test with that one
• If the issue appears only on the prerelease build then report it:
• First, check the https://github.com/Yellow-Dog-Man/Resonite-Issues/issues for any existing issues
• If there's no issue yet, create a new one using the prerelease feedback option: https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/new?assignees=shiftyscales&labels=prerelease&projects=&template=prerelease.yml

[jae1911]

Testing my own systems (incl. WebSocket stuff) as well as common ones (like the mute helper TTS add-on), everything works out of the box so far.

[epicEaston197]

I've been testing with my Mastodon viewer and everything has been working perfectly fine with it despite it being a more complex item

[coolymike]

Just wondering, what would the process be if there were issues with certain websites/items?

A website host is responsible for the version of TLS it uses. YDMS can't change that. I don't see what could be done even if there were issues with specific hosts.

Besides, these protocols were disabled in Firefox and Chromium several years ago, websites that still use them are not expected to work anywhere.

[Frooxius]

Depends on what it is - that's part why we're doing this. We don't expect any significant issues stemming from this. If something comes up, we'll evaluate it.

We're mainly worried about people's local things - websockets and local servers.

The protocols will be disabled sooner or later, but this is a way to make sure that nothing catches on fire and gives people a bit of a heads up that this is happening.

[bredo228]

Did a quick test of headless on Linux, appears to work fine starting / joining and connects to SignalR / Resonite API properly

[bontebok]

Rather than moving to fully block the insecure/legacy protocols, would you consider placing the deprecated TLS/SSL setting behind a user configurable toggle in settings? Similar to how browsers like Chrome are handling the ability to enable TLS v1.2 by requiring a user toggle. That way functionality can be restored if lost, but also allows a transitional period where users will be aware that access to legacy protocols will be permanently blocked in the future.

I'm all for removing support for weak/deprecated security, but we know that legacy systems still exist. There will be some users who won't participate in the prerelease testing, and rolling out this release may cause a loss of access to some functionality.

[stiefeljackal]

Agree with @bontebok's response, and that is exactly what I thought @bontebok is getting at. I don't believe the testing from the prerelease branch will reflect accurate results as far as how impactful this will be.

If the Resonite Team wants to offer a graceful transitional period for users, then default to the supported security protocols and offer a temporary legacy option to toggle deprecated protocols back on. Once it is time to move from .NET Framework 4.6.2 to .NET 8, remove the option entirely.

[KisaragiEffective]

The toggle option would be effectively useless because users of such legacy environments must be faced to problem in following point of view:

1. is out of date¹
2. cannot connect to most websites ²

Footnotes

1. For example, Internet Explorer 10 and earlier, Android 4 and earlier, and so on; those environments do not support TLS 1.2 and do not receive update regularly and are going to have poor support from today's website. ↩

2. Cloudflare said 88% of whole connection uses TLS 1.2 in Dec, 2017 at their blog post; the percentage must be increased in today ↩

[Frooxius]

I think it might be too much for this particular scenario. Implementing that option will take additional engineering time and complexity and the risk of this being a significant issue is low enough.

Assuming there aren't any huge issues from the testing that make Resonite fully unusable, we'll just push this change. If significant issues come up then, we'll revert the change (which can be done really quickly, it's just changing a line of code) and then invest time into adding the settings.

[stiefeljackal]

Assuming there aren't any huge issues from the testing that make Resonite fully unusable, we'll just push this change. If significant issues come up then, we'll revert the change (which can be done really quickly, it's just changing a line of code) and then invest time into adding the settings.

I believe this is a good action plan. Thank you for responding, @Frooxius; your response gives me confidence.

it's just changing a line of code

I assume it is the enum that just needs to be changed.

[Geenz]

It's pretty much two places in the codebase that would need to change. What's likely here is we'd probably "work backwards" - e.g., TLS1.2 + TLS 1.1. The older you get as far as TLS versions, the more vulnerable traffic will be coming from Resonite. But ideally TLS 1.2 is fine for everyone, and when we make the jump to .NET 8 we'll just be using TLS 1.2 + 1.3 as that's what the vast majority of the internet is using today.

However, there's some reports out there that largely seem to point towards the death of SSL3, TLS1.0, and 1.1. It's hard to nail down specific numbers, but across the board it's pretty clear that TLS 1.2 and 1.3 are the dominant protocols out there.

According to Keysight - TLS 1.2 makes up ~34% of internet traffic observed in a recent report with TLS 1.3 making up the rest. They do not list any deprecated protocols in their report.

A 2021 report by F5 - a information security research firm - shows that TLS 1.3 and 1.2 has been the dominant protocols of the time across observed internet traffic across the top one million sites of the time. However deprecated protocols largely broke down like this:
TLS 1.0 and 1.1 - ~0.4%
SSL3 - ~2%

Despite SSL3 taking up 2% in their 2021 report, we cannot continue supporting SSL3. It has been completely removed from .NET8. This is a hard blocker on our .NET8 plans - full stop. It is also considered a highly vulnerable protocol.

All in all the risk factors are looking fairly slim of something going wrong here. Regardless, we can drop down a version if absolutely needed.

[stiefeljackal]

I am all for removing these protocols entirely, but when are you planning to push the removal of these deprecated security protocols to production? Can you provide an estimated timeline?

[Frooxius]

We're going to play it a bit by ear. If we don't see super much testing activity and any issues pop up, we'll probably push it out tomorrow.

If something spooky comes up, we'll delay until we figure it out.

Worse case scenario, if there's big impact that's found after release, we can revert it.

[Frooxius]

Just a heads up, given little activity with this, we assume that there's no major issues discovered while in pre-release channel.

We'll be pushing this change out in the next build and monitoring then - if there's some big issues, we can revert pretty quick.

The prerelease branch will now have different builds.