Hacker News Reader

Comment by er4hn | Hacker News Reader

Summary: The Golang team is deciding what ranked order TLS cipher suites should be used in. You are not able to decide what cipher suites to use, the Golang team sets that in the code and will update it as they see fit.

My take on this is that Filippo is taking a heavy handed approach here. This works for the majority of "dev write code fast ship it over the wall" scenarios. But it also falls apart in a couple scenarios:

* Companies/govt agencies which mandate the use of certain algorithms, such as RSA, and both sides of the connection are running Golang code. Now you need to vendor the TLS library to allow for what the company wants.

* If an issue is discovered with an algorithm it would be really nice to be able to turn off the algorithm in production until the issue can be patched. I'm not sure if this is possible with the current set of changes.

View on HN

_o/ the summary is close, but there's a key detail that might have not come across: you can still enable and disable TLS 1.0-1.2 cipher suites. What we take care of is the preference order in which they are picked.

The two scenarios you present aren’t really affected by this change. However, I want to address the latter: if we fail to make it possible for Go applications to promptly roll out software security fixes, being able to change TLS configuration will be barely a band-aid. I actually can’t remember the last time that would have helped secure a Go application faster.

Thanks for the clarification. Being able to disable cipher suites in TLS <= 1.2 takes care of a lot of my concerns. It does still remain a concern for 1.3.

I still do worry about the lack of ability to disable cipher suites. Does that extend to not being able to say "I will only accept certificates signed with RSA?" Because if you are forced to allow EC certificates then there are a couple points in the past where this could have been an issue ( https://www.cvedetails.com/cve/CVE-2019-6486/ and https://www.cvedetails.com/cve/CVE-2021-3114/ ). Furthermore if we imagine a future where an issue is found with how one of the ciphersuites is implemented (say ChaCha20 is done incorrectly and we only want to allow AES-GCM) then being able to disable the known bad ciphersuite is a great band-aid.

Let's say that you are providing a Go application to a customer. The customer can configure the application with a config file that controls TLS params. If you can configure the TLS ciphersuites and an issue is found the customer turns off the ciphersuite until they can upgrade. The alternative is that you go through a chain of: vendor gets new Golang -> rebuilds application -> does in-house testing to make sure nothing else came in the new Golang that broke stuff -> customer gets new application -> customer does their own in-house testing -> finally it gets deployed. It's a way longer cycle if you rely on upstream to push changes in code.

Why do TLS issues need to get patched faster than any other security vulnerability? Or said another way, why is a slow deploy cycle ok for non-TLS vulnerabilities?

So far I haven’t heard any good reason. TLS issues are not more common than other components, at least in Go. Maybe people are just a little traumatized by how often other TLS stacks broke in the past?

We maintain two Go versions with very conservative patch releases specifically to allow quick deployment of critical and security fixes. If that still doesn’t allow for quick patching of security vulnerabilities, it sounds like a process issue (on our side or on the application side), not a reason to make TLS special.

> why is a slow deploy cycle ok for non-TLS vulnerabilities?

Okay, this is a fair point. I'd say that TLS is something where fixing it faster than the baseline is possible, if it had configurable knobs. In general we should of course strive to have fast deploy cycles for security vulnerabilities of all kinds.

Any government agency that mandates use of specific TLS algorithms (like whitelist) almost certainly requires FIPS cryptography (or classified cryptography), so you won’t be using crypto/TLS anyway.

As a security/cryptography engineer, I love this change: for cryptography, it’s clear that more knobs == more problems.

As a developer, however, I dislike it: more knobs it’s easier to get the code to do what I need it to do.

Personally, I think it’s a good choice by Filippo.

Isn't it mostly banks that want RSA key exchange, so their exfiltration detectors can sniff TLS streams?

Shouldn't matter in this case, anyhow, as they would be disabling ephemeral KEX suites entirely.

That's not so much to do with RSA as it does with Perfect Forward Secrecy. In fact, the banks tried to make their own separate TLS standard instead of using TLS 1.3: https://www.eff.org/deeplinks/2019/02/ets-isnt-tls-and-you-s...

From "Go Crypto and Kubernetes — FIPS 140–2 and FedRAMP Compliance" (2021) https://gokulchandrapr.medium.com/go-crypto-and-kubernetes-f... :

> If a vendor wants to supply cloud-based services to the US Federal Government, then they have to get FedRAMP approval. This certification process covers a whole host of security issues, but is very specific about its requirements on cryptography: usage of FIPS 140–2 validated modules wherever cryptography is needed, these encryption standards protect the cryptographic module from being cracked, altered, or otherwise tampered with. FIPS 140–2 validated encryption is a prerequisite for FedRAMP. [...]

> [...] Go Cryptography and Kubernetes — FIPS 140–2 Kubernetes is a Go project, as are most of the Kubernetes subcomponents and ecosystem. Golang has a crypto standard library, Golang Crypto which fulfills almost all the application crypto needs (TLS stack implementation for HTTPS servers and clients all the way to HMAC or any other primitive that are needed to make signatures to verify hashes, encrypt messages.). Go has made a different choice compared to most languages, which usually come with links or wrappers for OpenSSL or simply don’t provide any cryptography in the standard library (Rust doesn’t have standard library cryptography, JavaScript only has web crypto, Python doesn’t come with a crypto standard library). [...]

> The native go crypto is not FIPS compliant and there are few open proposals to facilitate Go code to meet FIPS requirements. Users can use prominent go compilers/toolsets backed by FIPS validated SSL libraries provided by Google or Redhat which enables Go to bypass the standard library cryptographic routines and instead call into a FIPS 140–2 validated cryptographic library. These toolsets are available as container images, where users can use the same to compile any Go based applications. [...]

> When a RHEL system is booted in FIPS mode, Go will instead call into OpenSSL via a new package that bridges between Go and OpenSSL. This also can be manually enabled by setting `GOLANG_FIPS=1`. The Go Toolset is available as a container image that can be downloaded from Red Hat Container Registry. Red Hat mentions that this as a new feature built on top of existing upstream work (BoringSSL). [...]

> To be FIPS 140–2 compliant, the module must use FIPS 140–2 complaint algorithms, ciphers, key establishment methods, and other protection profiles.

> FIPS-approved algorithms do change at times; not extremely frequently, but more often than they come out with a new version of FIPS 140. [...]

> Some of the fundamental requirements (not limited to) are as follows:

> [...] Support for TLS 1.0 and TLS 1.1 is now deprecated (only allowed in certain cases). TLS 1.3 is the preferred option, while TLS 1.2 is only tolerated.

> [...] DSA/RSA/ECDSA are only approved for key generation/signature.

> [...] The 0-RTT option in TLS 1.3 should be avoided.

Was there lag between the release of TLS 1.3 and an updated release of FIPS 140? @18f @DefenseDigital Can those systems be upgraded as easily?

NIST just moves slowly is all.

Common Criteria (NIAP) still only allows TLSv1.2 and TLSv1.1.

I'll note that this follows the general trend of the Golang Security team trying to remove all the sharp edges on security code so that people don't cut themselves. I won't say that this is a uniformly bad thing, but it does make things harder.

Another change in the same vein was removing official support for x/crypto/openpgp. There were no maintainers, it required too much effort, and pgp is in general a PITA to use. Totally understand. However this means that anyone working with signed git commits or signed rpm/deb packages is now using a forked library due to upstream dropping support.

> but it does make things harder.

Unknowingly doing bad things harder, yes.

It would break in my use case, for sure. We routinely initiate TLS connections to crappy devices which have TLS implementations broken in ways that cause them to fail if you select the wrong cipher suite, even when the server otherwise claims to support it. Our ability to force this on a per-service basis is crucial to our success. We do not have the ability to fix the broken devices nor the luxury of not connecting to them.

Can you open an issue elaborating on this? I’d expect the ability to disable broken cipher suites to be enough to work around this, and that is not changing. (What’s going away is controlling the order in which enabled cipher suites are picked.)

Why yes let's make it more secure by taking power away from the developers, that'll surely work.

Reply on news.ycombinator.com