Re: TLS V 1.0 - 1.1 no longer supported

[Kurt Seifried]

 

On Fri, Feb 11, 2022 at 8:21 AM Ruben Wylleman <rubenw...@gmail.com> wrote:

Hi all,

Since this week it seems google chrome pulled the plug on TLS V1.0 and V1.1.

I assume firefox and other browsers will follow quickly.

https://chromestatus.com/feature/5759116003770368

Will GSD also cover all devices that will no longer work due to this action?

So as I see it we have several issues:

1) At one point does using TLS 1.0 or 1.1 become a vulnerability, e.g. using DES/3DES is a vulnerability now, they're just to easy to crack. AFAIK TLS 1.0/1.1 aren't there yet and won't be for quite some time.

2) Providing a web server that doesn't or can't support modern TLS, is that a vulnerability? What about IPv6? I feel like at some level you need to support IPv4/IPv6, HTTPS and a modern TLS suite if you're a webserver. It may not be a vulnerability per se, but it is a concern.

3) Do we make the assumption that if it can't be upgraded to support TLS 1.2 and later that it isn't well supported in general? I think this is a safe assumption. But does that rise to the level of a vulnerability? I would say not, however, it is definitely a concern, e.g. if you have a piece of internet connect software that hasn't had an update in a year or more then it almost certainly has an unpatched vulnerability. I would say this is something the GSD should cover, but not as a vulnerability, "informational" perhaps? It would be fascinating to have a dashboard for the software I use to see when the last update was, this is something I generated by hand at Red Hat many times as we acquired companies (e.g. auditing the dep chain for how well supported the code is, the assumption being anything with no update in a year was a potential risk). 

SInce this week, the reports are coming in quickly.

Actually i'm shocked how much devices were still using TLS1.0 and 1.1

I'm not. 

 

I believe there will be quite a few more that will pop-up coming month.

The impact will be bigger than expected.

I've already been through this with the HTTP->HTTPS transition =). But there it was much more clear (take a password? that's a problem). 

 

Thanks for the info

Ruben

[Ruben Wylleman]

Concering your 1st point, when does something becomes a vulnerability. Who decides this? is this more like a slow transition without a clear tipping moment? 

In our case the reports came from our installers on the field and concerns hardware that primarely use a WebUI for management and configuration.

As far as i can tell, most affected devices had an update release pretty quick after contact with their support. 

It also concerned more of the lower grade network equipment. 

Rolling out these updates to all those scattered installations is another issue, but solvable. (also outside this scope)

There is only one vendor where we don't have an update yet. (they announced TLS1.2 was on the way, back in 2017)

For the moment these devices are partly unmanageable using chrome, edge and firefox, but indeed not vulnerable yet. it's more like a major inconvenience.

Anyway thanks for the input.

I suppose this type of issue's should only be added to GSD as an informational entry when there is no update available or planned.

So i'll wait this one out.

Typing the above, i was wondering..

When something is entered in GSD as informational, like in this example only TLS1.0 supported.

When it transitions in the far future to a vulnerability, i suppose this has te be updated in GSD from informational to a vulnerability.

How would GSD track these kinds of changes? Certainly since there will be some years in between.

 

Op dinsdag 15 februari 2022 om 05:34:55 UTC+1 schreef ksei...@cloudsecurityalliance.org:

[Kurt Seifried]

On Tue, Feb 15, 2022 at 5:18 AM Ruben Wylleman <rubenw...@gmail.com> wrote:

Concering your 1st point, when does something becomes a vulnerability. Who decides this? is this more like a slow transition without a clear tipping moment? 

In our case the reports came from our installers on the field and concerns hardware that primarely use a WebUI for management and configuration.

As far as i can tell, most affected devices had an update release pretty quick after contact with their support. 

It also concerned more of the lower grade network equipment. 

Rolling out these updates to all those scattered installations is another issue, but solvable. (also outside this scope)

There is only one vendor where we don't have an update yet. (they announced TLS1.2 was on the way, back in 2017)

For the moment these devices are partly unmanageable using chrome, edge and firefox, but indeed not vulnerable yet. it's more like a major inconvenience.

I would say this clearly constitutes a risk, e.g. as a buyer of network gear I'd like to know which ones practively ship software updates to remain more secure (e.g. support TLS 1.2/1.3) vs which ones reactively go "oh crap, we have to fix this... we'll get to it, eventually". That is to say, the one vendor is more likely to later have a vulnerability than other (statistically speaking). 

This is one of the major reasons I won't buy an Android phone in Canada, the carriers control access to updates and many phones don't get timely software updates, if at all (and I won't buy a proper Google phone because I can't get it fixed in Canada should there be a problem). So I stick to Apple because I get software updates whether my carrier likes it or not, and I can get it physically fixed in any major city in Canada (well, the world really). It's not a security issue per se, but it does definitely factor in to the "availability" piece of my phone.

 

Anyway thanks for the input.

I suppose this type of issue's should only be added to GSD as an informational entry when there is no update available or planned.

So i'll wait this one out.

I think adding a classification of "risk" especially when it can be clearly articulated "the risk is lack of software updates to ensure compatibility with TLS clients" would be the way to go here.

 

Typing the above, i was wondering..

When something is entered in GSD as informational, like in this example only TLS1.0 supported.

When it transitions in the far future to a vulnerability, i suppose this has te be updated in GSD from informational to a vulnerability.

How would GSD track these kinds of changes? Certainly since there will be some years in between.

Yup. So an easier example: exploitation, log4j is a great example, the timeline: (https://cloudsecurityalliance.org/blog/2021/12/16/keeping-up-with-log4shell-aka-cve-2021-44228-aka-the-log4j-version-2/)

as you can see had GSD somehow caught that at the pull stage or the "hypixel" discussion stage people would have had a weeks warning (the attackers clearly are paying attention, Cloudflare stated they saw activity early on after they knew what to look for in their log files). 

Now in this case the risk->vulnerability may take years, but simply put once TLS 1.1 is pronounced dead, like SSL, we simply grind through the data looking for all instances of "risk AND tls 1.1" and so on and update them to vulnerability. The other thing to keep in mind is that even though it's not a vulnerability, having that risk data is very useful for people, especially when making new buying decisions, and if it incentivizes the vendors to better support newer TLS protocols, then that would be exactly what we want.

[Ruben Wylleman]

great, thanks for the explanation.

Now the vendor seems to have patched the TLS V1.0 issue. 

Update is now available.

They seem to be well aware they dropped the ball in this situation.

Op dinsdag 15 februari 2022 om 18:25:03 UTC+1 schreef ksei...@cloudsecurityalliance.org: