TLS 密码套件名称的结构使得您可以知道握手和加密会话的每个部分使用了哪些算法和密钥大小。让我们分解一下，看看我们是否可以做出任何改进：

• TLS - 这本身并不意味着任何东西，但确实允许我提到 TLS 1.2 是 TLS 的最新版本，并且没有任何已知的漏洞。
• ECDHE- 带有临时键的椭圆曲线 Diffie-Hellman。这是密钥交换方法。使用临时（每个会话生成）密钥的 Diffie-Hellman 密钥交换提供前向保密，这意味着即使服务器的私钥已知，会话也无法在事后解密。椭圆曲线密码学提供与传统公钥密码学相当的强度，同时需要更小的密钥大小，这可以提高性能。此外，它们还可以作为对冲 RSA 突破的对冲赌注。
• RSA- 服务器的证书必须包含 RSA 公钥，并且必须使用对应的私钥对 ECDHE 参数进行签名。这就是提供服务器身份验证的原因。另一种选择是 ECDSA，另一种椭圆曲线算法，但您可能会受到 CA 将签署的证书类型的限制。
• AES_128- 对称加密密码是带有 128 位密钥的 AES。这相当快并且没有损坏（除非您认为 NSA 已经使用了 AES 后门，这是另一个话题）。除了 AES_256（在性能方面可能成本太高）之外，它是RFC 5246 中定义的对称密码的最佳选择，其他的是 RC4（它有一些已知的弱点，可能很快就会被破解）和 3DES_EDE（它只有实际位强度为 108 到 112，具体取决于您的来源）。
• CBC- 密码块链接模式。在这里，您可能可以改进您的选择。CBC 模式是一种使用分组密码对可变长度数据进行加密的方式，过去它一直是 TLS 问题的根源：BEAST、Lucky-Thirteen 和 POODLE 都是对 CBC 模式 TLS 的攻击。性能和安全性更好的选择是 AES_128_GCM，它是 TLS 1.2 中引入的新的 AEAD 密码之一，具有良好的性能和安全特性。
• SHA256- 这是 TLS 密码套件的消息验证码 (MAC) 功能基础的哈希函数。这是保证每条消息在传输过程中不被篡改的原因。SHA256 是一个不错的选择，它是 TLS 1.2 各个部分的默认哈希算法。我很确定在这里使用 SHA-1 是可以的，因为利用的窗口比证书签名小得多。AEAD 密码套件一开始就经过身份验证，因此不需要或实施此额外的 MAC 步骤。

本质上，您选择了一个目前没有任何实际问题的好的密码套件，但您可能希望切换到 AEAD 密码套件（AES-GCM 或 Bernstein 的 ChaCha20-Poly1305）以提高性能并防止未来与 CBC 相关的漏洞.

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256与任何密码套件一样“安全”：该密码套件不存在与 TLS 1.2 相关的已知协议弱点。当然，任何特定的实现都可能会自行解决问题并引入弱点。您还可以通过例如未能正确保护服务器 RSA 密钥的存储来破坏自己的安全性；或为该 RSA 密钥使用弱密钥对生成；或在客户端停用证书验证；或者如果你不小心的话，任何其他的无数愚蠢的行为都是可行的。

最近对所有 CBC 密码进行了更新，这可能会使它们在大多数情况下不安全。因此，您可能应该通过运行检查来重新评估您的服务器安全性。（来自 SSLLabs 的更多信息）

至于使用什么，cfieber 正确地评论了，你现在对 Java 8 最好的（也是唯一的）赌注是TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384，TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256并且TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384取决于证书类型。（取自这里）