On Mon, 21 Mar 2022 15:05:02 GMT, Sean Coffey <coff...@openjdk.org> wrote:
>> JDK-8253368 changed the behavior of SSLSocket to no longer throw a fatal >> internal_error (80) and invalidate existing sessions (either completed or >> under construction) as described in (RFC 4346/TLSv1.1+) if a connection was >> closed without receiving a close_notify alert from the peer. >> >> This change introduces similar behavior to SSLEngine. >> >> The unit test checks that closing the read(input) sides of the >> SSLSocket/SSLEngine throws an SSLException, but doesn't invalidate their >> respective sessions. >> >> Tier1/2 mach5 tests have been successfully run. > > test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketSSLEngineCloseInbound.java > line 130: > >> 128: * The following is to set up the keystores/trust material. >> 129: */ >> 130: private static final String pathToStores = >> "../../../../javax/net/ssl/etc"; > > I think the advise is to move away from binary style keystores. i.e. to use > test/jdk/javax/net/ssl/templates/SSLContextTemplate.java for a replacement. > Is that possible here ? Sigh...this is a whole can of worms I wasn't expecting. Looks like one person did the SSLContextTemplate and updated with SSLEngineTemplate, then another person took a completely different takes with SSLSocketTemplate, and then SSLSocketSSLEngineTemplate didn't get touched at all. This should really be harmonized. :( ------------- PR: https://git.openjdk.java.net/jdk/pull/7796
