I filed a bug for this improvement.
https://bugs.openjdk.java.net/browse/JDK-8209840
We may fix it in a near release.
Thanks,
Xuelei
On 8/22/2018 3:29 AM, Simone Bordet wrote:
Hi,
On 7/12/2018 1:17 PM, Simone Bordet wrote:
Currently:
- Server wraps 160, 6 and 907 in 3 wraps.
- Server
Hi,
> > On 7/12/2018 1:17 PM, Simone Bordet wrote:
> > Currently:
> > - Server wraps 160, 6 and 907 in 3 wraps.
> > - Server *sends* the 1073 bytes in 1 TCP write
> > - Client unwraps 160, then goes into NEED_WRAP
> > - Client wraps 6, then goes again into NEED_UNWRAP to finish with the
> > 6 and
Hi,
On Tue, Jul 31, 2018 at 9:56 PM Xuelei Fan wrote:
> Hm, I see your point. Because of the half-close policy, I think the
> server could keep sending messages other than the close_notify alert.
Exactly.
> My concern of the CLOSED+NOT_HANDSHAKING is that it does not indicate
> the following
On 7/31/2018 12:13 PM, Simone Bordet wrote:
Hi,
On Tue, Jul 31, 2018 at 5:10 PM Xuelei Fan wrote:
Hi,
On 7/31/2018 6:43 AM, Xuelei Fan wrote:
Current jdk11 tip with your patch:
1. client.closeOutbound() then goes into NEED_WRAP.
2. Client wraps 24 bytes, result is CLOSED, then goes into
Hi,
On Tue, Jul 31, 2018 at 5:10 PM Xuelei Fan wrote:
>
> Hi,
>
> On 7/31/2018 6:43 AM, Xuelei Fan wrote:
> > Current jdk11 tip with your patch:
> > 1. client.closeOutbound() then goes into NEED_WRAP.
> > 2. Client wraps 24 bytes, result is CLOSED, then goes into NEED_UNWRAP.
> > 3. Server
Hi,
On 7/31/2018 6:43 AM, Xuelei Fan wrote:
Current jdk11 tip with your patch:
1. client.closeOutbound() then goes into NEED_WRAP.
2. Client wraps 24 bytes, result is CLOSED, then goes into NEED_UNWRAP.
3. Server unwraps 24 bytes, result is CLOSED, then goes into NEED_WRAP.
4. Server wraps 0
Hi,
Looks like we are on the same page now. For the data transportation
(wrap/unwrap), I agree we'd better use OK so that applications can make
the right decision.
Thanks,
Xuelei
On 7/31/2018 7:23 AM, Simone Bordet wrote:
Hi,
On Tue, Jul 31, 2018 at 4:13 PM Xuelei Fan wrote:
The
Hi,
On Tue, Jul 31, 2018 at 4:13 PM Xuelei Fan wrote:
>
> The Status.CLOSED specification is defined as "The operation just closed
> this side of the SSLEngine, or the operation could not be completed
> because it was already closed.". My reading of the spec, the CLOSED
> status means
Hi,
On Tue, Jul 31, 2018 at 3:43 PM Xuelei Fan wrote:
> > 1. client.closeOutbound() then goes into NEED_WRAP.
> > 2. Client wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING.
> It might be a problem for application to make a right decision if using
> CLOSED status and
The Status.CLOSED specification is defined as "The operation just closed
this side of the SSLEngine, or the operation could not be completed
because it was already closed.". My reading of the spec, the CLOSED
status means half-close. If wrap() status is CLOSED, it means write
side close;
Hi Simone,
Thanks for the quick feedback. Read more in-lines, please.
On 7/31/2018 3:10 AM, Simone Bordet wrote:
Hi,
On Tue, Jul 31, 2018 at 11:39 AM Simone Bordet wrote:
Hi,
On Mon, Jul 30, 2018 at 8:08 PM Xuelei Fan wrote:
Would you mind look at the code I posted in the following
Hi,
On Tue, Jul 31, 2018 at 11:39 AM Simone Bordet wrote:
>
> Hi,
> On Mon, Jul 30, 2018 at 8:08 PM Xuelei Fan wrote:
> > Would you mind look at the code I posted in the following thread:
> > http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html
>
> JDK 11+21:
> 1.
Hi,
On Mon, Jul 30, 2018 at 8:08 PM Xuelei Fan wrote:
> Would you mind look at the code I posted in the following thread:
> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html
JDK 11+21:
1. client.closeOutbound() then goes into NEED_WRAP.
2. Client wraps 24 bytes, result is
Hi Simone,
Would you mind look at the code I posted in the following thread:
http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html
I'm trying to address the close concerns of yours. I appreciate if you
could comment by the end of this week.
Note that with this update, a
Hi,
On Fri, Jul 13, 2018 at 3:45 PM Xuelei Fan wrote:
> Thank you very much, Simone. I find at least two improvements we can
> take. It's really good!
Great!
Let know when they land in a 11+X release and we'll try them out.
Thanks!
--
Simone Bordet
---
Finally, no matter how good the
On 7/12/2018 1:17 PM, Simone Bordet wrote:
Hi,
On Thu, Jul 12, 2018 at 9:29 PM Xuelei Fan wrote:
Per the TLS 1.3 specification:
- The server sends a dummy change_cipher_spec record immediately
after its first handshake message. This may either be after a
ServerHello or a
On 7/12/2018 2:39 PM, Simone Bordet wrote:
Hi,
On Thu, Jul 12, 2018 at 11:10 PM Xuelei Fan wrote:
In TLS 1.3 closure, receiving of the close_notify is not required:
"... Both parties need not wait to receive a
"close_notify" alert before closing their read side of the
Hi,
On Thu, Jul 12, 2018 at 11:10 PM Xuelei Fan wrote:
> In TLS 1.3 closure, receiving of the close_notify is not required:
>"... Both parties need not wait to receive a
> "close_notify" alert before closing their read side of the
> connection, though doing so would introduce the
Hi,
On Thu, Jul 12, 2018 at 11:15 PM Xuelei Fan wrote:
>
> On 7/12/2018 1:09 PM, Simone Bordet wrote:
> > Hi,
> > On Thu, Jul 12, 2018 at 10:05 PM David Lloyd wrote:
> >> But more importantly, I think this
> >> represents a chance to fix this long-standing bad behavior of the JDK.
> >
> >
On 7/12/2018 1:09 PM, Simone Bordet wrote:
Hi,
On Thu, Jul 12, 2018 at 10:05 PM David Lloyd wrote:
But more importantly, I think this
represents a chance to fix this long-standing bad behavior of the JDK.
Indeed!
Another thing I was about to complain is that
SSLSocket.shutdownOutput() still
On 7/12/2018 1:04 PM, David Lloyd wrote:
On Thu, Jul 12, 2018 at 2:30 PM Xuelei Fan wrote:
On 7/12/2018 10:47 AM, Simone Bordet wrote:
On Thu, Jul 12, 2018 at 4:34 PM Xuelei Fan wrote:
[...]
In TLS 1.3, half-close policy is used. The server may not response with
the close_notify for
Hi,
On Thu, Jul 12, 2018 at 9:29 PM Xuelei Fan wrote:
> Per the TLS 1.3 specification:
>- The server sends a dummy change_cipher_spec record immediately
> after its first handshake message. This may either be after a
> ServerHello or a HelloRetryRequest.
>
> and
>- If not
Hi,
On Thu, Jul 12, 2018 at 10:05 PM David Lloyd wrote:
> But more importantly, I think this
> represents a chance to fix this long-standing bad behavior of the JDK.
Indeed!
Another thing I was about to complain is that
SSLSocket.shutdownOutput() still throws:
UnsupportedOperationException("The
On Thu, Jul 12, 2018 at 2:30 PM Xuelei Fan wrote:
> On 7/12/2018 10:47 AM, Simone Bordet wrote:
> > On Thu, Jul 12, 2018 at 4:34 PM Xuelei Fan wrote:
[...]
> >> In TLS 1.3, half-close policy is used. The server may not response with
> >> the close_notify for client close_notify request. See
On 7/12/2018 10:47 AM, Simone Bordet wrote:
Hi,
On Thu, Jul 12, 2018 at 4:34 PM Xuelei Fan wrote:
In order to mitigate the compatibility impact, the TLS 1.3 is
implemented in the middlebox compatibility mode (See Section D.4, TLS
1.3 draft 28) in JDK. The 6 bytes message is the dummy
Hi,
On Thu, Jul 12, 2018 at 4:34 PM Xuelei Fan wrote:
> In order to mitigate the compatibility impact, the TLS 1.3 is
> implemented in the middlebox compatibility mode (See Section D.4, TLS
> 1.3 draft 28) in JDK. The 6 bytes message is the dummy
> change_cipher_spec record. More details,
On 7/12/2018 7:33 AM, Xuelei Fan wrote:
In addition to what reported above, I would like to report also the
weird behavior during the close handshake (i.e. when one side decides
to close the connection).
1. client.closeOutbound() then goes into NEED_WRAP.
2. Client wraps 24 bytes, result is
Hi Simone,
Thank you very much for the debug logs.
Read more in-lines, please.
On 7/12/2018 2:03 AM, Simone Bordet wrote:
Hi,
On Thu, Jul 12, 2018 at 12:06 AM Simone Bordet wrote:
Hi,
I can see this (weird) behavior in SSLEngine for TLS 1.3 in JDK 11+21.
It's a simple new connection (no
Hi,
On Thu, Jul 12, 2018 at 12:06 AM Simone Bordet wrote:
>
> Hi,
>
> I can see this (weird) behavior in SSLEngine for TLS 1.3 in JDK 11+21.
> It's a simple new connection (no resumption) that performs a TLS 1.3
> handshake.
> The bytes numbers are those that I get, they may be different for
>
Hi Simone,
Thank for reporting this issue.
To speed up the evaluation, would you mind send us the debug log (using
system property "javax.net.debug=all")?
Thanks,
Xuelei
On 7/11/2018 3:06 PM, Simone Bordet wrote:
Hi,
I can see this (weird) behavior in SSLEngine for TLS 1.3 in JDK 11+21.
30 matches
Mail list logo
