Re: RFR JDK-8239595/JDK-8239594 : ssl context version is not respected/jdk.tls.client.protocols is not respected

On 3/27/2020 10:36 AM, Chris Hegarty wrote: Thank you Xuelei, this very helpful. Sorry, but I am going to ask just a few more clarifying questions to make sure that we’re on the same page. On 27 Mar 2020, at 16:23, Xuelei Fan wrote: On 3/27/2020 5:52 AM, Chris Hegarty wrote: Xuelei

Re: RFR JDK-8239595/JDK-8239594 : ssl context version is not respected/jdk.tls.client.protocols is not respected

DTLS"); and the protocol values returned by the following invocation on that context `getDefaultSSLParameters().getProtocols()`. Is this correct? If not, what does it do? Yes. Xuelei -Chris. On 26 Mar 2020, at 16:58, Xuelei Fan wrote: With this update, the logic looks like:

Re: RFR JDK-8239595/JDK-8239594 : ssl context version is not respected/jdk.tls.client.protocols is not respected

With this update, the logic looks like: if TLSv1.3 is not enabled in the SSLContext, use TLSv1.2 instead; Otherwise, use TLSv1.3 and TLSv1.2. There may be a couple of issues: 1. TLSv1.2 may be not enabled, although TLSv1.3 is enabled. For example:

Re: RFR JDK-8241039, Retire the deprecated SSLSession.getPeerCertificateChain() method

I updated the CSR and local code. Thanks, Xuelei On 3/16/2020 10:23 AM, Alan Bateman wrote: On 16/03/2020 16:00, Xuelei Fan wrote: Hi Alan, Thanks for the review.  All comments look good to me.  Here is the update webrev:   http://cr.openjdk.java.net/~xuelei/8241039/webrev.01

Re: RFR JDK-8241039, Retire the deprecated SSLSession.getPeerCertificateChain() method

about how to handle with the method in third party's source code. Thanks, Xuelei best regards -- daniel On 16/03/2020 04:25, Xuelei Fan wrote: Hi, Could I get the following update reviewed? Bug: https://bugs.openjdk.java.net/browse/JDK-8241039 CSR: https://bugs.openjdk.java.net/brows

Re: RFR JDK-8241039, Retire the deprecated SSLSession.getPeerCertificateChain() method

, Xuelei Fan wrote: Hi, Could I get the following update reviewed? Bug: https://bugs.openjdk.java.net/browse/JDK-8241039 CSR: https://bugs.openjdk.java.net/browse/JDK-8241047 webrev: http://cr.openjdk.java.net/~xuelei/8241039/webrev.00/ I see you've created a new issue (and sub-tasks), in which JDK

RFR JDK-8241039, Retire the deprecated SSLSession.getPeerCertificateChain() method

Hi, Could I get the following update reviewed? Bug: https://bugs.openjdk.java.net/browse/JDK-8241039 CSR: https://bugs.openjdk.java.net/browse/JDK-8241047 webrev: http://cr.openjdk.java.net/~xuelei/8241039/webrev.00/ In a preview review thread,

Re: (teststabilization) RFR 8230858: Replace wildcard address with loopback or local host in tests - part 23

+1. Xuelei On 9/12/2019 4:43 AM, Chris Hegarty wrote: On 11 Sep 2019, at 16:24, Daniel Fuchs wrote: Hi, Please find below a patch for: 8230858: Replace wildcard address with loopback or local host in tests - part 23 https://bugs.openjdk.java.net/browse/JDK-8230858 webrev:

Re: RFR [13] JDK-8215430: Remove the internal package com.sun.net.ssl

er classes and used by ProviderTest, which is used to test the com.sun.net.ssl wrappers. Thanks, Xuelei Thanks, Brad On 2/26/2019 7:33 AM, Chris Hegarty wrote: On 26 Feb 2019, at 03:53, Xuelei Fan wrote: It makes sense to me to leave the AbstractDelegateHttpsURLConnection methods as p

Re: RFR [13] JDK-8215430: Remove the internal package com.sun.net.ssl

there is using them (even though they are not supposed to). The rest of this looks ok, pretty straightforward. --Sean On 2/21/19 10:45 PM, Xuelei Fan wrote: Hi, Could I get the following update reviewed:     http://cr.openjdk.java.net/~xuelei/8215430/webrev.00/ The internal package com.sun.net.ssl

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

/18 7:22 PM, Xuelei Fan wrote: On 11/7/2018 1:30 PM, Sean Mullan wrote:    https://bugs.openjdk.java.net/browse/JDK-8213161    http://cr.openjdk.java.net/~xuelei/8212261/webrev.03/ I didn't see a test for SecureCacheResponse - is it possible? JDK does not have the reference implementation

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

On 11/7/2018 1:30 PM, Sean Mullan wrote:    https://bugs.openjdk.java.net/browse/JDK-8213161    http://cr.openjdk.java.net/~xuelei/8212261/webrev.03/ I didn't see a test for SecureCacheResponse - is it possible? JDK does not have the reference implementation of SecureCacheResponse. You

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

are OK with this change. Thanks, Xuelei On 11/2/2018 11:42 AM, Xuelei Fan wrote: Thanks for the review and suggestions, Chris and Sean. I just finalized the CSR. Thanks, Xuelei On 11/2/2018 5:58 AM, Chris Hegarty wrote: Thanks for the updates Xuelei, some minor comments inline.. On 1 Nov 2018

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

Thanks for the review and suggestions, Chris and Sean. I just finalized the CSR. Thanks, Xuelei On 11/2/2018 5:58 AM, Chris Hegarty wrote: Thanks for the updates Xuelei, some minor comments inline.. On 1 Nov 2018, at 23:42, Xuelei Fan <mailto:xuelei@oracle.com>> wrote: On 11/

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

On 11/1/2018 11:24 AM, Sean Mullan wrote: On 10/31/18 11:52 AM, Chris Hegarty wrote: Xuelei, On 30/10/18 20:55, Xuelei Fan wrote: Hi, For the current HttpsURLConnection, there is not much security parameters exposed in the public APIs.  An application may need richer information

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

, at 20:03, Xuelei Fan <mailto:xuelei@oracle.com>> wrote: ... Yes.  I had the same concern about the optional operation.  However, I came to a different conclusion if I'm from viewpoint of these users that need to use this new operation. If an application have to use this new

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

On 10/31/2018 8:52 AM, Chris Hegarty wrote: Xuelei, On 30/10/18 20:55, Xuelei Fan wrote: Hi, For the current HttpsURLConnection, there is not much security parameters exposed in the public APIs.  An application may need richer information for the underlying TLS connections, for example

A new proposal to add methods to HttpsURLConnection to access SSLSession

Hi, For the current HttpsURLConnection, there is not much security parameters exposed in the public APIs. An application may need richer information for the underlying TLS connections, for example the negotiated TLS protocol version. Please let me know if you have concerns to add a new

Re: Code Review Request, JDK-8207009 SSLEngine#closeInbound mentions SSLException when no close_notify is received

://mail.openjdk.java.net/pipermail/security-dev/2018-August/017778.html Please let me know your concerns before this Wednesday. Thanks, Xuelei On 8/3/2018 1:55 PM, Xuelei Fan wrote: Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.02/ In webrev.01, the socket close may be blocked by super class close

Re: Code Review Request, JDK-8207009 SSLEngine#closeInbound mentions SSLException when no close_notify is received

Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.02/ In webrev.01, the socket close may be blocked by super class close synchronization. Updated the SSLSocketImpl.java to use handshake only lock in the startHandshake() implementation. Thanks, Xuelei On 8/1/2018 7:27 PM, Xuelei Fan

Re: Code Review Request, JDK-8207009 SSLEngine#closeInbound mentions SSLException when no close_notify is received

1.3 client side. Thanks, Xuelei On 7/30/2018 10:24 AM, Xuelei Fan wrote: Please let me know your concerns by the end of August 1st, 2018. Thanks, Xuelei On 7/30/2018 9:59 AM, Xuelei Fan wrote: Hi, Please review the update for the TLS 1.3 half-close and synchronization implementation:

Re: Code Review Request, JDK-8207009 SSLEngine#closeInbound mentions SSLException when no close_notify is received

Please let me know your concerns by the end of August 1st, 2018. Thanks, Xuelei On 7/30/2018 9:59 AM, Xuelei Fan wrote: Hi, Please review the update for the TLS 1.3 half-close and synchronization implementation:    http://cr.openjdk.java.net/~xuelei/8207009/webrev.00/ Unlike TLS 1.2

Re: [RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

> On Sep 22, 2017, at 6:06 AM, Rob McKenna <rob.mcke...@oracle.com> wrote: > > Thanks Xuelei, webrev below: > > http://cr.openjdk.java.net/~robm/8184328/webrev.02/ > Looks fine to me. > Presumably this won't require a CSR? > Agreed. Xuelei > -Rob &g

Re: [RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

it's fine just call fatal() for the first timeout. Xuelei On 9/15/2017 4:32 PM, Xuelei Fan wrote: On 9/15/2017 8:22 AM, Rob McKenna wrote: This test calls close directly. (3rd last line in the stack) I believe this is the only possible stack (with the new parameter) once autoclose is set

Re: [RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

-Rob On 15/09/17 07:55, Xuelei Fan wrote: On 9/15/2017 7:41 AM, Rob McKenna wrote: On 15/09/17 07:07, Xuelei Fan wrote: On 9/15/2017 7:00 AM, Rob McKenna wrote: When we call close() on the SSLSocket that calls close() on the underlying java Socket which closes the native socket. Sorry, I did

Re: [RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

. Applications don't have to set a read timeout. Xuelei , my proposal doesn't alter this fact. (i.e. if the read timeout isn't set applications which call close could potentially get stuck in readReply indefinitely) -Rob On 15/09/17 07:23, Xuelei Fan wrote: On 9/15/2017 7:07 AM, Rob McKenna

Re: [RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

On 9/15/2017 7:41 AM, Rob McKenna wrote: On 15/09/17 07:07, Xuelei Fan wrote: On 9/15/2017 7:00 AM, Rob McKenna wrote: When we call close() on the SSLSocket that calls close() on the underlying java Socket which closes the native socket. Sorry, I did not get the point. Please see the close

Re: [RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

On 9/15/2017 7:16 AM, Rob McKenna wrote: On 13/09/17 03:52, Xuelei Fan wrote: On 9/13/2017 8:52 AM, Rob McKenna wrote: Hi Xuelei, This behaviour is already exposed via the autoclose boolean in: https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocketFactory.html#createSocket

Re: [RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

you are suggesting would effectively necessitate a reimplementation of the close mechanics discarding the read timeout completely. (which would be a significant enough change in terms of compatibility) -Rob On 13/09/17 03:56, Xuelei Fan wrote: On 9/13/2017 8:52 AM, Rob McKenna wrote: W.r.t

Re: [RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

the details. Xuelei -Rob On 13/09/17 04:09, Xuelei Fan wrote: It's a little bit complicated for layered SSL connections. Application can build a SSL connection on existing socket (we call it layered SSL connections). The problem scenarios make look like: 1. open a socket for applications

Re: [RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

05:52, Xuelei Fan wrote: In theory, there are intermittent compatibility problems as this update may not close the SSL connection over the existing socket layer gracefully, even for high speed networking environments, while the underlying socket is alive. The impact could be serious in some envir

Re: [RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

On 9/13/2017 8:52 AM, Rob McKenna wrote: W.r.t. a separate timeout, the underlying mechanics of a close already depend on the readTimeout in this situation. That's a concerns of mine. In order to work for your countermeasure, applications have to set receiving timeout, and take care of the

Re: [RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

that we are closing the underlying socket) I did not get the point, are we really closing the underlying socket (or the layered ssl connection?) for the context of you update? Xuelei I'll file a CSR as soon as we settle on the direction this fix will take. -Rob On 13/09/17 05:52, Xuelei

Re: [RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

On 9/13/2017 5:52 AM, Xuelei Fan wrote: In theory, there are intermittent compatibility problems as this update may not close the SSL connection over the existing socket layer gracefully, even for high speed networking environments, while the underlying socket is alive.  The impact could

Re: [RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

In theory, there are intermittent compatibility problems as this update may not close the SSL connection over the existing socket layer gracefully, even for high speed networking environments, while the underlying socket is alive. The impact could be serious in some environment. For safe, I

Re: RFR 8085575_8130657, misc fixes for a few of java.net intermittent failures

Just FYI. The intermittent failures look like similar to some anti-free-port using issues. In the current testing environment, for the InheritHandle test case, this anti-free-port using issue may looks like: 1. InheritHandle creates a server socket on a free port, and gets the port

Re: [9] RFR: 8164591: sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed with SSLHandshakeException

, you cannot avoid the intermittent failure for this test case in the current testing environment. Xuelei I can make this enhancement, but like I said I don't think it's going to help, so I would like to keep debug output on. Artem On 09/14/2016 06:39 PM, Xuelei Fan wrote: On 9/15/2016 9:23 AM

Re: [9] RFR: 8164591: sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed with SSLHandshakeException

. Xuelei I would prefer to have it as a separate enhancement. Artem On 09/14/2016 06:19 PM, Xuelei Fan wrote: As you were already there, I would suggest to consider the SSLSocketSample.java template as the comment in JDK-8163924 review thread. Thanks, Xuelei On 9/15/2016 9:13 AM, Artem Smotrakov

Re: [9] RFR: 8164591: sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed with SSLHandshakeException

As you were already there, I would suggest to consider the SSLSocketSample.java template as the comment in JDK-8163924 review thread. Thanks, Xuelei On 9/15/2016 9:13 AM, Artem Smotrakov wrote: Not urgent, but I would appreciate if someone can get a chance to look at this. Artem On

Re: 8143397: It looks like InetAddress.isReachable(timeout) works incorrectly

reachability I feel that this small corner case is a worthwhile tradeoff. > > -Rob > > On 09/12/15 01:31, Xuelei Fan wrote: >> Is it nice to say in the spec that it is not reliable if the timeout is >> too small? At least 1000ms timeout by default may be not acceptable in >

Re: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension

Looks fine to me. Thanks for the update. Xuelei On 12/1/2015 7:08 AM, Vincent Ryan wrote: > Thanks for your review. Comments in-line. > >> On 30 Nov 2015, at 06:30, Xuelei Fan <xuelei@oracle.com> wrote: >> >> Looks fine to me. Just a few minor comment

Re: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension

Looks fine to me. Just a few minor comments. ServerHandshaker.java = There is a typo of the first line. - /* Copyright (c) 1996, 2015, ... + /* + * Copyright (c) 1996, 2015 ... line 538-546 String negotiatedValue = null; List protocols =

Re: TLS ALPN Proposal v7

Thanks! Xuelei On 10/3/2015 8:19 AM, Bradford Wetmore wrote: > > > On 10/1/2015 7:35 PM, Xuelei Fan wrote: >> On 10/2/2015 9:03 AM, Bradford Wetmore wrote: >>> Major changes: >>> >>> 1. ApplicationProtocols is gone. The H2 black list and comp

Re: TLS ALPN Proposal v6

On 10/2/2015 9:03 AM, Bradford Wetmore wrote: > Major changes: > > 1. ApplicationProtocols is gone. The H2 black list and comparator were > moved to StandardConstants. > > 2. StandardConstants. Strings for "h2" and "http/1.1" are back. And > now that you are parsing the raw network bytes, I

Re: whether a concrete server can support,both HTTP/2 and HTTP/1.1, or not?

On 9/25/2015 10:28 PM, Simone Bordet wrote: > Hi, > > On Fri, Sep 25, 2015 at 4:19 PM, Xuelei Fan <xuelei@oracle.com> wrote: >> Actually, it was a puzzle to me: whether a concrete server can support >> both HTTP/2 and HTTP/1.1, or not. If HTTP/2 mode of the server

Re: TLS ALPN Proposal v5

On 9/25/2015 10:20 PM, Simone Bordet wrote: > Hi, > > On Fri, Sep 25, 2015 at 3:20 PM, Xuelei Fan <xuelei@oracle.com> wrote: >> For the complication, I posted the comments in previous mail here: >> >> - >>> In case you hav

Re: TLS ALPN Proposal v5

CC security-dev. On 9/25/2015 9:14 PM, Simone Bordet wrote: > Hi, > > On Fri, Sep 25, 2015 at 2:46 PM, David M. Lloyd > wrote: >> Well, SNI already basically works this way, so it's not so great a stretch. > > I don't follow ? > SNI has APIs in JDK 8, you don't use

Re: TLS ALPN Proposal v5

I would second David's proposal based on the #1/#A ideas. Here are some background and options. 1. a HTTP2 server should support HTTP2 If a HTTP2 server declare to support HTTP2, it should support HTTP2 protocol. What happens if corner cases happen that the security is not sufficient (client

Re: TLS ALPN Proposal v5

On 9/26/2015 8:47 AM, Bradford Wetmore wrote: >> {TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384} > > BTW, in case anyone was wondering, both of these suites are on the RFC > 7540 blacklist. Ooops, I meant to use "TLS_ECDHE_" as HTTP2 non-blacklisted cipher suite. Xuelei

Re: TLS ALPN Proposal v5

On 9/26/2015 8:47 AM, Bradford Wetmore wrote: >> It might be not customers expected behavior to re-order/sort their >> preference of cipher suites or preference. > > Are we are clear that the intention was never for the JDK to internally > resort the ciphersuites, but rather to provide an

Re: TLS ALPN Proposal v5

On 9/25/2015 7:42 PM, Simone Bordet wrote: > Hi, > > On Fri, Sep 25, 2015 at 11:47 AM, Xuelei Fan <xuelei@oracle.com> wrote: >> Here is the question to answer, which preference should be respected >> firstly between cipher suite and application protocol?

Re: TLS ALPN Proposal v5

On 9/25/2015 8:48 PM, Simone Bordet wrote: > Hi, > > On Fri, Sep 25, 2015 at 2:26 PM, Xuelei Fan <xuelei@oracle.com> wrote: >> Maybe, we are not on the same page, I think. > > We are. > >> I think a general cipher strength comparator is sufficient for HT

Re: TLS ALPN Proposal v5

On 9/25/2015 4:11 PM, Simone Bordet wrote: > Hi, > > On Fri, Sep 25, 2015 at 3:44 AM, Xuelei Fan <xuelei@oracle.com> wrote: >> For example, a client wants to negotiate {HTTP2, HTTP1.1} or {HTTP1.1, >> HTTP2} and {TLS_RSA_WITH_AES_128_CBC_SHA, >> TLS_

Re: TLS ALPN Proposal v5

On 9/25/2015 9:14 PM, Simone Bordet wrote: > On Fri, Sep 25, 2015 at 2:46 PM, David M. Lloyd > wrote: >> > Well, SNI already basically works this way, so it's not so great a stretch. > I don't follow ? > SNI has APIs in JDK 8, you don't use SSLExplorer at all. There are

Re: TLS ALPN Proposal v5

On 9/25/2015 7:45 AM, Bradford Wetmore wrote: > > On 9/23/2015 2:33 AM, Simone Bordet wrote: >> Hi, >> >> On Wed, Sep 23, 2015 at 7:04 AM, Bradford Wetmore >> wrote: >>> This new proposal still requires that ciphers are sorted in a way that matches the

Re: RFR 8072615: test/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java wrong on Windows

Good catch! Looks fine to me. Xuelei On 2/5/2015 7:54 PM, Weijun Wang wrote: Hi All A test helper tries to parse the test.src.path system property using delimiter :. This is not correct on Windows. The fix is simply diff --git

Re: RFR: 8055299 HttpsURLConnection.equals() broken

Looks fine to me. Thanks for the update. Xuelei On 8/20/2014 9:02 PM, Michael McMahon wrote: This is the recently reported fix to HttpsURLConnection.equals http://cr.openjdk.java.net/~michaelm/8055299/webrev.1/ The fix includes a test. Not shown in the webrev is java key store file

Re: [8u20] Request for approval/Review for CR 8041931: test/sun/net/www/http/HttpClient/B8025710.java fails in 8 Update

The change looks fine to me. Xuelei On 4/26/2014 1:22 AM, Chris Hegarty wrote: Hi 8u maintainers, Stupidly I mixed up testing results, and consequently pushed a new test to 8u-dev [1] that has a minor issue, that causes it to fail on all platforms, all of the time. Root cause, the

Re: Review Request of JDK Enhancement Proposal: DTLS

Networking experts, any suggestion? Xuelei On 3/21/2014 8:28 AM, Matthew Hall wrote: On Fri, Mar 21, 2014 at 06:58:50AM +0800, Xuelei Fan wrote: here. Although MTU is not PMTU, but it is normally correct. I would state, not normally correct, but frequently correct. In case of IPSEC, SSL

hg: jdk8/tl/jdk: 7093640: Enable client-side TLS 1.2 by default

Changeset: 8d35f0985dd7 Author:xuelei Date: 2013-12-18 16:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d35f0985dd7 7093640: Enable client-side TLS 1.2 by default Reviewed-by: weijun, mullan, wetmore ! src/share/classes/sun/security/ssl/ProtocolVersion.java !

hg: jdk8/tl/jdk: 8014266: regression test AsyncSSLSocketClose.java time out.

Changeset: 40d0ccd00f87 Author:xuelei Date: 2013-11-14 16:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40d0ccd00f87 8014266: regression test AsyncSSLSocketClose.java time out. Reviewed-by: xuelei Contributed-by: Rajan Halade rajan.hal...@oracle.com !

hg: jdk8/tl/jdk: 8023147: Test DisabledShortRSAKeys.java intermittent failed

Changeset: 1158d504e39e Author:xuelei Date: 2013-11-13 01:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1158d504e39e 8023147: Test DisabledShortRSAKeys.java intermittent failed Reviewed-by: mullan ! test/sun/security/ssl/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java

hg: jdk8/tl/jdk: 8026119: Regression test DHEKeySizing.java failing intermittently

Changeset: fb202a8e83c9 Author:xuelei Date: 2013-10-13 21:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fb202a8e83c9 8026119: Regression test DHEKeySizing.java failing intermittently Reviewed-by: weijun !

hg: jdk8/tl/jdk: 6956398: make ephemeral DH key match the length of the certificate key

Changeset: 0d5f4f1782e8 Author:xuelei Date: 2013-10-07 18:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0d5f4f1782e8 6956398: make ephemeral DH key match the length of the certificate key Reviewed-by: weijun ! src/share/classes/sun/security/ssl/ServerHandshaker.java +

hg: jdk8/tl/jdk: 8025123: SNI support in Kerberos cipher suites

Changeset: 3fca37c636be Author:xuelei Date: 2013-10-01 20:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3fca37c636be 8025123: SNI support in Kerberos cipher suites Reviewed-by: weijun, xuelei Contributed-by: Artem Smotrakov artem.smotra...@oracle.com !

hg: jdk8/tl/jdk: 8024501: sun.security.mscapi.Key has no definition of serialVersionUID

Changeset: c9083205e6eb Author:xuelei Date: 2013-09-10 21:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c9083205e6eb 8024501: sun.security.mscapi.Key has no definition of serialVersionUID Reviewed-by: weijun ! src/windows/classes/sun/security/mscapi/Key.java

hg: jdk8/tl/jdk: 8024444: Change to use othervm mode of tests in SSLEngineImpl

Changeset: f80b8af9c218 Author:xuelei Date: 2013-09-09 19:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f80b8af9c218 802: Change to use othervm mode of tests in SSLEngineImpl Reviewed-by: mullan !

hg: jdk8/tl/jdk: 7188657: There should be a way to reorder the JSSE ciphers

Changeset: 0f47f9f622d9 Author:xuelei Date: 2013-09-07 17:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0f47f9f622d9 7188657: There should be a way to reorder the JSSE ciphers Reviewed-by: weijun, wetmore ! src/share/classes/javax/net/ssl/SSLParameters.java !

hg: jdk8/tl/jdk: 8024068: sun/security/ssl/javax/net/ssl/ServerName/IllegalSNIName.java fails

Changeset: ead6babac5a9 Author:xuelei Date: 2013-09-01 20:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ead6babac5a9 8024068: sun/security/ssl/javax/net/ssl/ServerName/IllegalSNIName.java fails Reviewed-by: weijun !

[JDK 8] Code review request JDK-8023881, IDN.USE_STD3_ASCII_RULES option is too strict to use Unicode in IDN.toASCII

Hi, Please review the fix of JDK-8023881. webrev: http://cr.openjdk.java.net/~xuelei/8023881/webrev.00/ This bug has not been ported to bugs.sun.com. The following is the descirption of the issue. IDN.toASCII(示例.com,

hg: jdk8/tl/jdk: 8023881: IDN.USE_STD3_ASCII_RULES option is too strict to use Unicode in IDN.toASCII

Changeset: cdf68747b0fb Author:xuelei Date: 2013-08-29 18:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cdf68747b0fb 8023881: IDN.USE_STD3_ASCII_RULES option is too strict to use Unicode in IDN.toASCII Reviewed-by: michaelm ! src/share/classes/java/net/IDN.java +

Re: hg: jdk8/tl/jdk: 8022228: Intermittent test failures in sun/security/ssl/javax/net/ssl/NewAPIs

On 8/22/2013 11:37 AM, Laxmi Narayan NIT DGP wrote: is there are any chances of contribution for outsider of oracle and even student developers ?? Sure. Please see the following page about how to contribute: http://openjdk.java.net/contribute/ And The OpenJDK Developers' Guide:

hg: jdk8/tl/jdk: 8022228: Intermittent test failures in sun/security/ssl/javax/net/ssl/NewAPIs

Changeset: ec827a62070a Author:xuelei Date: 2013-08-21 19:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ec827a62070a 808: Intermittent test failures in sun/security/ssl/javax/net/ssl/NewAPIs Reviewed-by: weijun !

hg: jdk8/tl/jdk: 8020842: IDN do not throw IAE when hostname ends with a trailing dot

Changeset: 096e7c665857 Author:xuelei Date: 2013-08-19 17:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/096e7c665857 8020842: IDN do not throw IAE when hostname ends with a trailing dot Reviewed-by: weijun, michaelm ! src/share/classes/java/net/IDN.java +

hg: jdk8/tl/jdk: 8023230: The impl of KerberosClientKeyExchange maybe not exist

Changeset: 21a25911f7f7 Author:xuelei Date: 2013-08-19 18:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/21a25911f7f7 8023230: The impl of KerberosClientKeyExchange maybe not exist Reviewed-by: weijun ! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java

Re: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot

If no objections, I will push the change by COB Monday. Thanks, Xuelei On 8/13/2013 4:29 PM, Xuelei Fan wrote: Can I get an additional code review from networking team? Thanks, Xuelei On 8/12/2013 2:07 PM, Weijun Wang wrote: new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev

Re: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot

On Aug 13 2013, at 01:29 , Xuelei Fan wrote: Can I get an additional code review from networking team? Thanks, Xuelei On 8/12/2013 2:07 PM, Weijun Wang wrote: new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.06/

Re: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot

new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.05/ Added a new test to test illegal hostname in SNIHostName. Xuelei On 8/10/2013 10:49 AM, Xuelei Fan wrote: Hi Michael, It is pretty hard to get the issue solved in SNIHostName in a good sharp. Here is my try to state why we

hg: jdk8/tl/jdk: 8022487: DEREncodedKeyValue.supportedKeyTypes should be private

Changeset: ea4f4164422e Author:xuelei Date: 2013-08-11 18:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ea4f4164422e 8022487: DEREncodedKeyValue.supportedKeyTypes should be private Reviewed-by: mullan !

Re: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot

. One problem: lines 367-373 adds a new IAE to ToUnicode but the method should not fail forever. And some small comments on styles etc. On 8/12/13 9:09 AM, Xuelei Fan wrote: new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.05/ Lines 123 and 185: 184 p = q + 1

Re: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot

, Xuelei Fan wrote: Ping. Thanks, Xuelei On 8/7/2013 11:17 PM, Xuelei Fan wrote: Please review the new update: http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/ With this update, com. is valid (return com.); . and example..com are invalid. And IAE will be thrown for invalid IDN

Re: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot

that requirement is coming from, if it is actually necessary, and if not consider removing it from SNIHostName. If it is necessary, then the check should be implemented in SNIHostName. Michael On 09/08/13 05:28, Xuelei Fan wrote: Thanks for your feedback and suggestions. Here is the new webrev

Re: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot

Hi Michael, I plan to address this issue in SNIHostName. I have filled another two the potential bugs in IDN. Thank you, and other people, for the feedback. Thanks, Xuelei On 8/9/2013 11:25 PM, Xuelei Fan wrote: On 8/9/2013 7:31 PM, Michael McMahon wrote: I don't see how this fixes

Re: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot

Fan wrote: Hi Michael, I plan to address this issue in SNIHostName. I have filled another two the potential bugs in IDN. Thank you, and other people, for the feedback. Thanks, Xuelei On 8/9/2013 11:25 PM, Xuelei Fan wrote: On 8/9/2013 7:31 PM, Michael McMahon wrote: I don't see how

Re: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot

Ping. Thanks, Xuelei On 8/7/2013 11:17 PM, Xuelei Fan wrote: Please review the new update: http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/ With this update, com. is valid (return com.); . and example..com are invalid. And IAE will be thrown for invalid IDN. Thanks, Xuelei

Re: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot

in SNIHostName more than in IDN. However, we may need to rethink about the comparing of two IDN, for example, example.com. should equal to example.com. I want to consider it in another bug. Can I push the changeset? Thanks, Xuelei Thanks Max On 8/9/13 8:41 AM, Xuelei Fan wrote: Ping

Re: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot

On 8/9/2013 10:14 AM, Weijun Wang wrote: On 8/9/13 9:37 AM, Xuelei Fan wrote: On 8/9/2013 9:22 AM, Weijun Wang wrote: I tried nslookup. Those with .. inside are illegal, $ nslookup com.. nslookup: 'com..' is not a legal name (empty label) but $ nslookup . Server:192.168.10.1

Re: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot

On 8/9/2013 11:24 AM, Matthew Hall wrote: But, DNS considers . as the valid root zone... Good! Looks like that IDN.toASCII(.) should returns ., so that a general domain name can always use IDN.toASCII() conversion instead of throwing runtime exception. Xuelei

Re: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot

Thanks for your feedback and suggestions. Here is the new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/ . is regarded as valid IDN in this update. Thanks, Xuelei On 8/9/2013 10:50 AM, Xuelei Fan wrote: On 8/9/2013 10:14 AM, Weijun Wang wrote: On 8/9/13 9:37 AM, Xuelei

Re: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot

. -Dmitry On 2013-08-06 15:44, Xuelei Fan wrote: Hi, Please review the bug fix to strict the illegal input checking in IDN. webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/ Here is two test cases, which are expected to get IAE. Case 1: String host = IDN.toASCII

Re: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot

value is www.oracle.com. I would like to reserve the behavior in this update. I think we are on same page soon. Thanks, Xuelei Michael On 07/08/13 13:44, Xuelei Fan wrote: On 8/7/2013 12:06 AM, Matthew Hall wrote: Trailing dots are allowed in plain DNS (thus almost surely in IDN

Re: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot

returned value is www.oracle.com. I would like to reserve the behavior in this update. My opinion is to keep it as at present ie. www.oracle.com. Michael I think we are on same page soon. Thanks, Xuelei Michael On 07/08/13 13:44, Xuelei Fan wrote: On 8/7/2013 12:06 AM, Matthew Hall

Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot

Hi, Please review the bug fix to strict the illegal input checking in IDN. webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/ Here is two test cases, which are expected to get IAE. Case 1: String host = IDN.toASCII(., IDN.USE_STD3_ASCII_RULES); Exception in thread main

Re: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot

specifications. What's the case you saw with trailing dots? Thanks, Xuelei --Max On 8/6/13 7:44 PM, Xuelei Fan wrote: Hi, Please review the bug fix to strict the illegal input checking in IDN. webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/ Here is two test cases, which

hg: jdk8/tl/jdk: 7127524: P11TlsPrfGenerator has anonymous inner class with serialVersionUID

Changeset: d6de149b9f20 Author:xuelei Date: 2013-08-01 07:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d6de149b9f20 7127524: P11TlsPrfGenerator has anonymous inner class with serialVersionUID Reviewed-by: vinnie !

hg: jdk8/tl/jdk: 8021841: Remove SSLEngineDeadlock.java from problem list

Changeset: 613cc7beba64 Author:xuelei Date: 2013-07-29 19:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/613cc7beba64 8021841: Remove SSLEngineDeadlock.java from problem list Reviewed-by: wetmore ! test/ProblemList.txt

Re: TLS and Pre-shared Keys

It is not supported at present. Will consider it in the future. Xuelei On 7/18/2013 3:52 AM, Matthew Hall wrote: On Wed, Jul 17, 2013 at 03:45:19PM -0400, roger riggs wrote: Hi, Is there support in SSLEngine/TLS to support Pre-Shared Keys? I have been looking for relevant doc and have not

Re: RFR: 8019341: Update CookieHttpsClientTest to use the newer framework.

Good. :-) Learn something new today. Thanks! Xuelei On 7/6/2013 9:18 AM, Brad Wetmore wrote: On 7/2/2013 8:29 PM, Xuelei Fan wrote: On 7/3/2013 8:30 AM, Brad Wetmore wrote: http://cr.openjdk.java.net/~wetmore/8019341/webrev.01/ 261 // If both failed, return the curthread's

hg: jdk8/tl/jdk: 8019359: To comment why not use no_renegotiation to reject client initiated renegotiation

Changeset: 60d1994f63f7 Author:xuelei Date: 2013-06-27 19:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60d1994f63f7 8019359: To comment why not use no_renegotiation to reject client initiated renegotiation Reviewed-by: wetmore !

hg: jdk8/tl/jdk: 8017049: rename property jdk.tls.rejectClientInitializedRenego

Changeset: 0822bcddbd4f Author:xuelei Date: 2013-06-26 06:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0822bcddbd4f 8017049: rename property jdk.tls.rejectClientInitializedRenego Reviewed-by: vinnie, wetmore, mullan ! src/share/classes/sun/security/ssl/Handshaker.java

  1   2   >