RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368

[Bradford Wetmore]

On Mon, 21 Mar 2022 15:05:02 GMT, Sean Coffey <coffeys at 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