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.
-
How would a truncation attack be avoided in this case?
On Fri, Nov 13, 2020 at 8:23 AM Sean Coffey 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 TL
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
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
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
On Fri, 13 Nov 2020 14:16:35 GMT, Sean Coffey 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
> does
On Fri, 13 Nov 2020 14:16:35 GMT, Sean Coffey 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
> does
On Tue, 22 Dec 2020 15:40:12 GMT, Sean Coffey wrote:
> @XueleiFan I went ahead with your advice and chose to keep the check in the
> code. Since JDK 11, this code path would have thrown an SSLException. I've
> chosen to keep that instead of introduce another
> Exception(UnsupportedOperationExc
> 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
On Tue, 22 Dec 2020 15:40:22 GMT, Sean Coffey 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
10 matches
Mail list logo
