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可用”。

当我问优先顺序时，我是问如果多个事情都被列为“默认值”，哪一个实际上会被用作第一优先级？当然，我读过这篇文章。

Answer 1

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

没有“先后顺序”；对于Java实现的所有协议(SSLv3和三个TLSE)，客户端声明它支持的最大协议版本，服务器选择它自己的最大协议版本或客户端提供的较低的协议版本，给出两个对等体支持的最高版本。如果客户端提供的最大值对于服务器来说低得不能接受，服务器将拒绝Hello。如果服务器选择的最大值对于客户端来说是不可接受的低，客户端将中止握手。特别是Java客户机抛出一个异常，比如“服务器协议x不允许”，套接字没有连接。

然而，一些服务器软件没有正确地实现这种协商，并且不会协商低于最大值但仍可接受的版本。为了应对这一点，如果握手失败（一些？）浏览器再次尝试错误地声明较低的最大值；允许狮子狗攻击。浏览器开发人员已经了解到，网页用户大多不想要安全，他们现在只想要他们的跳舞猫视频；Java用户似乎没有那么鲁莽（到目前为止），除了协议指定的方式和您的配置允许的范围之外，Java不会降级。

您可能想到的是ciphersuites，其中客户端确实发送了一个名义上按偏好排序的列表，服务器可以根据该偏好选择“最佳”共享密码，但并不需要这样做。事实上，在野兽恐慌期间，许多服务器被配置为优先使用RC4，即使客户端没有首先列出它。结果发现，BEAST并不是什么问题，而RC4的弱点比之前想象的要糟糕得多，但一些服务器继续强制使用现在已经几乎崩溃的RC4，尽管客户机并不喜欢它，https://tools.ietf.org/html/rfc7465说您根本不应该使用RC4，更不应该使用它。保安不好玩吗？