与自定义 CipherSuites 的 Java HTTPS 连接
假设我尝试使用 HttpsURLConnection 通过 HTTPS 连接到 Web 服务器。现在，如果我使用以下方法在客户端上设置/限制密码：
System.setProperty("https.cipherSuites", myCustomCipherSuites);
我想知道我的 Java 客户端和 Web 服务器之间如何就密码达成一致。例如，如果我的密码套件包括 [中、强] 并且 Web 服务器支持 [弱、中、强、强] ...
1- 是否会选择“强”，即客户端和服务器上可用的最强密码？ 2- 是否存在由 Web 服务器定义的优先级，然后对客户端进行可用性检查，以查找具有最高优先级（在 Web 服务器上）且相互可用（在客户端和服务器上）的密码？
另外，如果我有一个密码“a”、“b”、“c”和“d”列表，并且网络服务器仅支持“e”、“f”和“g”......我可以确定客户端和服务器都会在放弃之前尝试找到通用密码来协商连接的所有可能性（因为没有可用的通用密码）。我很确定这个问题的答案是肯定的......但我只是想确认一下。
So let's say I try to connect to a web server over HTTPS using HttpsURLConnection. Now if I set/limit the ciphers on Client using:
System.setProperty("https.cipherSuites", myCustomCipherSuites);
I want to know how a cipher will be agreed upon between my Java Client and web server. For example, if my cipher suites include [medium, strong] and web server supports [weak, medium, strong, stronger] ...
1- Will "strong" be selected i.e. the strongest available on both client and server?
2- Is there a priority defined by the web server and then an availability check on client to find the cipher with highest priority (on web server) AND mutually available (on both client and server)?
Also, if I have a list of cipher "a", "b", "c", and "d" and web server supports "e", "f", and "g" only ... can I be sure that client and server would both exhaust all possibilities of negotiating a connection with trying to find a common cipher before giving up (as there is not common cipher available). I am pretty sure that answer for this would be yes ... but I just want to confirm it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
关于你的第一个问题：
客户提供了一个密码套件列表，其首选顺序是（最想要的第一个，最不想要的最后）。
服务器应该选择列表中它愿意同意的第一项，忽略服务器可能有的任何偏好。但是，没有（简单）方法可以阻止服务器使用自己的首选项（如果它们与客户端的首选项不匹配）。
对于第二个，如果没有匹配的密码套件，则连接失败。这并不是真正的“排气”，而是“我支持A、B、C、D”| “我不支持其中任何一个。我猜我们无法联系。”
As to your first question:
The client offers a list of cipher suites its preferred order (most desired first, least desired last).
The server is supposed to choose the first item in the list that it is willing to agree to, ignoring any preference the server may have. However, there is no (easy) way to prevent a server from using its own preferences (should they not match those of the client).
As to the second, if there is no matching cipher suite, the connection fails. It's not really an "exhaust", as much as a "I support A, B, C, and D" | "I don't support any of those. Guess we can't connect."