RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset

[Daniel Fuchs]

On Thu, 4 Feb 2021 13:00:47 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> The server side is binding to the wildcard address which has been a source of instability in many networking tests due to javax.net.ssl.SSLException: Connection reset. Changing the following tests to bind to loopback address fixes intermittent failures:
> sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java
> javax/net/ssl/TLSCommon/TLSTest.java
> sun/security/ssl/CipherSuite/SupportedGroups.java
> 
> 
> javax/net/ssl/SSLSession/TestEnabledProtocols.java still throws a connection reset occasionally because the server closes the connection before the client is done during handshake. That race condition cannot be completely removed in this test, thus is now handled and logged.

test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java line 29:

> 27: /*
> 28:  * @test
> 29:  * @bug 4416068 4478803 4479736 8241372

Here and in the other tests:
If a fix is a test bug and only contains test changes, we usually don't add the bug id to the modified tests. Instead we add the label `noreg-self` to the JBS issue. The bug ids in the tests files are supposed to identify *source changes* that can be verified by running the test.

test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java line 145:

> 143:             // The server side may have closed the socket.
> 144:             System.out.println("Client SSLException:");
> 145:             ssle.printStackTrace(System.out);

If security / TLS experts agree that this is OK, then it is OK for me. Not being an expert, I'd be concerned that catching plain SSLException might be too wide and that this might hide errors. In that case, and if the error is intermittent, one possibility could be to respin the test in case of SSLException (do client side and server side again) and fail if the second attempts fails too.

test/jdk/sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java line 90:

> 88:             (SSLServerSocketFactory) SSLServerSocketFactory.getDefault();
> 89:         InetSocketAddress socketAddress =
> 90:                 new InetSocketAddress(InetAddress.getLoopbackAddress(), serverPort);

The client is using 127.0.0.1. InetAddress.getLoopbackAddress() might return ::1 (IPv6 loopback) on certain configurations. 
Two possibility:
  1. run this test with -Djava.net.preferIPv4Stack to force usage of IPv4, but trivially pass if IPv4 is not available on the machine (see IPSupport in the test library)
  2. use InetAddress.getLoopbackAddress().getHostAddress() on the client side instead of "127.0.0.1" 

If you choose 2. you may want to add an additional @run the test with -Djava.net.preferIPv6Address to verify that it works with IPv6 - as there are several ways to represent the IPv6 loopback as a string

-------------

PR: https://git.openjdk.java.net/jdk/pull/2405