SSLSocketFactory 提供 getDefaultCipherSuites(默认情况下在套接字上启用的密码)和 getSupportedCipherSuites(如果需要，可以启用的密码)。
但是，SSLSocketFactory 不提供 setEnabledCipherSuites 来配置一次密码列表以提供对后续套接字的偏好。
事实上，我认为将 setEnabledCipherSuites 作为 SSLSocket 的一部分确实会使工作流程复杂化。例如，HttpsURLConnection 没有提供 getSocket，它确实打破了这个流程:
...
SSLContext context = SSLContext.getInstance("TLS");
context.init(null, trustManager.getTrustManagers(), null);
HttpsURLConnection connection = (HttpsURLConnection) url.openConnection();
connection.setSSLSocketFactory(context.getSocketFactory());
我认为 SSLContext 也可以这样说，因为它具有 getDefaultSSLParameters 和 getSupportedSSLParameters 等方法。
我正试图为(不)能力提出一个合理的安全工程理由，但我做不到。也许有软件工程方面的决定。 (我怀疑这是有充分理由的，但我目前缺乏洞察力)。
为什么 Java 缺少配置 SSLSocketFactory 的能力？这显然是一个设计决定，我试图理解为什么它是以牺牲图书馆相关部分的安全性为代价的。
最佳答案
Why does Java lack the ability to configure the SSLSocketFactory?
这可能是因为允许应用程序更改已启用的密码套件被认为是一个坏主意。您可能会争辩说，这是一个平台安全问题，而不是应用程序的责任，并且某些应用程序能够启用(或禁用)系统管理员已禁用的套件是一件坏事/启用。
但我不知道，而且我怀疑一小群真正知道的人都不会定期阅读 StackOverflow。
Its clearly a design decision,
从某种意义上说，是的。但这可能只是偶然或默认发生的设计决策之一。或者可能是“他们”认为不会使用此功能。或者这样做可能有充分的安全理由。
无论哪种方式，如果您对此有强烈的感觉，您可以建议将其作为 Java 增强(例如 here)，或者开发一个补丁来实现您的增强并将其提交给 OpenJDK团队。
如果您没有动力提出/实现增强功能，获得“他们为什么这样做”答案的最佳方式是您自己问“他们”。 (请分享答案...)
关于java - 为什么 SSLSocketFactory 缺少 setEnabledCipherSuites？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/23320787/