4 ms·

Google's fingers are going deeper than just "web standards." Filippo Valsorda, the Go lead for security, was one of the authors of TLS 1.3. He has refused to a

Google's fingers are going deeper than just "web standards." Filippo Valsorda, the Go lead for security, was one of the authors of TLS 1.3. He has refused to allow for configuration of TLS 1.3 ciphers in Go: https://github.com/golang/go/issues/29349 https://github.com/golang/go/issues/29349 Thanks to this decision: if a particular cipher is found to be weak or vulnerable, people using Go won't be able to immediately disable it. Instead, they'll be forced to wait for a release or patch, and possibly have to backport it to the version they're running in production. Another scenario, as pointed out in that ticket: sometimes other vendors don't properly implement ciphers on their end, and there's an incompatibility. Prior to TLS 1.3, one could just disable that particular cipher, perhaps even just for a particular connecting client. His response was, paraphrasing: "TLS 1.3 is amazing and awesome and will not have the same problems prior TLS versions had. It needs to Just Work, if there's a security issue we'll issue a patch, and if you can't apply it in a timely fashion you're incompetent." He seems unaware that not everyone uses Google's "just roll it out to a few hundred nodes and keep an eye on them" approach to SRE, or that major organizations don't have time to wait for a patch - they need a quick switch flip until the patch is out and can pass their normal validation before moving to production.

bawolff 5y ago
Wait, the security lead of the language designed by google is associated with google! What a conspiracy! I know we're on a google is evil thread, but not literally everything they're involved with is a conspiracy.
- rapind 5y ago
  > I know we're on a google is evil thread, but not literally everything they're involved with is a conspiracy. 100% agree, and yet one of the downsides of their recently exposed behaviour is an erosion of trust in everything they touch. For good or bad. Especially big important security considerations. The more crap like this I hear about, the less I’m willing to trust their products. For example, I almost chose GCP for a project but decided against it because I just don’t trust them not to hose me due to something completely out of my control. These things pile up and tarnish their brand and anyone closely associated with their brand.
- theduder99 5y ago
  what do you think about that guy's opinion about how ciphers should be handled?
  - bawolff 5y ago
    There's pros and cons. There's lots of evidence that people make bad choices when allowed to configure crypto, and there has generally been a movement towards having more opaque interfaces where users have less rope to hang themselves. People who don't have the ability to deploy updates will also be screwed when normal security issues happen, so i dont find that super compelling. Additionally there are some privacy implications about letting users configure. Otoh, personally i like the ability to config things if i really have to, and such a policy might lead to people running custom forks which is bad.
- passivate 5y ago
  That is true, but this is a normal thing that happens when there is a trust deficit.
jatone 5y ago
and hes absolutely right. it needs to just work. WireGuard takes the same approach. And you're talking about the default ciphering setup golang in no way prevents you as a developer from changing ciphers as a developer of an application. it just doesn't expose it directly. you can go and change the golang runtime and since its open source you can. but wtf ever would you? you're just opening yourself up to self inflicted pain.

bawolff 5y ago

Wait, the security lead of the language designed by google is associated with google! What a conspiracy! I know we're on a google is evil thread, but not literally everything they're involved with is a conspiracy.

rapind 5y ago
> I know we're on a google is evil thread, but not literally everything they're involved with is a conspiracy. 100% agree, and yet one of the downsides of their recently exposed behaviour is an erosion of trust in everything they touch. For good or bad. Especially big important security considerations. The more crap like this I hear about, the less I’m willing to trust their products. For example, I almost chose GCP for a project but decided against it because I just don’t trust them not to hose me due to something completely out of my control. These things pile up and tarnish their brand and anyone closely associated with their brand.
theduder99 5y ago
what do you think about that guy's opinion about how ciphers should be handled?
- bawolff 5y ago
  There's pros and cons. There's lots of evidence that people make bad choices when allowed to configure crypto, and there has generally been a movement towards having more opaque interfaces where users have less rope to hang themselves. People who don't have the ability to deploy updates will also be screwed when normal security issues happen, so i dont find that super compelling. Additionally there are some privacy implications about letting users configure. Otoh, personally i like the ability to config things if i really have to, and such a policy might lead to people running custom forks which is bad.
passivate 5y ago
That is true, but this is a normal thing that happens when there is a trust deficit.

jatone 5y ago

and hes absolutely right. it needs to just work. WireGuard takes the same approach. And you're talking about the default ciphering setup golang in no way prevents you as a developer from changing ciphers as a developer of an application. it just doesn't expose it directly. you can go and change the golang runtime and since its open source you can. but wtf ever would you? you're just opening yourself up to self inflicted pain.