The "RSA key exchange" cipher suites (not to be confused with ECDHE cipher suites that use RSA certificates), or non-ECDHE cipher suites, work dramatically differently from the ECDHE ones: instead of using the certificate to sign an ephemeral key exchange, they encrypt the session key with the certificate's public key.

This has two major downsides:

1. there is no forward secrecy, as if at any point the certificate key becomes compromised, all previous and future connections can be passively decrypted;
2. this forces the server to decrypt attacker-provided PKCS#1 v1.5 ciphertexts with the certificate private key, which needs to be done in perfectly constant time to avoid Bleichenbacher '98 padding oracles attacks, which we have the extremely dangerous rsa.DecryptPKCS1v15SessionKey API for, but which the Marvin attack suggests we might still not be doing correctly.

Thanks to automatic cipher suite ordering, we don't necessarily have to disable less secure cipher suites, confident that they will be only picked as a last resort. However, even as a last resort (1) and (2) are problematic: (1) delivers a meaningfully different security property for some connections, in a way that is mostly obscure to applications and not opt-in; (2) means that even just supporting the cipher suite makes it possible for attackers to mount potential attacks to retroactively decrypt connections, or even forge signatures.

Concretely, I propose we move the following cipher suites to disabled by default in Go 1.22 behind a godebug.

TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_3DES_EDE_CBC_SHA

Unfortunately, we have even less data than #62459, because Cloudflare does not publish cipher suite stats.

In theory, we could prioritize disabling the server side, which is affected by the Marvin attack, but we are generally more aggressive in modernizing the client anyway (because clients can have a stronger expectation of competence from servers than the other way around), so might as well keep it simple and disable them on both sides.

/cc @rolandshoemaker @golang/security