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 <coff...@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
