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
> o
Hi Alan,
Yes, it is likely to introduce the issue again. We should consider a
regression test. I just filed a follow-up bug in the JBS:
https://bugs.openjdk.java.net/browse/JDK-8207174
Thanks,
Xuelei
On 7/11/2018 11:53 PM, Alan Bateman wrote:
On 12/07/2018 05:47, Xuelei Fan wrote:
Hi,
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
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 CLOS
This change adds some checks for session resumption in TLS 1.3 to ensure
that the resumed session is compatible with what is requested.
Specifically, I'm adding checks for protocol version, cipher suite,
client authentication, and signature schemes. There are also some minor
whitespace formatti
A quick question about the update in HandshakeContext.java.
+ this.localSupportedSignAlgs = new ArrayList(
+ conContext.conSession.getLocalSupportedSignatureSchemes());
Why set the value here? The 'null' value of localSupportedSignAlgs has
a special meaning that it has not been set. A
This value needs to be set when we create a PostHandshakeContext from a
TransportContext. This only happens after the handshake is complete, so
we should always have a session (right?).
It may be better to set localSupportedSignAlgs in the constructor of
PostHandshakeContext instead of where i
Set it in PostHandshakeContext should be fine as the session should have
been negotiated.
Thanks,
Xuelei
On 7/12/2018 9:57 AM, Adam Petcher wrote:
This value needs to be set when we create a PostHandshakeContext from a
TransportContext. This only happens after the handshake is complete, so
we
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, pleas
Please review this fix to add T-systems, GlobalSign, and Starfield
services root certificates to cacerts.
Webrev: http://cr.openjdk.java.net/~rhalade/8199779/webrev.00/
Thanks,
Rajan
Hello!
I was reported that a 3rd-party PKCS11 provider stopped working
correctly since integrating the fix for JDK-8134605.
This is due to that a secret key is now generated via
CKM_SSL3_PRE_MASTER_KEY_GEN even if it is going to be discarded
(presumably, this is to avoid a time-attack.)
Wo
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
chang
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 the
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
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 o
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 client
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
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.
> >
> > Indeed
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 poss
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
connectio
The code itself looks good, but I didn't see a regression tests. Is
this what JDK-8207174 will be for?
On 7/11/2018 11:53 PM, Alan Bateman wrote:
On 12/07/2018 05:47, Xuelei Fan wrote:
It's an interesting user case of the TrustManagerFactory and
KeyManagerFactory. The KeyManager or TrustMa
On 7/12/2018 5:06 PM, Bradford Wetmore wrote:
The code itself looks good, but I didn't see a regression tests. Is
this what JDK-8207174 will be for?
No, I did not have a regression test in this update. I asked the bug
reporter helped for the testing, and passed. However, we definitely
need
Could the new patch be reviewed?
http://cr.openjdk.java.net/~jjiang/8206258/webrev.01/
Thanks!
John
On 2018/7/9 15:38, sha.ji...@oracle.com wrote:
Hi Thomas,
Thanks for your testing.
I'm not sure that's a reasonable case.
From my view, PKCS11Test.java simply checks if the NSS library
director
Hi Max,
The javadoc is for Signature.getParameters(), so null can be returned
for signature algorithms which do not use parameters, e.g.
SHA256withDSA. As Signature class covers all signature algorithms, I am
not sure about mentioning specific algorithm names as it may be lengthy
and even mis
> On Jul 13, 2018, at 10:01 AM, Valerie Peng wrote:
>
> Hi Max,
>
> The javadoc is for Signature.getParameters(), so null can be returned for
> signature algorithms which do not use parameters, e.g. SHA256withDSA. As
> Signature class covers all signature algorithms, I am not sure about
>
Hi,
JDK-8028563 has removed javac support for 6/1.6 source and target, so
the following tests has to be updated accordingly.
javax/net/ssl/compatibility/Compatibility.java
sun/security/tools/jarsigner/compatibility/Compatibility.java
In addition, this fix also makes
javax/net/ssl/compatibility
26 matches
Mail list logo
