4 ms·

When Heroku removed support for TLS 1.0 and TLS 1.1 this year, I was surprised at how many of my customers were effected. I didn't give the deprecation much tho

by ezekg 5y ago

When Heroku removed support for TLS 1.0 and TLS 1.1 this year, I was surprised at how many of my customers were effected. I didn't give the deprecation much thought, assuming everyone was using a secure TLS version, but I guess enterprises like their legacy technology.

umvi 5y ago
It's not that enterprises "like" legacy technology, it's just that it costs (potentially a lot of) time and money to audit and fix legacy code.
- AmericanChopper 5y ago
  The biggest problem the PCI SSC had with deprecating old TLS versions was the sheer number of devices running XP Embedded (which doesn’t support newer TLS versions). It was THE operating system for point of sale devices for a very long time, and replacing or upgrading these devices was a very complicated and expensive process for a lot of organisations. I haven’t worked with PCI for a couple of years, so I’m not sure where they got to. But that was the main issue that kept getting the depreciation deadlines pushed back. The ubiquity of that operating system was an issue in lots of other industries too. I worked in a place recently that had a large industrial robotics system, all of it was running on XP Embedded, and the most feasible approach they came up with for addresses the security issues created by that was to implement increasingly more strict network segmentation controls for their robots. I know it was also running on a fair amount of military hardware too (maybe still is? I have no idea), I don’t think you’ll find many helpful Stack Overflow threads for how to upgrade your Lockheed AC-130 from Windows XP…
IiydAbITMvJkqKf 5y ago
.net framework (NOT core) on windows did (does?) Not support tls 1.2 by default. Enabling it takes either one line of code or a registry change. It surprised me as well.
- will4274 5y ago
  *Windows 7. Which was released in 2009, 1 year after TLS 1.2 was finalized. Windows 8.1 and 10 support TLS 1.2 without opt in.
  - tetha 5y ago
    In case someone is hardening these settings, we had a weird issue with Windows Server 2016 (iirc) based on this. The mozilla SSL config generator is going to give you a cipher configuration and happily claims Windows 7 and Win2016 both can connect to these servers. However, that's only true if you use a certificate with an elliptic key. With a certificate with an RSA key, Win 7 and Windows Server 2016 cannot connect. That was a mess to figure out.
  - JonathonW 5y ago
    > Windows 8.1 and 10 support TLS 1.2 without opt in. Not necessarily true depending on the application and when it was compiled. For example, older versions of Nuget will not connect to the current Nuget registry (after they removed support for TLS 1.0/1.1 a while back) without a registry change to require TLS 1.2, even on fully-patched Windows 10. Compile against current .NET Framework and IIRC you get it by default, but old code still has to opt-in.
  - Already__Taken 5y ago
    Supported yes but windows won't do it until you turn it on and that change was a very very recent change. It's not even in the UI options were you enable it for TLS but down in the windows registry.
- ezekg 5y ago
  Yep, the .NET thing was the biggest cause of issue for my customers. Thankfully, all were a pretty quick fix but I also thought this was really weird.
- MarkSweep 5y ago
  On recent versions of .NET gotten easier. If your app targets a new enough version, you automatically get support for the most recent version of TLS. https://docs.microsoft.com/dotnet/framework/network-programming/tls https://docs.microsoft.com/dotnet/framework/network-programm...
shadowgovt 5y ago
If it ain't broke(1), standard operating procedure is not to fix it. So a lot of corps (and orgs, and individual devs) end up on TLS <1.2 without giving it any thought. It can even be hard to reach them... A lot of stuff gets automated, and it takes a level of discipline to avoid routing some of the low-level error messaging to /dev/null (or its spiritual sister, an infolog nobody ever reads) that surprisingly many institutions lack. (1) Security is extra-hard, because it ain't broke until it's broken into from the point of view of the end user.
rodgerd 5y ago
One challenge for a lot of enterprise shops is an addiction to things like MITM middleware boxes, which often lag far behind, and long approval cycles for updates - demanding that software be repackaged for deployment and the like. The biggest blocker on 1.3 deployment will be that it deliberately breaks middleboxes, which many, many enterprises have as a hard requirement (foolishly, in my opinion).

by ezekg 5y ago

umvi 5y ago

It's not that enterprises "like" legacy technology, it's just that it costs (potentially a lot of) time and money to audit and fix legacy code.

AmericanChopper 5y ago
The biggest problem the PCI SSC had with deprecating old TLS versions was the sheer number of devices running XP Embedded (which doesn’t support newer TLS versions). It was THE operating system for point of sale devices for a very long time, and replacing or upgrading these devices was a very complicated and expensive process for a lot of organisations. I haven’t worked with PCI for a couple of years, so I’m not sure where they got to. But that was the main issue that kept getting the depreciation deadlines pushed back. The ubiquity of that operating system was an issue in lots of other industries too. I worked in a place recently that had a large industrial robotics system, all of it was running on XP Embedded, and the most feasible approach they came up with for addresses the security issues created by that was to implement increasingly more strict network segmentation controls for their robots. I know it was also running on a fair amount of military hardware too (maybe still is? I have no idea), I don’t think you’ll find many helpful Stack Overflow threads for how to upgrade your Lockheed AC-130 from Windows XP…

IiydAbITMvJkqKf 5y ago

.net framework (NOT core) on windows did (does?) Not support tls 1.2 by default. Enabling it takes either one line of code or a registry change. It surprised me as well.

will4274 5y ago
*Windows 7. Which was released in 2009, 1 year after TLS 1.2 was finalized. Windows 8.1 and 10 support TLS 1.2 without opt in.
- tetha 5y ago
  In case someone is hardening these settings, we had a weird issue with Windows Server 2016 (iirc) based on this. The mozilla SSL config generator is going to give you a cipher configuration and happily claims Windows 7 and Win2016 both can connect to these servers. However, that's only true if you use a certificate with an elliptic key. With a certificate with an RSA key, Win 7 and Windows Server 2016 cannot connect. That was a mess to figure out.
- JonathonW 5y ago
  > Windows 8.1 and 10 support TLS 1.2 without opt in. Not necessarily true depending on the application and when it was compiled. For example, older versions of Nuget will not connect to the current Nuget registry (after they removed support for TLS 1.0/1.1 a while back) without a registry change to require TLS 1.2, even on fully-patched Windows 10. Compile against current .NET Framework and IIRC you get it by default, but old code still has to opt-in.
- Already__Taken 5y ago
  Supported yes but windows won't do it until you turn it on and that change was a very very recent change. It's not even in the UI options were you enable it for TLS but down in the windows registry.
ezekg 5y ago
Yep, the .NET thing was the biggest cause of issue for my customers. Thankfully, all were a pretty quick fix but I also thought this was really weird.
MarkSweep 5y ago
On recent versions of .NET gotten easier. If your app targets a new enough version, you automatically get support for the most recent version of TLS. https://docs.microsoft.com/dotnet/framework/network-programming/tls https://docs.microsoft.com/dotnet/framework/network-programm...

shadowgovt 5y ago

If it ain't broke(1), standard operating procedure is not to fix it. So a lot of corps (and orgs, and individual devs) end up on TLS <1.2 without giving it any thought. It can even be hard to reach them... A lot of stuff gets automated, and it takes a level of discipline to avoid routing some of the low-level error messaging to /dev/null (or its spiritual sister, an infolog nobody ever reads) that surprisingly many institutions lack. (1) Security is extra-hard, because it ain't broke until it's broken into from the point of view of the end user.

rodgerd 5y ago

One challenge for a lot of enterprise shops is an addiction to things like MITM middleware boxes, which often lag far behind, and long approval cycles for updates - demanding that software be repackaged for deployment and the like. The biggest blocker on 1.3 deployment will be that it deliberately breaks middleboxes, which many, many enterprises have as a hard requirement (foolishly, in my opinion).