Java 如何接受我的自签名证书而无需将其添加到 Java 信任库
How is Java accepting my self signed certificate without me having to add it to Java truststore
我已经在我的 aws ec2 实例上设置了一个 FTPS 服务器,并使用 vsftpd 配置了 SSL。我使用 -
创建了 SSL 证书
sudo openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout /etc/ssl/private/vsftpd.pem -out /etc/ssl/private/vsftpd.pem
我使用 Apache Commons net 连接到我的 FTPS 服务器并使用 -
检索文件
ftps = new FTPSClient(ftpsProtocol, isImplicit);
try
{
int reply;
ftps.connect(server);
System.out.println("Connected to " + server + ".");
// After connection attempt, you should check the reply code to verify
// success.
reply = ftps.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply))
{
ftps.disconnect();
System.err.println("FTP server refused connection.");
}
}
catch (IOException e)
{
if (ftps.isConnected())
{
try
{
ftps.disconnect();
}
catch (IOException f)
{
System.out.println("ERROR!");
// do nothing
}
}
System.err.println("Could not connect to server.");
e.printStackTrace();
System.exit(1);
}
__main:
try
{
ftps.enterLocalPassiveMode();
ftps.setBufferSize(1000);
ftps.execPROT("P");
if (!ftps.login(username, password))
{
ftps.logout();
error = true;
break __main;
}
}
这工作正常,我能够检索文件。既然不是CA证书,那么Java是如何接受服务器的自签名证书而不报错的呢?
(我的 vsftpd conf 有以下几行 -
我的 vsftpd.conf 有以下几行-
listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
chroot_local_user=YES
rsa_cert_file=/etc/ssl/private/vsftpd.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.pem
ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=YES
force_local_logins_ssl=YES
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
require_ssl_reuse=NO
ssl_ciphers=HIGH
pasv_enable=YES
pasv_max_port=12100
pasv_min_port=12000
port_enable=YES
)
你没有展示你是如何初始化你的 FTPSClient
,但我假设你已经使用了默认值。
查看 latest implementation of FTPSClient
in the trunk of the Subversion repository,它默认使用来自 TrustManagerUtils.getValidateServerCertificateTrustManager()
的 TrustManager
实现。
反过来,latest implementation of TrustManagerUtils
显示这提供了一个 TrustManager
,它只调用此证书上的 checkValidity
(这是打开验证的选项,甚至 ACCEPT_ALL
实施)。不幸的是,checkValidity
只检查证书在当前时间是否有效,关于它的 "not before" 和 "not after" 有效期。它不是针对任何已知信任锚的证书验证。这基本上几乎是无用的,因为能够插入不正确证书的攻击者应该能够创建一个具有他们想要的有效期的证书。
但是,您似乎可以用 SSLContext
实例化 FTPSClient
,因此使用 new FTPSClient(SSLContext.getDefault())
会给您默认的、更明智的行为(除非您更改了默认值SSLContext
)。 (当然,您也可以使用具有正确行为的自定义 SSLContext
,但也使用特定的信任库进行初始化。)
我还没有检查其余的实现,但我也想看看它对主机名验证器做了什么,以防万一。
(可能值得在 Apache Commons Net 项目上报告这一点。这种默认行为当时可能听起来是个好主意,但事实并非如此。)
我已经在我的 aws ec2 实例上设置了一个 FTPS 服务器,并使用 vsftpd 配置了 SSL。我使用 -
创建了 SSL 证书sudo openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout /etc/ssl/private/vsftpd.pem -out /etc/ssl/private/vsftpd.pem
我使用 Apache Commons net 连接到我的 FTPS 服务器并使用 -
检索文件ftps = new FTPSClient(ftpsProtocol, isImplicit);
try
{
int reply;
ftps.connect(server);
System.out.println("Connected to " + server + ".");
// After connection attempt, you should check the reply code to verify
// success.
reply = ftps.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply))
{
ftps.disconnect();
System.err.println("FTP server refused connection.");
}
}
catch (IOException e)
{
if (ftps.isConnected())
{
try
{
ftps.disconnect();
}
catch (IOException f)
{
System.out.println("ERROR!");
// do nothing
}
}
System.err.println("Could not connect to server.");
e.printStackTrace();
System.exit(1);
}
__main:
try
{
ftps.enterLocalPassiveMode();
ftps.setBufferSize(1000);
ftps.execPROT("P");
if (!ftps.login(username, password))
{
ftps.logout();
error = true;
break __main;
}
}
这工作正常,我能够检索文件。既然不是CA证书,那么Java是如何接受服务器的自签名证书而不报错的呢?
(我的 vsftpd conf 有以下几行 - 我的 vsftpd.conf 有以下几行-
listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
chroot_local_user=YES
rsa_cert_file=/etc/ssl/private/vsftpd.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.pem
ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=YES
force_local_logins_ssl=YES
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
require_ssl_reuse=NO
ssl_ciphers=HIGH
pasv_enable=YES
pasv_max_port=12100
pasv_min_port=12000
port_enable=YES
)
你没有展示你是如何初始化你的 FTPSClient
,但我假设你已经使用了默认值。
查看 latest implementation of FTPSClient
in the trunk of the Subversion repository,它默认使用来自 TrustManagerUtils.getValidateServerCertificateTrustManager()
的 TrustManager
实现。
反过来,latest implementation of TrustManagerUtils
显示这提供了一个 TrustManager
,它只调用此证书上的 checkValidity
(这是打开验证的选项,甚至 ACCEPT_ALL
实施)。不幸的是,checkValidity
只检查证书在当前时间是否有效,关于它的 "not before" 和 "not after" 有效期。它不是针对任何已知信任锚的证书验证。这基本上几乎是无用的,因为能够插入不正确证书的攻击者应该能够创建一个具有他们想要的有效期的证书。
但是,您似乎可以用 SSLContext
实例化 FTPSClient
,因此使用 new FTPSClient(SSLContext.getDefault())
会给您默认的、更明智的行为(除非您更改了默认值SSLContext
)。 (当然,您也可以使用具有正确行为的自定义 SSLContext
,但也使用特定的信任库进行初始化。)
我还没有检查其余的实现,但我也想看看它对主机名验证器做了什么,以防万一。
(可能值得在 Apache Commons Net 项目上报告这一点。这种默认行为当时可能听起来是个好主意,但事实并非如此。)