缓慢的SecureRandom初始化

Question

假设您做简单的事情：

public class Main {
    public static void main(String[] args) {
        long started = System.currentTimeMillis();
        try {
            new URL(args[0]).openConnection();
        } catch (Exception ignore) {
        }
        System.out.println(System.currentTimeMillis() - started);
    }
}

现在，随着运行的http：//本地主机作为args[0]

它需要~100 msec完成。

现在尝试https：// localhost

这需要5000+ msec。

现在在linux或docker中运行相同的东西：

• http： ~100 msec
• https： ~350 msec

为什么是这样？为什么平台之间会有如此巨大的差异？你能为这个做什么？

对于长时间运行的应用程序服务器以及具有各自冗长且繁琐的初始化序列的应用程序，这5秒可能无关紧要。

但是，在许多应用程序中，最初的5秒“挂起”很重要，并且可能会令人沮丧。

Answer 1

（注意：另请参阅本答案末尾的最新更新）

说明

原因是默认SecureRandom提供程序。

在Windows上，有2个SecureRandom提供程序可用：

- provider=SUN, type=SecureRandom, algorithm=SHA1PRNG
- provider=SunMSCAPI, type=SecureRandom, algorithm=Windows-PRNG

在Linux上（在Alpine docker中使用Oracle JDK 8u162进行了测试）：

- provider=SUN, type=SecureRandom, algorithm=NativePRNG
- provider=SUN, type=SecureRandom, algorithm=SHA1PRNG
- provider=SUN, type=SecureRandom, algorithm=NativePRNGBlocking
- provider=SUN, type=SecureRandom, algorithm=NativePRNGNonBlocking

这些在jre/lib/security/java.security文件中指定。

security.provider.1=sun.security.provider.Sun
...
security.provider.10=sun.security.mscapi.SunMSCAPI

默认情况下，使用第一个SecureRandom提供程序。在Windows上，默认值是sun.security.provider.Sun，当使用JVM运行JVM时，此实现报告如下-Djava.security.debug="provider,engine=SecureRandom"：

Provider: SecureRandom.SHA1PRNG algorithm from: SUN
provider: Failed to use operating system seed generator: java.io.IOException: Required native CryptoAPI features not  available on this machine
provider: Using default threaded seed generator

而且默认的线程种子生成器非常慢。

您需要使用SunMSCAPI提供程序。

解决方案1：配置

重新配置供应商：

编辑jre/lib/security/java.security：

security.provider.1=sun.security.mscapi.SunMSCAPI
...
security.provider.10=sun.security.provider.Sun

我不知道这可以通过系统属性来完成。

也许是的，使用-Djava.security.properties（未经测试，请参阅此）

解决方案2：程序化

以编程方式重新排序提供者：

Optional.ofNullable(Security.getProvider("SunMSCAPI")).ifPresent(p->{
    Security.removeProvider(p.getName());
    Security.insertProviderAt(p, 1);
});

JVM现在报告以下（-Djava.security.debug="provider,engine=SecureRandom"）：

Provider: SecureRandom.Windows-PRNG algorithm from: SunMSCAPI

解决方案3：编程v2

受此想法的启发，以下代码仅插入了一个SecureRandom服务，该服务是从现有SunMSCAPI提供程序动态配置的，而无需明确依赖sun.*类。这也避免了与提供SunMSCAPI者所有服务的不分优先次序相关的潜在风险。

public interface WindowsPRNG {

    static void init() {
        String provider = "SunMSCAPI"; // original provider
        String type = "SecureRandom"; // service type
        String alg = "Windows-PRNG"; // algorithm
        String name = String.format("%s.%s", provider, type); // our provider name
        if (Security.getProvider(name) != null) return; // already registered
        Optional.ofNullable(Security.getProvider(provider)) // only on Windows
                .ifPresent(p-> Optional.ofNullable(p.getService(type, alg)) // should exist but who knows?
                        .ifPresent(svc-> Security.insertProviderAt( // insert our provider with single SecureRandom service
                                new Provider(name, p.getVersion(), null) {{
                                    setProperty(String.format("%s.%s", type, alg), svc.getClassName());
                                }}, 1)));
    }

}

性能

<140 msec（而不是5000+ msec）

细节

使用时有一个调用到new SecureRandom()调用堆栈中的某个地方URL.openConnection("https://...")

它调用getPrngAlgorithm()（请参阅SecureRandom：880）

这将返回SecureRandom它找到的第一个提供程序。

出于测试目的，URL.openConnection()可以使用以下命令代替to ：

new SecureRandom().generateSeed(20);

免责声明

我不知道由提供商重新订购引起的任何负面影响。但是，可能会有一些，特别是考虑默认提供者选择算法。

无论如何，至少从理论上讲，从功能的角度来看，这对于应用程序应该是透明的。

更新2019-01-08

Windows 10（版本1803）：无法再在任何最新的JDK上重现此问题（已从旧oracle 1.7.0_72到openjdk“ 12-ea”
2019-03-19进行了全部测试）。

看来这是Windows问题，已在最新的操作系统更新中修复。相关更新可能在最近的JRE版本中也可能没有发生。但是，即使使用我最旧的JDK 7 update72安装程序，也绝对无法受影响，并且绝对未进行任何修补，但我无法重现原始问题。

使用此解决方案时，性能仍然会有少量提升（平均大约为350毫秒），但是默认行为不再遭受无法忍受的5秒以上的惩罚。