RFR: 8253368: TLS connection always receives close_notify exception

Seán Coffey sean.coffey at oracle.com
Fri Nov 20 11:32:40 UTC 2020


On 13/11/2020 21:23, David Lloyd wrote:
> Thinking about this some more, I suppose I tend to interpret the
> shutdownInput() API as indicating that the caller doesn't really care
> about any further data being received on the socket.  I expect that a
> truncation attack would only be significant if the socket EOF was
> received before close_notify while the caller is trying to read data
> from the socket.  So in that light the change is probably OK (since it
> only exists when explicitly shutting down the input) from the
> perspective that I was thinking of.  Whether it has any protocol-level
> implications I don't know and won't comment on.
>
> That said, maybe shutdownInput(boolean) should be collapsed into
> shutdownInput() since the parameter is no longer used?
Thanks for the comments. Fair point on the method overload. One I'll 
look into.

I'm looking to further study the consequences of the overall change some 
more and will reach out to other engineers for opinion also. Hope to 
revert to the list with an update in next 1-2 weeks.

regards,
Sean.

>
> On Fri, Nov 13, 2020 at 3:01 PM Seán Coffey <sean.coffey at oracle.com> wrote:
>> 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