crypto/tls: Remove Lucky13 padding oracle and deprioritize RC4

[matthewg]

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>;

[robpike]

Comment 1:

Owner changed to @agl.

[agl]

Comment 2:

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.

[matthewg]

Comment 3:

Should the order of these three entries in the default cipher suite list be changed,
then?
  TLS_RSA_WITH_RC4_128_SHA
  TLS_RSA_WITH_AES_128_CBC_SHA
  TLS_RSA_WITH_AES_256_CBC_SHA