testssl.sh reports this in the section Testing vulnerabilities

cc @FiloSottile @rolandshoemaker

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.

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.

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.

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

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

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

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.

/cc

Kindly pinging @rolandshoemaker @katiehockman @FiloSottile, shall we punt this to Go1.17?

Punted to Go1.17.

Change https://golang.org/cl/314609 mentions this issue: crypto/tls: make cipher suite preference ordering automatic