I am writing a Java TLS client. I have several questions regarding how to most securely use the SSLContext class so that TLS is used, when possible, and SSLv3 is only used when TLS is unavailable. (Side note: I see that the documentation says TLS1.1 and TLS1.2 are disabled for clients due to some incompatibility issues with certain vendor products).
SSLContext.getInstance("SSL") only use SSL protocols or are
TLS protocols used if they are available?SSLContext.getInstance("SSL") and what is their order of precedence?SSLContext.getInstance("TLS") only use TLS protocols or are SSL protocols used if they are available?SSLContext.getInstance("TLS") and what is their order of precedence?The Java documentation is unclear on many of these points. For example it says "choosing TLSv1 may make 1.0, 1.1, and 1.2 available".
SSLContext.getInstance("TLSv1") is SSLv3 unavailable or is it just not a default? When I ask about order of precedence, I'm asking if multiple things are all listed as "defaults" which one will actually be used as the first priority? Also, obligatory yes I've read this thread.
答案 0 :(得分：3)
正如#11504173（编辑后）所说，所有上下文都可以支持所有协议，但默认可能会有所不同。
没有“优先顺序”;适用于Java实现的所有协议（SSLv3和三个TLS） 客户端声明它支持的最大协议版本，服务器选择自己的最大或客户端的报价，以较低者为准， 给予同行支持的最高版本。如果客户端提供的max对于服务器而言是不可接受的低，则服务器拒绝hello。 如果服务器为客户端选择的最大值不可接受，则客户端将中止握手。特别是Java客户端抛出异常，例如“不允许服务器协议x”，并且套接字未连接。
但是，某些服务器软件没有正确实现此协商，并且不会协商低于最大但仍然可接受的版本。为了解决这个问题，如果握手失败（有些？）浏览器再试一次 错误地说明最低;允许POODLE攻击。浏览器开发人员已经了解到，网络用户大多不需要安全性，他们只是想要他们的跳舞猫视频现在; Java用户似乎不那么鲁莽（到目前为止）并且Java不会降级，除非按协议指定的方式和配置允许的范围。
您可能会想到 ciphersuites ，其中客户端会发送名义上按优先顺序排序的列表， 并且服务器可以根据该偏好选择“最佳”共享密码，但不是必需的。 实际上在BEAST恐慌期间，许多服务器被配置为优先考虑RC4，即使客户端没有首先列出它。 然后事实证明BEAST并不是一个大问题，而RC4的弱点比以前想象的要糟糕得多，但有些服务器 尽管客户不喜欢它并且https://tools.ietf.org/html/rfc7465继续强制现在 - 实际上已经破坏了RC4 说你根本不应该使用RC4 更不喜欢它。安全性不好吗？