Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
crypto/tls: Remove Lucky13 padding oracle and deprioritize RC4 #7418
crypto/tls/cipher_suites.go says: // Ciphersuite order is chosen so that ECDHE comes before plain RSA // and RC4 comes before AES (because of the Lucky13 attack). I believe this refers to this bit from crypto/tls/conn.go: // note that we still have a timing side-channel in the // MAC check, below. An attacker can align the record // so that a correct padding will cause one less hash // block to be calculated. Then they can iteratively // decrypt a record by breaking each byte. See // "Password Interception in a SSL/TLS Channel", Brice // Canvel et al. // // However, our behavior matches OpenSSL, so we leak // only as much as they do. If I understand correctly, OpenSSL addressed this issue with change <http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=e130841bccfc0bb9da254dc84e23bc6a1c78a64e>. It'd be good to apply a similar fix to Go, and then adjust the default cipher suite order to prefer AES to RC4. For comparison, Android's default suites <https://android.googlesource.com/platform/external/conscrypt/+/master/src/main/java/org/conscrypt/NativeCrypto.java>;
I don't plan on fixing Lucky13 in Go because I've done it in NSS and OpenSSL and it's a nightmare - it would destroy the codebase: https://www.imperialviolet.org/2013/02/04/luckythirteen.html Rather, AES-GCM is the answer.
Status changed to WorkingAsIntended.
This issue was closed.