RFR: 8253368: TLS connection always receives close_notify exception

Seán Coffey sean.coffey at oracle.com
Fri Nov 13 21:01:03 UTC 2020


Open to discussion on that. It's also highlighted in the TLSv1.3 RFC.

The TLS spec doesn't require a fatal alert to be issued when closing 
inbound without receiving the peer's close_notify. I've seen a handful 
of applications making JDK upgrades which are seeing regression as a 
result of this new JDK check (like the one described in this bug). If 
we're to keep the check in the JDK, should we restrict it to the v1.3 
protocol or should we implement it based on a system property perhaps ?

regards,
Sean.

On 13/11/2020 17:11, David Lloyd wrote:
> How would a truncation attack be avoided in this case?
>
> On Fri, Nov 13, 2020 at 8:23 AM Sean Coffey <coffeys at openjdk.java.net> wrote:
>> removing the "closing inbound before receiving peer's close_notify" exception that can be seen with TLS stack if calling close on inbound. After reading the relevant parts of the TLS v1.2/v1.3 RFCs, I believe the local end point doesn't have to wait for close_notify alert from remote end.
>>
>> -------------
>>
>> Commit messages:
>>   - 8253368: TLS connection always receives close_notify exception
>>
>> Changes: https://git.openjdk.java.net/jdk/pull/1205/files
>>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1205&range=00
>>    Issue: https://bugs.openjdk.java.net/browse/JDK-8253368
>>    Stats: 25 lines in 2 files changed: 12 ins; 10 del; 3 mod
>>    Patch: https://git.openjdk.java.net/jdk/pull/1205.diff
>>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/1205/head:pull/1205
>>
>> PR: https://git.openjdk.java.net/jdk/pull/1205
>>
>



More information about the security-dev mailing list