win_chocolatey - Allow users to select the TLS versions used for bootstrapping Chocolatey installation

[JamieMagee]

Since February 3rd 2020, Chocolatey has disabled TLS 1.0 and 1.1 (source). Therefore, this code that enables TLS 1.1 is at best unnecessary, and at worst silently leaves clients open to downgrade attacks.

[jborean93]

This might be problematic for people who are not using the public repo but some internal server that god forbid doesn't allow TLS 1.2.

[vexx32]

Not sure if it might be worth exposing a whole option just for that 🤔

[jborean93]

Typically I would leave this up to the OS to manage but I have no idea if .NET respects the value in the schannel registry entries if they are disabled but you still set them for the SecurityProtocol.

[vexx32]

IIRC if you leave the setting as SystemDefault it will default to the registry configuration. 🤔

[JamieMagee]

This might be problematic for people who are not using the public repo but some internal server that god forbid doesn't allow TLS 1.2.

True, but at that point you're really fighting against the grain. Google, Microsoft, and Apple (to name a few) are all removing support for TLS 1.0 and 1.1 across various different products.

Given that chocolatey runs with administrator privileges, I think that security should come first.

[vexx32]

@ferventcoder do you have any thoughts on this one?

[pauby]

I would agree with @jborean93 - if people are not using the public repositories then they may need to use TLS 1.1. It has its issues it's still widely used and probably more so internally where they can control access and the security risk is less.

@JamieMagee said:

True, but at that point you're really fighting against the grain. Google, Microsoft, and Apple (to name a few) are all removing support for TLS 1.0 and 1.1 across various different products.

Microsoft, Google and Apple are in different situations where they can more easily control that ecosystem. Chocolatey can't. It's easy for Microsoft to say 'you need to support TLS 1.2 or gadget-awesome is not going to be able to talk to your system' especially when they control gadget-awesome and system. They also have a pretty healthy external presence and in that respect the safes / best / strongest security is what you need to turn on and all the others off. We are talking about organizations internal infrastructure here and the horrors that could be contained within. Chocolatey talks to a whole host of different systems that are created by a whole who of different groups / organizations. So, it's not so easy to demand they adhere to a certain security standards.

TLS 1.2 might be what is 'best for them' in terms of security, but TLS 1.1 might be the only option for them to use.

[vexx32]

I think the ideal situation would be to allow a configuration option to select the TLS versions used, so that folks who can use TLS1.2 aren't left open to downgrade attacks. I'll have to see where the best place to sort that out is. 🤔

[JamieMagee]

@pauby That's fine, but don't enable TLS1.1 by default for all users. If it's an internal system, system administrators can enable or disable required TLS versions using Group Policies.

Why are you opening an attack vector for all users? This code should be secure by default.

[pauby]

@JamieMagee

@pauby That's fine, but don't enable TLS1.1 by default for all users. If it's an internal system, system administrators can enable or disable required TLS versions using Group Policies.

Why are you opening an attack vector for all users? This code should be secure by default.

I think what is needed is a step back here. I didn't suggest either of those things. I suggested that wholesale removal of TLS 1.1 is not what we should do. The world of IT is greatly different from the bubble we're currently writing this in.

Just to pick up on the point about Group Policies however - not everybody using Windows systems uses AD and not everybody who uses AD is using Group Policy. So leaving it to Group Policy isn't an option.

Perhaps we enable TLS 1.2 and fallback to TLS 1.1 rather than enabling TLS 1.1 and then enabling TLS 1.2. Or, a better suggestion is as @vexx32 said we enable TLS 1.1 only when asked - that gets my vote.

[vexx32]

Having looked closer at this code, the behaviour is actually a bit non-obvious:

chocolatey-ansible/chocolatey/plugins/modules/win_chocolatey.ps1

Lines 211 to 219 in 2c5e7cf

	# Enable TLS1.1/TLS1.2 if they're available but disabled (eg. .NET 4.5)
	$security_protocols = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::SystemDefault
	if ([Net.SecurityProtocolType].GetMember("Tls11").Count -gt 0) {
	$security_protocols = $security_protcols -bor [Net.SecurityProtocolType]::Tls11
	}
	if ([Net.SecurityProtocolType].GetMember("Tls12").Count -gt 0) {
	$security_protocols = $security_protcols -bor [Net.SecurityProtocolType]::Tls12
	}
	[Net.ServicePointManager]::SecurityProtocol = $security_protocols

It's easy to miss, but the variable used in both -bor expressions is actually misspelled (L214, L217), so these aren't enabling TLS as one might think. The actual result of this code is:

1. At minimum, it is set to SystemDefault, whatever that default is.
2. Then, if the Tls11 enum value is available, overwrites that (no longer permits system default) and forces it to TLS1.1
3. Then, if the Tls12 enum value is available, again overwrites the previous applications and forces it to TLS1.2

So assuming the system is capable of TLS1.2, it currently forces it to use that. So we're already kind of doing what the original request here is asking, by accident.

Judging by the discussion above, though, we should have a more robust method here, and we should allow users to select the value they want to use, and I don't think permitting fallbacks is necessarily a terrible thing -- as Paul pointed out above, folks may have internal servers which use earlier TLS versions that they still need to use.

[vexx32]

I have updated the issue title to better reflect the discussion here. I'll be looking to get a PR up for this soon.