Hi all,

I think I found another bug in the the SSL implementation (well really in the 
TrustManager related part) which leads to a NPE. I was able to reproduce this 
on Java8 and Java11 (ea28) but I am sure it also exists on 9 and 10. 

While trying to write some test code for netty I did something stupid while 
creating the SSLEngine by passing a hostname as parameter for the server which 
then ended up in an NPE during handshake. I would argue we should not fail with 
a NPE.

Basically something like:

SSLEngine serverEngine = serverCtx.createSSLEngine("localhost", -1);


I think this is caused by 
sun.security.ssl.X509TrustManagerImpl.checkIdentity(…) missing a null check for 
the hostname before calling sun.security.util.HostnameChecker.match(…)

A full reproduce (which I extracted from my netty testcase)  can be found here 
(there is a README.md which explains how to run it):

https://github.com/normanmaurer/jdk_ssl_npe_reproducer 
<https://github.com/normanmaurer/jdk_ssl_npe_reproducer>

The stack I see is:

Exception in thread "main" java.lang.RuntimeException: Delegated task threw 
Exception/Error
        at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1527)
        at 
sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
        at 
sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1214)
        at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1186)
        at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469)
        at JDKSslReproducer.handshake(JDKSslReproducer.java:76)
        at JDKSslReproducer.main(JDKSslReproducer.java:51)
Caused by: java.lang.NullPointerException
        at 
sun.net.util.IPAddressUtil.textToNumericFormatV4(IPAddressUtil.java:49)
        at 
sun.net.util.IPAddressUtil.isIPv4LiteralAddress(IPAddressUtil.java:241)
        at 
sun.security.util.HostnameChecker.isIpAddress(HostnameChecker.java:125)
        at sun.security.util.HostnameChecker.match(HostnameChecker.java:93)
        at 
sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:455)
        at 
sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:1068)
        at 
sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:1007)
        at 
sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1601)
        at 
sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
        at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
        at sun.security.ssl.Handshaker$1.run(Handshaker.java:992)
        at sun.security.ssl.Handshaker$1.run(Handshaker.java:989)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467)
        at JDKSslReproducer.runDelegatedTasks(JDKSslReproducer.java:131)
        at JDKSslReproducer.handshake(JDKSslReproducer.java:99)
        ... 1 more

This only happens if a X509Trustmanager is used (not the Extended version) and 
when  setEndpointIdentificationAlgorithm(…) is used on the client-side.

Please let me know if you agree this is a bug and I am happy to open a bug for 
it.


Thanks
Norman

Reply via email to