crypto/tls: mitigate "Sweet32"

[r10r]

What version of Go are you using (go version)?

$ go version go1.15.2 linux/amd64

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GOARCH="amd64"
GOHOSTARCH="amd64"
GOHOSTOS="linux"

What did you do?

The godoc for https://golang.org/pkg/crypto/tls/#CipherSuites states

CipherSuites returns a list of cipher suites currently implemented by this package, excluding those with security issues, which are returned by InsecureCipherSuites.

https://play.golang.org/p/1RmZ0n-CKbT

What did you expect to see?

No insecure ciphers listed.

What did you see instead?

TLS_RSA_WITH_3DES_EDE_CBC_SHA is vulnerable to Sweet32 CVE-2016-2183
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA is vulnerable to Sweet32 CVE-2016-2183

[r10r]

testssl.sh reports this in the section Testing vulnerabilities

[ALTree]

cc @FiloSottile @rolandshoemaker

[FiloSottile]

3DES ciphers are picked as the last fallback by peers that can't do anything better, and the only vulnerability they have is the birthday bound inherent to the block size. The attack is impractical, but I had already planned to drop a counter in there to mitigate it.

[r10r]

Thanks for your response.

but I had already planned to drop a counter in there to mitigate it.

So you're going to make some changes to the algorithm but keep the ciphers enabled ?

A note in the godoc would be good here. It's easy to drop these ciphers If you know that you have to.
I would like to keep going with the cipher list as sane defaults - but we got complaints from our customers.
It's hard to argue with customers that this can't be exploited in reality - they see a vulerability in their security scanner and complain about it.

[FiloSottile]

Since we can implement these ciphers securely, we're not going to break old clients that can still establish a secure connection only to appease security scanners. You should probably open an issue with the scanner if possible.

[r10r]

Ok that's good to know. So for secure implementation you "restrict the number of blocks in a key bundle" ?
Can you give me a short pointer how the scanner could possibly distinguish a secure from an insecure implementation?

I trust your words but maybe dropping a note in the godoc about this would be a good thing.

This is just for the records:

• https://en.wikipedia.org/wiki/Triple_DES#Security

as consequence Triple DES has been deprecated by NIST in 2017

• https://www.openssl.org/blog/blog/2016/08/24/sweet32/

OpenSSL does not include 3DES by default since version 1.1.0 (August 2016) and considers it a "weak cipher"

• https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.html
  German Cyber Security Agency BSI does neither mention "Sweet32" nor 3DES/DES in TR-02102-2

[r10r]

Shall I update the documentation and send you a pull request ?

[FiloSottile]

@rolandshoemaker, can you check if any other implementation added record limits to connections? I tried doing the math for staying under the NIST recommendation of 2^20 blocks but that worked out to a tiny size. I am curious what others are doing here.

[rolandshoemaker]

NSS implemented record limits for all ciphers after which they terminate the connection (https://bugzilla.mozilla.org/show_bug.cgi?id=1268745 contains some description of their thought process, and https://hg.mozilla.org/projects/nss/file/tip/lib/ssl/sslspec.c contains the current per cipher limit defs), with different limits depending on the ciphers security level.

As far as I can tell no other TLS implementation added record limits, most seem to have just disabled 3DES by default.