SSLContext协议

Question

我正在编写Java TLS 客户端 。 关于如何最安全地使用SSLContext类，我有几个问题，以便在可能的情况下使用TLS，并且仅在TLS不可用时使用SSLv3。 （旁注：我看到文档说由于某些供应商产品存在某些不兼容问题，因此客户端禁用了TLS1.1和TLS1.2）。

1. SSLContext.getInstance("SSL")是否仅使用SSL协议或是否可用的TLS协议？
2. 使用SSLContext.getInstance("SSL")时的默认协议是什么？它们的优先顺序是什么？
3. SSLContext.getInstance("TLS") 仅使用TLS协议还是使用SSL协议？
4. 使用SSLContext.getInstance("TLS")时的默认协议是什么？它们的优先顺序是什么？
5. 是否正如我所假设的那样， 默认协议总是先使用，只有在默认协议都不适用于握手双方时才使用支持的协议？

Java文档在许多方面都不清楚。 例如，它说“选择TLSv1可能会使1.0,1.1和1.2可用”。

6. 如果我使用SSLContext.getInstance("TLSv1")是SSLv3不可用还是它不是默认值？

当我询问优先顺序时，我问的是，是否有多个东西都列为“默认值”，哪一个实际上会被用作第一优先级？ 另外，强制性的是我已经读过这个帖子了 。

Answer 1

正如＃11504173 （编辑后）所说，所有上下文都可以支持所有协议，尽管默认值可能会有所不同。

没有“优先顺序”; 对于由Java（SSLv3和三个TLS）实现的所有协议，客户端声明它支持的最大协议版本，并且服务器选择其自己的最大值或客户端的要约中较低者，提供两个对等体支持的最高版本 。 如果客户端提供的max对于服务器而言是不可接受的低，则服务器拒绝hello。 如果服务器为客户端选择的最大值不可接受，则客户端将中止握手。 特别是Java客户端抛出异常，例如“不允许服务器协议x”，并且套接字未连接。

但是，某些服务器软件没有正确实现此协商，并且不会协商低于最大但仍然可接受的版本。 为了解决这个问题，如果握手失败（有些？），浏览器会再次尝试错误地说明较低的最大值; 允许POODLE攻击。 浏览器开发人员已经了解到，网络用户大多不需要安全性，他们现在只想要他们的跳舞猫视频; Java用户似乎不那么鲁莽（到目前为止）并且Java不会降级，除非按协议指定的方式和配置允许的范围。

您可能正在考虑密码套件 ，其中客户端确实发送名义上按优先级排序的列表，并且服务器可以根据该偏好选择“最佳”共享密码，但不是必需的。 实际上在BEAST恐慌期间，许多服务器被配置为优先考虑RC4，即使客户端没有首先列出它。 然后事实证明BEAST没有太大的问题，而RC4的弱点比以前想象的要差得多，但是有些服务器继续强制现在 - 实际上已经破坏了RC4，即使客户不喜欢它和https：//tools.ietf .ORG / HTML / rfc7465说，你不应该使用RC4 都更喜欢它。 安全性不好吗？