是否有可能说服Java应用程序忽略SSL问题而不修改其代码？

Question

我有一些Java应用程序抱怨不同的SSL问题,如自签名证书或不受信任的证书.

由于我没有这些应用程序的代码并且获得良好的证书太难了,我正在寻找一种可以让我强制连接的解决方案.

到目前为止,我尝试过这些,但似乎还不够:

-Dcom.sun.net.ssl.checkRevocation=false 
-Djava.security.debug=certpath

我仍然看到:

• sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
• javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Answer 1

通过完全忽略信任验证来忽略证书验证错误的代码修改(例如,使用不执行任何操作的信任管理器)通常不是正确的方法.它们可能会受到一些开发人员的欢迎,因为他们不必经历任何有关处理证书的步骤,但他们只是忽略了问题而不是修复它,从而也引入了MITM攻击的漏洞.(因为问题然后被解决了,所以在生产版本中永远不会修复它.)

JSSE参考指南中描述了配置信任管理的各种方法.

简而言之,您可以将证书显式导入JRE信任库(通常cacerts是JRE目录中的文件),也可以将其导入您自己的信任库(可能基于默认信任库的副本),并使用其指定路径的javax.net.ssl.trustStore(以及相关的)系统属性(见参考文献JSSE指南).

这些配置设置将影响使用默认设置的所有SSLSockets和SSLEngines(SSLContext代码中没有任何特定内容).

某些应用程序使用自己的应用程序SSLContext为特定连接加载特定的密钥库或信任库.这通常使用独立于JSSE默认选项的参数进行配置,在这种情况下,您必须检查应用程序文档或代码.

Answer 2

http://code.google.com/p/misc-utils/wiki/JavaHttpsUrl提供了几种侵入式解决方案.

可以使用系统属性覆盖 SSLSocketFactory .

但是,自定义HostnameVerifier只能通过额外的启动参数或动态使用特殊的java代理进行签名.

此外,AspectJ编织代理可用于覆盖任何方法行为.

还要考虑使用MiTM HTTPS代理的替代方法(如果应用程序允许重新配置URL和证书).