3 ms·
I'll do you one better. The head of security for Golang, a google employee, was also part of the TLS 1.3 committee and in Golang, it's impossible by design to
by KennyBlanken 3y ago
I'll do you one better.
The head of security for Golang, a google employee, was also part of the TLS 1.3 committee and in Golang, it's impossible by design to disable specific ciphers in TLS 1.3
The prick actually had the nerve to assert that TLS 1.3's security is so good this should never be necessary, and that even if it were, they'll just patch it and everyone can upgrade.
So someone releases a 0-day exploit for a specific TLS cipher. Now you have to wait until a patch is released and upgrade your production environment to fix it - all the while your pants are down. That's assuming you're running a current version in production and you don't have to test for bugs or performance issues upgrading to a current release.
Heaven fucking forbid you hear a cipher is exploitable and be able to push a config change within minutes of your team hearing about it.
I'd place 50/50 odds on it being a bribe by the NSA vs sheer ego.
- londons_explore 3y agoSeems like a stupid design, if only for the fact that some uses of TLS, where a very specific client is connecting, you might want to enable precisely the one cypher suite you expect that client to use. Then all your performance tests can rely on the encryption and key exchange will always use the same amount of CPU time etc.