3 ms·

_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 car

_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.

er4hn 5y ago
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/ https://www.cvedetails.com/cve/CVE-2019-6486/ and https://www.cvedetails.com/cve/CVE-2021-3114/ 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.
- FiloSottile 5y ago
  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.
  - er4hn 5y ago
    > 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.

er4hn 5y ago

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/ https://www.cvedetails.com/cve/CVE-2019-6486/ and https://www.cvedetails.com/cve/CVE-2021-3114/ 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.

FiloSottile 5y ago
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.
- er4hn 5y ago
  > 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.