From rajan.halade at oracle.com Fri Jun 1 03:40:01 2018 From: rajan.halade at oracle.com (Rajan Halade) Date: Thu, 31 May 2018 20:40:01 -0700 Subject: RFR: 8196141: Add GoDaddy root certificates Message-ID: <9ed4fc73-c133-7c00-fbbe-8b5af5dec965@oracle.com> Please review this fix to add GoDaddy root certificates to cacerts. Webrev: http://cr.openjdk.java.net/~rhalade/8196141/webrev.00/ Thanks, Rajan From xuelei.fan at oracle.com Fri Jun 1 05:04:33 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 31 May 2018 22:04:33 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> Message-ID: <84a1888c-d52c-8c9a-3c68-b4b9be053b2d@oracle.com> > http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 AlpnExtension.java ------------------ Looks fine to me. CertificateRequest.java ----------------------- Looks fine to me. CertificateStatus.java ---------------------- - 42 * Pack of the CertificateStatus handshake message. + 42 * Pack of the CertificateStatus handshake message. [RFC 6066] May be nice if adding the RFC number that defines this handshake message. Otherwise, looks fine to me. CertificateVerify.java ---------------------- -129 if (x509Credentials == null) { +129 if (x509Credentials == null || x509Credentials.popPublicKey == null) { 130 shc.conContext.fatal(Alert.HANDSHAKE_FAILURE, 131 "No X509 credentials negotiated for CertificateVerify"); 132 } May be safe to check the x509Credentials.popPublicKey as well. Similar to line 357-360, 607-610, 916-919. -233 if (x509Possession == null) { +233 if (x509Possession == null || x509Possession.popPrivateKey == null) { 234 if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) { 235 SSLLogger.fine( 236 "No X.509 credentials negotiated for CertificateVerify"); 237 } 238 239 return null; 240 } May be safe to check the x509Possession.popPrivateKey as well. Similar to line 458-466, 697-704, 1021-1027. Otherwise, looks fine to me. CertStatusExtension.java ------------------------ 326 private final int encodedLen; Looks like this field is not used. Remove it? 425 if (!responderIds.isEmpty()) { 426 ridStr = responderIds.toString(); -427 428 } One unnecessary blank line. Otherwise, looks fine to me. Xuelei On 5/25/2018 4:45 PM, Xuelei Fan wrote: > Hi, > > I'd like to invite you to review the TLS 1.3 implementation.? I > appreciate it if I could have compatibility and specification feedback > before May 31, 2018, and implementation feedback before June 7, 2018. > > Here is the webrev: > ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > The formal TLS 1.3 specification is not finalized yet, although it had > been approved to be a standard.? The implementation is based on the > draft version 28: > ??? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 > > For the overall description of this enhancement, please refer to JEP 332: > ??? http://openjdk.java.net/jeps/332 > > For the compatibility and specification update, please refer to CSR > 8202625: > ??? https://bugs.openjdk.java.net/browse/JDK-8202625 > > Note that we are using the sandbox for the development right now.? For > more information, please refer to Bradford's previous email: > > http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html > > Thanks & Regards, > Xuelei From jamil.j.nimeh at oracle.com Fri Jun 1 07:15:58 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 1 Jun 2018 00:15:58 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <84a1888c-d52c-8c9a-3c68-b4b9be053b2d@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <84a1888c-d52c-8c9a-3c68-b4b9be053b2d@oracle.com> Message-ID: <3d5eacfb-408e-1cda-9105-f9d759eb43d9@oracle.com> Some comments in-line: On 05/31/2018 10:04 PM, Xuelei Fan wrote: > > http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > AlpnExtension.java > ------------------ > Looks fine to me. > > > CertificateRequest.java > ----------------------- > Looks fine to me. > > > CertificateStatus.java > ---------------------- > - 42? * Pack of the CertificateStatus handshake message. > + 42? * Pack of the CertificateStatus handshake message. [RFC 6066] > > May be nice if adding the RFC number that defines this handshake > message.? Otherwise, looks fine to me. JJN: Yeah, we can do that.? And probably reference both 6066 and 6961 since both are represented in this handshake message.? Perhaps a full header comment that describes the structure of the message might be appropriate here, too.? It would help maintainers perhaps. > > > CertificateVerify.java > ---------------------- > -129? if (x509Credentials == null) { > +129? if (x509Credentials == null || > ???????????? x509Credentials.popPublicKey == null) { > ?130????? shc.conContext.fatal(Alert.HANDSHAKE_FAILURE, > ?131???????? "No X509 credentials negotiated for CertificateVerify"); > ?132? } > > May be safe to check the x509Credentials.popPublicKey as well. Similar > to line 357-360, 607-610, 916-919. > > > -233? if (x509Possession == null) { > +233? if (x509Possession == null || > ????????????? x509Possession.popPrivateKey == null) { > ?234????? if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) { > ?235???????? SSLLogger.fine( > ?236???????? "No X.509 credentials negotiated for CertificateVerify"); > ?237????? } > ?238 > ?239???? return null; > ?240? } > > May be safe to check the x509Possession.popPrivateKey as well. Similar > to line 458-466, 697-704, 1021-1027. > > Otherwise, looks fine to me. > > CertStatusExtension.java > ------------------------ > ?326???????? private final int encodedLen; > > Looks like this field is not used.? Remove it? > > ?425?????? if (!responderIds.isEmpty()) { > ?426?????????? ridStr = responderIds.toString(); > -427 > ?428????? } > One unnecessary blank line.? Otherwise, looks fine to me. JJN: For the last two comments, yes to both.? That encodedLen field is a remnant from the JDK 9 implementation and it was used there. > > Xuelei > > On 5/25/2018 4:45 PM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 implementation.? I >> appreciate it if I could have compatibility and specification >> feedback before May 31, 2018, and implementation feedback before June >> 7, 2018. >> >> Here is the webrev: >> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> The formal TLS 1.3 specification is not finalized yet, although it >> had been approved to be a standard.? The implementation is based on >> the draft version 28: >> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >> >> For the overall description of this enhancement, please refer to JEP >> 332: >> ???? http://openjdk.java.net/jeps/332 >> >> For the compatibility and specification update, please refer to CSR >> 8202625: >> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >> >> Note that we are using the sandbox for the development right now.? >> For more information, please refer to Bradford's previous email: >> >> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >> >> Thanks & Regards, >> Xuelei From xuelei.fan at oracle.com Fri Jun 1 14:11:28 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 1 Jun 2018 07:11:28 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> Message-ID: > http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 CookieExtension.java HelloRequest.java HelloVerifyRequest.java -------------------- Looks fine to me. HKDF.java --------- 46 class HKDF { Use "final class"? - 65 hmacObj = Mac.getInstance(hmacAlg); + 65 hmacObj = JsseJce.getMac(hmacAlg); In case a specific crypto provider is customized. 200 SecretKey extractExpand(... 226 SecretKey extractExpand(SecretKey inputKey, ... These two methods are not used. I may suggest remove them for now. We can add them back if necessary in the future. Xuelei On 5/25/2018 4:45 PM, Xuelei Fan wrote: > Hi, > > I'd like to invite you to review the TLS 1.3 implementation.? I > appreciate it if I could have compatibility and specification feedback > before May 31, 2018, and implementation feedback before June 7, 2018. > > Here is the webrev: > ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > The formal TLS 1.3 specification is not finalized yet, although it had > been approved to be a standard.? The implementation is based on the > draft version 28: > ??? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 > > For the overall description of this enhancement, please refer to JEP 332: > ??? http://openjdk.java.net/jeps/332 > > For the compatibility and specification update, please refer to CSR > 8202625: > ??? https://bugs.openjdk.java.net/browse/JDK-8202625 > > Note that we are using the sandbox for the development right now.? For > more information, please refer to Bradford's previous email: > > http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html > > Thanks & Regards, > Xuelei From jamil.j.nimeh at oracle.com Fri Jun 1 14:12:02 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 1 Jun 2018 07:12:02 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> Message-ID: <180af898-b64e-bc9e-10e3-d21148e43b66@oracle.com> On 6/1/2018 7:11 AM, Xuelei Fan wrote: > > http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > CookieExtension.java > HelloRequest.java > HelloVerifyRequest.java > -------------------- > Looks fine to me. > > HKDF.java > --------- > 46 class HKDF { > > Use "final class"? JJN: Yes, I don't see us needing to derive child classes from this. > > - 65? hmacObj = Mac.getInstance(hmacAlg); > + 65? hmacObj = JsseJce.getMac(hmacAlg); > In case a specific crypto provider is customized. > > 200???? SecretKey extractExpand(... > 226???? SecretKey extractExpand(SecretKey inputKey, ... > These two methods are not used.? I may suggest remove them for now.? > We can add them back if necessary in the future. JJN: Yes to both of your suggested changes...they both sound fine. > > > Xuelei > > > On 5/25/2018 4:45 PM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 implementation.? I >> appreciate it if I could have compatibility and specification >> feedback before May 31, 2018, and implementation feedback before June >> 7, 2018. >> >> Here is the webrev: >> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> The formal TLS 1.3 specification is not finalized yet, although it >> had been approved to be a standard.? The implementation is based on >> the draft version 28: >> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >> >> For the overall description of this enhancement, please refer to JEP >> 332: >> ???? http://openjdk.java.net/jeps/332 >> >> For the compatibility and specification update, please refer to CSR >> 8202625: >> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >> >> Note that we are using the sandbox for the development right now.? >> For more information, please refer to Bradford's previous email: >> >> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >> >> Thanks & Regards, >> Xuelei From adam.petcher at oracle.com Fri Jun 1 14:16:36 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Fri, 1 Jun 2018 10:16:36 -0400 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> Message-ID: <71215201-3377-584a-3684-785092bf8937@oracle.com> On 5/25/2018 7:45 PM, Xuelei Fan wrote: > Here is the webrev: > ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 Small update: http://hg.openjdk.java.net/jdk/sandbox/rev/50595f26ea8a This fixes a SSLEngine bug in which a result status of OK is returned (instead of the expected BUFFER_UNDERFLOW) from unwrap when the input buffers are empty. Note to reviewers: This change (along with other small updates like this) will be included in a future webrev that is published as a part of this code review. From xuelei.fan at oracle.com Fri Jun 1 14:21:34 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 1 Jun 2018 07:21:34 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <71215201-3377-584a-3684-785092bf8937@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <71215201-3377-584a-3684-785092bf8937@oracle.com> Message-ID: <9aa11418-27d6-9ac1-5a05-1ea6b3c21d72@oracle.com> > http://hg.openjdk.java.net/jdk/sandbox/rev/50595f26ea8a SSLEngineImpl.java: ------------------- - return new SSLEngineResult(Status.OK, getHandshakeStatus(), 0, 0); + return new SSLEngineResult(Status.BUFFER_UNDERFLOW, getHandshakeStatus(), 0, 0); As the handshake status has been retrieved in "hsStatus" in previous code, could we just use "hsStatus" rather than call getHandshakeStatus() again? return new SSLEngineResult(Status.BUFFER_UNDERFLOW, hsStatus, 0, 0); Xuelei On 6/1/2018 7:16 AM, Adam Petcher wrote: > On 5/25/2018 7:45 PM, Xuelei Fan wrote: > >> Here is the webrev: >> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > Small update: http://hg.openjdk.java.net/jdk/sandbox/rev/50595f26ea8a > > This fixes a SSLEngine bug in which a result status of OK is returned > (instead of the expected BUFFER_UNDERFLOW) from unwrap when the input > buffers are empty. > > Note to reviewers: This change (along with other small updates like > this) will be included in a future webrev that is published as a part of > this code review. From jamil.j.nimeh at oracle.com Fri Jun 1 15:41:40 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 1 Jun 2018 08:41:40 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <71215201-3377-584a-3684-785092bf8937@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <71215201-3377-584a-3684-785092bf8937@oracle.com> Message-ID: Minor updates based on TLS 1.3 code review comments from Xuelei. http://cr.openjdk.java.net/~jnimeh/reviews/tls13-fixes/webrev.01/ --Jamil From xuelei.fan at oracle.com Fri Jun 1 15:43:09 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 1 Jun 2018 08:43:09 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <71215201-3377-584a-3684-785092bf8937@oracle.com> Message-ID: Looks fine to me. Thanks! Xuelei On 6/1/2018 8:41 AM, Jamil Nimeh wrote: > Minor updates based on TLS 1.3 code review comments from Xuelei. > > http://cr.openjdk.java.net/~jnimeh/reviews/tls13-fixes/webrev.01/ > > --Jamil From xuelei.fan at oracle.com Fri Jun 1 15:59:42 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 1 Jun 2018 08:59:42 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> Message-ID: <1b336fdc-bb9d-930a-dfd8-8323d813f442@oracle.com> > http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 KeyShareExtension.java ---------------------- 346 NamedGroup ng = NamedGroup.valueOf(entry.namedGroupId); -347 if (ng != null && !SupportedGroups.isActivatable( +347 if (ng == null || !SupportedGroups.isActivatable( 348 shc.sslConfig.algorithmConstraints, ng)) { ... 354 continue; 355 } 'ng' could be null. Looks like, a "null" ng should be ignored as well. Xuelei On 5/25/2018 4:45 PM, Xuelei Fan wrote: > Hi, > > I'd like to invite you to review the TLS 1.3 implementation.? I > appreciate it if I could have compatibility and specification feedback > before May 31, 2018, and implementation feedback before June 7, 2018. > > Here is the webrev: > ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > The formal TLS 1.3 specification is not finalized yet, although it had > been approved to be a standard.? The implementation is based on the > draft version 28: > ??? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 > > For the overall description of this enhancement, please refer to JEP 332: > ??? http://openjdk.java.net/jeps/332 > > For the compatibility and specification update, please refer to CSR > 8202625: > ??? https://bugs.openjdk.java.net/browse/JDK-8202625 > > Note that we are using the sandbox for the development right now.? For > more information, please refer to Bradford's previous email: > > http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html > > Thanks & Regards, > Xuelei From xuelei.fan at oracle.com Fri Jun 1 19:56:05 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 1 Jun 2018 12:56:05 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> Message-ID: <2182528c-55cc-f81d-dd77-d9ad811f04c8@oracle.com> > http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 MaxFragExtension.java --------------------- Looks fine to me. KeyUpdate.java -------------- - 74 new IOException("KeyUpdate message value invalid: " + status); + 74 throw new IOException("KeyUpdate message value invalid: " + status); Or + 74 context.conContext.fatal(...); The exception is not thrown. Personally, I may prefer a RuntimeException as it is used in generation side, or send a fatal alert to indicate the problem. 81 if (m.remaining() != 1) { 82 throw new IOException("KeyUpdate has an unexpected length of "+ 83 m.remaining()); 84 } Personally, I'd prefer to send a fatal alert. 87 if (status > 1) { 88 new IOException("KeyUpdate message value invalid: " + status); 89 } The exception is not thrown. I may use a fatal alert. 108 @Override 109 public String toString() { 110 throw new UnsupportedOperationException("Not supported yet."); 111 } For debugging, please implement this method and dump debug information in the consumer and producer accordingly. 145 public void consume(ConnectionContext context, 146 ByteBuffer message) throws IOException { I think we need to catch up with the following spec in this method: Implementations that receive a KeyUpdate message prior to receiving a Finished message MUST terminate the connection with an unexpected_message" alert. 151 if (km.getStatus() == KeyUpdateMessage.NOTREQUSTED) { 152 return; 153 } If I'm correct, the "update_not_requested" status means "recipient of the KeyUpdate" may not respond with its own KeyUpdate", but still need to update its receiving keys. Am I missing something? 165 SSLKeyDerivation skd = kdg.createKeyDerivation(hc, 166 hc.conContext.inputRecord.readCipher.baseSecret); 167 SecretKey nplus1 = skd.deriveKey("TlsUpdateNplus1", null); 168 if (skd == null) { 169 // unlikely 170 hc.conContext.fatal(Alert.INTERNAL_ERROR, 171 "no key derivation"); 172 return; 173 } Move line 167 bellow 173? he skd non-null checking can be performed 198 new KeyUpdateMessage(hc, KeyUpdateMessage.NOTREQUSTED));earlier. The blank line 191 may be not necessary. 196 // Send Reply 197 handshakeProducer.produce(hc, 198 new KeyUpdateMessage(hc, KeyUpdateMessage.NOTREQUSTED)); If one update the 151-153 block, please don't forgot to update this block as well if needed: send reply if the status is REQUSTED. 219 if (km.getStatus() == KeyUpdateMessage.REQUSTED) { 220 secret = hc.conContext.outputRecord.writeCipher.baseSecret; 221 } else { 222 km.write(hc.handshakeOutput); 223 hc.handshakeOutput.flush(); 224 return null; 225 } Similar comment as 151-153. For NOTREQUSTED status, may still need to update the write keys. Xuelei On 5/25/2018 4:45 PM, Xuelei Fan wrote: > Hi, > > I'd like to invite you to review the TLS 1.3 implementation.? I > appreciate it if I could have compatibility and specification feedback > before May 31, 2018, and implementation feedback before June 7, 2018. > > Here is the webrev: > ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > The formal TLS 1.3 specification is not finalized yet, although it had > been approved to be a standard.? The implementation is based on the > draft version 28: > ??? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 > > For the overall description of this enhancement, please refer to JEP 332: > ??? http://openjdk.java.net/jeps/332 > > For the compatibility and specification update, please refer to CSR > 8202625: > ??? https://bugs.openjdk.java.net/browse/JDK-8202625 > > Note that we are using the sandbox for the development right now.? For > more information, please refer to Bradford's previous email: > > http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html > > Thanks & Regards, > Xuelei From xuelei.fan at oracle.com Fri Jun 1 20:25:01 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 1 Jun 2018 13:25:01 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <9aa11418-27d6-9ac1-5a05-1ea6b3c21d72@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <71215201-3377-584a-3684-785092bf8937@oracle.com> <9aa11418-27d6-9ac1-5a05-1ea6b3c21d72@oracle.com> Message-ID: <2fc620b4-f9b5-e078-4ee0-f27d37e355f0@oracle.com> > http://hg.openjdk.java.net/jdk/sandbox/rev/50595f26ea8a Update: http://hg.openjdk.java.net/jdk/sandbox/rev/c09b8b8c0017 Fixed the 80-characters line wrap and redundancy call issues. Xuelei On 6/1/2018 7:21 AM, Xuelei Fan wrote: > > http://hg.openjdk.java.net/jdk/sandbox/rev/50595f26ea8a > > SSLEngineImpl.java: > ------------------- > - return new SSLEngineResult(Status.OK, getHandshakeStatus(), 0, 0); > + return new SSLEngineResult(Status.BUFFER_UNDERFLOW, > ??????????????????????????????????????? getHandshakeStatus(), 0, 0); > > As the handshake status has been retrieved in "hsStatus" in previous > code, could we just use "hsStatus" rather than call getHandshakeStatus() > again? > > ? return new SSLEngineResult(Status.BUFFER_UNDERFLOW, hsStatus, 0, 0); > > Xuelei > > > On 6/1/2018 7:16 AM, Adam Petcher wrote: >> On 5/25/2018 7:45 PM, Xuelei Fan wrote: >> >>> Here is the webrev: >>> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> Small update: http://hg.openjdk.java.net/jdk/sandbox/rev/50595f26ea8a >> >> This fixes a SSLEngine bug in which a result status of OK is returned >> (instead of the expected BUFFER_UNDERFLOW) from unwrap when the input >> buffers are empty. >> >> Note to reviewers: This change (along with other small updates like >> this) will be included in a future webrev that is published as a part >> of this code review. From rajan.halade at oracle.com Fri Jun 1 21:17:09 2018 From: rajan.halade at oracle.com (Rajan Halade) Date: Fri, 1 Jun 2018 14:17:09 -0700 Subject: RFR: 8204250: ProblemList pkcs11 tests on windows Message-ID: <7ee3b553-f443-c106-9c4c-6c6610c5b210@oracle.com> Please review this fix to problem list pkcs11 tests on windows. These tests fail after JDK-8203795 which changed default compiler to VS2017. Webrev: http://cr.openjdk.java.net/~rhalade/8204250/webrev.00/ Thanks, Rajan From bradford.wetmore at oracle.com Fri Jun 1 22:21:30 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 1 Jun 2018 15:21:30 -0700 Subject: RFR: 8204250: ProblemList pkcs11 tests on windows In-Reply-To: <7ee3b553-f443-c106-9c4c-6c6610c5b210@oracle.com> References: <7ee3b553-f443-c106-9c4c-6c6610c5b210@oracle.com> Message-ID: Looks ok. Brad On 6/1/2018 2:17 PM, Rajan Halade wrote: > Please review this fix to problem list pkcs11 tests on windows. These > tests fail after JDK-8203795 which changed default compiler to VS2017. > > Webrev: http://cr.openjdk.java.net/~rhalade/8204250/webrev.00/ > > Thanks, > Rajan > > From xuelei.fan at oracle.com Sat Jun 2 14:36:34 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 2 Jun 2018 07:36:34 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <84a1888c-d52c-8c9a-3c68-b4b9be053b2d@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <84a1888c-d52c-8c9a-3c68-b4b9be053b2d@oracle.com> Message-ID: Update for the following comment: http://hg.openjdk.java.net/jdk/sandbox/rev/fe938437f7ba This update will be included in the next webrev for further review. Xuelei On 5/31/2018 10:04 PM, Xuelei Fan wrote: > CertificateVerify.java > ---------------------- > -129? if (x509Credentials == null) { > +129? if (x509Credentials == null || > ???????????? x509Credentials.popPublicKey == null) { > ?130????? shc.conContext.fatal(Alert.HANDSHAKE_FAILURE, > ?131???????? "No X509 credentials negotiated for CertificateVerify"); > ?132? } > > May be safe to check the x509Credentials.popPublicKey as well.? Similar > to line 357-360, 607-610, 916-919. > > > -233? if (x509Possession == null) { > +233? if (x509Possession == null || > ????????????? x509Possession.popPrivateKey == null) { > ?234????? if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) { > ?235???????? SSLLogger.fine( > ?236???????? "No X.509 credentials negotiated for CertificateVerify"); > ?237????? } > ?238 > ?239???? return null; > ?240? } > > May be safe to check the x509Possession.popPrivateKey as well. Similar > to line 458-466, 697-704, 1021-1027. > > Otherwise, looks fine to me. From xuelei.fan at oracle.com Sat Jun 2 14:51:49 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 2 Jun 2018 07:51:49 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <1b336fdc-bb9d-930a-dfd8-8323d813f442@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <1b336fdc-bb9d-930a-dfd8-8323d813f442@oracle.com> Message-ID: Update for the following comment: http://hg.openjdk.java.net/jdk/sandbox/rev/e5ed96e446ad This update will be included in the next webrev for further review. Xuelei On 6/1/2018 8:59 AM, Xuelei Fan wrote: > > http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > KeyShareExtension.java > ---------------------- > ?346? NamedGroup ng = NamedGroup.valueOf(entry.namedGroupId); > -347? if (ng != null && !SupportedGroups.isActivatable( > +347? if (ng == null || !SupportedGroups.isActivatable( > ?348????????? shc.sslConfig.algorithmConstraints, ng)) { > ????????? ... > ?354????? continue; > ?355? } > > 'ng' could be null.? Looks like, a "null" ng should be ignored as well. > > > Xuelei > > On 5/25/2018 4:45 PM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 implementation.? I >> appreciate it if I could have compatibility and specification feedback >> before May 31, 2018, and implementation feedback before June 7, 2018. >> >> Here is the webrev: >> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> The formal TLS 1.3 specification is not finalized yet, although it had >> been approved to be a standard.? The implementation is based on the >> draft version 28: >> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >> >> For the overall description of this enhancement, please refer to JEP 332: >> ???? http://openjdk.java.net/jeps/332 >> >> For the compatibility and specification update, please refer to CSR >> 8202625: >> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >> >> Note that we are using the sandbox for the development right now.? For >> more information, please refer to Bradford's previous email: >> >> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >> >> Thanks & Regards, >> Xuelei From xuelei.fan at oracle.com Sun Jun 3 00:58:36 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 2 Jun 2018 17:58:36 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> Message-ID: <38761d11-a29e-d1a3-afdc-f4fa71e5813c@oracle.com> > http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 PostHandshakeContext.java ------------------------- - 36 public class PostHandshakeContext extends HandshakeContext { + 36 final class PostHandshakeContext extends HandshakeContext { package class should be sufficient. 38 final static LinkedHashMap consumers; This field can be private. 57 handshakeConsumers = consumers; handshakeConsumers might be modified, safer to clone the map. Xuelei On 5/25/2018 4:45 PM, Xuelei Fan wrote: > Hi, > > I'd like to invite you to review the TLS 1.3 implementation.? I > appreciate it if I could have compatibility and specification feedback > before May 31, 2018, and implementation feedback before June 7, 2018. > > Here is the webrev: > ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > The formal TLS 1.3 specification is not finalized yet, although it had > been approved to be a standard.? The implementation is based on the > draft version 28: > ??? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 > > For the overall description of this enhancement, please refer to JEP 332: > ??? http://openjdk.java.net/jeps/332 > > For the compatibility and specification update, please refer to CSR > 8202625: > ??? https://bugs.openjdk.java.net/browse/JDK-8202625 > > Note that we are using the sandbox for the development right now.? For > more information, please refer to Bradford's previous email: > > http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html > > Thanks & Regards, > Xuelei From xuelei.fan at oracle.com Sun Jun 3 04:26:00 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 2 Jun 2018 21:26:00 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <2182528c-55cc-f81d-dd77-d9ad811f04c8@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <2182528c-55cc-f81d-dd77-d9ad811f04c8@oracle.com> Message-ID: <66106b2b-d3f9-eaa6-10fd-e4b5e15bc612@oracle.com> > KeyUpdate.java > -------------- Update: http://hg.openjdk.java.net/jdk/sandbox/rev/66c803c3ce32 Fixed two test issues and the following KeyUpdate implementation. This update will be included in the next webrev for further review. Xuelei On 6/1/2018 12:56 PM, Xuelei Fan wrote: > > http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > MaxFragExtension.java > --------------------- > Looks fine to me. > > > KeyUpdate.java > -------------- > - 74? new IOException("KeyUpdate message value invalid: " + status); > + 74? throw new IOException("KeyUpdate message value invalid: " + status); > Or > + 74? context.conContext.fatal(...); > The exception is not thrown.? Personally, I may prefer a > RuntimeException as it is used in generation side, or send a fatal alert > to indicate the problem. > > > ? 81? if (m.remaining() != 1) { > ? 82??? throw new IOException("KeyUpdate has an unexpected length of "+ > ? 83??????? m.remaining()); > ? 84? } > Personally, I'd prefer to send a fatal alert. > > > ? 87? if (status > 1) { > ? 88???? new IOException("KeyUpdate message value invalid: " + status); > ? 89? } > The exception is not thrown.? I may use a fatal alert. > > > ?108? @Override > ?109? public String toString() { > ?110????? throw new UnsupportedOperationException("Not supported yet."); > ?111? } > For debugging, please implement this method and dump debug information > in the consumer and producer accordingly. > > > ?145? public void consume(ConnectionContext context, > ?146????????? ByteBuffer message) throws IOException { > > I think we need to catch up with the following spec in this method: > ?? Implementations that receive a KeyUpdate message prior to receiving > ?? a Finished message MUST terminate the connection with an > ?? unexpected_message" alert. > > > ?151? if (km.getStatus() == KeyUpdateMessage.NOTREQUSTED) { > ?152????? return; > ?153? } > > If I'm correct, the "update_not_requested" status means "recipient of > the KeyUpdate" may not respond with its own KeyUpdate", but still need > to update its receiving keys.? Am I missing something? > > > ?165 SSLKeyDerivation skd = kdg.createKeyDerivation(hc, > ?166??????? hc.conContext.inputRecord.readCipher.baseSecret); > ?167 SecretKey nplus1 = skd.deriveKey("TlsUpdateNplus1", null); > ?168 if (skd == null) { > ?169????? // unlikely > ?170?????? hc.conContext.fatal(Alert.INTERNAL_ERROR, > ?171???????????? "no key derivation"); > ?172?????? return; > ?173 } > Move line 167 bellow 173? he skd non-null checking can be performed? 198 > ???? new KeyUpdateMessage(hc, KeyUpdateMessage.NOTREQUSTED));earlier. > > > The blank line 191 may be not necessary. > > > ?196? // Send Reply > ?197? handshakeProducer.produce(hc, > ?198????? new KeyUpdateMessage(hc, KeyUpdateMessage.NOTREQUSTED)); > If one update the 151-153 block, please don't forgot to update this > block as well if needed: send reply if the status is REQUSTED. > > > ?219? if (km.getStatus() == KeyUpdateMessage.REQUSTED) { > ?220????? secret = hc.conContext.outputRecord.writeCipher.baseSecret; > ?221? } else { > ?222????? km.write(hc.handshakeOutput); > ?223????? hc.handshakeOutput.flush(); > ?224????? return null; > ?225? } > Similar comment as 151-153.? For NOTREQUSTED status, may still need to > update the write keys. > > > Xuelei > > On 5/25/2018 4:45 PM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 implementation.? I >> appreciate it if I could have compatibility and specification feedback >> before May 31, 2018, and implementation feedback before June 7, 2018. >> >> Here is the webrev: >> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> The formal TLS 1.3 specification is not finalized yet, although it had >> been approved to be a standard.? The implementation is based on the >> draft version 28: >> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >> >> For the overall description of this enhancement, please refer to JEP 332: >> ???? http://openjdk.java.net/jeps/332 >> >> For the compatibility and specification update, please refer to CSR >> 8202625: >> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >> >> Note that we are using the sandbox for the development right now.? For >> more information, please refer to Bradford's previous email: >> >> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >> >> Thanks & Regards, >> Xuelei From xuelei.fan at oracle.com Sun Jun 3 04:26:56 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 2 Jun 2018 21:26:56 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <38761d11-a29e-d1a3-afdc-f4fa71e5813c@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <38761d11-a29e-d1a3-afdc-f4fa71e5813c@oracle.com> Message-ID: <8b418715-e030-0b50-ae7b-d408fdf776ee@oracle.com> > PostHandshakeContext.java > ------------------------- Update: http://hg.openjdk.java.net/jdk/sandbox/rev/66c803c3ce32 The following PostHandshakeContext issues fixed in the above update. This update will be included in the next webrev for further review. Xuelei On 6/2/2018 5:58 PM, Xuelei Fan wrote: > >? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > PostHandshakeContext.java > ------------------------- > - 36 public class PostHandshakeContext extends HandshakeContext { > + 36 final class PostHandshakeContext extends HandshakeContext { > > package class should be sufficient. > > ? 38 final static LinkedHashMap consumers; > This field can be private. > > > ? 57 handshakeConsumers = consumers; > handshakeConsumers might be modified, safer to clone the map. > > > Xuelei > > On 5/25/2018 4:45 PM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 implementation.? I >> appreciate it if I could have compatibility and specification feedback >> before May 31, 2018, and implementation feedback before June 7, 2018. >> >> Here is the webrev: >> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> The formal TLS 1.3 specification is not finalized yet, although it had >> been approved to be a standard.? The implementation is based on the >> draft version 28: >> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >> >> For the overall description of this enhancement, please refer to JEP 332: >> ???? http://openjdk.java.net/jeps/332 >> >> For the compatibility and specification update, please refer to CSR >> 8202625: >> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >> >> Note that we are using the sandbox for the development right now.? For >> more information, please refer to Bradford's previous email: >> >> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >> >> Thanks & Regards, >> Xuelei From anthony.scarpino at oracle.com Sun Jun 3 18:02:21 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Sun, 3 Jun 2018 11:02:21 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <66106b2b-d3f9-eaa6-10fd-e4b5e15bc612@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <2182528c-55cc-f81d-dd77-d9ad811f04c8@oracle.com> <66106b2b-d3f9-eaa6-10fd-e4b5e15bc612@oracle.com> Message-ID: Xuelei, From looking at your code change at 151 and 219 when a single KeyUpdate handshake is sent, it appears you are changing all 4 keys, both send and receive from the client and send and receive from the server. It was my interpretation of the spec that only the send and receive keys were for one side were updated. After many rereading of 4.6.3 I finally see where you think all 4 keys are updated. spec: If the request_update field is set to ?update_requested? then the receiver MUST send a KeyUpdate of its own with request_update set to ?update_not_requested? prior to sending its next application data I can see where you believe "send a KeyUpdate of its own" means update the send and receive keys from the opposite direction. Where I interpreted this as an ACK by the receiver to updating the receiving key. I believe your interpretation is probably right and the spec could be worded better. The other changes are fine. Tony On 06/02/2018 09:26 PM, Xuelei Fan wrote: > > KeyUpdate.java > > -------------- > Update: http://hg.openjdk.java.net/jdk/sandbox/rev/66c803c3ce32 > > Fixed two test issues and the following KeyUpdate implementation.? This > update will be included in the next webrev for further review. > > Xuelei > > On 6/1/2018 12:56 PM, Xuelei Fan wrote: >> ?> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> MaxFragExtension.java >> --------------------- >> Looks fine to me. >> >> >> KeyUpdate.java >> -------------- >> - 74? new IOException("KeyUpdate message value invalid: " + status); >> + 74? throw new IOException("KeyUpdate message value invalid: " + >> status); >> Or >> + 74? context.conContext.fatal(...); >> The exception is not thrown.? Personally, I may prefer a >> RuntimeException as it is used in generation side, or send a fatal >> alert to indicate the problem. >> >> >> ?? 81? if (m.remaining() != 1) { >> ?? 82??? throw new IOException("KeyUpdate has an unexpected length of "+ >> ?? 83??????? m.remaining()); >> ?? 84? } >> Personally, I'd prefer to send a fatal alert. >> >> >> ?? 87? if (status > 1) { >> ?? 88???? new IOException("KeyUpdate message value invalid: " + status); >> ?? 89? } >> The exception is not thrown.? I may use a fatal alert. >> >> >> ??108? @Override >> ??109? public String toString() { >> ??110????? throw new UnsupportedOperationException("Not supported yet."); >> ??111? } >> For debugging, please implement this method and dump debug information >> in the consumer and producer accordingly. >> >> >> ??145? public void consume(ConnectionContext context, >> ??146????????? ByteBuffer message) throws IOException { >> >> I think we need to catch up with the following spec in this method: >> ??? Implementations that receive a KeyUpdate message prior to receiving >> ??? a Finished message MUST terminate the connection with an >> ??? unexpected_message" alert. >> >> >> ??151? if (km.getStatus() == KeyUpdateMessage.NOTREQUSTED) { >> ??152????? return; >> ??153? } >> >> If I'm correct, the "update_not_requested" status means "recipient of >> the KeyUpdate" may not respond with its own KeyUpdate", but still need >> to update its receiving keys.? Am I missing something? >> >> >> ??165 SSLKeyDerivation skd = kdg.createKeyDerivation(hc, >> ??166??????? hc.conContext.inputRecord.readCipher.baseSecret); >> ??167 SecretKey nplus1 = skd.deriveKey("TlsUpdateNplus1", null); >> ??168 if (skd == null) { >> ??169????? // unlikely >> ??170?????? hc.conContext.fatal(Alert.INTERNAL_ERROR, >> ??171???????????? "no key derivation"); >> ??172?????? return; >> ??173 } >> Move line 167 bellow 173? he skd non-null checking can be performed >> 198 ????? new KeyUpdateMessage(hc, >> KeyUpdateMessage.NOTREQUSTED));earlier. >> >> >> The blank line 191 may be not necessary. >> >> >> ??196? // Send Reply >> ??197? handshakeProducer.produce(hc, >> ??198????? new KeyUpdateMessage(hc, KeyUpdateMessage.NOTREQUSTED)); >> If one update the 151-153 block, please don't forgot to update this >> block as well if needed: send reply if the status is REQUSTED. >> >> >> ??219? if (km.getStatus() == KeyUpdateMessage.REQUSTED) { >> ??220????? secret = hc.conContext.outputRecord.writeCipher.baseSecret; >> ??221? } else { >> ??222????? km.write(hc.handshakeOutput); >> ??223????? hc.handshakeOutput.flush(); >> ??224????? return null; >> ??225? } >> Similar comment as 151-153.? For NOTREQUSTED status, may still need to >> update the write keys. >> >> >> Xuelei >> >> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>> Hi, >>> >>> I'd like to invite you to review the TLS 1.3 implementation.? I >>> appreciate it if I could have compatibility and specification >>> feedback before May 31, 2018, and implementation feedback before June >>> 7, 2018. >>> >>> Here is the webrev: >>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>> >>> The formal TLS 1.3 specification is not finalized yet, although it >>> had been approved to be a standard.? The implementation is based on >>> the draft version 28: >>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>> >>> For the overall description of this enhancement, please refer to JEP >>> 332: >>> ???? http://openjdk.java.net/jeps/332 >>> >>> For the compatibility and specification update, please refer to CSR >>> 8202625: >>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>> >>> Note that we are using the sandbox for the development right now. >>> For more information, please refer to Bradford's previous email: >>> >>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>> >>> Thanks & Regards, >>> Xuelei From xuelei.fan at oracle.com Sun Jun 3 19:58:13 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 3 Jun 2018 12:58:13 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> Message-ID: <8e0a341c-9c53-d671-57f1-f730b70de20e@oracle.com> > http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 PreSharedKeyExtension.java -------------------------- A few lines exceed the 80-characters per line limit. 68 static final class PskIdentity { This class can be private. 72 public PskIdentity(byte[] identity, int obfuscatedAge) { 77 public PskIdentity(ByteBuffer m) It is not necessary to use "public" scope. Please check other public methods as well if existing. 111 CHPreSharedKeySpec(ByteBuffer m) 112 throws IllegalParameterException, IOException { Implementation of this method does not check the boundary of the PreSharedKeyExtension struct. 271 ServerHandshakeContext shc = (ServerHandshakeContext) message.handshakeContext; It is more simple to use the context parameter rather than the message context. 315 shc.isResumption = false; 316 shc.resumingSession = null; ... 324 resumeSession(shc, s, idIndex); This resets of shc.isResumption and shc.resumingSession override the set of other extensions. It could lead to unexpected behaviors. 675 if (shPsk.selectedIdentity != 0) { If only the 1st id can be use, may be don't bother to cache and request other ids. I'm not very sure of it yet, need more time to think about it. Xuelei On 5/25/2018 4:45 PM, Xuelei Fan wrote: > Hi, > > I'd like to invite you to review the TLS 1.3 implementation.? I > appreciate it if I could have compatibility and specification feedback > before May 31, 2018, and implementation feedback before June 7, 2018. > > Here is the webrev: > ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > The formal TLS 1.3 specification is not finalized yet, although it had > been approved to be a standard.? The implementation is based on the > draft version 28: > ??? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 > > For the overall description of this enhancement, please refer to JEP 332: > ??? http://openjdk.java.net/jeps/332 > > For the compatibility and specification update, please refer to CSR > 8202625: > ??? https://bugs.openjdk.java.net/browse/JDK-8202625 > > Note that we are using the sandbox for the development right now.? For > more information, please refer to Bradford's previous email: > > http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html > > Thanks & Regards, > Xuelei From xuelei.fan at oracle.com Sun Jun 3 23:42:35 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 3 Jun 2018 16:42:35 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <2182528c-55cc-f81d-dd77-d9ad811f04c8@oracle.com> <66106b2b-d3f9-eaa6-10fd-e4b5e15bc612@oracle.com> Message-ID: Hi Tony, Thanks for the quick review! Xuelei On 6/3/2018 11:02 AM, Anthony Scarpino wrote: > Xuelei, > > From looking at your code change at 151 and 219? when a single > KeyUpdate handshake is sent, it appears you are changing all 4 keys, > both send and receive from the client and send and receive from the server. > > It was my interpretation of the spec that only the send and receive keys > were for one side were updated.? After many rereading of 4.6.3 I finally > see where you think all 4 keys are updated. > > spec: > ? If the request_update field is set to ?update_requested? then the > ? receiver MUST send a KeyUpdate of its own with request_update set to > ? ?update_not_requested? prior to sending its next application data > > I can see where you believe "send a KeyUpdate of its own" means update > the send and receive keys from the opposite direction.? Where I > interpreted this as an ACK by the receiver to updating the receiving key. > > I believe your interpretation is probably right and the spec could be > worded better. > > The other changes are fine. > > Tony > > On 06/02/2018 09:26 PM, Xuelei Fan wrote: >> ?> KeyUpdate.java >> ?> -------------- >> Update: http://hg.openjdk.java.net/jdk/sandbox/rev/66c803c3ce32 >> >> Fixed two test issues and the following KeyUpdate implementation. >> This update will be included in the next webrev for further review. >> >> Xuelei >> >> On 6/1/2018 12:56 PM, Xuelei Fan wrote: >>> ?> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>> >>> MaxFragExtension.java >>> --------------------- >>> Looks fine to me. >>> >>> >>> KeyUpdate.java >>> -------------- >>> - 74? new IOException("KeyUpdate message value invalid: " + status); >>> + 74? throw new IOException("KeyUpdate message value invalid: " + >>> status); >>> Or >>> + 74? context.conContext.fatal(...); >>> The exception is not thrown.? Personally, I may prefer a >>> RuntimeException as it is used in generation side, or send a fatal >>> alert to indicate the problem. >>> >>> >>> ?? 81? if (m.remaining() != 1) { >>> ?? 82??? throw new IOException("KeyUpdate has an unexpected length of "+ >>> ?? 83??????? m.remaining()); >>> ?? 84? } >>> Personally, I'd prefer to send a fatal alert. >>> >>> >>> ?? 87? if (status > 1) { >>> ?? 88???? new IOException("KeyUpdate message value invalid: " + status); >>> ?? 89? } >>> The exception is not thrown.? I may use a fatal alert. >>> >>> >>> ??108? @Override >>> ??109? public String toString() { >>> ??110????? throw new UnsupportedOperationException("Not supported >>> yet."); >>> ??111? } >>> For debugging, please implement this method and dump debug >>> information in the consumer and producer accordingly. >>> >>> >>> ??145? public void consume(ConnectionContext context, >>> ??146????????? ByteBuffer message) throws IOException { >>> >>> I think we need to catch up with the following spec in this method: >>> ??? Implementations that receive a KeyUpdate message prior to receiving >>> ??? a Finished message MUST terminate the connection with an >>> ??? unexpected_message" alert. >>> >>> >>> ??151? if (km.getStatus() == KeyUpdateMessage.NOTREQUSTED) { >>> ??152????? return; >>> ??153? } >>> >>> If I'm correct, the "update_not_requested" status means "recipient of >>> the KeyUpdate" may not respond with its own KeyUpdate", but still >>> need to update its receiving keys.? Am I missing something? >>> >>> >>> ??165 SSLKeyDerivation skd = kdg.createKeyDerivation(hc, >>> ??166??????? hc.conContext.inputRecord.readCipher.baseSecret); >>> ??167 SecretKey nplus1 = skd.deriveKey("TlsUpdateNplus1", null); >>> ??168 if (skd == null) { >>> ??169????? // unlikely >>> ??170?????? hc.conContext.fatal(Alert.INTERNAL_ERROR, >>> ??171???????????? "no key derivation"); >>> ??172?????? return; >>> ??173 } >>> Move line 167 bellow 173? he skd non-null checking can be performed >>> 198 ????? new KeyUpdateMessage(hc, >>> KeyUpdateMessage.NOTREQUSTED));earlier. >>> >>> >>> The blank line 191 may be not necessary. >>> >>> >>> ??196? // Send Reply >>> ??197? handshakeProducer.produce(hc, >>> ??198????? new KeyUpdateMessage(hc, KeyUpdateMessage.NOTREQUSTED)); >>> If one update the 151-153 block, please don't forgot to update this >>> block as well if needed: send reply if the status is REQUSTED. >>> >>> >>> ??219? if (km.getStatus() == KeyUpdateMessage.REQUSTED) { >>> ??220????? secret = hc.conContext.outputRecord.writeCipher.baseSecret; >>> ??221? } else { >>> ??222????? km.write(hc.handshakeOutput); >>> ??223????? hc.handshakeOutput.flush(); >>> ??224????? return null; >>> ??225? } >>> Similar comment as 151-153.? For NOTREQUSTED status, may still need >>> to update the write keys. >>> >>> >>> Xuelei >>> >>> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> I'd like to invite you to review the TLS 1.3 implementation.? I >>>> appreciate it if I could have compatibility and specification >>>> feedback before May 31, 2018, and implementation feedback before >>>> June 7, 2018. >>>> >>>> Here is the webrev: >>>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>>> >>>> The formal TLS 1.3 specification is not finalized yet, although it >>>> had been approved to be a standard.? The implementation is based on >>>> the draft version 28: >>>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>>> >>>> For the overall description of this enhancement, please refer to JEP >>>> 332: >>>> ???? http://openjdk.java.net/jeps/332 >>>> >>>> For the compatibility and specification update, please refer to CSR >>>> 8202625: >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>>> >>>> Note that we are using the sandbox for the development right now. >>>> For more information, please refer to Bradford's previous email: >>>> >>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>>> >>>> >>>> Thanks & Regards, >>>> Xuelei > From xuelei.fan at oracle.com Mon Jun 4 00:24:58 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 3 Jun 2018 17:24:58 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> Message-ID: <4148acdf-3f12-4301-0b22-c7deaf16f62f@oracle.com> > http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 PskKeyExchangeModesExtension.java --------------------------------- 66 static final class PskKeyExchangeModesSpec implements SSLExtensionSpec { 67 68 69 final List modes; This class can be private. The modes may be null if an invalid value is used. No code to check if the value if valid and behavior accordingly. The lacking of the checking could have unexpected issues. Xuelei On 5/25/2018 4:45 PM, Xuelei Fan wrote: > Hi, > > I'd like to invite you to review the TLS 1.3 implementation.? I > appreciate it if I could have compatibility and specification feedback > before May 31, 2018, and implementation feedback before June 7, 2018. > > Here is the webrev: > ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > The formal TLS 1.3 specification is not finalized yet, although it had > been approved to be a standard.? The implementation is based on the > draft version 28: > ??? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 > > For the overall description of this enhancement, please refer to JEP 332: > ??? http://openjdk.java.net/jeps/332 > > For the compatibility and specification update, please refer to CSR > 8202625: > ??? https://bugs.openjdk.java.net/browse/JDK-8202625 > > Note that we are using the sandbox for the development right now.? For > more information, please refer to Bradford's previous email: > > http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html > > Thanks & Regards, > Xuelei From xuelei.fan at oracle.com Mon Jun 4 02:45:38 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 3 Jun 2018 19:45:38 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <8e0a341c-9c53-d671-57f1-f730b70de20e@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8e0a341c-9c53-d671-57f1-f730b70de20e@oracle.com> Message-ID: <1ebf97e2-0378-b570-89e1-1e47d744f3a8@oracle.com> > PreSharedKeyExtension.java > -------------------------- Update: http://hg.openjdk.java.net/jdk/sandbox/rev/2a820e434f17 This update fixed some issues of PreSharedKeyExtension.java. This update will be included in the next webrev for further review. Xuelei On 6/3/2018 12:58 PM, Xuelei Fan wrote: > > http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > PreSharedKeyExtension.java > -------------------------- > A few lines exceed the 80-characters per line limit. > > ? 68? static final class PskIdentity { > This class can be private. > > > ? 72? public PskIdentity(byte[] identity, int obfuscatedAge) { > ? 77? public PskIdentity(ByteBuffer m) > It is not necessary to use "public" scope.? Please check other public > methods as well if existing. > > > ?111? CHPreSharedKeySpec(ByteBuffer m) > ?112????? throws IllegalParameterException, IOException { > Implementation of this method does not check the boundary of the > PreSharedKeyExtension struct. > > > ?271? ServerHandshakeContext shc = (ServerHandshakeContext) > message.handshakeContext; > It is more simple to use the context parameter rather than the message > context. > > > ?315?? shc.isResumption = false; > ?316?? shc.resumingSession = null; > ?????? ... > ?324?????? resumeSession(shc, s, idIndex); > This resets of shc.isResumption and shc.resumingSession override the set > of other extensions.? It could lead to unexpected behaviors. > > > ?675?? if (shPsk.selectedIdentity != 0) { > If only the 1st id can be use, may be don't bother to cache and request > other ids.? I'm? not very sure of it yet, need more time to think about it. > > Xuelei > > On 5/25/2018 4:45 PM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 implementation.? I >> appreciate it if I could have compatibility and specification feedback >> before May 31, 2018, and implementation feedback before June 7, 2018. >> >> Here is the webrev: >> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> The formal TLS 1.3 specification is not finalized yet, although it had >> been approved to be a standard.? The implementation is based on the >> draft version 28: >> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >> >> For the overall description of this enhancement, please refer to JEP 332: >> ???? http://openjdk.java.net/jeps/332 >> >> For the compatibility and specification update, please refer to CSR >> 8202625: >> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >> >> Note that we are using the sandbox for the development right now.? For >> more information, please refer to Bradford's previous email: >> >> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >> >> Thanks & Regards, >> Xuelei From xuelei.fan at oracle.com Mon Jun 4 04:43:02 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 3 Jun 2018 21:43:02 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> Message-ID: <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> Hi, Here it the 2nd full webrev: http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 and the delta update to the 1st webrev: http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ Xuelei On 5/25/2018 4:45 PM, Xuelei Fan wrote: > Hi, > > I'd like to invite you to review the TLS 1.3 implementation.? I > appreciate it if I could have compatibility and specification feedback > before May 31, 2018, and implementation feedback before June 7, 2018. > > Here is the webrev: > ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > The formal TLS 1.3 specification is not finalized yet, although it had > been approved to be a standard.? The implementation is based on the > draft version 28: > ??? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 > > For the overall description of this enhancement, please refer to JEP 332: > ??? http://openjdk.java.net/jeps/332 > > For the compatibility and specification update, please refer to CSR > 8202625: > ??? https://bugs.openjdk.java.net/browse/JDK-8202625 > > Note that we are using the sandbox for the development right now.? For > more information, please refer to Bradford's previous email: > > http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html > > Thanks & Regards, > Xuelei From adam.petcher at oracle.com Mon Jun 4 13:43:03 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 4 Jun 2018 09:43:03 -0400 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> Message-ID: <64f837d4-048f-0232-1c42-467c5014e0ce@oracle.com> This webrev also includes a small change I made to enable TLS 1.3 by default in the HTTP client: http://hg.openjdk.java.net/jdk/sandbox/rev/2a396fdb3afb On 6/4/2018 12:43 AM, Xuelei Fan wrote: > Hi, > > Here it the 2nd full webrev: > ? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 > > and the delta update to the 1st webrev: > ? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ > > Xuelei > > On 5/25/2018 4:45 PM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 implementation.? I >> appreciate it if I could have compatibility and specification >> feedback before May 31, 2018, and implementation feedback before June >> 7, 2018. >> >> Here is the webrev: >> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> The formal TLS 1.3 specification is not finalized yet, although it >> had been approved to be a standard.? The implementation is based on >> the draft version 28: >> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >> >> For the overall description of this enhancement, please refer to JEP >> 332: >> ???? http://openjdk.java.net/jeps/332 >> >> For the compatibility and specification update, please refer to CSR >> 8202625: >> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >> >> Note that we are using the sandbox for the development right now.? >> For more information, please refer to Bradford's previous email: >> >> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >> >> Thanks & Regards, >> Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Mon Jun 4 15:36:48 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 4 Jun 2018 08:36:48 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> Message-ID: Here are questions I have about the code before I or someone makes a change: ChangeCipherSpec.java - 69 & 200: Given this is legacy data on older version of TLS, is the exception better worded "Not supported"? "yet" implies future additions. - ChangeCipherSpec is removed in 1.3, why is there a T13 consumer ? Client/ServerHello are consuming these messages too, shouldn't their references be removed as well? Below are some changes I will make: Alert.java - optimized imports. Authenticator.java - 271-2: Clarifying comments about byte array ordering. Moved sequence number to the end - 406: static declaration for the interface is redundant ClientHandshakeContext: - 3 spelling errors Tony From xuelei.fan at oracle.com Mon Jun 4 15:50:12 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 4 Jun 2018 08:50:12 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> Message-ID: On 6/4/2018 8:36 AM, Anthony Scarpino wrote: > Here are questions I have about the code before I or someone makes a > change: > > ChangeCipherSpec.java > - 69 & 200:? Given this is legacy data on older version of TLS, is the > exception better worded "Not supported"?? "yet" implies future additions. I agreed. Would you mind update it in one of your changeset as well? > - ChangeCipherSpec is removed in 1.3, why is there a T13 consumer ? For compatibility reason, ChangeCipherSpec was back in TLS 1.3 in the recent drafts. But it is used for compatibility purposes only. See Section 5 of draft 28: An implementation may receive an unencrypted record of type change_cipher_spec consisting of the single byte value 0x01 at any time after the first ClientHello message has been sent or received and before the peer's Finished message has been received and MUST simply drop it without further processing. As JDK is using the compatibility mode, so ChangeCipherSpec has a T13 consumer. > Client/ServerHello are consuming these messages too, shouldn't their > references be removed as well? > See above. > > Below are some changes I will make: > Alert.java > - optimized imports. > > Authenticator.java > - 271-2: Clarifying comments about byte array ordering.? Moved sequence > number to the end > - 406: static declaration for the interface is redundant > > ClientHandshakeContext: > - 3 spelling errors > Thanks! Xuelei From anthony.scarpino at oracle.com Mon Jun 4 16:14:19 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 4 Jun 2018 09:14:19 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> Message-ID: <1dc24bc8-6b97-c486-b450-5070e907b150@oracle.com> On 06/04/2018 08:50 AM, Xuelei Fan wrote: > On 6/4/2018 8:36 AM, Anthony Scarpino wrote: >> Here are questions I have about the code before I or someone makes a >> change: >> >> ChangeCipherSpec.java >> - 69 & 200:? Given this is legacy data on older version of TLS, is the >> exception better worded "Not supported"?? "yet" implies future additions. > I agreed.? Would you mind update it in one of your changeset as well? > >> - ChangeCipherSpec is removed in 1.3, why is there a T13 consumer ? > For compatibility reason, ChangeCipherSpec was back in TLS 1.3 in the > recent drafts.? But it is used for compatibility purposes only.? See > Section 5 of draft 28: > ?? An implementation may receive an unencrypted record of type > ?? change_cipher_spec consisting of the single byte value 0x01 at any > ?? time after the first ClientHello message has been sent or received > ?? and before the peer's Finished message has been received and MUST > ?? simply drop it without further processing. > > As JDK is using the compatibility mode, so ChangeCipherSpec has a T13 > consumer. Ok.. thanks. I see they talk about is as "change_cipher_spec" and not ChangeCipherSpec. > >> Client/ServerHello are consuming these messages too, shouldn't their >> references be removed as well? >> > See above. > >> >> Below are some changes I will make: >> Alert.java >> - optimized imports. >> >> Authenticator.java >> - 271-2: Clarifying comments about byte array ordering.? Moved >> sequence number to the end >> - 406: static declaration for the interface is redundant >> >> ClientHandshakeContext: >> - 3 spelling errors >> Thanks! > > Xuelei From mbalao at redhat.com Mon Jun 4 22:39:07 2018 From: mbalao at redhat.com (Martin Balao) Date: Mon, 4 Jun 2018 19:39:07 -0300 Subject: RFR 6913047: SunPKCS11 memory leak In-Reply-To: References: Message-ID: Hi Valerie, 4 bugs have been fixed in Webrev 09: * http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.09/ * http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.09.zip Bug #1 ---------------------- Bug happened when re-building sensitive private DSA keys. A wrapping key -that lives in the token- is used for an encrypted extraction of the private DSA key when a token is operated in FIPS mode. NSS + legacy DB, because of internal storage constraints, uses a special key attribute called CKA_NETSCAPE_DB to store the public key associated to the private key. Previous to webrev.09, we were not reading and encoding this attribute when extracting the key so it couldn't be re-built. This problem could have potentially affected EC keys. Bug #2 ---------------------- There was a misshandling of object sessions reference counting, which was leading to leaked open sessions and closure of in-use sessions. Suppose the following case: * A key "A" was re-built in session M (P11Key.incNativeKeyRef). Session M has a key object associated, and is returned to the pool. * A session number N was obtained to perform a derivation of key "A" * Before derivation finishes, session M was closed (session N remained alive). Thus, sourceKey in "sourceKey = sftk_ObjectFromHandle(hBaseKey, session)" is NULL and CKR_KEY_HANDLE_INVALID returned. See here [1]. This was happening because when re-building key "A", the session objects number was not incremented with addObject method. Only the session for the original key had its reference counter incremented -and was, in fact, leaked-. Sessions reference counting has been simplified. When a key is destroyed (because key info is extracted out of the token), reference counter is decremented. When a key is re-built in the token, reference counter is incremented. This applies to both original and re-built keys. Bug #3 ---------------------- A session was released in P11Cipher at the end of the operation. However, session instance variable was not updated to null. Thus, session could be killed by any other object and when tried to be reused with the same P11Cipher instance, an error occurred. Bug #4 ---------------------- A P11Digest session was killed without verifying if session had objects. In addition to fixing these bugs, I did some further refactoring to align how P11Signature, P11Cipher, P11Mac and P11RSACipher classes handle initialization and finalization. Kind regards, Martin.- -- [1] - https://github.com/nss-dev/nss/blob/a66859469920b7d619f3efab7ce993579c4085fd/lib/softoken/pkcs11c.c#L6502 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue Jun 5 00:42:35 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 4 Jun 2018 17:42:35 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> Message-ID: > http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 NewSessionTicket.java --------------------- 184 if (shc.pskKeyExchangeModes.isEmpty()) { Need additional check of the requested mode. 215 if (sessionTimeoutSeconds > SEVEN_DAYS_IN_SECONDS) { 216 if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) { 217 SSLLogger.fine( 218 "Session timeout is too long. No NewSessionTicket sent."); 219 } 220 return null; 221 } It does not sound right to me that if the session timeout is too long, log and silent return for the producing side. It may involve more wider scope of session time. I need time to think more about it. RenegoInfoExtension.java ------------------------ Looks fine to me. RSAClientKeyExchange.java ------------------------- 76 // This happens in server side only. 77 ServerHandshakeContext shc = 78 (ServerHandshakeContext)handshakeContext; The 'context' can be used directly where shc is used in the method. The above lines are not strictly necessary. SSLExtension.java ----------------- 441 // TLS 1.3 PSK extension must be last 442 CH_PRE_SHARED_KEY (0x0029, "pre_shared_key", ... 449 null, null), 450 SH_PRE_SHARED_KEY (0x0029, "pre_shared_key", ... 456 null, null, null); No SSLStringize defined for the above two extensions. Nice to have them for debug logging. SessionId.java -------------- Looks fine to me. A minor comment, checking session id length after the construction looks like friable unless coding carefully. StatusResponseManager.java -------------------------- Looks fine to me. Thanks, Xuelei On 6/3/2018 9:43 PM, Xuelei Fan wrote: > Hi, > > Here it the 2nd full webrev: > ? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 > > and the delta update to the 1st webrev: > ? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ > > Xuelei > > On 5/25/2018 4:45 PM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 implementation.? I >> appreciate it if I could have compatibility and specification feedback >> before May 31, 2018, and implementation feedback before June 7, 2018. >> >> Here is the webrev: >> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> The formal TLS 1.3 specification is not finalized yet, although it had >> been approved to be a standard.? The implementation is based on the >> draft version 28: >> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >> >> For the overall description of this enhancement, please refer to JEP 332: >> ???? http://openjdk.java.net/jeps/332 >> >> For the compatibility and specification update, please refer to CSR >> 8202625: >> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >> >> Note that we are using the sandbox for the development right now.? For >> more information, please refer to Bradford's previous email: >> >> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >> >> Thanks & Regards, >> Xuelei From xuelei.fan at oracle.com Tue Jun 5 04:12:29 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 4 Jun 2018 21:12:29 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> Message-ID: <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> > http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 ClientHello.java ---------------- 1086 public void consume(ConnectionContext context, 1087 HandshakeMessage message) throws IOException { 1134 private void goServerHello(ServerHandshakeContext shc, 1135 ClientHelloMessage clientHello) throws IOException { In the TLS 1.3 consumer of the ClientHello, the session resumption is not considered and the related variables (HandshakeContext.isResumption and HandshakeContext.resumingSession) are not initialized. There is chance to set them in the pre_shared_key extension actors. But it is too later as other extensions and connection parameters may also need to check the variables for session resumption before calling the last pre_shared_key extension actors. Missing those checks may result in various unexpected issues. I will take care of this issue in the next one day or two. Xuelei On 6/3/2018 9:43 PM, Xuelei Fan wrote: > Hi, > > Here it the 2nd full webrev: > ? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 > > and the delta update to the 1st webrev: > ? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ > > Xuelei > > On 5/25/2018 4:45 PM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 implementation.? I >> appreciate it if I could have compatibility and specification feedback >> before May 31, 2018, and implementation feedback before June 7, 2018. >> >> Here is the webrev: >> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> The formal TLS 1.3 specification is not finalized yet, although it had >> been approved to be a standard.? The implementation is based on the >> draft version 28: >> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >> >> For the overall description of this enhancement, please refer to JEP 332: >> ???? http://openjdk.java.net/jeps/332 >> >> For the compatibility and specification update, please refer to CSR >> 8202625: >> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >> >> Note that we are using the sandbox for the development right now.? For >> more information, please refer to Bradford's previous email: >> >> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >> >> Thanks & Regards, >> Xuelei From jamil.j.nimeh at oracle.com Tue Jun 5 06:15:44 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 4 Jun 2018 23:15:44 -0700 Subject: [Sandbox]: ChaCha20 cipher suite prototype Message-ID: <817bdca8-1fc6-6ce7-d2a6-19ad45d2ebae@oracle.com> Hi guys, Since this is sandbox only right now and in prototype form I wanted to go ahead and put this out there so folks could see where the ChaCha20 cipher suite code was headed in the new handshaking model.? This has been tested with small webpages using openssl and Mozilla NSS (through Firefox) as a client with JDK on the server side as both a standalone server implementation and hooked into Tomcat7.? I've also used JDK as a client against openssl s_server. Disclaimer: Because of time constraints and the blocking dependency on the new TLS handshaking code, I want to be clear that putting this review out is not a commitment that this feature will make JDK 11.? I am putting this out though so folks can take a look at it and hopefully get a little ahead of the curve if there's time left to get it in after the new handshaker goes back. http://cr.openjdk.java.net/~jnimeh/reviews/tls13-cc20-ciphersuite/webrev.01 --Jamil From ecki at zusammenkunft.net Tue Jun 5 08:38:17 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 5 Jun 2018 08:38:17 +0000 Subject: [Sandbox]: ChaCha20 cipher suite prototype In-Reply-To: <817bdca8-1fc6-6ce7-d2a6-19ad45d2ebae@oracle.com> References: <817bdca8-1fc6-6ce7-d2a6-19ad45d2ebae@oracle.com> Message-ID: Jamil, I was wandering if you have performance test numbers to share yet? Do you have an internal acceptance criteria for it? Do we expect it to beat unaccelerated AES256-GCM or come close to CBC performance? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: security-dev on behalf of Jamil Nimeh Sent: Tuesday, June 5, 2018 8:15:44 AM To: OpenJDK Dev list Subject: [Sandbox]: ChaCha20 cipher suite prototype Hi guys, Since this is sandbox only right now and in prototype form I wanted to go ahead and put this out there so folks could see where the ChaCha20 cipher suite code was headed in the new handshaking model. This has been tested with small webpages using openssl and Mozilla NSS (through Firefox) as a client with JDK on the server side as both a standalone server implementation and hooked into Tomcat7. I've also used JDK as a client against openssl s_server. Disclaimer: Because of time constraints and the blocking dependency on the new TLS handshaking code, I want to be clear that putting this review out is not a commitment that this feature will make JDK 11. I am putting this out though so folks can take a look at it and hopefully get a little ahead of the curve if there's time left to get it in after the new handshaker goes back. http://cr.openjdk.java.net/~jnimeh/reviews/tls13-cc20-ciphersuite/webrev.01 --Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Jun 5 13:54:42 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 5 Jun 2018 21:54:42 +0800 Subject: HelloCookieManager.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> Message-ID: <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> HelloCookieManager.java: 44 HelloCookieManager(SecureRandom secureRandom) { 45 this.secureRandom = secureRandom; 46 } 47 48 HelloCookieManager valueOf(ProtocolVersion protocolVersion) { Why not just create a static method and make HelloCookieManager abstract? static HelloCookieManager of(SecureRandom secureRandom, ProtocolVersion protocolVersion) I haven't seen "raw" HelloCookieManager used anywhere. Also, if createCookie() and isCookieValid() are only called on the server side, why not always use ServerHandshakeContext? Thanks Max > On Jun 5, 2018, at 12:12 PM, Xuelei Fan wrote: > > > http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 From jamil.j.nimeh at oracle.com Tue Jun 5 14:16:39 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 5 Jun 2018 07:16:39 -0700 Subject: [Sandbox]: ChaCha20 cipher suite prototype In-Reply-To: References: <817bdca8-1fc6-6ce7-d2a6-19ad45d2ebae@oracle.com> Message-ID: Hi Bernd, I do have some perf numbers, but I haven't done a lot of comparisons yet against other algs like AES-GCM and CBC.? It would be a good idea to get those numbers before I release what I have so far. --Jamil On 6/5/2018 1:38 AM, Bernd Eckenfels wrote: > Jamil, I was wandering if you have performance test numbers to share > yet? Do you have an internal acceptance criteria for it? Do we expect > it to beat unaccelerated AES256-GCM or come close to CBC performance? > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > *From:* security-dev on behalf > of Jamil Nimeh > *Sent:* Tuesday, June 5, 2018 8:15:44 AM > *To:* OpenJDK Dev list > *Subject:* [Sandbox]: ChaCha20 cipher suite prototype > Hi guys, > > Since this is sandbox only right now and in prototype form I wanted to > go ahead and put this out there so folks could see where the ChaCha20 > cipher suite code was headed in the new handshaking model. This has > been tested with small webpages using openssl and Mozilla NSS (through > Firefox) as a client with JDK on the server side as both a standalone > server implementation and hooked into Tomcat7.? I've also used JDK as a > client against openssl s_server. > > Disclaimer: Because of time constraints and the blocking dependency on > the new TLS handshaking code, I want to be clear that putting this > review out is not a commitment that this feature will make JDK 11.? I am > putting this out though so folks can take a look at it and hopefully get > a little ahead of the curve if there's time left to get it in after the > new handshaker goes back. > > http://cr.openjdk.java.net/~jnimeh/reviews/tls13-cc20-ciphersuite/webrev.01 > > > --Jamil > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue Jun 5 18:54:33 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 5 Jun 2018 11:54:33 -0700 Subject: HelloCookieManager.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> Message-ID: <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> Update: http://hg.openjdk.java.net/jdk/sandbox/rev/ec5537b61038 Note that the above changeset will be included in next webrev for further code review. On 6/5/2018 6:54 AM, Weijun Wang wrote: > HelloCookieManager.java: > > 44 HelloCookieManager(SecureRandom secureRandom) { > 45 this.secureRandom = secureRandom; > 46 } > 47 > 48 HelloCookieManager valueOf(ProtocolVersion protocolVersion) { > > Why not just create a static method and make HelloCookieManager abstract? > > static HelloCookieManager of(SecureRandom secureRandom, ProtocolVersion protocolVersion) > > I haven't seen "raw" HelloCookieManager used anywhere. > For every SSLContext, the SecureRandom may be different, so we need a different HelloCookieManager instance and cookie managers for each SSLContext instance: SSLContextImpl.java ------------------- 253 helloCookieManager = new HelloCookieManager(secureRandom); > Also, if createCookie() and isCookieValid() are only called on the server side, why not always use ServerHandshakeContext? > Good point! I made the update in the changeset above. Thanks, Xuelei > Thanks > Max > > > >> On Jun 5, 2018, at 12:12 PM, Xuelei Fan wrote: >> >>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 > From weijun.wang at oracle.com Wed Jun 6 03:04:02 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 6 Jun 2018 11:04:02 +0800 Subject: Module-info.hava (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> Message-ID: <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> module-info.java in java.base and java.security.jgss look fine. There are other codes in java.security.jgss related to the JSSE krb5 ciphersuites. Do you want me to add a chanegset to the sandbox for a cleanup? Thanks Max > > > >> On Jun 5, 2018, at 12:12 PM, Xuelei Fan wrote: >> >>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 > From weijun.wang at oracle.com Wed Jun 6 03:48:34 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 6 Jun 2018 11:48:34 +0800 Subject: HelloCookieManager.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> Message-ID: > On 6/5/2018 6:54 AM, Weijun Wang wrote: >> HelloCookieManager.java: >> 44 HelloCookieManager(SecureRandom secureRandom) { >> 45 this.secureRandom = secureRandom; >> 46 } >> 47 >> 48 HelloCookieManager valueOf(ProtocolVersion protocolVersion) { >> Why not just create a static method and make HelloCookieManager abstract? >> static HelloCookieManager of(SecureRandom secureRandom, ProtocolVersion protocolVersion) >> I haven't seen "raw" HelloCookieManager used anywhere. > For every SSLContext, the SecureRandom may be different, so we need a different HelloCookieManager instance and cookie managers for each SSLContext instance: > > SSLContextImpl.java > ------------------- > 253 helloCookieManager = new HelloCookieManager(secureRandom); So the main benefit of the current implementation is that once a HelloCookieManager is created you can reuse the 3 child HelloCookieManager objects inside it. Right? If so, I'm OK with the current structure. My major concern is, since the "base" HelloCookieManager is never useful we should take great care not to create an instance of it. How about this? 1. Make HelloCookieManager abstract. 2. Create an non-abstract inner class HelloCookieManager$Builder and move the 3 real instances there. 3. Inside SSLContextImpl, store a field of HelloCookieManager$Builder, and in getHelloCookieManager(), call "builder.get(protocolVersion)" to return one of the 3 real instances. If the reuse of the 3 real instances is not a big benefit, you can just make HelloCookieManager abstract and create a new child instance in every getHelloCookieManager() call. Anyway, I feel uncomfortable that the base HelloCookieManager class can be instantiated. Thanks Max >>> On Jun 5, 2018, at 12:12 PM, Xuelei Fan wrote: >>> >>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 From weijun.wang at oracle.com Wed Jun 6 05:37:43 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 6 Jun 2018 13:37:43 +0800 Subject: RandomCookie.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> Message-ID: RandomCookie.java: + private boolean isT12Downgrade() { + return Arrays.equals(randomBytes, 24, 31, t12Protection, 0, 7); + } + + private boolean isT11Downgrade() { + return Arrays.equals(randomBytes, 24, 31, t11Protection, 0, 7); + } The "to" in Arrays::equals is exclusive, so please update 31 -> 32, 7 -> 8. Also, at the end of https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.1.3 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH Implementations of draft versions (see Section 4.2.1.1) of this specification SHOULD NOT implement this mechanism on either client and server. A pre-RFC client connecting to RFC servers, or vice versa, will appear to downgrade to TLS 1.2. With the mechanism enabled, this will cause an interoperability failure. Has the current implementation implemented (and turned on) this mechanism? Thanks Max > > >>>> On Jun 5, 2018, at 12:12 PM, Xuelei Fan wrote: >>>> >>>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 > From weijun.wang at oracle.com Wed Jun 6 05:41:40 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 6 Jun 2018 13:41:40 +0800 Subject: Module-info.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> Message-ID: <53FFA825-DB0C-44A5-AFB5-DC14397848FB@oracle.com> Here is the proposed code change http://cr.openjdk.java.net/~weijun/9999999/webrev.jgss.cleanup/ Please take a review. Thanks Max > On Jun 6, 2018, at 11:04 AM, Weijun Wang wrote: > > module-info.java in java.base and java.security.jgss look fine. > > There are other codes in java.security.jgss related to the JSSE krb5 ciphersuites. Do you want me to add a chanegset to the sandbox for a cleanup? > > Thanks > Max > >> >> >> >>> On Jun 5, 2018, at 12:12 PM, Xuelei Fan wrote: >>> >>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >> > From weijun.wang at oracle.com Wed Jun 6 10:58:05 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 6 Jun 2018 18:58:05 +0800 Subject: SSLStringize.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> Message-ID: <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> SSLStringize.java: 1. I assume the toString() method does not change the internal status of a ByteBuffer? Is it worth mentioning this in the spec? 2. Should this interface and all its implementations be renamed to ***Stringnizer? 3. Lot of typo: ***Concumer. You can probably "cd sun/security/ssl" and run perl -i -pe 's/Concumer/Consumer/g' *.java The whole SSLStringize + children classes looks complicated to me. Since the implementation is almost always creating a SSLExtensionSpec object and calling its toString, is it possible to register this SSLExtensionSpec class name in each enum value in SSLExtension and somehow simplify the design? Something like -- In constructor of SSLExtension, change the last parameter from "SSLStringize stringize" to "Class specClazz" store the value into a private field named specClazz, and then you can change "stringize.toString(byteBuffer)" to something like "specClazz.newInstance(byteBuffer).toString()". That said, I know you must have thought about this much more. If there is any space for enhancement, we can always refactor it later. Thanks Max From weijun.wang at oracle.com Wed Jun 6 12:41:07 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 6 Jun 2018 20:41:07 +0800 Subject: SSLLogger.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> Message-ID: <12F8F4BF-F46C-4F0C-ABC2-162D1BADBCF1@oracle.com> There are lots of calls like RSAClientKeyExchangeMessage ckem = new RSAClientKeyExchangeMessage(shc, message); if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) { SSLLogger.fine( "Consuming RSA ClientKeyExchange handshake message", ckem); } which finally calls to String formatted = SSLSimpleFormatter.formatParameters(params); logger.log(level, msg, formatted); Now that msg contains no placeholder likes "{0}", nothing on temporary will be shown. Am I understanding this correctly? Thanks Max From xuelei.fan at oracle.com Wed Jun 6 14:26:29 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 6 Jun 2018 07:26:29 -0700 Subject: Module-info.hava (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> Message-ID: <887fdcc9-6171-476e-99e2-cf83896ae8a5@oracle.com> On 6/5/2018 8:04 PM, Weijun Wang wrote: > module-info.java in java.base and java.security.jgss look fine. > > There are other codes in java.security.jgss related to the JSSE krb5 ciphersuites. Do you want me to add a chanegset to the sandbox for a cleanup? > Yes, please! Xuelei > Thanks > Max > >> >> >> >>> On Jun 5, 2018, at 12:12 PM, Xuelei Fan wrote: >>> >>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >> > From xuelei.fan at oracle.com Wed Jun 6 14:40:25 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 6 Jun 2018 07:40:25 -0700 Subject: HelloCookieManager.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> Message-ID: <869a1707-dc45-dbd2-0270-914a4a23d55b@oracle.com> On 6/5/2018 8:48 PM, Weijun Wang wrote: >> On 6/5/2018 6:54 AM, Weijun Wang wrote: >>> HelloCookieManager.java: >>> 44 HelloCookieManager(SecureRandom secureRandom) { >>> 45 this.secureRandom = secureRandom; >>> 46 } >>> 47 >>> 48 HelloCookieManager valueOf(ProtocolVersion protocolVersion) { >>> Why not just create a static method and make HelloCookieManager abstract? >>> static HelloCookieManager of(SecureRandom secureRandom, ProtocolVersion protocolVersion) >>> I haven't seen "raw" HelloCookieManager used anywhere. >> For every SSLContext, the SecureRandom may be different, so we need a different HelloCookieManager instance and cookie managers for each SSLContext instance: >> >> SSLContextImpl.java >> ------------------- >> 253 helloCookieManager = new HelloCookieManager(secureRandom); > > So the main benefit of the current implementation is that once a HelloCookieManager is created you can reuse the 3 child HelloCookieManager objects inside it. Right? > Yes. > If so, I'm OK with the current structure. I see you concerns. The structure looks weird in some sense, although it is easier for a package private class. Let me see if I can make an update in the next changeset. Thanks, Xuelei > My major concern is, since the "base" HelloCookieManager is never useful we should take great care not to create an instance of it. How about this? > > 1. Make HelloCookieManager abstract. > > 2. Create an non-abstract inner class HelloCookieManager$Builder and move the 3 real instances there. > > 3. Inside SSLContextImpl, store a field of HelloCookieManager$Builder, and in getHelloCookieManager(), call "builder.get(protocolVersion)" to return one of the 3 real instances. > > > If the reuse of the 3 real instances is not a big benefit, you can just make HelloCookieManager abstract and create a new child instance in every getHelloCookieManager() call. > > Anyway, I feel uncomfortable that the base HelloCookieManager class can be instantiated. > > Thanks > Max > > >>>> On Jun 5, 2018, at 12:12 PM, Xuelei Fan wrote: >>>> >>>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 > From Xuelei.Fan at Oracle.Com Wed Jun 6 15:17:49 2018 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Wed, 6 Jun 2018 08:17:49 -0700 Subject: Module-info.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <53FFA825-DB0C-44A5-AFB5-DC14397848FB@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> <53FFA825-DB0C-44A5-AFB5-DC14397848FB@oracle.com> Message-ID: Looks fine to me. Thanks, Xuelei > On Jun 5, 2018, at 10:41 PM, Weijun Wang wrote: > > Here is the proposed code change > > http://cr.openjdk.java.net/~weijun/9999999/webrev.jgss.cleanup/ > > Please take a review. > > Thanks > Max > >> On Jun 6, 2018, at 11:04 AM, Weijun Wang wrote: >> >> module-info.java in java.base and java.security.jgss look fine. >> >> There are other codes in java.security.jgss related to the JSSE krb5 ciphersuites. Do you want me to add a chanegset to the sandbox for a cleanup? >> >> Thanks >> Max >> >>> >>> >>> >>>>> On Jun 5, 2018, at 12:12 PM, Xuelei Fan wrote: >>>>> >>>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >>> >> > From xuelei.fan at oracle.com Wed Jun 6 16:19:00 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 6 Jun 2018 09:19:00 -0700 Subject: RandomCookie.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> Message-ID: <8f2dc56a-f86d-6f76-626b-c570a196a34a@oracle.com> On 6/5/2018 10:37 PM, Weijun Wang wrote: > RandomCookie.java: > > + private boolean isT12Downgrade() { > + return Arrays.equals(randomBytes, 24, 31, t12Protection, 0, 7); > + } > + > + private boolean isT11Downgrade() { > + return Arrays.equals(randomBytes, 24, 31, t11Protection, 0, 7); > + } > > The "to" in Arrays::equals is exclusive, so please update 31 -> 32, 7 -> 8. > Good catch! > Also, at the end of https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.1.3 > > RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH Implementations of > draft versions (see Section 4.2.1.1) of this specification SHOULD NOT > implement this mechanism on either client and server. A pre-RFC > client connecting to RFC servers, or vice versa, will appear to > downgrade to TLS 1.2. With the mechanism enabled, this will cause an > interoperability failure. > > Has the current implementation implemented (and turned on) this mechanism? > Yes, the mechanism is turned on. Thanks, Xuelei > Thanks > Max > >> >> >>>>> On Jun 5, 2018, at 12:12 PM, Xuelei Fan wrote: >>>>> >>>>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >> > From xuelei.fan at oracle.com Wed Jun 6 16:27:57 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 6 Jun 2018 09:27:57 -0700 Subject: SSLLogger.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <12F8F4BF-F46C-4F0C-ABC2-162D1BADBCF1@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> <12F8F4BF-F46C-4F0C-ABC2-162D1BADBCF1@oracle.com> Message-ID: On 6/6/2018 5:41 AM, Weijun Wang wrote: > There are lots of calls like > > RSAClientKeyExchangeMessage ckem = > new RSAClientKeyExchangeMessage(shc, message); > if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) { > SSLLogger.fine( > "Consuming RSA ClientKeyExchange handshake message", ckem); > } > > which finally calls to > > String formatted = > SSLSimpleFormatter.formatParameters(params); > logger.log(level, msg, formatted); > > Now that msg contains no placeholder likes "{0}", nothing on temporary will be shown. > I did not catch you here. SSLSimpleFormatter is a package private class (SSLLogger#SSLSimpleFormatter), which does not use placeholder in msg. Thanks, Xuelei > Am I understanding this correctly? > > Thanks > Max > From xuelei.fan at oracle.com Wed Jun 6 16:41:20 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 6 Jun 2018 09:41:20 -0700 Subject: RandomCookie.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <8f2dc56a-f86d-6f76-626b-c570a196a34a@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <8f2dc56a-f86d-6f76-626b-c570a196a34a@oracle.com> Message-ID: <702f6557-027b-712b-84b0-81d08582bdd1@oracle.com> Update: http://hg.openjdk.java.net/jdk/sandbox/rev/cf2370de8673 This update will be included in the next webrev for further code review if needed. Thanks, Xuelei On 6/6/2018 9:19 AM, Xuelei Fan wrote: > On 6/5/2018 10:37 PM, Weijun Wang wrote: >> RandomCookie.java: >> >> +??? private boolean isT12Downgrade() { >> +??????? return Arrays.equals(randomBytes, 24, 31, t12Protection, 0, 7); >> +??? } >> + >> +??? private boolean isT11Downgrade() { >> +??????? return Arrays.equals(randomBytes, 24, 31, t11Protection, 0, 7); >> +??? } >> >> The "to" in Arrays::equals is exclusive, so please update 31 -> 32, 7 >> -> 8. >> > Good catch! From adam.petcher at oracle.com Wed Jun 6 18:35:18 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 6 Jun 2018 14:35:18 -0400 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <64f837d4-048f-0232-1c42-467c5014e0ce@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <64f837d4-048f-0232-1c42-467c5014e0ce@oracle.com> Message-ID: <2b782d33-f842-b867-0bad-27a7d7c466f1@oracle.com> On 6/4/2018 9:43 AM, Adam Petcher wrote: > This webrev also includes a small change I made to enable TLS 1.3 by > default in the HTTP client: > > http://hg.openjdk.java.net/jdk/sandbox/rev/2a396fdb3afb This change has been backed out. The default TLS version in the HTTP client will be addressed later. http://hg.openjdk.java.net/jdk/sandbox/rev/89bfd8e0ff19 -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Wed Jun 6 20:11:56 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 6 Jun 2018 13:11:56 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <131b1645-d297-f39b-f119-97b0eaa77c44@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <131b1645-d297-f39b-f119-97b0eaa77c44@oracle.com> Message-ID: I can make the below changes if they are accepted. Tony ------ InputRecord.java - Optimize Imports - fragmentSize appears not to be used. It is constructed, it can be set by changeFragmentSize. MaxFragExtension even calls these methods, but no where can I find that uses the fragmentSize. It appears the fragment sizes are either calculated in the SSLCipher or the negotiatedMaxFragLen is used in the handshakeSession. 65: getHelloVersion() is unused - For the below, I would assume integer overflow isn't an issue since these are all internal APIs and the worse we would see is an Out of Bounds exception 337: for (int i = offset, j = 0; 338: i < (offset + length) && j < headerSize; i++) { 359: for (int i = offset; i < offset + length; i++) { 373: for (int i = offset; i < offset + length; i++) { DTLSInputRecord.java - Optimize Imports 102 } else if (srcsLength == 1) { 103 return decode(srcs[srcsOffset]); shouldn't it be decode(srcs[0]); otherwise it could be out of bounds. SSLEngineInputRecord.java - Optimize Imports 41: prevType never used 347: srcLimit never used 42 & 43: hsMsgOff and hsMsgLim are set to 0 and never change, later they are used in a check with themselves: 232: if ( ... && hsMsgOff != hsMsgLen) { SSLSocketInputRecord.java - Optimize Imports 47: prevType never used 48 & 49: nsMsgOff and hsMsgLim are set to 0 and never change, later they are used in a check with themselves: 266: if ( ... && hsMsgOff != hsMsgLen) { From valerie.peng at oracle.com Wed Jun 6 21:16:17 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 6 Jun 2018 14:16:17 -0700 Subject: RFR JDK-8178374: Problematic ByteBuffer handling in CipherSpi.bufferCrypt method Message-ID: Hi Tony, Can you please help reviewing this fix? The original impl uses buffering for both input and output and is broken in several places. I ended up re-writing most of them. The buffering is done only on input. The new regression test covers all 4 combination of input/output ByteBuffers as well as various sizes. Webrev: http://cr.openjdk.java.net/~valeriep/8178374/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8178374 Thanks, Valerie From valerie.peng at oracle.com Wed Jun 6 21:26:46 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 6 Jun 2018 14:26:46 -0700 Subject: RFR 6913047: SunPKCS11 memory leak In-Reply-To: References: Message-ID: Hi Martin, Thanks for the update. I will try the updated webrev out and see if the failed regression tests now pass. Sorry that my cycles for reviewing your patches for JDK-6913047 and JDK-8029661 are somewhat limited due to current project priorities. I will return to work on them as soon as I have time. Regards, Valerie On 6/4/2018 3:39 PM, Martin Balao wrote: > Hi Valerie, > > 4 bugs have been fixed in Webrev 09: > > ?* > http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.09/ > > > ?* > http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.09.zip > > > Bug #1 > ---------------------- > > Bug happened when re-building sensitive private DSA keys. A wrapping > key -that lives in the token- is used for an encrypted extraction of > the private DSA key when a token is operated in FIPS mode. NSS + > legacy DB, because of internal storage constraints, uses a special key > attribute called CKA_NETSCAPE_DB to store the public key associated to > the private key. Previous to webrev.09, we were not reading and > encoding this attribute when extracting the key so it couldn't be > re-built. This problem could have potentially affected EC keys. > > Bug #2 > ---------------------- > > There was a misshandling of object sessions reference counting, which > was leading to leaked open sessions and closure of in-use sessions. > > Suppose the following case: > ?* A key "A" was re-built in session M (P11Key.incNativeKeyRef). > Session M has a key object associated, and is returned to the pool. > ?* A session number N was obtained to perform a derivation of key "A" > ?* Before derivation finishes, session M was closed (session N > remained alive). Thus, sourceKey in "sourceKey = > sftk_ObjectFromHandle(hBaseKey, session)" is NULL and > CKR_KEY_HANDLE_INVALID returned. See here [1]. This was happening > because when re-building key "A", the session objects number was not > incremented with addObject method. Only the session for the original > key had its reference counter incremented -and was, in fact, leaked-. > > Sessions reference counting has been simplified. When a key is > destroyed (because key info is extracted out of the token), reference > counter is decremented. When a key is re-built in the token, reference > counter is incremented. This applies to both original and re-built keys. > > Bug #3 > ---------------------- > > A session was released in P11Cipher at the end of the operation. > However, session instance variable was not updated to null. Thus, > session could be killed by any other object and when tried to be > reused with the same P11Cipher instance, an error occurred. > > Bug #4 > ---------------------- > > A P11Digest session was killed without verifying if session had objects. > > In addition to fixing these bugs, I did some further refactoring to > align how P11Signature, P11Cipher, P11Mac and P11RSACipher classes > handle initialization and finalization. > > Kind regards, > Martin.- > > -- > [1] - > https://github.com/nss-dev/nss/blob/a66859469920b7d619f3efab7ce993579c4085fd/lib/softoken/pkcs11c.c#L6502 From jamil.j.nimeh at oracle.com Wed Jun 6 22:19:03 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 6 Jun 2018 15:19:03 -0700 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: <0419f803-e67c-074c-ff02-f0d45326d3b4@oracle.com> References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> <0419f803-e67c-074c-ff02-f0d45326d3b4@oracle.com> Message-ID: Hello, comments below, minor stuff for the most part: * KeyUpdate.java o 128-129: Spelling nit: REQUSTED --> REQUESTED o That change will have to get sprinkled throughout the code * OutputRecord.java o 291-295: It seems like using an absolute put would simplify this code a bit:? Just advance the destination limit by one like you're already doing, then destination.put(destination.limit() - 1, contentType);? Or you can set an int variable to destination.limit() before you make the limit one larger and then use that as the first argument to the absolute put.? Either way you don't need to move your position marker forward and backward. + I know absolute puts are not guaranteed to be implemented, but they are used further down on line 312, 317-318 so I think we're safe here. * SSLEngineOutputRecord.java o Looks good to me * SSLSocketOutputRecord.java o 315: REQUSTED -> REQUESTED o Looks okay otherwise * DTLSOutputRecord o 68: Do we need to hang onto this for now, or can we remove this commented out line? o Otherwise looks OK. More on the way... --Jamil On 02/22/2018 12:29 PM, Xuelei Fan wrote: > Updated to use package private HKDF implementation. > > webrev (based on JDK-8185576): > ????? http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.01 > > webrev (including JDK-8185576): > ????? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 > > Thanks, > Xuelei > > On 2/20/2018 11:57 AM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 full handshake >> implementation.? I appreciate it if I could have feedback before >> March 9, 2018. >> >> In the "JDK-8185576: New handshake implementation" [1] code review >> around, I was trying to re-org the TLS handshaking implementation in the >> SunJSSE provider.? If you had reviewed that part, you can start from >> the following webrev that based on the update of JDK-8185576: >> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.00 >> >> If you would like start from earlier, here is the webrev that >> contains the handshaking implementation re-org in JDK-8185576: >> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> >> This changeset only implements the full handshake of TLS 1.3, rather >> then a fully implementation of the latest TLS 1.3 draft [2]. >> >> In this implementation, I removed: >> 1. the KRB5 cipher suite implementation. >> Please let me know if you are still using KRB5 cipher suite.? I may >> not add them back if no objections. >> >> 2. OCSP stapling. >> This feature will be added back later. >> >> Resumption and key update, and more features may be added later. >> >> Thanks & Regards, >> Xuelei >> >> [1]: >> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016642.html >> >> [2]: https://tools.ietf.org/html/draft-ietf-tls-tls13-24 -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Jun 6 23:21:50 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 7 Jun 2018 07:21:50 +0800 Subject: SSLLogger.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> <12F8F4BF-F46C-4F0C-ABC2-162D1BADBCF1@oracle.com> Message-ID: > On Jun 7, 2018, at 12:27 AM, Xuelei Fan wrote: > > On 6/6/2018 5:41 AM, Weijun Wang wrote: >> There are lots of calls like >> RSAClientKeyExchangeMessage ckem = >> new RSAClientKeyExchangeMessage(shc, message); >> if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) { >> SSLLogger.fine( >> "Consuming RSA ClientKeyExchange handshake message", ckem); >> } >> which finally calls to >> String formatted = >> SSLSimpleFormatter.formatParameters(params); >> logger.log(level, msg, formatted); >> Now that msg contains no placeholder likes "{0}", nothing on temporary will be shown. > I did not catch you here. SSLSimpleFormatter is a package private class (SSLLogger#SSLSimpleFormatter), which does not use placeholder in msg. I see. BTW, at the beginning of SSLLogger, there is String p = GetPropertyAction.privilegedGetProperty("javax.net.debug"); if (p != null) { if (p.isEmpty()) { property = ""; logger = System.getLogger("javax.net.ssl"); } else { Will this "p.isEmpty()" ever happen? I cannot find a place when only SSLLogger.isOn is checked but not SSLLogger.isOn("something"). Thanks Max > > Thanks, > Xuelei > >> Am I understanding this correctly? >> Thanks >> Max From xuelei.fan at oracle.com Thu Jun 7 00:19:00 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 6 Jun 2018 17:19:00 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <131b1645-d297-f39b-f119-97b0eaa77c44@oracle.com> Message-ID: <87410cd9-da48-7377-912d-b8096eca0861@oracle.com> On 6/6/2018 1:11 PM, Anthony Scarpino wrote: > I can make the below changes if they are accepted. > Please take care of the update, except the fragmentSize for InputRecord.java. > Tony > ------ > > InputRecord.java > - Optimize Imports > - fragmentSize appears not to be used.? It is constructed, > it can be set by changeFragmentSize.? MaxFragExtension even calls these > methods, but no where can I find that uses the fragmentSize.? It appears > the fragment sizes are either calculated in the SSLCipher or the > negotiatedMaxFragLen is used in the handshakeSession. > I need more time for this point. > 65: getHelloVersion() is unused > > - For the below, I would assume integer overflow isn't an issue since > these are all internal APIs and the worse we would see is an Out of > Bounds exception > > 337:?? for (int i = offset, j = 0; > 338:??????? i < (offset + length) && j < headerSize; i++) { > > 359:??????? for (int i = offset; i < offset + length; i++) { > > 373:??????? for (int i = offset; i < offset + length; i++) { > Yes. These integers have been checked before calling into this method. > > > DTLSInputRecord.java > - Optimize Imports > 102???????? } else if (srcsLength == 1) { > 103???????????? return decode(srcs[srcsOffset]); > > shouldn't it be decode(srcs[0]); otherwise it could be out of bounds. > The 'srcsLength' refer to the length from the offset. I think srcsOffset should be used as the index. > > > SSLEngineInputRecord.java > - Optimize Imports > 41:? prevType never used > 347: srcLimit never used > > 42 & 43:? hsMsgOff and hsMsgLim are set to 0 and never change, later > they are used in a check with themselves: > ???? 232:? if ( ... && hsMsgOff != hsMsgLen) { > I missed the cleanup. hsMsgOff and hsMsgLen are not used any more. "hsMsgOff != hsMsgLen" may be replaced with something like handshakeBuffer.hasRemaining() or similar. > > > SSLSocketInputRecord.java > - Optimize Imports > 47: prevType never used > 48 & 49:? nsMsgOff and hsMsgLim are set to 0 and never change, later > they are used in a check with themselves: > ???? 266:? if ( ... && hsMsgOff != hsMsgLen) { > As above. Thanks, Xuelei From xuelei.fan at oracle.com Thu Jun 7 00:41:20 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 6 Jun 2018 17:41:20 -0700 Subject: SSLLogger.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> <12F8F4BF-F46C-4F0C-ABC2-162D1BADBCF1@oracle.com> Message-ID: <7f438619-0555-4860-63a3-ffd6270da97b@oracle.com> On 6/6/2018 4:21 PM, Weijun Wang wrote: > > >> On Jun 7, 2018, at 12:27 AM, Xuelei Fan wrote: >> >> On 6/6/2018 5:41 AM, Weijun Wang wrote: >>> There are lots of calls like >>> RSAClientKeyExchangeMessage ckem = >>> new RSAClientKeyExchangeMessage(shc, message); >>> if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) { >>> SSLLogger.fine( >>> "Consuming RSA ClientKeyExchange handshake message", ckem); >>> } >>> which finally calls to >>> String formatted = >>> SSLSimpleFormatter.formatParameters(params); >>> logger.log(level, msg, formatted); >>> Now that msg contains no placeholder likes "{0}", nothing on temporary will be shown. >> I did not catch you here. SSLSimpleFormatter is a package private class (SSLLogger#SSLSimpleFormatter), which does not use placeholder in msg. > > I see. > > BTW, at the beginning of SSLLogger, there is > > String p = GetPropertyAction.privilegedGetProperty("javax.net.debug"); > if (p != null) { > if (p.isEmpty()) { > property = ""; > logger = System.getLogger("javax.net.ssl"); > } else { > > Will this "p.isEmpty()" ever happen? I cannot find a place when only SSLLogger.isOn is checked but not SSLLogger.isOn("something"). > If p.isEmpty(), SSLLogger.isOn("something") always returns true. It means that 'something" (ssl, handshake, etc) is not used to control the debug level any more. Instead, the System.Logger levels (FINE, WARNING, etc) get used instead. Xuelei From xuelei.fan at oracle.com Thu Jun 7 00:44:26 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 6 Jun 2018 17:44:26 -0700 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> <0419f803-e67c-074c-ff02-f0d45326d3b4@oracle.com> Message-ID: <4efe36b1-a032-23c9-914d-fbe124410eb5@oracle.com> Hi Jamil, All good catches to me. Would you mind take care of the update as well? Thanks, Xuelei On 6/6/2018 3:19 PM, Jamil Nimeh wrote: > Hello, comments below, minor stuff for the most part: > > * KeyUpdate.java > o 128-129: Spelling nit: REQUSTED --> REQUESTED > o That change will have to get sprinkled throughout the code > * OutputRecord.java > o 291-295: It seems like using an absolute put would simplify this > code a bit:? Just advance the destination limit by one like > you're already doing, then destination.put(destination.limit() - > 1, contentType);? Or you can set an int variable to > destination.limit() before you make the limit one larger and > then use that as the first argument to the absolute put.? Either > way you don't need to move your position marker forward and > backward. > + I know absolute puts are not guaranteed to be implemented, > but they are used further down on line 312, 317-318 so I > think we're safe here. > * SSLEngineOutputRecord.java > o Looks good to me > * SSLSocketOutputRecord.java > o 315: REQUSTED -> REQUESTED > o Looks okay otherwise > * DTLSOutputRecord > o 68: Do we need to hang onto this for now, or can we remove this > commented out line? > o Otherwise looks OK. > > More on the way... > > --Jamil > > > On 02/22/2018 12:29 PM, Xuelei Fan wrote: >> Updated to use package private HKDF implementation. >> >> webrev (based on JDK-8185576): >> http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.01 >> >> webrev (including JDK-8185576): >> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >> >> Thanks, >> Xuelei >> >> On 2/20/2018 11:57 AM, Xuelei Fan wrote: >>> Hi, >>> >>> I'd like to invite you to review the TLS 1.3 full handshake >>> implementation.? I appreciate it if I could have feedback before >>> March 9, 2018. >>> >>> In the "JDK-8185576: New handshake implementation" [1] code review >>> around, I was trying to re-org the TLS handshaking implementation in the >>> SunJSSE provider.? If you had reviewed that part, you can start from >>> the following webrev that based on the update of JDK-8185576: >>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.00 >>> >>> If you would like start from earlier, here is the webrev that >>> contains the handshaking implementation re-org in JDK-8185576: >>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>> >>> >>> This changeset only implements the full handshake of TLS 1.3, rather >>> then a fully implementation of the latest TLS 1.3 draft [2]. >>> >>> In this implementation, I removed: >>> 1. the KRB5 cipher suite implementation. >>> Please let me know if you are still using KRB5 cipher suite.? I may >>> not add them back if no objections. >>> >>> 2. OCSP stapling. >>> This feature will be added back later. >>> >>> Resumption and key update, and more features may be added later. >>> >>> Thanks & Regards, >>> Xuelei >>> >>> [1]: >>> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016642.html >>> >>> [2]: https://tools.ietf.org/html/draft-ietf-tls-tls13-24 > From bradford.wetmore at oracle.com Thu Jun 7 00:45:11 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 6 Jun 2018 17:45:11 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> Message-ID: Today, I looked over SunJSSE.java, Utilities.java, and module-info.java. Mostly nits below, some style things. Utilities.java -------------- 39: hexDigits can be private. 42: Extra level of indent. 4 or 8. 39-41: Nits: When variables are static finals, they are usually written uppercase. 115: Extra " " and can we get SNI cap'd? HostName for server name indication -> HostName for Server Name Indication 150: Minor Nit: You're concating ("+") and then using StringBuilder.append(), instead of simply append chaining which might be slightly more efficient. 167-217: The code looks ok, but this might be reworked to take better advantage of StringBuilder.append() chaining, rather than the mix of concat and append here now. e.g. what you did with toHexString(long). I see much of the same code repeated over and over here. Can be done later. Brad On 6/3/2018 9:43 PM, Xuelei Fan wrote: > Hi, > > Here it the 2nd full webrev: > ? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 > > and the delta update to the 1st webrev: > ? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ > > Xuelei > > On 5/25/2018 4:45 PM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 implementation.? I >> appreciate it if I could have compatibility and specification feedback >> before May 31, 2018, and implementation feedback before June 7, 2018. >> >> Here is the webrev: >> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> The formal TLS 1.3 specification is not finalized yet, although it had >> been approved to be a standard.? The implementation is based on the >> draft version 28: >> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >> >> For the overall description of this enhancement, please refer to JEP 332: >> ???? http://openjdk.java.net/jeps/332 >> >> For the compatibility and specification update, please refer to CSR >> 8202625: >> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >> >> Note that we are using the sandbox for the development right now.? For >> more information, please refer to Bradford's previous email: >> >> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >> >> Thanks & Regards, >> Xuelei From weijun.wang at oracle.com Thu Jun 7 00:46:22 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 7 Jun 2018 08:46:22 +0800 Subject: SSLLogger.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <7f438619-0555-4860-63a3-ffd6270da97b@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> <12F8F4BF-F46C-4F0C-ABC2-162D1BADBCF1@oracle.com> <7f438619-0555-4860-63a3-ffd6270da97b@oracle.com> Message-ID: > On Jun 7, 2018, at 8:41 AM, Xuelei Fan wrote: > > > > On 6/6/2018 4:21 PM, Weijun Wang wrote: >>> On Jun 7, 2018, at 12:27 AM, Xuelei Fan wrote: >>> >>> On 6/6/2018 5:41 AM, Weijun Wang wrote: >>>> There are lots of calls like >>>> RSAClientKeyExchangeMessage ckem = >>>> new RSAClientKeyExchangeMessage(shc, message); >>>> if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) { >>>> SSLLogger.fine( >>>> "Consuming RSA ClientKeyExchange handshake message", ckem); >>>> } >>>> which finally calls to >>>> String formatted = >>>> SSLSimpleFormatter.formatParameters(params); >>>> logger.log(level, msg, formatted); >>>> Now that msg contains no placeholder likes "{0}", nothing on temporary will be shown. >>> I did not catch you here. SSLSimpleFormatter is a package private class (SSLLogger#SSLSimpleFormatter), which does not use placeholder in msg. >> I see. >> BTW, at the beginning of SSLLogger, there is >> String p = GetPropertyAction.privilegedGetProperty("javax.net.debug"); >> if (p != null) { >> if (p.isEmpty()) { >> property = ""; >> logger = System.getLogger("javax.net.ssl"); >> } else { >> Will this "p.isEmpty()" ever happen? I cannot find a place when only SSLLogger.isOn is checked but not SSLLogger.isOn("something"). > If p.isEmpty(), SSLLogger.isOn("something") always returns true. It means that 'something" (ssl, handshake, etc) is not used to control the debug level any more. Instead, the System.Logger levels (FINE, WARNING, etc) get used instead. And in this case, what would >>>> SSLLogger.fine( >>>> "Consuming RSA ClientKeyExchange handshake message", ckem); print out? --Max > > Xuelei From xuelei.fan at oracle.com Thu Jun 7 00:54:53 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 6 Jun 2018 17:54:53 -0700 Subject: SSLLogger.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> <12F8F4BF-F46C-4F0C-ABC2-162D1BADBCF1@oracle.com> <7f438619-0555-4860-63a3-ffd6270da97b@oracle.com> Message-ID: <81ac5d21-4315-3df5-c65e-9a518f797211@oracle.com> On 6/6/2018 5:46 PM, Weijun Wang wrote: > > >> On Jun 7, 2018, at 8:41 AM, Xuelei Fan wrote: >> >> >> >> On 6/6/2018 4:21 PM, Weijun Wang wrote: >>>> On Jun 7, 2018, at 12:27 AM, Xuelei Fan wrote: >>>> >>>> On 6/6/2018 5:41 AM, Weijun Wang wrote: >>>>> There are lots of calls like >>>>> RSAClientKeyExchangeMessage ckem = >>>>> new RSAClientKeyExchangeMessage(shc, message); >>>>> if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) { >>>>> SSLLogger.fine( >>>>> "Consuming RSA ClientKeyExchange handshake message", ckem); >>>>> } >>>>> which finally calls to >>>>> String formatted = >>>>> SSLSimpleFormatter.formatParameters(params); >>>>> logger.log(level, msg, formatted); >>>>> Now that msg contains no placeholder likes "{0}", nothing on temporary will be shown. >>>> I did not catch you here. SSLSimpleFormatter is a package private class (SSLLogger#SSLSimpleFormatter), which does not use placeholder in msg. >>> I see. >>> BTW, at the beginning of SSLLogger, there is >>> String p = GetPropertyAction.privilegedGetProperty("javax.net.debug"); >>> if (p != null) { >>> if (p.isEmpty()) { >>> property = ""; >>> logger = System.getLogger("javax.net.ssl"); >>> } else { >>> Will this "p.isEmpty()" ever happen? I cannot find a place when only SSLLogger.isOn is checked but not SSLLogger.isOn("something"). >> If p.isEmpty(), SSLLogger.isOn("something") always returns true. It means that 'something" (ssl, handshake, etc) is not used to control the debug level any more. Instead, the System.Logger levels (FINE, WARNING, etc) get used instead. > > And in this case, what would > >>>>> SSLLogger.fine( >>>>> "Consuming RSA ClientKeyExchange handshake message", ckem); > > print out? > If Level.DEBUG is enabled, the printout may look like (I use the DH ClientkeyExchange handshake message as I happen to have the debug log in hand): javax.net.ssl|DEBUG|01|main|2018-06-06 17:49:38.624 PDT|DHClientKeyExchange.java:271|Consuming DH ClientKeyExchange handshake message ( "DH ClientKeyExchange": { "parameters": { "dh_Yc": { 0000: 4E 8B 14 6B E7 D6 EB BF 8C 69 C6 03 5D D0 EA 10 N..k.....i..]... 0010: F9 B6 37 89 B5 50 67 3B A0 3B 18 2C EE 99 87 D5 ..7..Pg;.;.,.... 0020: D8 61 62 D1 5F 97 66 6B 27 03 19 6C 6D DE 91 07 .ab._.fk'..lm... 0030: E1 A8 AC D7 30 55 2C 86 A1 D1 9C 98 BF DF 83 3E ....0U,........> 0040: 34 1F 7C F0 AC 87 BC 5E D4 E9 99 33 2C D0 79 20 4......^...3,.y 0050: B5 66 12 95 84 66 50 24 5D F6 C9 1A D0 18 8C A9 .f...fP$]....... 0060: 9A EC E5 59 5C FE 57 31 66 CE BF FD E2 61 4B 5D ...Y\.W1f....aK] 0070: A5 49 94 0B CC 30 BA 0A 16 D9 0A B3 19 EE 58 C7 .I...0........X. 0080: E4 D1 22 9E 1D 9A 43 57 D0 B8 B6 87 02 A0 42 D3 .."...CW......B. 0090: A1 66 EB 04 5F 5F B7 3F 1F B9 1A 23 D1 79 A6 01 .f..__.?...#.y.. 00A0: 9F CE 65 EE CD 04 B7 1A 38 2E 2A 7B F3 0E F6 F8 ..e.....8.*..... 00B0: 5F D3 8F E5 5E 83 89 FD 97 17 9D C4 81 99 9A AB _...^........... 00C0: 83 EC E5 C5 68 0A E2 D5 CF D0 70 D9 D5 BE C4 16 ....h.....p..... 00D0: 37 E2 2D 86 2C 53 95 C8 D9 EE 9F E4 32 35 DE FE 7.-.,S......25.. 00E0: D8 5D 78 BC 6E 2C 98 90 03 0B F4 CF 36 20 6E F1 .]x.n,......6 n. 00F0: F9 3B 05 C1 3E 17 2A 7B 11 39 6D 59 82 A8 61 9C .;..>.*..9mY..a. }, } } ) Xuelei From jamil.j.nimeh at oracle.com Thu Jun 7 00:56:03 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 6 Jun 2018 17:56:03 -0700 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: <4efe36b1-a032-23c9-914d-fbe124410eb5@oracle.com> References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> <0419f803-e67c-074c-ff02-f0d45326d3b4@oracle.com> <4efe36b1-a032-23c9-914d-fbe124410eb5@oracle.com> Message-ID: Yes, I'll delete that commented line and rework the absolute put later tonight. --Jamil On 06/06/2018 05:44 PM, Xuelei Fan wrote: > Hi Jamil, > > All good catches to me.? Would you mind take care of the update as well? > > Thanks, > Xuelei > > On 6/6/2018 3:19 PM, Jamil Nimeh wrote: >> Hello, comments below, minor stuff for the most part: >> >> ? * KeyUpdate.java >> ????? o 128-129: Spelling nit: REQUSTED --> REQUESTED >> ????? o That change will have to get sprinkled throughout the code >> ? * OutputRecord.java >> ????? o 291-295: It seems like using an absolute put would simplify this >> ??????? code a bit:? Just advance the destination limit by one like >> ??????? you're already doing, then destination.put(destination.limit() - >> ??????? 1, contentType);? Or you can set an int variable to >> ??????? destination.limit() before you make the limit one larger and >> ??????? then use that as the first argument to the absolute put.? Either >> ??????? way you don't need to move your position marker forward and >> ??????? backward. >> ????????? + I know absolute puts are not guaranteed to be implemented, >> ??????????? but they are used further down on line 312, 317-318 so I >> ??????????? think we're safe here. >> ? * SSLEngineOutputRecord.java >> ????? o Looks good to me >> ? * SSLSocketOutputRecord.java >> ????? o 315: REQUSTED -> REQUESTED >> ????? o Looks okay otherwise >> ? * DTLSOutputRecord >> ????? o 68: Do we need to hang onto this for now, or can we remove this >> ??????? commented out line? >> ????? o Otherwise looks OK. >> >> More on the way... >> >> --Jamil >> >> >> On 02/22/2018 12:29 PM, Xuelei Fan wrote: >>> Updated to use package private HKDF implementation. >>> >>> webrev (based on JDK-8185576): >>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.01 >>> >>> webrev (including JDK-8185576): >>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >>> >>> Thanks, >>> Xuelei >>> >>> On 2/20/2018 11:57 AM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> I'd like to invite you to review the TLS 1.3 full handshake >>>> implementation.? I appreciate it if I could have feedback before >>>> March 9, 2018. >>>> >>>> In the "JDK-8185576: New handshake implementation" [1] code review >>>> around, I was trying to re-org the TLS handshaking implementation >>>> in the >>>> SunJSSE provider.? If you had reviewed that part, you can start >>>> from the following webrev that based on the update of JDK-8185576: >>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.00 >>>> >>>> If you would like start from earlier, here is the webrev that >>>> contains the handshaking implementation re-org in JDK-8185576: >>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>>> >>>> >>>> This changeset only implements the full handshake of TLS 1.3, >>>> rather then a fully implementation of the latest TLS 1.3 draft [2]. >>>> >>>> In this implementation, I removed: >>>> 1. the KRB5 cipher suite implementation. >>>> Please let me know if you are still using KRB5 cipher suite.? I may >>>> not add them back if no objections. >>>> >>>> 2. OCSP stapling. >>>> This feature will be added back later. >>>> >>>> Resumption and key update, and more features may be added later. >>>> >>>> Thanks & Regards, >>>> Xuelei >>>> >>>> [1]: >>>> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016642.html >>>> >>>> [2]: https://tools.ietf.org/html/draft-ietf-tls-tls13-24 >> From weijun.wang at oracle.com Thu Jun 7 01:10:06 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 7 Jun 2018 09:10:06 +0800 Subject: SSLLogger.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <81ac5d21-4315-3df5-c65e-9a518f797211@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> <12F8F4BF-F46C-4F0C-ABC2-162D1BADBCF1@oracle.com> <7f438619-0555-4860-63a3-ffd6270da97b@oracle.com> <81ac5d21-4315-3df5-c65e-9a518f797211@oracle.com> Message-ID: I assume this output is for the internal SSLLogger. I was asking what would be printed if someone only set "-Djavax.net.debug" and a System logger is used. --Max > On Jun 7, 2018, at 8:54 AM, Xuelei Fan wrote: > > > > On 6/6/2018 5:46 PM, Weijun Wang wrote: >>> On Jun 7, 2018, at 8:41 AM, Xuelei Fan wrote: >>> >>> >>> >>> On 6/6/2018 4:21 PM, Weijun Wang wrote: >>>>> On Jun 7, 2018, at 12:27 AM, Xuelei Fan wrote: >>>>> >>>>> On 6/6/2018 5:41 AM, Weijun Wang wrote: >>>>>> There are lots of calls like >>>>>> RSAClientKeyExchangeMessage ckem = >>>>>> new RSAClientKeyExchangeMessage(shc, message); >>>>>> if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) { >>>>>> SSLLogger.fine( >>>>>> "Consuming RSA ClientKeyExchange handshake message", ckem); >>>>>> } >>>>>> which finally calls to >>>>>> String formatted = >>>>>> SSLSimpleFormatter.formatParameters(params); >>>>>> logger.log(level, msg, formatted); >>>>>> Now that msg contains no placeholder likes "{0}", nothing on temporary will be shown. >>>>> I did not catch you here. SSLSimpleFormatter is a package private class (SSLLogger#SSLSimpleFormatter), which does not use placeholder in msg. >>>> I see. >>>> BTW, at the beginning of SSLLogger, there is >>>> String p = GetPropertyAction.privilegedGetProperty("javax.net.debug"); >>>> if (p != null) { >>>> if (p.isEmpty()) { >>>> property = ""; >>>> logger = System.getLogger("javax.net.ssl"); >>>> } else { >>>> Will this "p.isEmpty()" ever happen? I cannot find a place when only SSLLogger.isOn is checked but not SSLLogger.isOn("something"). >>> If p.isEmpty(), SSLLogger.isOn("something") always returns true. It means that 'something" (ssl, handshake, etc) is not used to control the debug level any more. Instead, the System.Logger levels (FINE, WARNING, etc) get used instead. >> And in this case, what would >>>>>> SSLLogger.fine( >>>>>> "Consuming RSA ClientKeyExchange handshake message", ckem); >> print out? > If Level.DEBUG is enabled, the printout may look like (I use the DH ClientkeyExchange handshake message as I happen to have the debug log in hand): > > javax.net.ssl|DEBUG|01|main|2018-06-06 17:49:38.624 PDT|DHClientKeyExchange.java:271|Consuming DH ClientKeyExchange handshake message ( > "DH ClientKeyExchange": { > "parameters": { > "dh_Yc": { > 0000: 4E 8B 14 6B E7 D6 EB BF 8C 69 C6 03 5D D0 EA 10 N..k.....i..]... > 0010: F9 B6 37 89 B5 50 67 3B A0 3B 18 2C EE 99 87 D5 ..7..Pg;.;.,.... > 0020: D8 61 62 D1 5F 97 66 6B 27 03 19 6C 6D DE 91 07 .ab._.fk'..lm... > 0030: E1 A8 AC D7 30 55 2C 86 A1 D1 9C 98 BF DF 83 3E ....0U,........> > 0040: 34 1F 7C F0 AC 87 BC 5E D4 E9 99 33 2C D0 79 20 4......^...3,.y > 0050: B5 66 12 95 84 66 50 24 5D F6 C9 1A D0 18 8C A9 .f...fP$]....... > 0060: 9A EC E5 59 5C FE 57 31 66 CE BF FD E2 61 4B 5D ...Y\.W1f....aK] > 0070: A5 49 94 0B CC 30 BA 0A 16 D9 0A B3 19 EE 58 C7 .I...0........X. > 0080: E4 D1 22 9E 1D 9A 43 57 D0 B8 B6 87 02 A0 42 D3 .."...CW......B. > 0090: A1 66 EB 04 5F 5F B7 3F 1F B9 1A 23 D1 79 A6 01 .f..__.?...#.y.. > 00A0: 9F CE 65 EE CD 04 B7 1A 38 2E 2A 7B F3 0E F6 F8 ..e.....8.*..... > 00B0: 5F D3 8F E5 5E 83 89 FD 97 17 9D C4 81 99 9A AB _...^........... > 00C0: 83 EC E5 C5 68 0A E2 D5 CF D0 70 D9 D5 BE C4 16 ....h.....p..... > 00D0: 37 E2 2D 86 2C 53 95 C8 D9 EE 9F E4 32 35 DE FE 7.-.,S......25.. > 00E0: D8 5D 78 BC 6E 2C 98 90 03 0B F4 CF 36 20 6E F1 .]x.n,......6 n. > 00F0: F9 3B 05 C1 3E 17 2A 7B 11 39 6D 59 82 A8 61 9C .;..>.*..9mY..a. > }, > } > } > ) > > Xuelei From xuelei.fan at oracle.com Thu Jun 7 01:35:46 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 6 Jun 2018 18:35:46 -0700 Subject: SSLLogger.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> <12F8F4BF-F46C-4F0C-ABC2-162D1BADBCF1@oracle.com> <7f438619-0555-4860-63a3-ffd6270da97b@oracle.com> <81ac5d21-4315-3df5-c65e-9a518f797211@oracle.com> Message-ID: I see your concerns now. Currently, we don't fine the format if using System logger. Applications can define the format and output style for themselves if needed. That's also the purpose why we introduce the System Logger in the provider. Xuelei On 6/6/2018 6:10 PM, Weijun Wang wrote: > I assume this output is for the internal SSLLogger. I was asking what would be printed if someone only set "-Djavax.net.debug" and a System logger is used. > > --Max > >> On Jun 7, 2018, at 8:54 AM, Xuelei Fan wrote: >> >> >> >> On 6/6/2018 5:46 PM, Weijun Wang wrote: >>>> On Jun 7, 2018, at 8:41 AM, Xuelei Fan wrote: >>>> >>>> >>>> >>>> On 6/6/2018 4:21 PM, Weijun Wang wrote: >>>>>> On Jun 7, 2018, at 12:27 AM, Xuelei Fan wrote: >>>>>> >>>>>> On 6/6/2018 5:41 AM, Weijun Wang wrote: >>>>>>> There are lots of calls like >>>>>>> RSAClientKeyExchangeMessage ckem = >>>>>>> new RSAClientKeyExchangeMessage(shc, message); >>>>>>> if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) { >>>>>>> SSLLogger.fine( >>>>>>> "Consuming RSA ClientKeyExchange handshake message", ckem); >>>>>>> } >>>>>>> which finally calls to >>>>>>> String formatted = >>>>>>> SSLSimpleFormatter.formatParameters(params); >>>>>>> logger.log(level, msg, formatted); >>>>>>> Now that msg contains no placeholder likes "{0}", nothing on temporary will be shown. >>>>>> I did not catch you here. SSLSimpleFormatter is a package private class (SSLLogger#SSLSimpleFormatter), which does not use placeholder in msg. >>>>> I see. >>>>> BTW, at the beginning of SSLLogger, there is >>>>> String p = GetPropertyAction.privilegedGetProperty("javax.net.debug"); >>>>> if (p != null) { >>>>> if (p.isEmpty()) { >>>>> property = ""; >>>>> logger = System.getLogger("javax.net.ssl"); >>>>> } else { >>>>> Will this "p.isEmpty()" ever happen? I cannot find a place when only SSLLogger.isOn is checked but not SSLLogger.isOn("something"). >>>> If p.isEmpty(), SSLLogger.isOn("something") always returns true. It means that 'something" (ssl, handshake, etc) is not used to control the debug level any more. Instead, the System.Logger levels (FINE, WARNING, etc) get used instead. >>> And in this case, what would >>>>>>> SSLLogger.fine( >>>>>>> "Consuming RSA ClientKeyExchange handshake message", ckem); >>> print out? >> If Level.DEBUG is enabled, the printout may look like (I use the DH ClientkeyExchange handshake message as I happen to have the debug log in hand): >> >> javax.net.ssl|DEBUG|01|main|2018-06-06 17:49:38.624 PDT|DHClientKeyExchange.java:271|Consuming DH ClientKeyExchange handshake message ( >> "DH ClientKeyExchange": { >> "parameters": { >> "dh_Yc": { >> 0000: 4E 8B 14 6B E7 D6 EB BF 8C 69 C6 03 5D D0 EA 10 N..k.....i..]... >> 0010: F9 B6 37 89 B5 50 67 3B A0 3B 18 2C EE 99 87 D5 ..7..Pg;.;.,.... >> 0020: D8 61 62 D1 5F 97 66 6B 27 03 19 6C 6D DE 91 07 .ab._.fk'..lm... >> 0030: E1 A8 AC D7 30 55 2C 86 A1 D1 9C 98 BF DF 83 3E ....0U,........> >> 0040: 34 1F 7C F0 AC 87 BC 5E D4 E9 99 33 2C D0 79 20 4......^...3,.y >> 0050: B5 66 12 95 84 66 50 24 5D F6 C9 1A D0 18 8C A9 .f...fP$]....... >> 0060: 9A EC E5 59 5C FE 57 31 66 CE BF FD E2 61 4B 5D ...Y\.W1f....aK] >> 0070: A5 49 94 0B CC 30 BA 0A 16 D9 0A B3 19 EE 58 C7 .I...0........X. >> 0080: E4 D1 22 9E 1D 9A 43 57 D0 B8 B6 87 02 A0 42 D3 .."...CW......B. >> 0090: A1 66 EB 04 5F 5F B7 3F 1F B9 1A 23 D1 79 A6 01 .f..__.?...#.y.. >> 00A0: 9F CE 65 EE CD 04 B7 1A 38 2E 2A 7B F3 0E F6 F8 ..e.....8.*..... >> 00B0: 5F D3 8F E5 5E 83 89 FD 97 17 9D C4 81 99 9A AB _...^........... >> 00C0: 83 EC E5 C5 68 0A E2 D5 CF D0 70 D9 D5 BE C4 16 ....h.....p..... >> 00D0: 37 E2 2D 86 2C 53 95 C8 D9 EE 9F E4 32 35 DE FE 7.-.,S......25.. >> 00E0: D8 5D 78 BC 6E 2C 98 90 03 0B F4 CF 36 20 6E F1 .]x.n,......6 n. >> 00F0: F9 3B 05 C1 3E 17 2A 7B 11 39 6D 59 82 A8 61 9C .;..>.*..9mY..a. >> }, >> } >> } >> ) >> >> Xuelei > From weijun.wang at oracle.com Thu Jun 7 01:37:39 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 7 Jun 2018 09:37:39 +0800 Subject: SSLLogger.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> <12F8F4BF-F46C-4F0C-ABC2-162D1BADBCF1@oracle.com> <7f438619-0555-4860-63a3-ffd6270da97b@oracle.com> <81ac5d21-4315-3df5-c65e-9a518f797211@oracle.com> Message-ID: <4555CC11-AE7F-4B3E-B1C0-89B8DBA3B78B@oracle.com> But will any application use the logger named "javax.net.debug"? I think that's only for JSSE. > On Jun 7, 2018, at 9:35 AM, Xuelei Fan wrote: > > I see your concerns now. Currently, we don't fine the format if using System logger. Applications can define the format and output style for themselves if needed. That's also the purpose why we introduce the System Logger in the provider. > > Xuelei > > On 6/6/2018 6:10 PM, Weijun Wang wrote: >> I assume this output is for the internal SSLLogger. I was asking what would be printed if someone only set "-Djavax.net.debug" and a System logger is used. >> --Max >>> On Jun 7, 2018, at 8:54 AM, Xuelei Fan wrote: >>> >>> >>> >>> On 6/6/2018 5:46 PM, Weijun Wang wrote: >>>>> On Jun 7, 2018, at 8:41 AM, Xuelei Fan wrote: >>>>> >>>>> >>>>> >>>>> On 6/6/2018 4:21 PM, Weijun Wang wrote: >>>>>>> On Jun 7, 2018, at 12:27 AM, Xuelei Fan wrote: >>>>>>> >>>>>>> On 6/6/2018 5:41 AM, Weijun Wang wrote: >>>>>>>> There are lots of calls like >>>>>>>> RSAClientKeyExchangeMessage ckem = >>>>>>>> new RSAClientKeyExchangeMessage(shc, message); >>>>>>>> if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) { >>>>>>>> SSLLogger.fine( >>>>>>>> "Consuming RSA ClientKeyExchange handshake message", ckem); >>>>>>>> } >>>>>>>> which finally calls to >>>>>>>> String formatted = >>>>>>>> SSLSimpleFormatter.formatParameters(params); >>>>>>>> logger.log(level, msg, formatted); >>>>>>>> Now that msg contains no placeholder likes "{0}", nothing on temporary will be shown. >>>>>>> I did not catch you here. SSLSimpleFormatter is a package private class (SSLLogger#SSLSimpleFormatter), which does not use placeholder in msg. >>>>>> I see. >>>>>> BTW, at the beginning of SSLLogger, there is >>>>>> String p = GetPropertyAction.privilegedGetProperty("javax.net.debug"); >>>>>> if (p != null) { >>>>>> if (p.isEmpty()) { >>>>>> property = ""; >>>>>> logger = System.getLogger("javax.net.ssl"); >>>>>> } else { >>>>>> Will this "p.isEmpty()" ever happen? I cannot find a place when only SSLLogger.isOn is checked but not SSLLogger.isOn("something"). >>>>> If p.isEmpty(), SSLLogger.isOn("something") always returns true. It means that 'something" (ssl, handshake, etc) is not used to control the debug level any more. Instead, the System.Logger levels (FINE, WARNING, etc) get used instead. >>>> And in this case, what would >>>>>>>> SSLLogger.fine( >>>>>>>> "Consuming RSA ClientKeyExchange handshake message", ckem); >>>> print out? >>> If Level.DEBUG is enabled, the printout may look like (I use the DH ClientkeyExchange handshake message as I happen to have the debug log in hand): >>> >>> javax.net.ssl|DEBUG|01|main|2018-06-06 17:49:38.624 PDT|DHClientKeyExchange.java:271|Consuming DH ClientKeyExchange handshake message ( >>> "DH ClientKeyExchange": { >>> "parameters": { >>> "dh_Yc": { >>> 0000: 4E 8B 14 6B E7 D6 EB BF 8C 69 C6 03 5D D0 EA 10 N..k.....i..]... >>> 0010: F9 B6 37 89 B5 50 67 3B A0 3B 18 2C EE 99 87 D5 ..7..Pg;.;.,.... >>> 0020: D8 61 62 D1 5F 97 66 6B 27 03 19 6C 6D DE 91 07 .ab._.fk'..lm... >>> 0030: E1 A8 AC D7 30 55 2C 86 A1 D1 9C 98 BF DF 83 3E ....0U,........> >>> 0040: 34 1F 7C F0 AC 87 BC 5E D4 E9 99 33 2C D0 79 20 4......^...3,.y >>> 0050: B5 66 12 95 84 66 50 24 5D F6 C9 1A D0 18 8C A9 .f...fP$]....... >>> 0060: 9A EC E5 59 5C FE 57 31 66 CE BF FD E2 61 4B 5D ...Y\.W1f....aK] >>> 0070: A5 49 94 0B CC 30 BA 0A 16 D9 0A B3 19 EE 58 C7 .I...0........X. >>> 0080: E4 D1 22 9E 1D 9A 43 57 D0 B8 B6 87 02 A0 42 D3 .."...CW......B. >>> 0090: A1 66 EB 04 5F 5F B7 3F 1F B9 1A 23 D1 79 A6 01 .f..__.?...#.y.. >>> 00A0: 9F CE 65 EE CD 04 B7 1A 38 2E 2A 7B F3 0E F6 F8 ..e.....8.*..... >>> 00B0: 5F D3 8F E5 5E 83 89 FD 97 17 9D C4 81 99 9A AB _...^........... >>> 00C0: 83 EC E5 C5 68 0A E2 D5 CF D0 70 D9 D5 BE C4 16 ....h.....p..... >>> 00D0: 37 E2 2D 86 2C 53 95 C8 D9 EE 9F E4 32 35 DE FE 7.-.,S......25.. >>> 00E0: D8 5D 78 BC 6E 2C 98 90 03 0B F4 CF 36 20 6E F1 .]x.n,......6 n. >>> 00F0: F9 3B 05 C1 3E 17 2A 7B 11 39 6D 59 82 A8 61 9C .;..>.*..9mY..a. >>> }, >>> } >>> } >>> ) >>> >>> Xuelei From xuelei.fan at oracle.com Thu Jun 7 01:51:24 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 6 Jun 2018 18:51:24 -0700 Subject: SSLLogger.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <4555CC11-AE7F-4B3E-B1C0-89B8DBA3B78B@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> <12F8F4BF-F46C-4F0C-ABC2-162D1BADBCF1@oracle.com> <7f438619-0555-4860-63a3-ffd6270da97b@oracle.com> <81ac5d21-4315-3df5-c65e-9a518f797211@oracle.com> <4555CC11-AE7F-4B3E-B1C0-89B8DBA3B78B@oracle.com> Message-ID: <72191acc-b6d3-7ec1-8d62-e2164ddc4ac6@oracle.com> In this implementation, the SunJSSE logging is updated to (the class comment lines): /** * Implementation of SSL logger. * * If the system property "javax.net.debug" is not defined, the debug logging * is turned off. If the system property "javax.net.debug" is defined as * empty, the debug logger is specified by System.getLogger("javax.net.ssl"), * and applications can customize and configure the logger or use external * logging mechanisms. If the system property "javax.net.debug" is defined * and non-empty, a private debug logger implemented in this class is used. */ On 6/6/2018 6:37 PM, Weijun Wang wrote: > But will any application use the logger named "javax.net.debug"? I think that's only for JSSE. > If using System Logger, the "javax.net.debug" system property will be used to turn on/off the logger (define with empty or not defined). Xuelei >> On Jun 7, 2018, at 9:35 AM, Xuelei Fan wrote: >> >> I see your concerns now. Currently, we don't fine the format if using System logger. Applications can define the format and output style for themselves if needed. That's also the purpose why we introduce the System Logger in the provider. From weijun.wang at oracle.com Thu Jun 7 03:11:31 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 7 Jun 2018 11:11:31 +0800 Subject: Utilities.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <4555CC11-AE7F-4B3E-B1C0-89B8DBA3B78B@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> <12F8F4BF-F46C-4F0C-ABC2-162D1BADBCF1@oracle.com> <7f438619-0555-4860-63a3-ffd6270da97b@oracle.com> <81ac5d21-4315-3df5-c65e-9a518f797211@oracle.com> <4555CC11-AE7F-4B3E-B1C0-89B8DBA3B78B@oracle.com> Message-ID: <4C127382-F604-4984-85A8-6F6E37A6ACE7@oracle.com> Utilities.java: 39 static final char[] hexDigits = "0123456789ABCDEF".toCharArray(); 40 private static final String indent = " "; 41 private static final Pattern lineBreakPatern = 42 Pattern.compile("\\r\\n|\\n|\\r"); Use UPPERCASE letters for final static fields. 147 static String indent(String source, String prefix) { 148 StringBuilder builder = new StringBuilder(); 149 if (source == null) { 150 builder.append("\n" + prefix + ""); 151 } else { 152 String[] lines = lineBreakPatern.split(source); The split call would remove existing newline(s) at the end. Is this what you intended? Thanks Max >>>> >>>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 From weijun.wang at oracle.com Thu Jun 7 03:17:58 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 7 Jun 2018 11:17:58 +0800 Subject: RandomCookie.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <8f2dc56a-f86d-6f76-626b-c570a196a34a@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <8f2dc56a-f86d-6f76-626b-c570a196a34a@oracle.com> Message-ID: > On Jun 7, 2018, at 12:19 AM, Xuelei Fan wrote: > > On 6/5/2018 10:37 PM, Weijun Wang wrote: >> RandomCookie.java: >> + private boolean isT12Downgrade() { >> + return Arrays.equals(randomBytes, 24, 31, t12Protection, 0, 7); >> + } >> + >> + private boolean isT11Downgrade() { >> + return Arrays.equals(randomBytes, 24, 31, t11Protection, 0, 7); >> + } >> The "to" in Arrays::equals is exclusive, so please update 31 -> 32, 7 -> 8. > Good catch! > >> Also, at the end of https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.1.3 >> RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH Implementations of >> draft versions (see Section 4.2.1.1) of this specification SHOULD NOT >> implement this mechanism on either client and server. A pre-RFC >> client connecting to RFC servers, or vice versa, will appear to >> downgrade to TLS 1.2. With the mechanism enabled, this will cause an >> interoperability failure. >> Has the current implementation implemented (and turned on) this mechanism? > Yes, the mechanism is turned on. Should it depend on the value of "jdk.tls13.version"? --Max > > Thanks, > Xuelei > >> Thanks >> Max >>> >>> >>>>>> On Jun 5, 2018, at 12:12 PM, Xuelei Fan wrote: >>>>>> >>>>>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >>> From weijun.wang at oracle.com Thu Jun 7 03:24:40 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 7 Jun 2018 11:24:40 +0800 Subject: SSLLogger.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <72191acc-b6d3-7ec1-8d62-e2164ddc4ac6@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> <12F8F4BF-F46C-4F0C-ABC2-162D1BADBCF1@oracle.com> <7f438619-0555-4860-63a3-ffd6270da97b@oracle.com> <81ac5d21-4315-3df5-c65e-9a518f797211@oracle.com> <4555CC11-AE7F-4B3E-B1C0-89B8DBA3B78B@oracle.com> <72191acc-b6d3-7ec1-8d62-e2164ddc4ac6@oracle.com> Message-ID: I think I understand. So if a user sets it to empty, they will also need to create a customized logger/formatter like SSLLogger that is able to output a parameter without a placeholder in msg. --Max > On Jun 7, 2018, at 9:51 AM, Xuelei Fan wrote: > > In this implementation, the SunJSSE logging is updated to (the class comment lines): > > /** > * Implementation of SSL logger. > * > * If the system property "javax.net.debug" is not defined, the debug logging > * is turned off. If the system property "javax.net.debug" is defined as > * empty, the debug logger is specified by System.getLogger("javax.net.ssl"), > * and applications can customize and configure the logger or use external > * logging mechanisms. If the system property "javax.net.debug" is defined > * and non-empty, a private debug logger implemented in this class is used. > */ > > On 6/6/2018 6:37 PM, Weijun Wang wrote: >> But will any application use the logger named "javax.net.debug"? I think that's only for JSSE. > If using System Logger, the "javax.net.debug" system property will be used to turn on/off the logger (define with empty or not defined). > > Xuelei > >>> On Jun 7, 2018, at 9:35 AM, Xuelei Fan wrote: >>> >>> I see your concerns now. Currently, we don't fine the format if using System logger. Applications can define the format and output style for themselves if needed. That's also the purpose why we introduce the System Logger in the provider. From xuelei.fan at oracle.com Thu Jun 7 04:17:33 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 6 Jun 2018 21:17:33 -0700 Subject: RandomCookie.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <8f2dc56a-f86d-6f76-626b-c570a196a34a@oracle.com> Message-ID: <1d795fe0-542d-9092-06a1-9002b0d7f7b2@oracle.com> On 6/6/2018 8:17 PM, Weijun Wang wrote: > > >> On Jun 7, 2018, at 12:19 AM, Xuelei Fan wrote: >> >> On 6/5/2018 10:37 PM, Weijun Wang wrote: >>> RandomCookie.java: >>> + private boolean isT12Downgrade() { >>> + return Arrays.equals(randomBytes, 24, 31, t12Protection, 0, 7); >>> + } >>> + >>> + private boolean isT11Downgrade() { >>> + return Arrays.equals(randomBytes, 24, 31, t11Protection, 0, 7); >>> + } >>> The "to" in Arrays::equals is exclusive, so please update 31 -> 32, 7 -> 8. >> Good catch! >> >>> Also, at the end of https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.1.3 >>> RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH Implementations of >>> draft versions (see Section 4.2.1.1) of this specification SHOULD NOT >>> implement this mechanism on either client and server. A pre-RFC >>> client connecting to RFC servers, or vice versa, will appear to >>> downgrade to TLS 1.2. With the mechanism enabled, this will cause an >>> interoperability failure. >>> Has the current implementation implemented (and turned on) this mechanism? >> Yes, the mechanism is turned on. > > Should it depend on the value of "jdk.tls13.version"? > No, the system property is only used to set the the version number. As we don't want to ship draft TLS 1.3, we don't actually follow the above draft special spec ("SHOULD NOT implement this mechanism"). Xuelei > --Max > >> >> Thanks, >> Xuelei >> >>> Thanks >>> Max >>>> >>>> >>>>>>> On Jun 5, 2018, at 12:12 PM, Xuelei Fan wrote: >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >>>> > From xuelei.fan at oracle.com Thu Jun 7 04:40:19 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 6 Jun 2018 21:40:19 -0700 Subject: Utilities.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <4C127382-F604-4984-85A8-6F6E37A6ACE7@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> <12F8F4BF-F46C-4F0C-ABC2-162D1BADBCF1@oracle.com> <7f438619-0555-4860-63a3-ffd6270da97b@oracle.com> <81ac5d21-4315-3df5-c65e-9a518f797211@oracle.com> <4555CC11-AE7F-4B3E-B1C0-89B8DBA3B78B@oracle.com> <4C127382-F604-4984-85A8-6F6E37A6ACE7@oracle.com> Message-ID: On 6/6/2018 8:11 PM, Weijun Wang wrote: > Utilities.java: > > 39 static final char[] hexDigits = "0123456789ABCDEF".toCharArray(); > 40 private static final String indent = " "; > 41 private static final Pattern lineBreakPatern = > 42 Pattern.compile("\\r\\n|\\n|\\r"); > > Use UPPERCASE letters for final static fields. > When the type is other than primitive type, using UPPERCASE may be not a better choice. For example, LINE_BREAK_PATERN.split() looks weird to me. Anyway, if you like to use UPPERCASE letters, I will make an update. > 147 static String indent(String source, String prefix) { > 148 StringBuilder builder = new StringBuilder(); > 149 if (source == null) { > 150 builder.append("\n" + prefix + ""); > 151 } else { > 152 String[] lines = lineBreakPatern.split(source); > > The split call would remove existing newline(s) at the end. Is this what you intended? > Yes, it is intended. Xuelei From weijun.wang at oracle.com Thu Jun 7 04:49:19 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 7 Jun 2018 12:49:19 +0800 Subject: Utilities.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> <12F8F4BF-F46C-4F0C-ABC2-162D1BADBCF1@oracle.com> <7f438619-0555-4860-63a3-ffd6270da97b@oracle.com> <81ac5d21-4315-3df5-c65e-9a518f797211@oracle.com> <4555CC11-AE7F-4B3E-B1C0-89B8DBA3B78B@oracle.com> <4C127382-F604-4984-85A8-6F6E37A6ACE7@oracle.com> Message-ID: <41DA5071-0F57-4287-80FD-5AE028E28DE9@oracle.com> > On Jun 7, 2018, at 12:40 PM, Xuelei Fan wrote: > > On 6/6/2018 8:11 PM, Weijun Wang wrote: >> Utilities.java: >> 39 static final char[] hexDigits = "0123456789ABCDEF".toCharArray(); >> 40 private static final String indent = " "; >> 41 private static final Pattern lineBreakPatern = >> 42 Pattern.compile("\\r\\n|\\n|\\r"); >> Use UPPERCASE letters for final static fields. > When the type is other than primitive type, using UPPERCASE may be not a better choice. For example, LINE_BREAK_PATERN.split() looks weird to me. > > Anyway, if you like to use UPPERCASE letters, I will make an update. My understanding is that at least immutable static final fields should be UPPERCASE. You have the final decision. --Max > >> 147 static String indent(String source, String prefix) { >> 148 StringBuilder builder = new StringBuilder(); >> 149 if (source == null) { >> 150 builder.append("\n" + prefix + ""); >> 151 } else { >> 152 String[] lines = lineBreakPatern.split(source); >> The split call would remove existing newline(s) at the end. Is this what you intended? > Yes, it is intended. > > Xuelei From jamil.j.nimeh at oracle.com Thu Jun 7 06:56:10 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 6 Jun 2018 23:56:10 -0700 Subject: [Sandbox] *OutputStream fixes for TLS 1.3 branch Message-ID: <85bc72e8-e019-a654-f774-3560101928af@oracle.com> This is the changeset for the *OutputStream fixes, plus a small fix I missed in the HKDF code. http://hg.openjdk.java.net/jdk/sandbox/rev/07dc566630ee --Jamil From weijun.wang at oracle.com Thu Jun 7 08:31:28 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 7 Jun 2018 16:31:28 +0800 Subject: KRB5 (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> <53FFA825-DB0C-44A5-AFB5-DC14397848FB@oracle.com> Message-ID: I still see K_KRB5 KeyExchange and TLS_KRB5_WITH_3DES_EDE_CBC_SHA etc in CipherSuite.java. Shall I also remove them. Thanks Max From weijun.wang at oracle.com Thu Jun 7 08:45:22 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 7 Jun 2018 16:45:22 +0800 Subject: KRB5 (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> <53FFA825-DB0C-44A5-AFB5-DC14397848FB@oracle.com> Message-ID: <06F6CA08-DF0D-4B08-82DE-92E1FE8E360C@oracle.com> And there are the Kerberos word in public APIs: share/classes/javax/net/ssl/SSLContext.java 336: * Some cipher suites (such as Kerberos) require remote hostname 366: * Some cipher suites (such as Kerberos) require remote hostname share/classes/javax/net/ssl/HttpsURLConnection.java 106: * such as Kerberos, will throw an SSLPeerUnverifiedException. 130: * such as Kerberos. 134: * KerberosPrincipal for Kerberos cipher suites. 158: * return null for non-certificate based ciphersuites, such as Kerberos. 162: * KerberosPrincipal for Kerberos cipher suites. If no principal was share/classes/javax/net/ssl/SSLContextSpi.java 90: * Some cipher suites (such as Kerberos) require remote hostname 110: * Some cipher suites (such as Kerberos) require remote hostname share/classes/javax/net/ssl/SSLEngine.java 395: * Some cipher suites (such as Kerberos) require remote hostname 397: * constructor to use Kerberos. share/classes/javax/net/ssl/SSLSession.java 221: * such as Kerberos, will throw an SSLPeerUnverifiedException. 264: * such as Kerberos, will throw an SSLPeerUnverifiedException. 295: * KerberosPrincipal for Kerberos cipher suites. 313: * KerberosPrincipal for Kerberos cipher suites. If no principal was share/classes/javax/net/ssl/HandshakeCompletedEvent.java 122: * such as Kerberos, will throw an SSLPeerUnverifiedException. 145: * such as Kerberos, will throw an SSLPeerUnverifiedException. 178: * KerberosPrincipal for Kerberos cipher suites. 208: * KerberosPrincipal for Kerberos cipher suites. If no principal was --Max > On Jun 7, 2018, at 4:31 PM, Weijun Wang wrote: > > I still see K_KRB5 KeyExchange and TLS_KRB5_WITH_3DES_EDE_CBC_SHA etc in CipherSuite.java. Shall I also remove them. > > Thanks > Max > From xuelei.fan at oracle.com Thu Jun 7 14:23:32 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 7 Jun 2018 07:23:32 -0700 Subject: KRB5 (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <06F6CA08-DF0D-4B08-82DE-92E1FE8E360C@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> <53FFA825-DB0C-44A5-AFB5-DC14397848FB@oracle.com> <06F6CA08-DF0D-4B08-82DE-92E1FE8E360C@oracle.com> Message-ID: <2800cda6-cc4c-30f8-b373-4a8cd1e224da@oracle.com> Yes, please KRB5 cipher suite from the supported list. For the public APIs part, please leave it as it is before we deprecate the specification. Some other JSSE provider might still support KRB5 cipher suites. Xuelei On 6/7/2018 1:45 AM, Weijun Wang wrote: > And there are the Kerberos word in public APIs: > > share/classes/javax/net/ssl/SSLContext.java > 336: * Some cipher suites (such as Kerberos) require remote hostname > 366: * Some cipher suites (such as Kerberos) require remote hostname > > share/classes/javax/net/ssl/HttpsURLConnection.java > 106: * such as Kerberos, will throw an SSLPeerUnverifiedException. > 130: * such as Kerberos. > 134: * KerberosPrincipal for Kerberos cipher suites. > 158: * return null for non-certificate based ciphersuites, such as Kerberos. > 162: * KerberosPrincipal for Kerberos cipher suites. If no principal was > > share/classes/javax/net/ssl/SSLContextSpi.java > 90: * Some cipher suites (such as Kerberos) require remote hostname > 110: * Some cipher suites (such as Kerberos) require remote hostname > > share/classes/javax/net/ssl/SSLEngine.java > 395: * Some cipher suites (such as Kerberos) require remote hostname > 397: * constructor to use Kerberos. > > share/classes/javax/net/ssl/SSLSession.java > 221: * such as Kerberos, will throw an SSLPeerUnverifiedException. > 264: * such as Kerberos, will throw an SSLPeerUnverifiedException. > 295: * KerberosPrincipal for Kerberos cipher suites. > 313: * KerberosPrincipal for Kerberos cipher suites. If no principal was > > share/classes/javax/net/ssl/HandshakeCompletedEvent.java > 122: * such as Kerberos, will throw an SSLPeerUnverifiedException. > 145: * such as Kerberos, will throw an SSLPeerUnverifiedException. > 178: * KerberosPrincipal for Kerberos cipher suites. > 208: * KerberosPrincipal for Kerberos cipher suites. If no principal was > > --Max > >> On Jun 7, 2018, at 4:31 PM, Weijun Wang wrote: >> >> I still see K_KRB5 KeyExchange and TLS_KRB5_WITH_3DES_EDE_CBC_SHA etc in CipherSuite.java. Shall I also remove them. >> >> Thanks >> Max >> > From xuelei.fan at oracle.com Thu Jun 7 14:24:56 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 7 Jun 2018 07:24:56 -0700 Subject: KRB5 (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <2800cda6-cc4c-30f8-b373-4a8cd1e224da@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> <53FFA825-DB0C-44A5-AFB5-DC14397848FB@oracle.com> <06F6CA08-DF0D-4B08-82DE-92E1FE8E360C@oracle.com> <2800cda6-cc4c-30f8-b373-4a8cd1e224da@oracle.com> Message-ID: > Yes, please KRB5 cipher suite from the supported list. Typo: Yes, please remove KRB5 cipher suite from the supported list. On 6/7/2018 7:23 AM, Xuelei Fan wrote: > Yes, please KRB5 cipher suite from the supported list. > > For the public APIs part, please leave it as it is before we deprecate > the specification.? Some other JSSE provider might still support KRB5 > cipher suites. > > Xuelei > > On 6/7/2018 1:45 AM, Weijun Wang wrote: >> And there are the Kerberos word in public APIs: >> >> share/classes/javax/net/ssl/SSLContext.java >> 336:???? * Some cipher suites (such as Kerberos) require remote hostname >> 366:???? * Some cipher suites (such as Kerberos) require remote hostname >> >> share/classes/javax/net/ssl/HttpsURLConnection.java >> 106:???? * such as Kerberos, will throw an SSLPeerUnverifiedException. >> 130:???? * such as Kerberos. >> 134:???? * KerberosPrincipal for Kerberos cipher suites. >> 158:???? * return null for non-certificate based ciphersuites, such as >> Kerberos. >> 162:???? * KerberosPrincipal for Kerberos cipher suites. If no >> principal was >> >> share/classes/javax/net/ssl/SSLContextSpi.java >> 90:???? * Some cipher suites (such as Kerberos) require remote hostname >> 110:???? * Some cipher suites (such as Kerberos) require remote hostname >> >> share/classes/javax/net/ssl/SSLEngine.java >> 395:???? * Some cipher suites (such as Kerberos) require remote hostname >> 397:???? * constructor to use Kerberos. >> >> share/classes/javax/net/ssl/SSLSession.java >> 221:???? * such as Kerberos, will throw an SSLPeerUnverifiedException. >> 264:???? * such as Kerberos, will throw an SSLPeerUnverifiedException. >> 295:???? * KerberosPrincipal for Kerberos cipher suites. >> 313:???? * KerberosPrincipal for Kerberos cipher suites. If no >> principal was >> >> share/classes/javax/net/ssl/HandshakeCompletedEvent.java >> 122:???? * such as Kerberos, will throw an SSLPeerUnverifiedException. >> 145:???? * such as Kerberos, will throw an SSLPeerUnverifiedException. >> 178:???? * KerberosPrincipal for Kerberos cipher suites. >> 208:???? * KerberosPrincipal for Kerberos cipher suites. If no >> principal was >> >> --Max >> >>> On Jun 7, 2018, at 4:31 PM, Weijun Wang wrote: >>> >>> I still see K_KRB5 KeyExchange and TLS_KRB5_WITH_3DES_EDE_CBC_SHA etc >>> in CipherSuite.java. Shall I also remove them. >>> >>> Thanks >>> Max >>> >> From weijun.wang at oracle.com Thu Jun 7 14:41:01 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 7 Jun 2018 22:41:01 +0800 Subject: KRB5 (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> <53FFA825-DB0C-44A5-AFB5-DC14397848FB@oracle.com> <06F6CA08-DF0D-4B08-82DE-92E1FE8E360C@oracle.com> <2800cda6-cc4c-30f8-b373-4a8cd1e224da@oracle.com> Message-ID: Please take a review http://cr.openjdk.java.net/~weijun/9999999/webrev.more-krb5-cleanup/ --Max > On Jun 7, 2018, at 10:24 PM, Xuelei Fan wrote: > > > Yes, please KRB5 cipher suite from the supported list. > Typo: Yes, please remove KRB5 cipher suite from the supported list. > > On 6/7/2018 7:23 AM, Xuelei Fan wrote: >> Yes, please KRB5 cipher suite from the supported list. >> For the public APIs part, please leave it as it is before we deprecate the specification. Some other JSSE provider might still support KRB5 cipher suites. >> Xuelei >> On 6/7/2018 1:45 AM, Weijun Wang wrote: >>> And there are the Kerberos word in public APIs: >>> >>> share/classes/javax/net/ssl/SSLContext.java >>> 336: * Some cipher suites (such as Kerberos) require remote hostname >>> 366: * Some cipher suites (such as Kerberos) require remote hostname >>> >>> share/classes/javax/net/ssl/HttpsURLConnection.java >>> 106: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>> 130: * such as Kerberos. >>> 134: * KerberosPrincipal for Kerberos cipher suites. >>> 158: * return null for non-certificate based ciphersuites, such as Kerberos. >>> 162: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>> >>> share/classes/javax/net/ssl/SSLContextSpi.java >>> 90: * Some cipher suites (such as Kerberos) require remote hostname >>> 110: * Some cipher suites (such as Kerberos) require remote hostname >>> >>> share/classes/javax/net/ssl/SSLEngine.java >>> 395: * Some cipher suites (such as Kerberos) require remote hostname >>> 397: * constructor to use Kerberos. >>> >>> share/classes/javax/net/ssl/SSLSession.java >>> 221: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>> 264: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>> 295: * KerberosPrincipal for Kerberos cipher suites. >>> 313: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>> >>> share/classes/javax/net/ssl/HandshakeCompletedEvent.java >>> 122: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>> 145: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>> 178: * KerberosPrincipal for Kerberos cipher suites. >>> 208: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>> >>> --Max >>> >>>> On Jun 7, 2018, at 4:31 PM, Weijun Wang wrote: >>>> >>>> I still see K_KRB5 KeyExchange and TLS_KRB5_WITH_3DES_EDE_CBC_SHA etc in CipherSuite.java. Shall I also remove them. >>>> >>>> Thanks >>>> Max >>>> >>> From weijun.wang at oracle.com Thu Jun 7 14:43:32 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 7 Jun 2018 22:43:32 +0800 Subject: KRB5 (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> <53FFA825-DB0C-44A5-AFB5-DC14397848FB@oracle.com> <06F6CA08-DF0D-4B08-82DE-92E1FE8E360C@oracle.com> <2800cda6-cc4c-30f8-b373-4a8cd1e224da@oracle.com> Message-ID: Or you mean keep the definitions but move them to "known but unsupported"? > On Jun 7, 2018, at 10:41 PM, Weijun Wang wrote: > > Please take a review > > http://cr.openjdk.java.net/~weijun/9999999/webrev.more-krb5-cleanup/ > > --Max > > >> On Jun 7, 2018, at 10:24 PM, Xuelei Fan wrote: >> >>> Yes, please KRB5 cipher suite from the supported list. >> Typo: Yes, please remove KRB5 cipher suite from the supported list. >> >> On 6/7/2018 7:23 AM, Xuelei Fan wrote: >>> Yes, please KRB5 cipher suite from the supported list. >>> For the public APIs part, please leave it as it is before we deprecate the specification. Some other JSSE provider might still support KRB5 cipher suites. >>> Xuelei >>> On 6/7/2018 1:45 AM, Weijun Wang wrote: >>>> And there are the Kerberos word in public APIs: >>>> >>>> share/classes/javax/net/ssl/SSLContext.java >>>> 336: * Some cipher suites (such as Kerberos) require remote hostname >>>> 366: * Some cipher suites (such as Kerberos) require remote hostname >>>> >>>> share/classes/javax/net/ssl/HttpsURLConnection.java >>>> 106: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>> 130: * such as Kerberos. >>>> 134: * KerberosPrincipal for Kerberos cipher suites. >>>> 158: * return null for non-certificate based ciphersuites, such as Kerberos. >>>> 162: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>> >>>> share/classes/javax/net/ssl/SSLContextSpi.java >>>> 90: * Some cipher suites (such as Kerberos) require remote hostname >>>> 110: * Some cipher suites (such as Kerberos) require remote hostname >>>> >>>> share/classes/javax/net/ssl/SSLEngine.java >>>> 395: * Some cipher suites (such as Kerberos) require remote hostname >>>> 397: * constructor to use Kerberos. >>>> >>>> share/classes/javax/net/ssl/SSLSession.java >>>> 221: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>> 264: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>> 295: * KerberosPrincipal for Kerberos cipher suites. >>>> 313: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>> >>>> share/classes/javax/net/ssl/HandshakeCompletedEvent.java >>>> 122: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>> 145: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>> 178: * KerberosPrincipal for Kerberos cipher suites. >>>> 208: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>> >>>> --Max >>>> >>>>> On Jun 7, 2018, at 4:31 PM, Weijun Wang wrote: >>>>> >>>>> I still see K_KRB5 KeyExchange and TLS_KRB5_WITH_3DES_EDE_CBC_SHA etc in CipherSuite.java. Shall I also remove them. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>> > From xuelei.fan at oracle.com Thu Jun 7 14:47:57 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 7 Jun 2018 07:47:57 -0700 Subject: KRB5 (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> <53FFA825-DB0C-44A5-AFB5-DC14397848FB@oracle.com> <06F6CA08-DF0D-4B08-82DE-92E1FE8E360C@oracle.com> <2800cda6-cc4c-30f8-b373-4a8cd1e224da@oracle.com> Message-ID: <6c2d18c9-15a6-b181-78b0-023b63384c79@oracle.com> CipherSuite.java ---------------- I think we may still want to have KRB5 cipher suite in the unsupported list, as we did for from line 455. - TLS_KRB5_WITH_3DES_EDE_CBC_SHA( - 0x001F, false, "TLS_KRB5_WITH_3DES_EDE_CBC_SHA", "", - ProtocolVersion.PROTOCOLS_TO_T12, - K_KRB5, B_3DES, M_SHA, H_SHA256), + TLS_KRB5_WITH_3DES_EDE_CBC_SHA("TLS_KRB5_WITH_3DES_EDE_CBC_SHA", 0x001F), I may prefer to have lines 545-549 (old lines) there as unsupported cipher suites. Otherwise, looks fine to me. Thanks, Xuelei On 6/7/2018 7:41 AM, Weijun Wang wrote: > Please take a review > > http://cr.openjdk.java.net/~weijun/9999999/webrev.more-krb5-cleanup/ > > --Max > > >> On Jun 7, 2018, at 10:24 PM, Xuelei Fan wrote: >> >>> Yes, please KRB5 cipher suite from the supported list. >> Typo: Yes, please remove KRB5 cipher suite from the supported list. >> >> On 6/7/2018 7:23 AM, Xuelei Fan wrote: >>> Yes, please KRB5 cipher suite from the supported list. >>> For the public APIs part, please leave it as it is before we deprecate the specification. Some other JSSE provider might still support KRB5 cipher suites. >>> Xuelei >>> On 6/7/2018 1:45 AM, Weijun Wang wrote: >>>> And there are the Kerberos word in public APIs: >>>> >>>> share/classes/javax/net/ssl/SSLContext.java >>>> 336: * Some cipher suites (such as Kerberos) require remote hostname >>>> 366: * Some cipher suites (such as Kerberos) require remote hostname >>>> >>>> share/classes/javax/net/ssl/HttpsURLConnection.java >>>> 106: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>> 130: * such as Kerberos. >>>> 134: * KerberosPrincipal for Kerberos cipher suites. >>>> 158: * return null for non-certificate based ciphersuites, such as Kerberos. >>>> 162: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>> >>>> share/classes/javax/net/ssl/SSLContextSpi.java >>>> 90: * Some cipher suites (such as Kerberos) require remote hostname >>>> 110: * Some cipher suites (such as Kerberos) require remote hostname >>>> >>>> share/classes/javax/net/ssl/SSLEngine.java >>>> 395: * Some cipher suites (such as Kerberos) require remote hostname >>>> 397: * constructor to use Kerberos. >>>> >>>> share/classes/javax/net/ssl/SSLSession.java >>>> 221: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>> 264: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>> 295: * KerberosPrincipal for Kerberos cipher suites. >>>> 313: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>> >>>> share/classes/javax/net/ssl/HandshakeCompletedEvent.java >>>> 122: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>> 145: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>> 178: * KerberosPrincipal for Kerberos cipher suites. >>>> 208: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>> >>>> --Max >>>> >>>>> On Jun 7, 2018, at 4:31 PM, Weijun Wang wrote: >>>>> >>>>> I still see K_KRB5 KeyExchange and TLS_KRB5_WITH_3DES_EDE_CBC_SHA etc in CipherSuite.java. Shall I also remove them. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>> > From xuelei.fan at oracle.com Thu Jun 7 14:48:24 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 7 Jun 2018 07:48:24 -0700 Subject: KRB5 (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> <53FFA825-DB0C-44A5-AFB5-DC14397848FB@oracle.com> <06F6CA08-DF0D-4B08-82DE-92E1FE8E360C@oracle.com> <2800cda6-cc4c-30f8-b373-4a8cd1e224da@oracle.com> Message-ID: On 6/7/2018 7:43 AM, Weijun Wang wrote: > Or you mean keep the definitions but move them to "known but unsupported"? > Yes. Xuelei >> On Jun 7, 2018, at 10:41 PM, Weijun Wang wrote: >> >> Please take a review >> >> http://cr.openjdk.java.net/~weijun/9999999/webrev.more-krb5-cleanup/ >> >> --Max >> >> >>> On Jun 7, 2018, at 10:24 PM, Xuelei Fan wrote: >>> >>>> Yes, please KRB5 cipher suite from the supported list. >>> Typo: Yes, please remove KRB5 cipher suite from the supported list. >>> >>> On 6/7/2018 7:23 AM, Xuelei Fan wrote: >>>> Yes, please KRB5 cipher suite from the supported list. >>>> For the public APIs part, please leave it as it is before we deprecate the specification. Some other JSSE provider might still support KRB5 cipher suites. >>>> Xuelei >>>> On 6/7/2018 1:45 AM, Weijun Wang wrote: >>>>> And there are the Kerberos word in public APIs: >>>>> >>>>> share/classes/javax/net/ssl/SSLContext.java >>>>> 336: * Some cipher suites (such as Kerberos) require remote hostname >>>>> 366: * Some cipher suites (such as Kerberos) require remote hostname >>>>> >>>>> share/classes/javax/net/ssl/HttpsURLConnection.java >>>>> 106: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>> 130: * such as Kerberos. >>>>> 134: * KerberosPrincipal for Kerberos cipher suites. >>>>> 158: * return null for non-certificate based ciphersuites, such as Kerberos. >>>>> 162: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>>> >>>>> share/classes/javax/net/ssl/SSLContextSpi.java >>>>> 90: * Some cipher suites (such as Kerberos) require remote hostname >>>>> 110: * Some cipher suites (such as Kerberos) require remote hostname >>>>> >>>>> share/classes/javax/net/ssl/SSLEngine.java >>>>> 395: * Some cipher suites (such as Kerberos) require remote hostname >>>>> 397: * constructor to use Kerberos. >>>>> >>>>> share/classes/javax/net/ssl/SSLSession.java >>>>> 221: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>> 264: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>> 295: * KerberosPrincipal for Kerberos cipher suites. >>>>> 313: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>>> >>>>> share/classes/javax/net/ssl/HandshakeCompletedEvent.java >>>>> 122: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>> 145: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>> 178: * KerberosPrincipal for Kerberos cipher suites. >>>>> 208: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>>> >>>>> --Max >>>>> >>>>>> On Jun 7, 2018, at 4:31 PM, Weijun Wang wrote: >>>>>> >>>>>> I still see K_KRB5 KeyExchange and TLS_KRB5_WITH_3DES_EDE_CBC_SHA etc in CipherSuite.java. Shall I also remove them. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>> >> > From weijun.wang at oracle.com Thu Jun 7 14:49:51 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 7 Jun 2018 22:49:51 +0800 Subject: KRB5 (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <6c2d18c9-15a6-b181-78b0-023b63384c79@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> <53FFA825-DB0C-44A5-AFB5-DC14397848FB@oracle.com> <06F6CA08-DF0D-4B08-82DE-92E1FE8E360C@oracle.com> <2800cda6-cc4c-30f8-b373-4a8cd1e224da@oracle.com> <6c2d18c9-15a6-b181-78b0-023b63384c79@oracle.com> Message-ID: <59766BBD-78D0-4344-9FF6-94C05A237412@oracle.com> > On Jun 7, 2018, at 10:47 PM, Xuelei Fan wrote: > > CipherSuite.java > ---------------- > I think we may still want to have KRB5 cipher suite in the unsupported list, as we did for from line 455. > > - TLS_KRB5_WITH_3DES_EDE_CBC_SHA( > - 0x001F, false, "TLS_KRB5_WITH_3DES_EDE_CBC_SHA", "", > - ProtocolVersion.PROTOCOLS_TO_T12, > - K_KRB5, B_3DES, M_SHA, H_SHA256), > + TLS_KRB5_WITH_3DES_EDE_CBC_SHA("TLS_KRB5_WITH_3DES_EDE_CBC_SHA", 0x001F), Or CS_001F("TLS_KRB5_WITH_3DES_EDE_CBC_SHA", 0x001F), which matches the naming style of other unsupported CS. --Max > > I may prefer to have lines 545-549 (old lines) there as unsupported cipher suites. > > Otherwise, looks fine to me. > > Thanks, > Xuelei > > > On 6/7/2018 7:41 AM, Weijun Wang wrote: >> Please take a review >> http://cr.openjdk.java.net/~weijun/9999999/webrev.more-krb5-cleanup/ >> --Max >>> On Jun 7, 2018, at 10:24 PM, Xuelei Fan wrote: >>> >>>> Yes, please KRB5 cipher suite from the supported list. >>> Typo: Yes, please remove KRB5 cipher suite from the supported list. >>> >>> On 6/7/2018 7:23 AM, Xuelei Fan wrote: >>>> Yes, please KRB5 cipher suite from the supported list. >>>> For the public APIs part, please leave it as it is before we deprecate the specification. Some other JSSE provider might still support KRB5 cipher suites. >>>> Xuelei >>>> On 6/7/2018 1:45 AM, Weijun Wang wrote: >>>>> And there are the Kerberos word in public APIs: >>>>> >>>>> share/classes/javax/net/ssl/SSLContext.java >>>>> 336: * Some cipher suites (such as Kerberos) require remote hostname >>>>> 366: * Some cipher suites (such as Kerberos) require remote hostname >>>>> >>>>> share/classes/javax/net/ssl/HttpsURLConnection.java >>>>> 106: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>> 130: * such as Kerberos. >>>>> 134: * KerberosPrincipal for Kerberos cipher suites. >>>>> 158: * return null for non-certificate based ciphersuites, such as Kerberos. >>>>> 162: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>>> >>>>> share/classes/javax/net/ssl/SSLContextSpi.java >>>>> 90: * Some cipher suites (such as Kerberos) require remote hostname >>>>> 110: * Some cipher suites (such as Kerberos) require remote hostname >>>>> >>>>> share/classes/javax/net/ssl/SSLEngine.java >>>>> 395: * Some cipher suites (such as Kerberos) require remote hostname >>>>> 397: * constructor to use Kerberos. >>>>> >>>>> share/classes/javax/net/ssl/SSLSession.java >>>>> 221: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>> 264: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>> 295: * KerberosPrincipal for Kerberos cipher suites. >>>>> 313: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>>> >>>>> share/classes/javax/net/ssl/HandshakeCompletedEvent.java >>>>> 122: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>> 145: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>> 178: * KerberosPrincipal for Kerberos cipher suites. >>>>> 208: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>>> >>>>> --Max >>>>> >>>>>> On Jun 7, 2018, at 4:31 PM, Weijun Wang wrote: >>>>>> >>>>>> I still see K_KRB5 KeyExchange and TLS_KRB5_WITH_3DES_EDE_CBC_SHA etc in CipherSuite.java. Shall I also remove them. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>> From xuelei.fan at oracle.com Thu Jun 7 14:54:11 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 7 Jun 2018 07:54:11 -0700 Subject: KRB5 (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <59766BBD-78D0-4344-9FF6-94C05A237412@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> <53FFA825-DB0C-44A5-AFB5-DC14397848FB@oracle.com> <06F6CA08-DF0D-4B08-82DE-92E1FE8E360C@oracle.com> <2800cda6-cc4c-30f8-b373-4a8cd1e224da@oracle.com> <6c2d18c9-15a6-b181-78b0-023b63384c79@oracle.com> <59766BBD-78D0-4344-9FF6-94C05A237412@oracle.com> Message-ID: <3192716e-cd42-aeb0-fbf2-cd3fe49aa8bb@oracle.com> On 6/7/2018 7:49 AM, Weijun Wang wrote: > > >> On Jun 7, 2018, at 10:47 PM, Xuelei Fan wrote: >> >> CipherSuite.java >> ---------------- >> I think we may still want to have KRB5 cipher suite in the unsupported list, as we did for from line 455. >> >> - TLS_KRB5_WITH_3DES_EDE_CBC_SHA( >> - 0x001F, false, "TLS_KRB5_WITH_3DES_EDE_CBC_SHA", "", >> - ProtocolVersion.PROTOCOLS_TO_T12, >> - K_KRB5, B_3DES, M_SHA, H_SHA256), >> + TLS_KRB5_WITH_3DES_EDE_CBC_SHA("TLS_KRB5_WITH_3DES_EDE_CBC_SHA", 0x001F), > > Or > > CS_001F("TLS_KRB5_WITH_3DES_EDE_CBC_SHA", 0x001F), > > which matches the naming style of other unsupported CS. > CS_001F is better. Xuelei > --Max > >> >> I may prefer to have lines 545-549 (old lines) there as unsupported cipher suites. >> >> Otherwise, looks fine to me. >> >> Thanks, >> Xuelei >> >> >> On 6/7/2018 7:41 AM, Weijun Wang wrote: >>> Please take a review >>> http://cr.openjdk.java.net/~weijun/9999999/webrev.more-krb5-cleanup/ >>> --Max >>>> On Jun 7, 2018, at 10:24 PM, Xuelei Fan wrote: >>>> >>>>> Yes, please KRB5 cipher suite from the supported list. >>>> Typo: Yes, please remove KRB5 cipher suite from the supported list. >>>> >>>> On 6/7/2018 7:23 AM, Xuelei Fan wrote: >>>>> Yes, please KRB5 cipher suite from the supported list. >>>>> For the public APIs part, please leave it as it is before we deprecate the specification. Some other JSSE provider might still support KRB5 cipher suites. >>>>> Xuelei >>>>> On 6/7/2018 1:45 AM, Weijun Wang wrote: >>>>>> And there are the Kerberos word in public APIs: >>>>>> >>>>>> share/classes/javax/net/ssl/SSLContext.java >>>>>> 336: * Some cipher suites (such as Kerberos) require remote hostname >>>>>> 366: * Some cipher suites (such as Kerberos) require remote hostname >>>>>> >>>>>> share/classes/javax/net/ssl/HttpsURLConnection.java >>>>>> 106: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>>> 130: * such as Kerberos. >>>>>> 134: * KerberosPrincipal for Kerberos cipher suites. >>>>>> 158: * return null for non-certificate based ciphersuites, such as Kerberos. >>>>>> 162: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>>>> >>>>>> share/classes/javax/net/ssl/SSLContextSpi.java >>>>>> 90: * Some cipher suites (such as Kerberos) require remote hostname >>>>>> 110: * Some cipher suites (such as Kerberos) require remote hostname >>>>>> >>>>>> share/classes/javax/net/ssl/SSLEngine.java >>>>>> 395: * Some cipher suites (such as Kerberos) require remote hostname >>>>>> 397: * constructor to use Kerberos. >>>>>> >>>>>> share/classes/javax/net/ssl/SSLSession.java >>>>>> 221: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>>> 264: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>>> 295: * KerberosPrincipal for Kerberos cipher suites. >>>>>> 313: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>>>> >>>>>> share/classes/javax/net/ssl/HandshakeCompletedEvent.java >>>>>> 122: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>>> 145: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>>> 178: * KerberosPrincipal for Kerberos cipher suites. >>>>>> 208: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>>>> >>>>>> --Max >>>>>> >>>>>>> On Jun 7, 2018, at 4:31 PM, Weijun Wang wrote: >>>>>>> >>>>>>> I still see K_KRB5 KeyExchange and TLS_KRB5_WITH_3DES_EDE_CBC_SHA etc in CipherSuite.java. Shall I also remove them. >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>> > From weijun.wang at oracle.com Thu Jun 7 15:01:47 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 7 Jun 2018 23:01:47 +0800 Subject: KRB5 (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <59766BBD-78D0-4344-9FF6-94C05A237412@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> <53FFA825-DB0C-44A5-AFB5-DC14397848FB@oracle.com> <06F6CA08-DF0D-4B08-82DE-92E1FE8E360C@oracle.com> <2800cda6-cc4c-30f8-b373-4a8cd1e224da@oracle.com> <6c2d18c9-15a6-b181-78b0-023b63384c79@oracle.com> <59766BBD-78D0-4344-9FF6-94C05A237412@oracle.com> Message-ID: <514480CA-93F0-4861-BB30-F0D5042276B3@oracle.com> Still at http://cr.openjdk.java.net/~weijun/9999999/webrev.more-krb5-cleanup/ I keep the existing unsupported KRB5 ciphersuites and move the 10 previously supported ones there. --Max > On Jun 7, 2018, at 10:49 PM, Weijun Wang wrote: > > > >> On Jun 7, 2018, at 10:47 PM, Xuelei Fan wrote: >> >> CipherSuite.java >> ---------------- >> I think we may still want to have KRB5 cipher suite in the unsupported list, as we did for from line 455. >> >> - TLS_KRB5_WITH_3DES_EDE_CBC_SHA( >> - 0x001F, false, "TLS_KRB5_WITH_3DES_EDE_CBC_SHA", "", >> - ProtocolVersion.PROTOCOLS_TO_T12, >> - K_KRB5, B_3DES, M_SHA, H_SHA256), >> + TLS_KRB5_WITH_3DES_EDE_CBC_SHA("TLS_KRB5_WITH_3DES_EDE_CBC_SHA", 0x001F), > > Or > > CS_001F("TLS_KRB5_WITH_3DES_EDE_CBC_SHA", 0x001F), > > which matches the naming style of other unsupported CS. > > --Max > >> >> I may prefer to have lines 545-549 (old lines) there as unsupported cipher suites. >> >> Otherwise, looks fine to me. >> >> Thanks, >> Xuelei >> >> >> On 6/7/2018 7:41 AM, Weijun Wang wrote: >>> Please take a review >>> http://cr.openjdk.java.net/~weijun/9999999/webrev.more-krb5-cleanup/ >>> --Max >>>> On Jun 7, 2018, at 10:24 PM, Xuelei Fan wrote: >>>> >>>>> Yes, please KRB5 cipher suite from the supported list. >>>> Typo: Yes, please remove KRB5 cipher suite from the supported list. >>>> >>>> On 6/7/2018 7:23 AM, Xuelei Fan wrote: >>>>> Yes, please KRB5 cipher suite from the supported list. >>>>> For the public APIs part, please leave it as it is before we deprecate the specification. Some other JSSE provider might still support KRB5 cipher suites. >>>>> Xuelei >>>>> On 6/7/2018 1:45 AM, Weijun Wang wrote: >>>>>> And there are the Kerberos word in public APIs: >>>>>> >>>>>> share/classes/javax/net/ssl/SSLContext.java >>>>>> 336: * Some cipher suites (such as Kerberos) require remote hostname >>>>>> 366: * Some cipher suites (such as Kerberos) require remote hostname >>>>>> >>>>>> share/classes/javax/net/ssl/HttpsURLConnection.java >>>>>> 106: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>>> 130: * such as Kerberos. >>>>>> 134: * KerberosPrincipal for Kerberos cipher suites. >>>>>> 158: * return null for non-certificate based ciphersuites, such as Kerberos. >>>>>> 162: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>>>> >>>>>> share/classes/javax/net/ssl/SSLContextSpi.java >>>>>> 90: * Some cipher suites (such as Kerberos) require remote hostname >>>>>> 110: * Some cipher suites (such as Kerberos) require remote hostname >>>>>> >>>>>> share/classes/javax/net/ssl/SSLEngine.java >>>>>> 395: * Some cipher suites (such as Kerberos) require remote hostname >>>>>> 397: * constructor to use Kerberos. >>>>>> >>>>>> share/classes/javax/net/ssl/SSLSession.java >>>>>> 221: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>>> 264: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>>> 295: * KerberosPrincipal for Kerberos cipher suites. >>>>>> 313: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>>>> >>>>>> share/classes/javax/net/ssl/HandshakeCompletedEvent.java >>>>>> 122: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>>> 145: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>>> 178: * KerberosPrincipal for Kerberos cipher suites. >>>>>> 208: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>>>> >>>>>> --Max >>>>>> >>>>>>> On Jun 7, 2018, at 4:31 PM, Weijun Wang wrote: >>>>>>> >>>>>>> I still see K_KRB5 KeyExchange and TLS_KRB5_WITH_3DES_EDE_CBC_SHA etc in CipherSuite.java. Shall I also remove them. >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>> > From xuelei.fan at oracle.com Thu Jun 7 15:03:19 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 7 Jun 2018 08:03:19 -0700 Subject: KRB5 (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <514480CA-93F0-4861-BB30-F0D5042276B3@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> <53FFA825-DB0C-44A5-AFB5-DC14397848FB@oracle.com> <06F6CA08-DF0D-4B08-82DE-92E1FE8E360C@oracle.com> <2800cda6-cc4c-30f8-b373-4a8cd1e224da@oracle.com> <6c2d18c9-15a6-b181-78b0-023b63384c79@oracle.com> <59766BBD-78D0-4344-9FF6-94C05A237412@oracle.com> <514480CA-93F0-4861-BB30-F0D5042276B3@oracle.com> Message-ID: <1a1dd474-7a17-d0f4-d3ef-4898cc030f1d@oracle.com> Looks fine to me. Thanks! Xuelei On 6/7/2018 8:01 AM, Weijun Wang wrote: > Still at > > http://cr.openjdk.java.net/~weijun/9999999/webrev.more-krb5-cleanup/ > > I keep the existing unsupported KRB5 ciphersuites and move the 10 previously supported ones there. > > --Max > > >> On Jun 7, 2018, at 10:49 PM, Weijun Wang wrote: >> >> >> >>> On Jun 7, 2018, at 10:47 PM, Xuelei Fan wrote: >>> >>> CipherSuite.java >>> ---------------- >>> I think we may still want to have KRB5 cipher suite in the unsupported list, as we did for from line 455. >>> >>> - TLS_KRB5_WITH_3DES_EDE_CBC_SHA( >>> - 0x001F, false, "TLS_KRB5_WITH_3DES_EDE_CBC_SHA", "", >>> - ProtocolVersion.PROTOCOLS_TO_T12, >>> - K_KRB5, B_3DES, M_SHA, H_SHA256), >>> + TLS_KRB5_WITH_3DES_EDE_CBC_SHA("TLS_KRB5_WITH_3DES_EDE_CBC_SHA", 0x001F), >> >> Or >> >> CS_001F("TLS_KRB5_WITH_3DES_EDE_CBC_SHA", 0x001F), >> >> which matches the naming style of other unsupported CS. >> >> --Max >> >>> >>> I may prefer to have lines 545-549 (old lines) there as unsupported cipher suites. >>> >>> Otherwise, looks fine to me. >>> >>> Thanks, >>> Xuelei >>> >>> >>> On 6/7/2018 7:41 AM, Weijun Wang wrote: >>>> Please take a review >>>> http://cr.openjdk.java.net/~weijun/9999999/webrev.more-krb5-cleanup/ >>>> --Max >>>>> On Jun 7, 2018, at 10:24 PM, Xuelei Fan wrote: >>>>> >>>>>> Yes, please KRB5 cipher suite from the supported list. >>>>> Typo: Yes, please remove KRB5 cipher suite from the supported list. >>>>> >>>>> On 6/7/2018 7:23 AM, Xuelei Fan wrote: >>>>>> Yes, please KRB5 cipher suite from the supported list. >>>>>> For the public APIs part, please leave it as it is before we deprecate the specification. Some other JSSE provider might still support KRB5 cipher suites. >>>>>> Xuelei >>>>>> On 6/7/2018 1:45 AM, Weijun Wang wrote: >>>>>>> And there are the Kerberos word in public APIs: >>>>>>> >>>>>>> share/classes/javax/net/ssl/SSLContext.java >>>>>>> 336: * Some cipher suites (such as Kerberos) require remote hostname >>>>>>> 366: * Some cipher suites (such as Kerberos) require remote hostname >>>>>>> >>>>>>> share/classes/javax/net/ssl/HttpsURLConnection.java >>>>>>> 106: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>>>> 130: * such as Kerberos. >>>>>>> 134: * KerberosPrincipal for Kerberos cipher suites. >>>>>>> 158: * return null for non-certificate based ciphersuites, such as Kerberos. >>>>>>> 162: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>>>>> >>>>>>> share/classes/javax/net/ssl/SSLContextSpi.java >>>>>>> 90: * Some cipher suites (such as Kerberos) require remote hostname >>>>>>> 110: * Some cipher suites (such as Kerberos) require remote hostname >>>>>>> >>>>>>> share/classes/javax/net/ssl/SSLEngine.java >>>>>>> 395: * Some cipher suites (such as Kerberos) require remote hostname >>>>>>> 397: * constructor to use Kerberos. >>>>>>> >>>>>>> share/classes/javax/net/ssl/SSLSession.java >>>>>>> 221: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>>>> 264: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>>>> 295: * KerberosPrincipal for Kerberos cipher suites. >>>>>>> 313: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>>>>> >>>>>>> share/classes/javax/net/ssl/HandshakeCompletedEvent.java >>>>>>> 122: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>>>> 145: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>>>> 178: * KerberosPrincipal for Kerberos cipher suites. >>>>>>> 208: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>>>>> >>>>>>> --Max >>>>>>> >>>>>>>> On Jun 7, 2018, at 4:31 PM, Weijun Wang wrote: >>>>>>>> >>>>>>>> I still see K_KRB5 KeyExchange and TLS_KRB5_WITH_3DES_EDE_CBC_SHA etc in CipherSuite.java. Shall I also remove them. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>> >> > From weijun.wang at oracle.com Thu Jun 7 15:56:57 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 7 Jun 2018 23:56:57 +0800 Subject: KRB5 (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <1a1dd474-7a17-d0f4-d3ef-4898cc030f1d@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> <53FFA825-DB0C-44A5-AFB5-DC14397848FB@oracle.com> <06F6CA08-DF0D-4B08-82DE-92E1FE8E360C@oracle.com> <2800cda6-cc4c-30f8-b373-4a8cd1e224da@oracle.com> <6c2d18c9-15a6-b181-78b0-023b63384c79@oracle.com> <59766BBD-78D0-4344-9FF6-94C05A237412@oracle.com> <514480CA-93F0-4861-BB30-F0D5042276B3@oracle.com> <1a1dd474-7a17-d0f4-d3ef-4898cc030f1d@oracle.com> Message-ID: Oops, another place needs change http://hg.openjdk.java.net/jdk/sandbox/rev/64aa781522be --Max > On Jun 7, 2018, at 11:03 PM, Xuelei Fan wrote: > > Looks fine to me. Thanks! > > Xuelei > > On 6/7/2018 8:01 AM, Weijun Wang wrote: >> Still at >> http://cr.openjdk.java.net/~weijun/9999999/webrev.more-krb5-cleanup/ >> I keep the existing unsupported KRB5 ciphersuites and move the 10 previously supported ones there. >> --Max >>> On Jun 7, 2018, at 10:49 PM, Weijun Wang wrote: >>> >>> >>> >>>> On Jun 7, 2018, at 10:47 PM, Xuelei Fan wrote: >>>> >>>> CipherSuite.java >>>> ---------------- >>>> I think we may still want to have KRB5 cipher suite in the unsupported list, as we did for from line 455. >>>> >>>> - TLS_KRB5_WITH_3DES_EDE_CBC_SHA( >>>> - 0x001F, false, "TLS_KRB5_WITH_3DES_EDE_CBC_SHA", "", >>>> - ProtocolVersion.PROTOCOLS_TO_T12, >>>> - K_KRB5, B_3DES, M_SHA, H_SHA256), >>>> + TLS_KRB5_WITH_3DES_EDE_CBC_SHA("TLS_KRB5_WITH_3DES_EDE_CBC_SHA", 0x001F), >>> >>> Or >>> >>> CS_001F("TLS_KRB5_WITH_3DES_EDE_CBC_SHA", 0x001F), >>> >>> which matches the naming style of other unsupported CS. >>> >>> --Max >>> >>>> >>>> I may prefer to have lines 545-549 (old lines) there as unsupported cipher suites. >>>> >>>> Otherwise, looks fine to me. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> >>>> On 6/7/2018 7:41 AM, Weijun Wang wrote: >>>>> Please take a review >>>>> http://cr.openjdk.java.net/~weijun/9999999/webrev.more-krb5-cleanup/ >>>>> --Max >>>>>> On Jun 7, 2018, at 10:24 PM, Xuelei Fan wrote: >>>>>> >>>>>>> Yes, please KRB5 cipher suite from the supported list. >>>>>> Typo: Yes, please remove KRB5 cipher suite from the supported list. >>>>>> >>>>>> On 6/7/2018 7:23 AM, Xuelei Fan wrote: >>>>>>> Yes, please KRB5 cipher suite from the supported list. >>>>>>> For the public APIs part, please leave it as it is before we deprecate the specification. Some other JSSE provider might still support KRB5 cipher suites. >>>>>>> Xuelei >>>>>>> On 6/7/2018 1:45 AM, Weijun Wang wrote: >>>>>>>> And there are the Kerberos word in public APIs: >>>>>>>> >>>>>>>> share/classes/javax/net/ssl/SSLContext.java >>>>>>>> 336: * Some cipher suites (such as Kerberos) require remote hostname >>>>>>>> 366: * Some cipher suites (such as Kerberos) require remote hostname >>>>>>>> >>>>>>>> share/classes/javax/net/ssl/HttpsURLConnection.java >>>>>>>> 106: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>>>>> 130: * such as Kerberos. >>>>>>>> 134: * KerberosPrincipal for Kerberos cipher suites. >>>>>>>> 158: * return null for non-certificate based ciphersuites, such as Kerberos. >>>>>>>> 162: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>>>>>> >>>>>>>> share/classes/javax/net/ssl/SSLContextSpi.java >>>>>>>> 90: * Some cipher suites (such as Kerberos) require remote hostname >>>>>>>> 110: * Some cipher suites (such as Kerberos) require remote hostname >>>>>>>> >>>>>>>> share/classes/javax/net/ssl/SSLEngine.java >>>>>>>> 395: * Some cipher suites (such as Kerberos) require remote hostname >>>>>>>> 397: * constructor to use Kerberos. >>>>>>>> >>>>>>>> share/classes/javax/net/ssl/SSLSession.java >>>>>>>> 221: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>>>>> 264: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>>>>> 295: * KerberosPrincipal for Kerberos cipher suites. >>>>>>>> 313: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>>>>>> >>>>>>>> share/classes/javax/net/ssl/HandshakeCompletedEvent.java >>>>>>>> 122: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>>>>> 145: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>>>>> 178: * KerberosPrincipal for Kerberos cipher suites. >>>>>>>> 208: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>>>>>> >>>>>>>> --Max >>>>>>>> >>>>>>>>> On Jun 7, 2018, at 4:31 PM, Weijun Wang wrote: >>>>>>>>> >>>>>>>>> I still see K_KRB5 KeyExchange and TLS_KRB5_WITH_3DES_EDE_CBC_SHA etc in CipherSuite.java. Shall I also remove them. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Max >>>>>>>>> >>>>>>>> >>> From xuelei.fan at oracle.com Thu Jun 7 16:32:52 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 7 Jun 2018 09:32:52 -0700 Subject: KRB5 (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> <53FFA825-DB0C-44A5-AFB5-DC14397848FB@oracle.com> <06F6CA08-DF0D-4B08-82DE-92E1FE8E360C@oracle.com> <2800cda6-cc4c-30f8-b373-4a8cd1e224da@oracle.com> <6c2d18c9-15a6-b181-78b0-023b63384c79@oracle.com> <59766BBD-78D0-4344-9FF6-94C05A237412@oracle.com> <514480CA-93F0-4861-BB30-F0D5042276B3@oracle.com> <1a1dd474-7a17-d0f4-d3ef-4898cc030f1d@oracle.com> Message-ID: <1b6f391a-ff53-1940-9d45-f7f9a6f0a252@oracle.com> Looks good to me. Xuelei On 6/7/2018 8:56 AM, Weijun Wang wrote: > Oops, another place needs change > > http://hg.openjdk.java.net/jdk/sandbox/rev/64aa781522be > > --Max > >> On Jun 7, 2018, at 11:03 PM, Xuelei Fan wrote: >> >> Looks fine to me. Thanks! >> >> Xuelei >> >> On 6/7/2018 8:01 AM, Weijun Wang wrote: >>> Still at >>> http://cr.openjdk.java.net/~weijun/9999999/webrev.more-krb5-cleanup/ >>> I keep the existing unsupported KRB5 ciphersuites and move the 10 previously supported ones there. >>> --Max >>>> On Jun 7, 2018, at 10:49 PM, Weijun Wang wrote: >>>> >>>> >>>> >>>>> On Jun 7, 2018, at 10:47 PM, Xuelei Fan wrote: >>>>> >>>>> CipherSuite.java >>>>> ---------------- >>>>> I think we may still want to have KRB5 cipher suite in the unsupported list, as we did for from line 455. >>>>> >>>>> - TLS_KRB5_WITH_3DES_EDE_CBC_SHA( >>>>> - 0x001F, false, "TLS_KRB5_WITH_3DES_EDE_CBC_SHA", "", >>>>> - ProtocolVersion.PROTOCOLS_TO_T12, >>>>> - K_KRB5, B_3DES, M_SHA, H_SHA256), >>>>> + TLS_KRB5_WITH_3DES_EDE_CBC_SHA("TLS_KRB5_WITH_3DES_EDE_CBC_SHA", 0x001F), >>>> >>>> Or >>>> >>>> CS_001F("TLS_KRB5_WITH_3DES_EDE_CBC_SHA", 0x001F), >>>> >>>> which matches the naming style of other unsupported CS. >>>> >>>> --Max >>>> >>>>> >>>>> I may prefer to have lines 545-549 (old lines) there as unsupported cipher suites. >>>>> >>>>> Otherwise, looks fine to me. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> >>>>> On 6/7/2018 7:41 AM, Weijun Wang wrote: >>>>>> Please take a review >>>>>> http://cr.openjdk.java.net/~weijun/9999999/webrev.more-krb5-cleanup/ >>>>>> --Max >>>>>>> On Jun 7, 2018, at 10:24 PM, Xuelei Fan wrote: >>>>>>> >>>>>>>> Yes, please KRB5 cipher suite from the supported list. >>>>>>> Typo: Yes, please remove KRB5 cipher suite from the supported list. >>>>>>> >>>>>>> On 6/7/2018 7:23 AM, Xuelei Fan wrote: >>>>>>>> Yes, please KRB5 cipher suite from the supported list. >>>>>>>> For the public APIs part, please leave it as it is before we deprecate the specification. Some other JSSE provider might still support KRB5 cipher suites. >>>>>>>> Xuelei >>>>>>>> On 6/7/2018 1:45 AM, Weijun Wang wrote: >>>>>>>>> And there are the Kerberos word in public APIs: >>>>>>>>> >>>>>>>>> share/classes/javax/net/ssl/SSLContext.java >>>>>>>>> 336: * Some cipher suites (such as Kerberos) require remote hostname >>>>>>>>> 366: * Some cipher suites (such as Kerberos) require remote hostname >>>>>>>>> >>>>>>>>> share/classes/javax/net/ssl/HttpsURLConnection.java >>>>>>>>> 106: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>>>>>> 130: * such as Kerberos. >>>>>>>>> 134: * KerberosPrincipal for Kerberos cipher suites. >>>>>>>>> 158: * return null for non-certificate based ciphersuites, such as Kerberos. >>>>>>>>> 162: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>>>>>>> >>>>>>>>> share/classes/javax/net/ssl/SSLContextSpi.java >>>>>>>>> 90: * Some cipher suites (such as Kerberos) require remote hostname >>>>>>>>> 110: * Some cipher suites (such as Kerberos) require remote hostname >>>>>>>>> >>>>>>>>> share/classes/javax/net/ssl/SSLEngine.java >>>>>>>>> 395: * Some cipher suites (such as Kerberos) require remote hostname >>>>>>>>> 397: * constructor to use Kerberos. >>>>>>>>> >>>>>>>>> share/classes/javax/net/ssl/SSLSession.java >>>>>>>>> 221: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>>>>>> 264: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>>>>>> 295: * KerberosPrincipal for Kerberos cipher suites. >>>>>>>>> 313: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>>>>>>> >>>>>>>>> share/classes/javax/net/ssl/HandshakeCompletedEvent.java >>>>>>>>> 122: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>>>>>> 145: * such as Kerberos, will throw an SSLPeerUnverifiedException. >>>>>>>>> 178: * KerberosPrincipal for Kerberos cipher suites. >>>>>>>>> 208: * KerberosPrincipal for Kerberos cipher suites. If no principal was >>>>>>>>> >>>>>>>>> --Max >>>>>>>>> >>>>>>>>>> On Jun 7, 2018, at 4:31 PM, Weijun Wang wrote: >>>>>>>>>> >>>>>>>>>> I still see K_KRB5 KeyExchange and TLS_KRB5_WITH_3DES_EDE_CBC_SHA etc in CipherSuite.java. Shall I also remove them. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Max >>>>>>>>>> >>>>>>>>> >>>> > From bradford.wetmore at oracle.com Thu Jun 7 17:28:58 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 7 Jun 2018 10:28:58 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> Message-ID: Also reviewed SSLSocketFactoryImpl.java BaseSSLSocketImpl.java ---------------------- I don't see where requireCloseNotify is actually being used in the remaining code. If you are removing this functionality, you should probably be calling that out in your CSR. SSLSessionContextImpl.java -------------------------- The only change here was to reorder the import of Vector (obsolete) and update the copyright? May I ask why? If this was somehow a netbeans suggestion, there were several other things that could be updated that seem more important. e.g. 37-39 could be made final. 207: unnecessary unboxing. Brad On 6/6/2018 5:45 PM, Bradford Wetmore wrote: > Today, I looked over SunJSSE.java, Utilities.java, and module-info.java. > ?Mostly nits below, some style things. > > > Utilities.java > -------------- > > 39:? hexDigits can be private. > > 42:? Extra level of indent.? 4 or 8. > > 39-41:? Nits: When variables are static finals, they are usually written > uppercase. > > 115:? Extra " " and can we get SNI cap'd? > > HostName for? server name indication > -> > HostName for Server Name Indication > > 150:? Minor Nit:? You're concating ("+") and then using > StringBuilder.append(), instead of simply append chaining which might be > slightly more efficient. > > 167-217:? The code looks ok, but this might be reworked to take better > advantage of StringBuilder.append() chaining, rather than the mix of > concat and append here now.? e.g. what you did with toHexString(long). I > see much of the same code repeated over and over here.? Can be done later. > > Brad > > > > On 6/3/2018 9:43 PM, Xuelei Fan wrote: >> Hi, >> >> Here it the 2nd full webrev: >> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >> >> and the delta update to the 1st webrev: >> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >> >> Xuelei >> >> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>> Hi, >>> >>> I'd like to invite you to review the TLS 1.3 implementation.? I >>> appreciate it if I could have compatibility and specification >>> feedback before May 31, 2018, and implementation feedback before June >>> 7, 2018. >>> >>> Here is the webrev: >>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>> >>> The formal TLS 1.3 specification is not finalized yet, although it >>> had been approved to be a standard.? The implementation is based on >>> the draft version 28: >>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>> >>> For the overall description of this enhancement, please refer to JEP >>> 332: >>> ???? http://openjdk.java.net/jeps/332 >>> >>> For the compatibility and specification update, please refer to CSR >>> 8202625: >>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>> >>> Note that we are using the sandbox for the development right now. >>> For more information, please refer to Bradford's previous email: >>> >>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>> >>> Thanks & Regards, >>> Xuelei From adam.petcher at oracle.com Thu Jun 7 18:03:43 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 7 Jun 2018 14:03:43 -0400 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <4148acdf-3f12-4301-0b22-c7deaf16f62f@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <4148acdf-3f12-4301-0b22-c7deaf16f62f@oracle.com> Message-ID: <8cfa21d0-13e4-7320-21a8-87d640d77b63@oracle.com> Updates to address these comments: http://hg.openjdk.java.net/jdk/sandbox/rev/2dc6efcdeb11 http://hg.openjdk.java.net/jdk/sandbox/rev/97447478b7da On 6/3/2018 8:24 PM, Xuelei Fan wrote: > > http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > PskKeyExchangeModesExtension.java > --------------------------------- > ? 66???? static final class PskKeyExchangeModesSpec implements > SSLExtensionSpec { > ? 67 > ? 68 > ? 69???????? final List modes; > > This class can be private. > > The modes may be null if an invalid value is used.? No code to check > if the value if valid and behavior accordingly.? The lacking of the > checking could have unexpected issues. > > Xuelei > > On 5/25/2018 4:45 PM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 implementation.? I >> appreciate it if I could have compatibility and specification >> feedback before May 31, 2018, and implementation feedback before June >> 7, 2018. >> >> Here is the webrev: >> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> The formal TLS 1.3 specification is not finalized yet, although it >> had been approved to be a standard.? The implementation is based on >> the draft version 28: >> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >> >> For the overall description of this enhancement, please refer to JEP >> 332: >> ???? http://openjdk.java.net/jeps/332 >> >> For the compatibility and specification update, please refer to CSR >> 8202625: >> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >> >> Note that we are using the sandbox for the development right now.? >> For more information, please refer to Bradford's previous email: >> >> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >> >> Thanks & Regards, >> Xuelei From magnus.ihse.bursie at oracle.com Thu Jun 7 20:22:48 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 7 Jun 2018 22:22:48 +0200 Subject: RFR (XL): JDK-8204572 SetupJdkLibrary should setup SRC and -I flags automatically Message-ID: This change needs some background information. I've been working on simplifying and streamlining the compilation of native libraries of the JDK. Previously, I introduced the SetupJdkLibrary function, and started to get a better control of compiler flags. This patch continues on both paths. The original intent of this change, which I naively thought was going to be much simpler than it turned out :-) was to separate the -I flags (location of header files) from other flags, and to generate these automatically, wherever possible. Since we have a standard way of locating native code, and most libraries just want to have an -I path to their own source base and the generated Java header, we should be able to provide this in SetupJdkLibrary. This turned out to be closely related to SetupJdkLibrary being able to discover the location of the SRC directories itself, using "convention over configuration" and assuming that the library "libfoo" for "java.module" would be located in java.module/*/native/libfoo. While this sounds simple in theory, when actually trying to implement this I of course ran into all the places where some special handling was indeed needed. So even if like 90% of all libraries were simple to get to build using automated discovery of source and header directories, the 10% that did not caused me much more headaches than I had anticipated. On the other hand, now that I've sorted out all those places, the few remaining odd solutions is clearly documented and not just something that "just happens" due to strange configurations. One file deserves mentioning specifically: Awt2dLibraries.gmk. The java.desktop libraries are unfortunately quite entangled with each other, and do not readily follow the patterns that are used elsewhere in the code base. So it might just look like the file has just gone from one state of messiness, to another, which would hardly be an improvement. :-( I would still argue that the new messiness is better: It is now much clearer in what ways the libraries diverge from our standard assumption, and what course of action needs to be taken to minimize these differences. (Which is something I believe should be done -- these issues are not just cosmetic but is the root of most of the issues we always see for these libraries, when upgrading compilers, etc.) During this change, I noticed that not all native libraries include the proper generated header file. This is a dangerous coding practice, since a change in the Java part of the interface might not get picked up properly in the native part. I've added the missing includes that I've detected, and due to these changes, I'm also including the component teams in what is really only a build change. As can be seen for jdk.crypto.mscapi; there had indeed been changes that needed correcting. Since this is (basically) a pure build change, my gold standard here has been the build compare script. In essence, the build output prior to my change and with this change are 100% identical. In truth, this is a bit too strong a claim. A few changes has occurred, but none of them should matter. Here's a breakdown of the compare.sh results: * Windows-x64: No differences at all. * Solaris: Two libraries are reported to differ: libsaproc.so and libfontmanager.so, both with a disass diff on ~700 bytes. Analyzing this, I found that the object files used to link these two libraries has no disass differences. They have a slight binary difference and a difference in size, due to the include paths being different (and this is stored in the .o file, which makes it different). Somehow this apparently triggers the linker to generate a slightly different code in a few places, using a different register or so. (Weird...) * MacOS: Two libraries are reported to differ: libjava.dylib and libmlib_image.dylib, both of them just reported as a binary diff (no symbol, disass or fulldump differences). This is not really unsuspected, but I analyzed it anyway. I found that for libjava.dylib, a single .o file was different. This one was actually picked up from closed sources, and are not really relevant for OpenJDK. Anyway, the reason for the difference was the same as for the Solaris libs; the include paths had changes, which caused a binary diff. For libmlib_image.dylib, the link order had changed causing the noted binary difference. * Linux: On linux, the compare script noted differences for libextnet, libjava, libmlib_image, libprefs, libsaproc, libsplashscreen and libsunec. The differences for libextnet, libprefs, libsplashscreen and libsunec turned out to be caused by the added #include of the generated Java headers. This caused binary differences (reasonably), and for some odd reason also a symbol difference in java_awt_SplashScreen.o (clazz.10057 and mid.10058 were replaced by clazz.10015 and mid.10016). I can't claim to understand this, but I'm assuming it's some kind of generated code. libsaproc and libjava changes was caused by closed source changes, and is therefore not relevant to OpenJDK. For libmlib_image.dylib, the link order had changed causing the noted binary difference, as on MacOS. Bug: https://bugs.openjdk.java.net/browse/JDK-8204572 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8204572-autodetect-SRC-and-headers-dirs/webrev.01 /Magnus From jamil.j.nimeh at oracle.com Thu Jun 7 20:38:50 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 7 Jun 2018 13:38:50 -0700 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: <0419f803-e67c-074c-ff02-f0d45326d3b4@oracle.com> References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> <0419f803-e67c-074c-ff02-f0d45326d3b4@oracle.com> Message-ID: Hello there!? Only nits for these two files (and possibly more based on a method name change), but they've been reviewed in the past so most issues have already been dealt with: * SSLExtension.java o 39: Silly nit - you could update this to say RFC 6066, since we're probably working to that standard these days and if there are any minor diffs between the two we'd probably favor the latter. o Various: More nits - we still seem to have a few "Concumer" methods floating around.? I'll go through the code and fix those. o 575 - 581: Can we remove this block or do we need to hang onto it? * SSLExtensions.java o 142-144: Another commented out chunk of code.? Do we need it?? Given where it is situated (right after a continue statement) it looks like something that should be removed. --Jamil On 02/22/2018 12:29 PM, Xuelei Fan wrote: > Updated to use package private HKDF implementation. > > webrev (based on JDK-8185576): > ????? http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.01 > > webrev (including JDK-8185576): > ????? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 > > Thanks, > Xuelei > > On 2/20/2018 11:57 AM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 full handshake >> implementation.? I appreciate it if I could have feedback before >> March 9, 2018. >> >> In the "JDK-8185576: New handshake implementation" [1] code review >> around, I was trying to re-org the TLS handshaking implementation in the >> SunJSSE provider.? If you had reviewed that part, you can start from >> the following webrev that based on the update of JDK-8185576: >> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.00 >> >> If you would like start from earlier, here is the webrev that >> contains the handshaking implementation re-org in JDK-8185576: >> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> >> This changeset only implements the full handshake of TLS 1.3, rather >> then a fully implementation of the latest TLS 1.3 draft [2]. >> >> In this implementation, I removed: >> 1. the KRB5 cipher suite implementation. >> Please let me know if you are still using KRB5 cipher suite.? I may >> not add them back if no objections. >> >> 2. OCSP stapling. >> This feature will be added back later. >> >> Resumption and key update, and more features may be added later. >> >> Thanks & Regards, >> Xuelei >> >> [1]: >> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016642.html >> >> [2]: https://tools.ietf.org/html/draft-ietf-tls-tls13-24 -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Thu Jun 7 21:20:52 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 7 Jun 2018 14:20:52 -0700 Subject: RFR (XL): JDK-8204572 SetupJdkLibrary should setup SRC and -I flags automatically In-Reply-To: References: Message-ID: Hello Magnus, Very nice refactoring! JdkNativeCompilation.gmk line 126-127 looks a bit long. There is an extra space on 126. Also, why not addprefix for adding -I instead of clunky foreach? Not that I care greatly, but I usually prefer that construct. Otherwise looks good. /Erik On 2018-06-07 13:22, Magnus Ihse Bursie wrote: > This change needs some background information. > > I've been working on simplifying and streamlining the compilation of > native libraries of the JDK. Previously, I introduced the > SetupJdkLibrary function, and started to get a better control of > compiler flags. This patch continues on both paths. > > The original intent of this change, which I naively thought was going > to be much simpler than it turned out :-) was to separate the -I flags > (location of header files) from other flags, and to generate these > automatically, wherever possible. Since we have a standard way of > locating native code, and most libraries just want to have an -I path > to their own source base and the generated Java header, we should be > able to provide this in SetupJdkLibrary. > > This turned out to be closely related to SetupJdkLibrary being able to > discover the location of the SRC directories itself, using "convention > over configuration" and assuming that the library "libfoo" for > "java.module" would be located in java.module/*/native/libfoo. > > While this sounds simple in theory, when actually trying to implement > this I of course ran into all the places where some special handling > was indeed needed. So even if like 90% of all libraries were simple to > get to build using automated discovery of source and header > directories, the 10% that did not caused me much more headaches than I > had anticipated. On the other hand, now that I've sorted out all those > places, the few remaining odd solutions is clearly documented and not > just something that "just happens" due to strange configurations. > > One file deserves mentioning specifically: Awt2dLibraries.gmk. The > java.desktop libraries are unfortunately quite entangled with each > other, and do not readily follow the patterns that are used elsewhere > in the code base. So it might just look like the file has just gone > from one state of messiness, to another, which would hardly be an > improvement. :-( I would still argue that the new messiness is better: > It is now much clearer in what ways the libraries diverge from our > standard assumption, and what course of action needs to be taken to > minimize these differences. (Which is something I believe should be > done -- these issues are not just cosmetic but is the root of most of > the issues we always see for these libraries, when upgrading > compilers, etc.) > > During this change, I noticed that not all native libraries include > the proper generated header file. This is a dangerous coding practice, > since a change in the Java part of the interface might not get picked > up properly in the native part. I've added the missing includes that > I've detected, and due to these changes, I'm also including the > component teams in what is really only a build change. As can be seen > for jdk.crypto.mscapi; there had indeed been changes that needed > correcting. > > Since this is (basically) a pure build change, my gold standard here > has been the build compare script. In essence, the build output prior > to my change and with this change are 100% identical. In truth, this > is a bit too strong a claim. A few changes has occurred, but none of > them should matter. Here's a breakdown of the compare.sh results: > > * Windows-x64: > > No differences at all. > > * Solaris: > > Two libraries are reported to differ: libsaproc.so and > libfontmanager.so, both with a disass diff on ~700 bytes. Analyzing > this, I found that the object files used to link these two libraries > has no disass differences. They have a slight binary difference and a > difference in size, due to the include paths being different (and this > is stored in the .o file, which makes it different). Somehow this > apparently triggers the linker to generate a slightly different code > in a few places, using a different register or so. (Weird...) > > * MacOS: > > Two libraries are reported to differ: libjava.dylib and > libmlib_image.dylib, both of them just reported as a binary diff (no > symbol, disass or fulldump differences). This is not really > unsuspected, but I analyzed it anyway. > > I found that for libjava.dylib, a single .o file was different. This > one was actually picked up from closed sources, and are not really > relevant for OpenJDK. Anyway, the reason for the difference was the > same as for the Solaris libs; the include paths had changes, which > caused a binary diff. > > For libmlib_image.dylib, the link order had changed causing the noted > binary difference. > > * Linux: > > On linux, the compare script noted differences for libextnet, libjava, > libmlib_image, libprefs, libsaproc, libsplashscreen and libsunec. > > The differences for libextnet, libprefs, libsplashscreen and libsunec > turned out to be caused by the added #include of the generated Java > headers. This caused binary differences (reasonably), and for some odd > reason also a symbol difference in java_awt_SplashScreen.o > (clazz.10057 and mid.10058 were replaced by clazz.10015 and > mid.10016). I can't claim to understand this, but I'm assuming it's > some kind of generated code. > > libsaproc and libjava changes was caused by closed source changes, and > is therefore not relevant to OpenJDK. > > For libmlib_image.dylib, the link order had changed causing the noted > binary difference, as on MacOS. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8204572 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8204572-autodetect-SRC-and-headers-dirs/webrev.01 > > /Magnus > From valerie.peng at oracle.com Thu Jun 7 22:27:07 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 7 Jun 2018 15:27:07 -0700 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> Message-ID: <00792b59-64ef-c406-fe37-02756310ec0a@oracle.com> Hi Xuelei, There seems to be inconsistency in whether you can override the internal md5, sha1 digest objects through the engineSetParameter(String, Object) call. Assuming we no longer need to override the internal digest objects, we can remove getInternalInstance(), setHashes(...). Also, not sure how useful is RSASignature.getInstance() as it simply calls JsseJce.getSignature(JsseJce.SIGNATURE_SSLRSA); Still looking at more files, just thought that I will get this to you first. Valerie On 2/20/2018 11:57 AM, Xuelei Fan wrote: > Hi, > > I'd like to invite you to review the TLS 1.3 full handshake > implementation.? I appreciate it if I could have feedback before March > 9, 2018. > > In the "JDK-8185576: New handshake implementation" [1] code review > around, I was trying to re-org the TLS handshaking implementation in the > SunJSSE provider.? If you had reviewed that part, you can start from > the following webrev that based on the update of JDK-8185576: > ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.00 > > If you would like start from earlier, here is the webrev that contains > the handshaking implementation re-org in JDK-8185576: > ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > > This changeset only implements the full handshake of TLS 1.3, rather > then a fully implementation of the latest TLS 1.3 draft [2]. > > In this implementation, I removed: > 1. the KRB5 cipher suite implementation. > Please let me know if you are still using KRB5 cipher suite.? I may > not add them back if no objections. > > 2. OCSP stapling. > This feature will be added back later. > > Resumption and key update, and more features may be added later. > > Thanks & Regards, > Xuelei > > [1]: > http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016642.html > [2]: https://tools.ietf.org/html/draft-ietf-tls-tls13-24 From anthony.scarpino at oracle.com Thu Jun 7 23:03:00 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 7 Jun 2018 16:03:00 -0700 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> Message-ID: Xuelei, I'll push updates if you're are ok with the changes. Tony --- ServerHandshakeContext.java ServerHello.java - spelling nits only HandshakeContext.java - Could getActiveCipherSuites() compile a list of cipher suites once per ProtocolVersion instead doing it for each instance of ServerHello? The lists could then be cache for performance. I believe all the checks, like constraints or availability, are decided at startup. This is something that can be address at a later date. 122: preferableSignatureAlgorithm is never used. 233: Throwing IOException is not needed. 503: isNegotiable(byte majorVersion, byte minorVersion) not used TransportContext.java 85: baseWriteSecret, baseReadSecret never used 476: closeInbound() does not need to throw SSLException Removing below commented out code in passiveInboundClose() 515 // For TLS 1.3, output closure is independent from input closure. 516 // if (isNegotiated && protocolVersion.useTLS13PlusSpec()) { 517 // return; 518 // } Removing below commented out code in initiateOutboundClose() 582 // For TLS 1.3, output closure is independent from input closure. 583 // 584 // if (isNegotiated && protocolVersion.useTLS13PlusSpec()) { 585 // return; 586 // } Removing below commented out code in finishHandshake() 644 // inputRecord and outputRecord shares the same handshakeHash 645 // inputRecord.handshakeHash.finish(); From xuelei.fan at oracle.com Fri Jun 8 00:02:28 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 7 Jun 2018 17:02:28 -0700 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> Message-ID: Looks all good catches to me. Please take care of the update as well. Thanks, Xuelei On 6/7/2018 4:03 PM, Anthony Scarpino wrote: > Xuelei, > > I'll push updates if you're are ok with the changes. > > Tony > --- > > ServerHandshakeContext.java > ServerHello.java > - spelling nits only > > HandshakeContext.java > - Could getActiveCipherSuites() compile a list of cipher suites once per > ProtocolVersion instead doing it for each instance of ServerHello?? The > lists could then be cache for performance.? I believe all the checks, > like constraints or availability, are decided at startup.? This is > something that can be address at a later date. > > ?122: preferableSignatureAlgorithm is never used. > ?233: Throwing IOException is not needed. > ?503: isNegotiable(byte majorVersion, byte minorVersion) not used > > TransportContext.java > ? 85: baseWriteSecret, baseReadSecret never used > ?476: closeInbound()? does not need to throw SSLException > > ?Removing below commented out code in passiveInboundClose() > ?515 // For TLS 1.3, output closure is independent from input? closure. > ?516 //????? if (isNegotiated && protocolVersion.useTLS13PlusSpec()) { > ?517 //????????? return; > ?518 //????? } > > ?Removing below commented out code in initiateOutboundClose() > ?582 // For TLS 1.3, output closure is independent from input closure. > ?583 // > ?584 //????? if (isNegotiated && protocolVersion.useTLS13PlusSpec()) { > ?585 //????????? return; > ?586 //????? } > > ?Removing below commented out code in finishHandshake() > ?644 // inputRecord and outputRecord shares the same handshakeHash > ?645 // inputRecord.handshakeHash.finish(); From xuelei.fan at oracle.com Fri Jun 8 00:25:01 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 7 Jun 2018 17:25:01 -0700 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: <00792b59-64ef-c406-fe37-02756310ec0a@oracle.com> References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> <00792b59-64ef-c406-fe37-02756310ec0a@oracle.com> Message-ID: <57f19cae-50e1-066e-cfc2-47678eb493ea@oracle.com> On 6/7/2018 3:27 PM, Valerie Peng wrote: > Hi Xuelei, > > There seems to be inconsistency in > whether you can override the internal md5, sha1 digest objects through > the engineSetParameter(String, Object) call. I agreed. The use of RSASignature is limited in the provider. The engineSetParameter() is not used so we don't allow the method in the implementation. > Assuming we no longer need > to override the internal digest objects, we can remove > getInternalInstance(), setHashes(...). I agreed. > Also, not sure how useful is > RSASignature.getInstance() as it simply calls > JsseJce.getSignature(JsseJce.SIGNATURE_SSLRSA); > The calls to JsseJce.getSignature() are mainly to use the specific FIPS SunJSSE.cryptoProvider. Although FIPS is an old experimental feature, we don't remove it from the provider yet. So you may see some unusual use of getInstance() that calling into JsseJce impl. Thanks, Xuelei > Still looking at more files, just thought that I will get this to you > first. > > Valerie > > > On 2/20/2018 11:57 AM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 full handshake >> implementation.? I appreciate it if I could have feedback before March >> 9, 2018. >> >> In the "JDK-8185576: New handshake implementation" [1] code review >> around, I was trying to re-org the TLS handshaking implementation in the >> SunJSSE provider.? If you had reviewed that part, you can start from >> the following webrev that based on the update of JDK-8185576: >> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.00 >> >> If you would like start from earlier, here is the webrev that contains >> the handshaking implementation re-org in JDK-8185576: >> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> >> This changeset only implements the full handshake of TLS 1.3, rather >> then a fully implementation of the latest TLS 1.3 draft [2]. >> >> In this implementation, I removed: >> 1. the KRB5 cipher suite implementation. >> Please let me know if you are still using KRB5 cipher suite.? I may >> not add them back if no objections. >> >> 2. OCSP stapling. >> This feature will be added back later. >> >> Resumption and key update, and more features may be added later. >> >> Thanks & Regards, >> Xuelei >> >> [1]: >> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016642.html >> >> [2]: https://tools.ietf.org/html/draft-ietf-tls-tls13-24 > From xuelei.fan at oracle.com Fri Jun 8 00:32:19 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 7 Jun 2018 17:32:19 -0700 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> <0419f803-e67c-074c-ff02-f0d45326d3b4@oracle.com> Message-ID: <9e7baaed-b909-30a2-0274-efa20f86dc98@oracle.com> On 6/7/2018 1:38 PM, Jamil Nimeh wrote: > Hello there!? Only nits for these two files (and possibly more based on > a method name change), but they've been reviewed in the past so most > issues have already been dealt with: > > * SSLExtension.java > o 39: Silly nit - you could update this to say RFC 6066, since > we're probably working to that standard these days and if there > are any minor diffs between the two we'd probably favor the latter. Good catch! > o Various: More nits - we still seem to have a few "Concumer" > methods floating around.? I'll go through the code and fix those. > o 575 - 581: Can we remove this block or do we need to hang onto it? I may prefer to remove this block. > * SSLExtensions.java > o 142-144: Another commented out chunk of code.? Do we need it? > Given where it is situated (right after a continue statement) it > looks like something that should be removed. > No need of it any more. Would you mind take care of the updates? Thanks, Xuelei > --Jamil > > > On 02/22/2018 12:29 PM, Xuelei Fan wrote: >> Updated to use package private HKDF implementation. >> >> webrev (based on JDK-8185576): >> http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.01 >> >> webrev (including JDK-8185576): >> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >> >> Thanks, >> Xuelei >> >> On 2/20/2018 11:57 AM, Xuelei Fan wrote: >>> Hi, >>> >>> I'd like to invite you to review the TLS 1.3 full handshake >>> implementation.? I appreciate it if I could have feedback before >>> March 9, 2018. >>> >>> In the "JDK-8185576: New handshake implementation" [1] code review >>> around, I was trying to re-org the TLS handshaking implementation in the >>> SunJSSE provider.? If you had reviewed that part, you can start from >>> the following webrev that based on the update of JDK-8185576: >>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.00 >>> >>> If you would like start from earlier, here is the webrev that >>> contains the handshaking implementation re-org in JDK-8185576: >>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>> >>> >>> This changeset only implements the full handshake of TLS 1.3, rather >>> then a fully implementation of the latest TLS 1.3 draft [2]. >>> >>> In this implementation, I removed: >>> 1. the KRB5 cipher suite implementation. >>> Please let me know if you are still using KRB5 cipher suite.? I may >>> not add them back if no objections. >>> >>> 2. OCSP stapling. >>> This feature will be added back later. >>> >>> Resumption and key update, and more features may be added later. >>> >>> Thanks & Regards, >>> Xuelei >>> >>> [1]: >>> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016642.html >>> >>> [2]: https://tools.ietf.org/html/draft-ietf-tls-tls13-24 > From weijun.wang at oracle.com Fri Jun 8 01:23:45 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 8 Jun 2018 09:23:45 +0800 Subject: SSLLogger.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> <12F8F4BF-F46C-4F0C-ABC2-162D1BADBCF1@oracle.com> <7f438619-0555-4860-63a3-ffd6270da97b@oracle.com> <81ac5d21-4315-3df5-c65e-9a518f797211@oracle.com> <4555CC11-AE7F-4B3E-B1C0-89B8DBA3B78B@oracle.com> <72191acc-b6d3-7ec1-8d62-e2164ddc4ac6@oracle.com> Message-ID: <2B36A4B3-C64F-46C4-9F05-3DC716E5B844@oracle.com> My final comment on this class: Since SSLConsoleLogger is a Logger child, its log(..., params) method should follow the Logger::log spec, which has /** * Logs a message with resource bundle and an optional list of * parameters. * ... * @param format the string message format in {@link * java.text.MessageFormat} format, (or a key in the message * catalog if {@code bundle} is not {@code null}); can be {@code null}. * @param params an optional list of parameters to the message (may be * none). * ... */ public void log(Level level, ResourceBundle bundle, String format, Object... params); Especially, the String parameter is in MessageFormat format (that's why it's named "format" but not "message"). However, SSLConsoleLogger::log is always called with format being a plain string and params are stacked in the output separated by command and newline. My opinion is that this is not the normal style of using a Logger and we should not allow system logger (through -Djavax.net.debug=). If you still see benefit in that, can we make this change at the moment? - logger.log(level, msg, formatted); + if (logger instanceof SSLConsoleLogger) { + logger.log(level, msg, formatted); + } else { + logger.log(level, msg + ": " + formatted); + } Thanks Max > On Jun 7, 2018, at 11:24 AM, Weijun Wang wrote: > > I think I understand. So if a user sets it to empty, they will also need to create a customized logger/formatter like SSLLogger that is able to output a parameter without a placeholder in msg. > > --Max > >> On Jun 7, 2018, at 9:51 AM, Xuelei Fan wrote: >> >> In this implementation, the SunJSSE logging is updated to (the class comment lines): >> >> /** >> * Implementation of SSL logger. >> * >> * If the system property "javax.net.debug" is not defined, the debug logging >> * is turned off. If the system property "javax.net.debug" is defined as >> * empty, the debug logger is specified by System.getLogger("javax.net.ssl"), >> * and applications can customize and configure the logger or use external >> * logging mechanisms. If the system property "javax.net.debug" is defined >> * and non-empty, a private debug logger implemented in this class is used. >> */ >> >> On 6/6/2018 6:37 PM, Weijun Wang wrote: >>> But will any application use the logger named "javax.net.debug"? I think that's only for JSSE. >> If using System Logger, the "javax.net.debug" system property will be used to turn on/off the logger (define with empty or not defined). >> >> Xuelei >> >>>> On Jun 7, 2018, at 9:35 AM, Xuelei Fan wrote: >>>> >>>> I see your concerns now. Currently, we don't fine the format if using System logger. Applications can define the format and output style for themselves if needed. That's also the purpose why we introduce the System Logger in the provider. > From weijun.wang at oracle.com Fri Jun 8 01:29:42 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 8 Jun 2018 09:29:42 +0800 Subject: HelloCookieManager.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <869a1707-dc45-dbd2-0270-914a4a23d55b@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <869a1707-dc45-dbd2-0270-914a4a23d55b@oracle.com> Message-ID: Have you updated it yourself? I have a proposal at http://cr.openjdk.java.net/~weijun/9999999/webrev.hello-cookie-manager/ --Max > On Jun 6, 2018, at 10:40 PM, Xuelei Fan wrote: > > On 6/5/2018 8:48 PM, Weijun Wang wrote: >>> On 6/5/2018 6:54 AM, Weijun Wang wrote: >>>> HelloCookieManager.java: >>>> 44 HelloCookieManager(SecureRandom secureRandom) { >>>> 45 this.secureRandom = secureRandom; >>>> 46 } >>>> 47 >>>> 48 HelloCookieManager valueOf(ProtocolVersion protocolVersion) { >>>> Why not just create a static method and make HelloCookieManager abstract? >>>> static HelloCookieManager of(SecureRandom secureRandom, ProtocolVersion protocolVersion) >>>> I haven't seen "raw" HelloCookieManager used anywhere. >>> For every SSLContext, the SecureRandom may be different, so we need a different HelloCookieManager instance and cookie managers for each SSLContext instance: >>> >>> SSLContextImpl.java >>> ------------------- >>> 253 helloCookieManager = new HelloCookieManager(secureRandom); >> So the main benefit of the current implementation is that once a HelloCookieManager is created you can reuse the 3 child HelloCookieManager objects inside it. Right? > Yes. > >> If so, I'm OK with the current structure. > I see you concerns. The structure looks weird in some sense, although it is easier for a package private class. Let me see if I can make an update in the next changeset. > > Thanks, > Xuelei > >> My major concern is, since the "base" HelloCookieManager is never useful we should take great care not to create an instance of it. How about this? >> 1. Make HelloCookieManager abstract. >> 2. Create an non-abstract inner class HelloCookieManager$Builder and move the 3 real instances there. >> 3. Inside SSLContextImpl, store a field of HelloCookieManager$Builder, and in getHelloCookieManager(), call "builder.get(protocolVersion)" to return one of the 3 real instances. >> If the reuse of the 3 real instances is not a big benefit, you can just make HelloCookieManager abstract and create a new child instance in every getHelloCookieManager() call. >> Anyway, I feel uncomfortable that the base HelloCookieManager class can be instantiated. >> Thanks >> Max >>>>> On Jun 5, 2018, at 12:12 PM, Xuelei Fan wrote: >>>>> >>>>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 From xuelei.fan at oracle.com Fri Jun 8 01:40:07 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 7 Jun 2018 18:40:07 -0700 Subject: SSLLogger.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <2B36A4B3-C64F-46C4-9F05-3DC716E5B844@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> <12F8F4BF-F46C-4F0C-ABC2-162D1BADBCF1@oracle.com> <7f438619-0555-4860-63a3-ffd6270da97b@oracle.com> <81ac5d21-4315-3df5-c65e-9a518f797211@oracle.com> <4555CC11-AE7F-4B3E-B1C0-89B8DBA3B78B@oracle.com> <72191acc-b6d3-7ec1-8d62-e2164ddc4ac6@oracle.com> <2B36A4B3-C64F-46C4-9F05-3DC716E5B844@oracle.com> Message-ID: I got your ideas. Let's see if we can make a change, a little bit later. Thanks, Xuelei On 6/7/2018 6:23 PM, Weijun Wang wrote: > My final comment on this class: > > Since SSLConsoleLogger is a Logger child, its log(..., params) method should follow the Logger::log spec, which has > > /** > * Logs a message with resource bundle and an optional list of > * parameters. > * ... > * @param format the string message format in {@link > * java.text.MessageFormat} format, (or a key in the message > * catalog if {@code bundle} is not {@code null}); can be {@code null}. > * @param params an optional list of parameters to the message (may be > * none). > * ... > */ > public void log(Level level, ResourceBundle bundle, String format, > Object... params); > > Especially, the String parameter is in MessageFormat format (that's why it's named "format" but not "message"). However, SSLConsoleLogger::log is always called with format being a plain string and params are stacked in the output separated by command and newline. > > My opinion is that this is not the normal style of using a Logger and we should not allow system logger (through -Djavax.net.debug=). If you still see benefit in that, can we make this change at the moment? > > - logger.log(level, msg, formatted); > + if (logger instanceof SSLConsoleLogger) { > + logger.log(level, msg, formatted); > + } else { > + logger.log(level, msg + ": " + formatted); > + } > > Thanks > Max > >> On Jun 7, 2018, at 11:24 AM, Weijun Wang wrote: >> >> I think I understand. So if a user sets it to empty, they will also need to create a customized logger/formatter like SSLLogger that is able to output a parameter without a placeholder in msg. >> >> --Max >> >>> On Jun 7, 2018, at 9:51 AM, Xuelei Fan wrote: >>> >>> In this implementation, the SunJSSE logging is updated to (the class comment lines): >>> >>> /** >>> * Implementation of SSL logger. >>> * >>> * If the system property "javax.net.debug" is not defined, the debug logging >>> * is turned off. If the system property "javax.net.debug" is defined as >>> * empty, the debug logger is specified by System.getLogger("javax.net.ssl"), >>> * and applications can customize and configure the logger or use external >>> * logging mechanisms. If the system property "javax.net.debug" is defined >>> * and non-empty, a private debug logger implemented in this class is used. >>> */ >>> >>> On 6/6/2018 6:37 PM, Weijun Wang wrote: >>>> But will any application use the logger named "javax.net.debug"? I think that's only for JSSE. >>> If using System Logger, the "javax.net.debug" system property will be used to turn on/off the logger (define with empty or not defined). >>> >>> Xuelei >>> >>>>> On Jun 7, 2018, at 9:35 AM, Xuelei Fan wrote: >>>>> >>>>> I see your concerns now. Currently, we don't fine the format if using System logger. Applications can define the format and output style for themselves if needed. That's also the purpose why we introduce the System Logger in the provider. >> > From xuelei.fan at oracle.com Fri Jun 8 01:58:05 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 7 Jun 2018 18:58:05 -0700 Subject: HelloCookieManager.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <869a1707-dc45-dbd2-0270-914a4a23d55b@oracle.com> Message-ID: On 6/7/2018 6:29 PM, Weijun Wang wrote: > Have you updated it yourself? I did not. > I have a proposal at > > http://cr.openjdk.java.net/~weijun/9999999/webrev.hello-cookie-manager/ > Looks fine to me. Minor nit: Would you mind limit the maximum line character to 80 characters (line 250)? Thanks, Xuelei > --Max > >> On Jun 6, 2018, at 10:40 PM, Xuelei Fan wrote: >> >> On 6/5/2018 8:48 PM, Weijun Wang wrote: >>>> On 6/5/2018 6:54 AM, Weijun Wang wrote: >>>>> HelloCookieManager.java: >>>>> 44 HelloCookieManager(SecureRandom secureRandom) { >>>>> 45 this.secureRandom = secureRandom; >>>>> 46 } >>>>> 47 >>>>> 48 HelloCookieManager valueOf(ProtocolVersion protocolVersion) { >>>>> Why not just create a static method and make HelloCookieManager abstract? >>>>> static HelloCookieManager of(SecureRandom secureRandom, ProtocolVersion protocolVersion) >>>>> I haven't seen "raw" HelloCookieManager used anywhere. >>>> For every SSLContext, the SecureRandom may be different, so we need a different HelloCookieManager instance and cookie managers for each SSLContext instance: >>>> >>>> SSLContextImpl.java >>>> ------------------- >>>> 253 helloCookieManager = new HelloCookieManager(secureRandom); >>> So the main benefit of the current implementation is that once a HelloCookieManager is created you can reuse the 3 child HelloCookieManager objects inside it. Right? >> Yes. >> >>> If so, I'm OK with the current structure. >> I see you concerns. The structure looks weird in some sense, although it is easier for a package private class. Let me see if I can make an update in the next changeset. >> >> Thanks, >> Xuelei >> >>> My major concern is, since the "base" HelloCookieManager is never useful we should take great care not to create an instance of it. How about this? >>> 1. Make HelloCookieManager abstract. >>> 2. Create an non-abstract inner class HelloCookieManager$Builder and move the 3 real instances there. >>> 3. Inside SSLContextImpl, store a field of HelloCookieManager$Builder, and in getHelloCookieManager(), call "builder.get(protocolVersion)" to return one of the 3 real instances. >>> If the reuse of the 3 real instances is not a big benefit, you can just make HelloCookieManager abstract and create a new child instance in every getHelloCookieManager() call. >>> Anyway, I feel uncomfortable that the base HelloCookieManager class can be instantiated. >>> Thanks >>> Max >>>>>> On Jun 5, 2018, at 12:12 PM, Xuelei Fan wrote: >>>>>> >>>>>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 > From bradford.wetmore at oracle.com Fri Jun 8 02:36:56 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 7 Jun 2018 19:36:56 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> Message-ID: <637c1aa7-a62f-ecae-7b7d-d261aae36573@oracle.com> I'm working my way through CipherSuite.java, slow going as I'm making sure all of the ciphersuites got updated to the new format. SSLServerSocketFactoryImpl.java ------------------------------- This comment is actually an overall comment in other files in your review. Typically we don't make changes just for style (e.g. foo () -> foo() , lines 56/73), but I'm guessing since so much has changed, you're just going to clean things up now? So I'm wondering why you didn't do it in line /75/80/82/87/89/etc. I'm all for making this change now since the world is changing anyway. 38/73: Why not just make it one line? It's under 80 chars. 41: context can be final. CipherSuite.java ---------------- 28-33: Just wondering why you chose to enumerate all of the java.util.*; ProtocolVersion.java -------------------- 29-32: Same question about enumerating all instances. 41: And in SSLConfiguration: 99-101. Why not just get rid of this now? It's going to be 0x0304 in the final RFC. 49: I believe this protocol number is your anticipated number, I don't see it mentioned anywhere in the current DTLS spec: https://tools.ietf.org/html/draft-ietf-tls-dtls13-26 Just alluded to in section 5.3, but I haven't see anything in my further IETF scanning about a specific DTLS version number having been assigned. Later down, you mention DTLS 1.3 quite a bit (e.g. PROTOCOLS_TO_13), is this going to cause any adverse reactions since there is no DTLS 1.3 implementation yet? 95: Why does this comment say 1.3 if this is a _OF_30? 136-146: These "T" names are a little non-intuitive. PROTOCOLS_TO_TLS11? Should there be a similar for _TO_TLS13? What about PROTCOLS_TO_DTLS*? 229: I probably don't understand the callers of this code well enough. If DTLS, you return true if it's DLTS10/12/13 or later. But false if less. Why are you allowing DTLS 1.0 and all later (unknown) versions? Same question for the TLS arm. Why fail earlier than SSLv3, and allow above TLSv1.3? Also suggest you move the 243 into the else arm. 289: You already checked this condition in 285-287 above. And then 304 is no longer needed. Brad On 6/7/2018 10:28 AM, Bradford Wetmore wrote: > Also reviewed SSLSocketFactoryImpl.java > > > BaseSSLSocketImpl.java > ---------------------- > I don't see where requireCloseNotify is actually being used in the > remaining code.? If you are removing this functionality, you should > probably be calling that out in your CSR. > > SSLSessionContextImpl.java > -------------------------- > The only change here was to reorder the import of Vector (obsolete) and > update the copyright?? May I ask why?? If this was somehow a netbeans > suggestion, there were several other things that could be updated that > seem more important.? e.g.? 37-39 could be made final.? 207: unnecessary > unboxing. > > Brad > > > > > On 6/6/2018 5:45 PM, Bradford Wetmore wrote: >> Today, I looked over SunJSSE.java, Utilities.java, and >> module-info.java. ??Mostly nits below, some style things. >> >> >> Utilities.java >> -------------- >> >> 39:? hexDigits can be private. >> >> 42:? Extra level of indent.? 4 or 8. >> >> 39-41:? Nits: When variables are static finals, they are usually >> written uppercase. >> >> 115:? Extra " " and can we get SNI cap'd? >> >> HostName for? server name indication >> -> >> HostName for Server Name Indication >> >> 150:? Minor Nit:? You're concating ("+") and then using >> StringBuilder.append(), instead of simply append chaining which might >> be slightly more efficient. >> >> 167-217:? The code looks ok, but this might be reworked to take better >> advantage of StringBuilder.append() chaining, rather than the mix of >> concat and append here now.? e.g. what you did with toHexString(long). >> I see much of the same code repeated over and over here.? Can be done >> later. >> >> Brad >> >> >> >> On 6/3/2018 9:43 PM, Xuelei Fan wrote: >>> Hi, >>> >>> Here it the 2nd full webrev: >>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >>> >>> and the delta update to the 1st webrev: >>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >>> >>> Xuelei >>> >>> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> I'd like to invite you to review the TLS 1.3 implementation.? I >>>> appreciate it if I could have compatibility and specification >>>> feedback before May 31, 2018, and implementation feedback before >>>> June 7, 2018. >>>> >>>> Here is the webrev: >>>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>>> >>>> The formal TLS 1.3 specification is not finalized yet, although it >>>> had been approved to be a standard.? The implementation is based on >>>> the draft version 28: >>>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>>> >>>> For the overall description of this enhancement, please refer to JEP >>>> 332: >>>> ???? http://openjdk.java.net/jeps/332 >>>> >>>> For the compatibility and specification update, please refer to CSR >>>> 8202625: >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>>> >>>> Note that we are using the sandbox for the development right now. >>>> For more information, please refer to Bradford's previous email: >>>> >>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>>> >>>> >>>> Thanks & Regards, >>>> Xuelei From xuelei.fan at oracle.com Fri Jun 8 04:20:33 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 7 Jun 2018 21:20:33 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <8e0a341c-9c53-d671-57f1-f730b70de20e@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8e0a341c-9c53-d671-57f1-f730b70de20e@oracle.com> Message-ID: Update: http://hg.openjdk.java.net/jdk/sandbox/rev/75527e40bdfd This update fixed the session resumption and related issues. The update code will be included in the next webrev for further review. Xuelei On 6/3/2018 12:58 PM, Xuelei Fan wrote: > > http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > PreSharedKeyExtension.java > -------------------------- > A few lines exceed the 80-characters per line limit. > > ? 68? static final class PskIdentity { > This class can be private. > > > ? 72? public PskIdentity(byte[] identity, int obfuscatedAge) { > ? 77? public PskIdentity(ByteBuffer m) > It is not necessary to use "public" scope.? Please check other public > methods as well if existing. > > > ?111? CHPreSharedKeySpec(ByteBuffer m) > ?112????? throws IllegalParameterException, IOException { > Implementation of this method does not check the boundary of the > PreSharedKeyExtension struct. > > > ?271? ServerHandshakeContext shc = (ServerHandshakeContext) > message.handshakeContext; > It is more simple to use the context parameter rather than the message > context. > > > ?315?? shc.isResumption = false; > ?316?? shc.resumingSession = null; > ?????? ... > ?324?????? resumeSession(shc, s, idIndex); > This resets of shc.isResumption and shc.resumingSession override the set > of other extensions.? It could lead to unexpected behaviors. > > > ?675?? if (shPsk.selectedIdentity != 0) { > If only the 1st id can be use, may be don't bother to cache and request > other ids.? I'm? not very sure of it yet, need more time to think about it. > > Xuelei > > On 5/25/2018 4:45 PM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 implementation.? I >> appreciate it if I could have compatibility and specification feedback >> before May 31, 2018, and implementation feedback before June 7, 2018. >> >> Here is the webrev: >> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> The formal TLS 1.3 specification is not finalized yet, although it had >> been approved to be a standard.? The implementation is based on the >> draft version 28: >> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >> >> For the overall description of this enhancement, please refer to JEP 332: >> ???? http://openjdk.java.net/jeps/332 >> >> For the compatibility and specification update, please refer to CSR >> 8202625: >> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >> >> Note that we are using the sandbox for the development right now.? For >> more information, please refer to Bradford's previous email: >> >> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >> >> Thanks & Regards, >> Xuelei From weijun.wang at oracle.com Fri Jun 8 04:25:59 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 8 Jun 2018 12:25:59 +0800 Subject: Other files assigned to me (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> <12F8F4BF-F46C-4F0C-ABC2-162D1BADBCF1@oracle.com> <7f438619-0555-4860-63a3-ffd6270da97b@oracle.com> <81ac5d21-4315-3df5-c65e-9a518f797211@oracle.com> <4555CC11-AE7F-4B3E-B1C0-89B8DBA3B78B@oracle.com> <72191acc-b6d3-7ec1-8d62-e2164ddc4ac6@oracle.com> <2B36A4B3-C64F-46C4-9F05-3DC716E5B844@oracle.com> Message-ID: I've finished reviewing of other files assigned to me. Turns out most changes are on Debug -> SSLLogger. There are only 2 concerns left: 1. SSLLogger: I talked about in another mail, SSLConsoleLogger::log does not use format. 2. SSLStringize: I think this is unnecessarily complex. Also, you have changed "import java.security.*" to individual "import java.security.Abc" lines in some files (which I think is good) but not all. If you think it's better to apply this change everywhere I can help. This might need some co-ordination because I don't want to interrupt some people's work. Thanks Max From xuelei.fan at oracle.com Fri Jun 8 04:55:52 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 7 Jun 2018 21:55:52 -0700 Subject: Other files assigned to me (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> <12F8F4BF-F46C-4F0C-ABC2-162D1BADBCF1@oracle.com> <7f438619-0555-4860-63a3-ffd6270da97b@oracle.com> <81ac5d21-4315-3df5-c65e-9a518f797211@oracle.com> <4555CC11-AE7F-4B3E-B1C0-89B8DBA3B78B@oracle.com> <72191acc-b6d3-7ec1-8d62-e2164ddc4ac6@oracle.com> <2B36A4B3-C64F-46C4-9F05-3DC716E5B844@oracle.com> Message-ID: <7e2ba485-64d2-aca1-5e98-22be4a00ba23@oracle.com> On 6/7/2018 9:25 PM, Weijun Wang wrote: > I've finished reviewing of other files assigned to me. Turns out most changes are on Debug -> SSLLogger. > Thanks! Well, would you mind to pick up a few more P1 file code review? We are trying to catch the June 13 deadline. It still looks like a challenge for now. > There are only 2 concerns left: > > 1. SSLLogger: I talked about in another mail, SSLConsoleLogger::log does not use format. > I agree with you. However, I have no cycle for it right now. Siba just found an interop issue with EC algorithms, I need to head on it sooner. Maybe, we can make the update after RDP1. > 2. SSLStringize: I think this is unnecessarily complex. > I did not agree for the 1st read of the comment, but I need time to think more about it. Maybe, we can refactor it after RDP1. > Also, you have changed "import java.security.*" to individual "import java.security.Abc" lines in some files (which I think is good) but not all. If you think it's better to apply this change everywhere I can help. > ;-) It's auto-completed by NetBeans IDE. Personally, I don't care of the import style. Using "import java.security.*" is more compact. Looks like Brad/Tony prefer to use a compact one. Please help if you prefer the compact one as well. Thanks, Xuelei From xuelei.fan at oracle.com Fri Jun 8 05:08:44 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 7 Jun 2018 22:08:44 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> Message-ID: <4d9e0847-4c04-b887-92bc-f5f06403f7cc@oracle.com> Update: http://hg.openjdk.java.net/jdk/sandbox/rev/33a2451070d3 This update add debug log for pre_shared_key extension. The update code will be included in the next webrev for further review if needed. Xuelei On 6/3/2018 9:43 PM, Xuelei Fan wrote: > Hi, > > Here it the 2nd full webrev: > ? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 > > and the delta update to the 1st webrev: > ? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ > > Xuelei > > On 5/25/2018 4:45 PM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 implementation.? I >> appreciate it if I could have compatibility and specification feedback >> before May 31, 2018, and implementation feedback before June 7, 2018. >> >> Here is the webrev: >> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> The formal TLS 1.3 specification is not finalized yet, although it had >> been approved to be a standard.? The implementation is based on the >> draft version 28: >> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >> >> For the overall description of this enhancement, please refer to JEP 332: >> ???? http://openjdk.java.net/jeps/332 >> >> For the compatibility and specification update, please refer to CSR >> 8202625: >> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >> >> Note that we are using the sandbox for the development right now.? For >> more information, please refer to Bradford's previous email: >> >> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >> >> Thanks & Regards, >> Xuelei From jamil.j.nimeh at oracle.com Fri Jun 8 05:00:52 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 7 Jun 2018 22:00:52 -0700 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: <0419f803-e67c-074c-ff02-f0d45326d3b4@oracle.com> References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> <0419f803-e67c-074c-ff02-f0d45326d3b4@oracle.com> Message-ID: Changeset for the nits found in SSLExtension/SSLExtensions.java http://hg.openjdk.java.net/jdk/sandbox/rev/585e6d31677b --Jamil On 02/22/2018 12:29 PM, Xuelei Fan wrote: > Updated to use package private HKDF implementation. > > webrev (based on JDK-8185576): > ????? http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.01 > > webrev (including JDK-8185576): > ????? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 > > Thanks, > Xuelei > > On 2/20/2018 11:57 AM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 full handshake >> implementation.? I appreciate it if I could have feedback before >> March 9, 2018. >> >> In the "JDK-8185576: New handshake implementation" [1] code review >> around, I was trying to re-org the TLS handshaking implementation in the >> SunJSSE provider.? If you had reviewed that part, you can start from >> the following webrev that based on the update of JDK-8185576: >> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.00 >> >> If you would like start from earlier, here is the webrev that >> contains the handshaking implementation re-org in JDK-8185576: >> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> >> This changeset only implements the full handshake of TLS 1.3, rather >> then a fully implementation of the latest TLS 1.3 draft [2]. >> >> In this implementation, I removed: >> 1. the KRB5 cipher suite implementation. >> Please let me know if you are still using KRB5 cipher suite.? I may >> not add them back if no objections. >> >> 2. OCSP stapling. >> This feature will be added back later. >> >> Resumption and key update, and more features may be added later. >> >> Thanks & Regards, >> Xuelei >> >> [1]: >> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016642.html >> >> [2]: https://tools.ietf.org/html/draft-ietf-tls-tls13-24 From xuelei.fan at oracle.com Fri Jun 8 06:14:44 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 7 Jun 2018 23:14:44 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> Message-ID: <07188b5c-efc5-5b5a-1cea-04484ceb6b61@oracle.com> Update: http://hg.openjdk.java.net/jdk/sandbox/rev/a82a96b62d22 This update fix the signature algorithm selection issue for ecdsa_secp256r1_sha256/ecdsa_secp384r1_sha384/ecdsa_secp512r1_sha512. The update code will be included in the next webrev for further review. Xuelei On 6/3/2018 9:43 PM, Xuelei Fan wrote: > Hi, > > Here it the 2nd full webrev: > ? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 > > and the delta update to the 1st webrev: > ? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ > > Xuelei > > On 5/25/2018 4:45 PM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 implementation.? I >> appreciate it if I could have compatibility and specification feedback >> before May 31, 2018, and implementation feedback before June 7, 2018. >> >> Here is the webrev: >> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> The formal TLS 1.3 specification is not finalized yet, although it had >> been approved to be a standard.? The implementation is based on the >> draft version 28: >> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >> >> For the overall description of this enhancement, please refer to JEP 332: >> ???? http://openjdk.java.net/jeps/332 >> >> For the compatibility and specification update, please refer to CSR >> 8202625: >> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >> >> Note that we are using the sandbox for the development right now.?For >> more information, please refer to Bradford's previous email: >> >> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >> >> Thanks & Regards, >> Xuelei From magnus.ihse.bursie at oracle.com Fri Jun 8 08:50:37 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 8 Jun 2018 10:50:37 +0200 Subject: RFR (XL): JDK-8204572 SetupJdkLibrary should setup SRC and -I flags automatically In-Reply-To: References: Message-ID: <4ff74b09-ec9f-0a80-31d5-49039d5e1e8c@oracle.com> On 2018-06-07 23:20, Erik Joelsson wrote: > Hello Magnus, > > Very nice refactoring! Thanks! > > JdkNativeCompilation.gmk > line 126-127 looks a bit long. There is an extra space on 126. Also, > why not addprefix for adding -I instead of clunky foreach? Not that I > care greatly, but I usually prefer that construct. Yeah, I agree, addprefix is better. I just forgot about it; foreach is a nice allround tool. Updated webrev: http://cr.openjdk.java.net/~ihse/JDK-8204572-autodetect-SRC-and-headers-dirs/webrev.02/ (Only changes is in JdkNativeCompilation.gmk, as per above comments). /Magnus > > Otherwise looks good. > > /Erik > > > On 2018-06-07 13:22, Magnus Ihse Bursie wrote: >> This change needs some background information. >> >> I've been working on simplifying and streamlining the compilation of >> native libraries of the JDK. Previously, I introduced the >> SetupJdkLibrary function, and started to get a better control of >> compiler flags. This patch continues on both paths. >> >> The original intent of this change, which I naively thought was going >> to be much simpler than it turned out :-) was to separate the -I >> flags (location of header files) from other flags, and to generate >> these automatically, wherever possible. Since we have a standard way >> of locating native code, and most libraries just want to have an -I >> path to their own source base and the generated Java header, we >> should be able to provide this in SetupJdkLibrary. >> >> This turned out to be closely related to SetupJdkLibrary being able >> to discover the location of the SRC directories itself, using >> "convention over configuration" and assuming that the library >> "libfoo" for "java.module" would be located in >> java.module/*/native/libfoo. >> >> While this sounds simple in theory, when actually trying to implement >> this I of course ran into all the places where some special handling >> was indeed needed. So even if like 90% of all libraries were simple >> to get to build using automated discovery of source and header >> directories, the 10% that did not caused me much more headaches than >> I had anticipated. On the other hand, now that I've sorted out all >> those places, the few remaining odd solutions is clearly documented >> and not just something that "just happens" due to strange >> configurations. >> >> One file deserves mentioning specifically: Awt2dLibraries.gmk. The >> java.desktop libraries are unfortunately quite entangled with each >> other, and do not readily follow the patterns that are used elsewhere >> in the code base. So it might just look like the file has just gone >> from one state of messiness, to another, which would hardly be an >> improvement. :-( I would still argue that the new messiness is >> better: It is now much clearer in what ways the libraries diverge >> from our standard assumption, and what course of action needs to be >> taken to minimize these differences. (Which is something I believe >> should be done -- these issues are not just cosmetic but is the root >> of most of the issues we always see for these libraries, when >> upgrading compilers, etc.) >> >> During this change, I noticed that not all native libraries include >> the proper generated header file. This is a dangerous coding >> practice, since a change in the Java part of the interface might not >> get picked up properly in the native part. I've added the missing >> includes that I've detected, and due to these changes, I'm also >> including the component teams in what is really only a build change. >> As can be seen for jdk.crypto.mscapi; there had indeed been changes >> that needed correcting. >> >> Since this is (basically) a pure build change, my gold standard here >> has been the build compare script. In essence, the build output prior >> to my change and with this change are 100% identical. In truth, this >> is a bit too strong a claim. A few changes has occurred, but none of >> them should matter. Here's a breakdown of the compare.sh results: >> >> * Windows-x64: >> >> No differences at all. >> >> * Solaris: >> >> Two libraries are reported to differ: libsaproc.so and >> libfontmanager.so, both with a disass diff on ~700 bytes. Analyzing >> this, I found that the object files used to link these two libraries >> has no disass differences. They have a slight binary difference and a >> difference in size, due to the include paths being different (and >> this is stored in the .o file, which makes it different). Somehow >> this apparently triggers the linker to generate a slightly different >> code in a few places, using a different register or so. (Weird...) >> >> * MacOS: >> >> Two libraries are reported to differ: libjava.dylib and >> libmlib_image.dylib, both of them just reported as a binary diff (no >> symbol, disass or fulldump differences). This is not really >> unsuspected, but I analyzed it anyway. >> >> I found that for libjava.dylib, a single .o file was different. This >> one was actually picked up from closed sources, and are not really >> relevant for OpenJDK. Anyway, the reason for the difference was the >> same as for the Solaris libs; the include paths had changes, which >> caused a binary diff. >> >> For libmlib_image.dylib, the link order had changed causing the noted >> binary difference. >> >> * Linux: >> >> On linux, the compare script noted differences for libextnet, >> libjava, libmlib_image, libprefs, libsaproc, libsplashscreen and >> libsunec. >> >> The differences for libextnet, libprefs, libsplashscreen and libsunec >> turned out to be caused by the added #include of the generated Java >> headers. This caused binary differences (reasonably), and for some >> odd reason also a symbol difference in java_awt_SplashScreen.o >> (clazz.10057 and mid.10058 were replaced by clazz.10015 and >> mid.10016). I can't claim to understand this, but I'm assuming it's >> some kind of generated code. >> >> libsaproc and libjava changes was caused by closed source changes, >> and is therefore not relevant to OpenJDK. >> >> For libmlib_image.dylib, the link order had changed causing the noted >> binary difference, as on MacOS. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8204572 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8204572-autodetect-SRC-and-headers-dirs/webrev.01 >> >> /Magnus >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Fri Jun 8 15:37:10 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 8 Jun 2018 08:37:10 -0700 Subject: RFR (XL): JDK-8204572 SetupJdkLibrary should setup SRC and -I flags automatically In-Reply-To: <4ff74b09-ec9f-0a80-31d5-49039d5e1e8c@oracle.com> References: <4ff74b09-ec9f-0a80-31d5-49039d5e1e8c@oracle.com> Message-ID: <04d6b9dc-e091-4d63-1816-15846a7b34d3@oracle.com> Looks good. /Erik On 2018-06-08 01:50, Magnus Ihse Bursie wrote: > On 2018-06-07 23:20, Erik Joelsson wrote: >> Hello Magnus, >> >> Very nice refactoring! > Thanks! > >> >> JdkNativeCompilation.gmk >> line 126-127 looks a bit long. There is an extra space on 126. Also, >> why not addprefix for adding -I instead of clunky foreach? Not that I >> care greatly, but I usually prefer that construct. > > Yeah, I agree, addprefix is better. I just forgot about it; foreach is > a nice allround tool. > > Updated webrev: > http://cr.openjdk.java.net/~ihse/JDK-8204572-autodetect-SRC-and-headers-dirs/webrev.02/ > (Only changes is in JdkNativeCompilation.gmk, as per above comments). > > /Magnus > >> >> Otherwise looks good. >> >> /Erik >> >> >> On 2018-06-07 13:22, Magnus Ihse Bursie wrote: >>> This change needs some background information. >>> >>> I've been working on simplifying and streamlining the compilation of >>> native libraries of the JDK. Previously, I introduced the >>> SetupJdkLibrary function, and started to get a better control of >>> compiler flags. This patch continues on both paths. >>> >>> The original intent of this change, which I naively thought was >>> going to be much simpler than it turned out :-) was to separate the >>> -I flags (location of header files) from other flags, and to >>> generate these automatically, wherever possible. Since we have a >>> standard way of locating native code, and most libraries just want >>> to have an -I path to their own source base and the generated Java >>> header, we should be able to provide this in SetupJdkLibrary. >>> >>> This turned out to be closely related to SetupJdkLibrary being able >>> to discover the location of the SRC directories itself, using >>> "convention over configuration" and assuming that the library >>> "libfoo" for "java.module" would be located in >>> java.module/*/native/libfoo. >>> >>> While this sounds simple in theory, when actually trying to >>> implement this I of course ran into all the places where some >>> special handling was indeed needed. So even if like 90% of all >>> libraries were simple to get to build using automated discovery of >>> source and header directories, the 10% that did not caused me much >>> more headaches than I had anticipated. On the other hand, now that >>> I've sorted out all those places, the few remaining odd solutions is >>> clearly documented and not just something that "just happens" due to >>> strange configurations. >>> >>> One file deserves mentioning specifically: Awt2dLibraries.gmk. The >>> java.desktop libraries are unfortunately quite entangled with each >>> other, and do not readily follow the patterns that are used >>> elsewhere in the code base. So it might just look like the file has >>> just gone from one state of messiness, to another, which would >>> hardly be an improvement. :-( I would still argue that the new >>> messiness is better: It is now much clearer in what ways the >>> libraries diverge from our standard assumption, and what course of >>> action needs to be taken to minimize these differences. (Which is >>> something I believe should be done -- these issues are not just >>> cosmetic but is the root of most of the issues we always see for >>> these libraries, when upgrading compilers, etc.) >>> >>> During this change, I noticed that not all native libraries include >>> the proper generated header file. This is a dangerous coding >>> practice, since a change in the Java part of the interface might not >>> get picked up properly in the native part. I've added the missing >>> includes that I've detected, and due to these changes, I'm also >>> including the component teams in what is really only a build change. >>> As can be seen for jdk.crypto.mscapi; there had indeed been changes >>> that needed correcting. >>> >>> Since this is (basically) a pure build change, my gold standard here >>> has been the build compare script. In essence, the build output >>> prior to my change and with this change are 100% identical. In >>> truth, this is a bit too strong a claim. A few changes has occurred, >>> but none of them should matter. Here's a breakdown of the compare.sh >>> results: >>> >>> * Windows-x64: >>> >>> No differences at all. >>> >>> * Solaris: >>> >>> Two libraries are reported to differ: libsaproc.so and >>> libfontmanager.so, both with a disass diff on ~700 bytes. Analyzing >>> this, I found that the object files used to link these two libraries >>> has no disass differences. They have a slight binary difference and >>> a difference in size, due to the include paths being different (and >>> this is stored in the .o file, which makes it different). Somehow >>> this apparently triggers the linker to generate a slightly different >>> code in a few places, using a different register or so. (Weird...) >>> >>> * MacOS: >>> >>> Two libraries are reported to differ: libjava.dylib and >>> libmlib_image.dylib, both of them just reported as a binary diff (no >>> symbol, disass or fulldump differences). This is not really >>> unsuspected, but I analyzed it anyway. >>> >>> I found that for libjava.dylib, a single .o file was different. This >>> one was actually picked up from closed sources, and are not really >>> relevant for OpenJDK. Anyway, the reason for the difference was the >>> same as for the Solaris libs; the include paths had changes, which >>> caused a binary diff. >>> >>> For libmlib_image.dylib, the link order had changed causing the >>> noted binary difference. >>> >>> * Linux: >>> >>> On linux, the compare script noted differences for libextnet, >>> libjava, libmlib_image, libprefs, libsaproc, libsplashscreen and >>> libsunec. >>> >>> The differences for libextnet, libprefs, libsplashscreen and >>> libsunec turned out to be caused by the added #include of the >>> generated Java headers. This caused binary differences (reasonably), >>> and for some odd reason also a symbol difference in >>> java_awt_SplashScreen.o (clazz.10057 and mid.10058 were replaced by >>> clazz.10015 and mid.10016). I can't claim to understand this, but >>> I'm assuming it's some kind of generated code. >>> >>> libsaproc and libjava changes was caused by closed source changes, >>> and is therefore not relevant to OpenJDK. >>> >>> For libmlib_image.dylib, the link order had changed causing the >>> noted binary difference, as on MacOS. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8204572 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8204572-autodetect-SRC-and-headers-dirs/webrev.01 >>> >>> /Magnus >>> >> > From xuelei.fan at oracle.com Fri Jun 8 17:21:29 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 8 Jun 2018 10:21:29 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> Message-ID: <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> Here is the 3rd full webrev: http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.02 and the delta update to the 1st webrev: http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.01 Xuelei On 6/3/2018 9:43 PM, Xuelei Fan wrote: > Hi, > > Here it the 2nd full webrev: > ? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 > > and the delta update to the 1st webrev: > ? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ > > Xuelei > > On 5/25/2018 4:45 PM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 implementation.? I >> appreciate it if I could have compatibility and specification feedback >> before May 31, 2018, and implementation feedback before June 7, 2018. >> >> Here is the webrev: >> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> The formal TLS 1.3 specification is not finalized yet, although it had >> been approved to be a standard.? The implementation is based on the >> draft version 28: >> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >> >> For the overall description of this enhancement, please refer to JEP 332: >> ???? http://openjdk.java.net/jeps/332 >> >> For the compatibility and specification update, please refer to CSR >> 8202625: >> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >> >> Note that we are using the sandbox for the development right now.? For >> more information, please refer to Bradford's previous email: >> >> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >> >> Thanks & Regards, >> Xuelei From xuelei.fan at oracle.com Fri Jun 8 17:23:27 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 8 Jun 2018 10:23:27 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> Message-ID: <4a19a2c6-4a03-5a28-f9bb-3f900b0959f4@oracle.com> On 6/8/2018 10:21 AM, Xuelei Fan wrote: > Here is the 3rd full webrev: > ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.02 > > and the delta update to the 1st webrev: typo: 1st -> 2nd > ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.01 > > Xuelei > > On 6/3/2018 9:43 PM, Xuelei Fan wrote: >> Hi, >> >> Here it the 2nd full webrev: >> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >> >> and the delta update to the 1st webrev: >> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >> >> Xuelei >> >> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>> Hi, >>> >>> I'd like to invite you to review the TLS 1.3 implementation.? I >>> appreciate it if I could have compatibility and specification >>> feedback before May 31, 2018, and implementation feedback before June >>> 7, 2018. >>> >>> Here is the webrev: >>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>> >>> The formal TLS 1.3 specification is not finalized yet, although it >>> had been approved to be a standard.? The implementation is based on >>> the draft version 28: >>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>> >>> For the overall description of this enhancement, please refer to JEP >>> 332: >>> ???? http://openjdk.java.net/jeps/332 >>> >>> For the compatibility and specification update, please refer to CSR >>> 8202625: >>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>> >>> Note that we are using the sandbox for the development right now. >>> For more information, please refer to Bradford's previous email: >>> >>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>> >>> Thanks & Regards, >>> Xuelei From anthony.scarpino at oracle.com Fri Jun 8 18:22:05 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 8 Jun 2018 11:22:05 -0700 Subject: RFR JDK-8178374: Problematic ByteBuffer handling in CipherSpi.bufferCrypt method In-Reply-To: References: Message-ID: <3d200acb-b6dd-1062-7404-05ce3337362a@oracle.com> On 06/06/2018 02:16 PM, Valerie Peng wrote: > Hi Tony, > > Can you please help reviewing this fix? The original impl uses buffering > for both input and output and is broken in several places. I ended up > re-writing most of them. The buffering is done only on input. The new > regression test covers all 4 combination of input/output ByteBuffers as > well as various sizes. > > Webrev: http://cr.openjdk.java.net/~valeriep/8178374/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8178374 > > Thanks, > Valerie The change looks fine to me. Thanks Tony From xuelei.fan at oracle.com Fri Jun 8 19:05:04 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 8 Jun 2018 12:05:04 -0700 Subject: SSLStringize.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> Message-ID: Update: http://hg.openjdk.java.net/jdk/sandbox/rev/25178bb3e8f5 On 6/6/2018 3:58 AM, Weijun Wang wrote: > SSLStringize.java: > > 1. I assume the toString() method does not change the internal status of a ByteBuffer? Is it worth mentioning this in the spec? > > 2. Should this interface and all its implementations be renamed to ***Stringnizer? > Good points! Updated in the above changeset. > 3. Lot of typo: ***Concumer. You can probably "cd sun/security/ssl" and run > > perl -i -pe 's/Concumer/Consumer/g' *.java > The issues had been updated in another changeset. > The whole SSLStringize + children classes looks complicated to me. Since the implementation is almost always creating a SSLExtensionSpec object and calling its toString, is it possible to register this SSLExtensionSpec class name in each enum value in SSLExtension and somehow simplify the design? Something like -- > > In constructor of SSLExtension, change the last parameter from > "SSLStringize stringize" to "Class specClazz" > store the value into a private field named specClazz, and > then you can change "stringize.toString(byteBuffer)" to something like > "specClazz.newInstance(byteBuffer).toString()". > There is one or two exceptions that the specClazz.newInstance(byteBuffer) does not apply. If we use this style, we would have a limit on the extension constructor. I would prefer to have the flexibility in the SSLExtensionSpec implementation. Thanks, Xuelei > That said, I know you must have thought about this much more. If there is any space for enhancement, we can always refactor it later. > > Thanks > Max > From valerie.peng at oracle.com Fri Jun 8 19:19:36 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 8 Jun 2018 12:19:36 -0700 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> Message-ID: <38e2cb45-002b-6e56-f4e0-84f2361f3556@oracle.com> Hi Xuelei, Some typos, line 139: minial -> minimal, line 144: caculate -> calculate, minial -> minimal When constructing PSSParameterSpec object on line 174, I think it's better to specify new MGF1ParameterSpec(hash) instead of null. Although current RSASSA-PSS signature algorithm impl in SunRsaSign provider will use the same message digest algorithm if no MGF1ParameterSpec is specified. However, this is somewhat a gray area and maybe better to be explicit Do we need a constructor with both NamedGroup and SigAlgParamSpec? NamedGroup is for EC and SigAlgParamSpec is for RSASSA-PSS, they shouldn't co-exist in the same scheme, right? There are currently 5 constructors in SignatureScheme class, I find the ordering of arguments somewhat confusing. The required arguments should appear first and we can add optional ones after them. Easier to read this way, at least for me... That's it for this class. More to review. Thanks, Valerie On 2/20/2018 11:57 AM, Xuelei Fan wrote: > Hi, > > I'd like to invite you to review the TLS 1.3 full handshake > implementation.? I appreciate it if I could have feedback before March > 9, 2018. > > In the "JDK-8185576: New handshake implementation" [1] code review > around, I was trying to re-org the TLS handshaking implementation in the > SunJSSE provider.? If you had reviewed that part, you can start from > the following webrev that based on the update of JDK-8185576: > http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.00 > > If you would like start from earlier, here is the webrev that contains > the handshaking implementation re-org in JDK-8185576: > http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > > This changeset only implements the full handshake of TLS 1.3, rather > then a fully implementation of the latest TLS 1.3 draft [2]. > > In this implementation, I removed: > 1. the KRB5 cipher suite implementation. > Please let me know if you are still using KRB5 cipher suite.? I may > not add them back if no objections. > > 2. OCSP stapling. > This feature will be added back later. > > Resumption and key update, and more features may be added later. > > Thanks & Regards, > Xuelei > > [1]: > http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016642.html > [2]: https://tools.ietf.org/html/draft-ietf-tls-tls13-24 From xuelei.fan at oracle.com Fri Jun 8 19:54:51 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 8 Jun 2018 12:54:51 -0700 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: <38e2cb45-002b-6e56-f4e0-84f2361f3556@oracle.com> References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> <38e2cb45-002b-6e56-f4e0-84f2361f3556@oracle.com> Message-ID: <80740395-1d45-2bf8-439e-c08235d5914a@oracle.com> > http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.02 Update: http://hg.openjdk.java.net/jdk/sandbox/rev/f4c7a97a1275 On 6/8/2018 12:19 PM, Valerie Peng wrote: > Hi Xuelei, > > > > Some typos, line 139: minial -> minimal, line 144: caculate -> > calculate, minial -> minimal > When constructing PSSParameterSpec object on line 174, I think it's > better to specify new MGF1ParameterSpec(hash) instead of null. Although > current RSASSA-PSS signature algorithm impl in SunRsaSign provider will > use the same message digest algorithm if no MGF1ParameterSpec is > specified. However, this is somewhat a gray area and maybe better to be > explicit > Good catches! Fixed in the above changeset. > Do we need a constructor with both NamedGroup and SigAlgParamSpec? > NamedGroup is for EC and SigAlgParamSpec is for RSASSA-PSS, they > shouldn't co-exist in the same scheme, right? > So far, they cannot co-exist in the same scheme. I would like to make an update together with the following coding style. > There are currently 5 constructors in SignatureScheme class, I find the > ordering of arguments somewhat confusing. The required arguments should > appear first and we can add optional ones after them. Easier to read > this way, at least for me... > It makes senses to me. I plan to do it later, maybe after we merge to the mainline. Here is the JBS bug I used to track the issues: https://bugs.openjdk.java.net/browse/JDK-8204636 Thanks, Xuelei > That's it for this class. More to review. > Thanks, > Valerie > > On 2/20/2018 11:57 AM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 full handshake >> implementation.? I appreciate it if I could have feedback before March >> 9, 2018. >> >> In the "JDK-8185576: New handshake implementation" [1] code review >> around, I was trying to re-org the TLS handshaking implementation in the >> SunJSSE provider.? If you had reviewed that part, you can start from >> the following webrev that based on the update of JDK-8185576: >> http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.00 >> >> If you would like start from earlier, here is the webrev that contains >> the handshaking implementation re-org in JDK-8185576: >> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> >> This changeset only implements the full handshake of TLS 1.3, rather >> then a fully implementation of the latest TLS 1.3 draft [2]. >> >> In this implementation, I removed: >> 1. the KRB5 cipher suite implementation. >> Please let me know if you are still using KRB5 cipher suite.? I may >> not add them back if no objections. >> >> 2. OCSP stapling. >> This feature will be added back later. >> >> Resumption and key update, and more features may be added later. >> >> Thanks & Regards, >> Xuelei >> >> [1]: >> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016642.html >> >> [2]: https://tools.ietf.org/html/draft-ietf-tls-tls13-24 > From xuelei.fan at oracle.com Fri Jun 8 23:52:49 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 8 Jun 2018 16:52:49 -0700 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: <57f19cae-50e1-066e-cfc2-47678eb493ea@oracle.com> References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> <00792b59-64ef-c406-fe37-02756310ec0a@oracle.com> <57f19cae-50e1-066e-cfc2-47678eb493ea@oracle.com> Message-ID: <5a34abf0-37c3-55b2-5500-bb5a4f4648b9@oracle.com> Update: http://hg.openjdk.java.net/jdk/sandbox/rev/ad4c1c488574 This update cleans the unused methods in RSASignature.java. Xuelei On 6/7/2018 5:25 PM, Xuelei Fan wrote: > On 6/7/2018 3:27 PM, Valerie Peng wrote: >> Hi Xuelei, >> >> There seems to be inconsistency >> in whether you can override the internal md5, sha1 digest objects >> through the engineSetParameter(String, Object) call. > I agreed.? The use of RSASignature is limited in the provider.? The > engineSetParameter() is not used so we don't allow the method in the > implementation. > >> Assuming we no longer need to override the internal digest objects, we >> can remove getInternalInstance(), setHashes(...). > I agreed. > >> Also, not sure how useful is RSASignature.getInstance() as it simply >> calls JsseJce.getSignature(JsseJce.SIGNATURE_SSLRSA); >> > The calls to JsseJce.getSignature() are mainly to use the specific FIPS > SunJSSE.cryptoProvider.? Although FIPS is an old experimental feature, > we don't remove it from the provider yet.? So you may see some unusual > use of getInstance() that calling into JsseJce impl. > > Thanks, > Xuelei > >> Still looking at more files, just thought that I will get this to you >> first. >> >> Valerie >> >> >> On 2/20/2018 11:57 AM, Xuelei Fan wrote: >>> Hi, >>> >>> I'd like to invite you to review the TLS 1.3 full handshake >>> implementation.? I appreciate it if I could have feedback before >>> March 9, 2018. >>> >>> In the "JDK-8185576: New handshake implementation" [1] code review >>> around, I was trying to re-org the TLS handshaking implementation in the >>> SunJSSE provider.? If you had reviewed that part, you can start from >>> the following webrev that based on the update of JDK-8185576: >>> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.00 >>> >>> If you would like start from earlier, here is the webrev that >>> contains the handshaking implementation re-org in JDK-8185576: >>> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>> >>> >>> This changeset only implements the full handshake of TLS 1.3, rather >>> then a fully implementation of the latest TLS 1.3 draft [2]. >>> >>> In this implementation, I removed: >>> 1. the KRB5 cipher suite implementation. >>> Please let me know if you are still using KRB5 cipher suite.? I may >>> not add them back if no objections. >>> >>> 2. OCSP stapling. >>> This feature will be added back later. >>> >>> Resumption and key update, and more features may be added later. >>> >>> Thanks & Regards, >>> Xuelei >>> >>> [1]: >>> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016642.html >>> >>> [2]: https://tools.ietf.org/html/draft-ietf-tls-tls13-24 >> From valerie.peng at oracle.com Sat Jun 9 00:16:29 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 8 Jun 2018 17:16:29 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> Message-ID: Hi Xuelei, Will this.requestedServerNames ever be null? This field is initialized in constructors with Collections.xxxList(...) method. Are the two private fields "peerPrincipal" and "localPrincipal" really used? There are two pkg private methods, setPeer/LocalPrincipal(...) which sets their values, however, I don't see these two fields used inside this class. line 232, 240, 248, 264, - 273: Are we sure that we want to throw RuntimeException? It seems too generic? Quite some more fields are initialized in one constructor (line 191) than the other one (line 175), e.g. peerCerts, compressionMethod, negotiatedMaxFragLen (and more). Is such difference expected? The ordering of initialization is also different which may be error prone for future maintenance. That's all I have for today. Will continue review next Monday. Valerie On 5/25/2018 4:45 PM, Xuelei Fan wrote: > Hi, > > I'd like to invite you to review the TLS 1.3 implementation.? I > appreciate it if I could have compatibility and specification feedback > before May 31, 2018, and implementation feedback before June 7, 2018. > > Here is the webrev: > ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > The formal TLS 1.3 specification is not finalized yet, although it had > been approved to be a standard.? The implementation is based on the > draft version 28: > ??? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 > > For the overall description of this enhancement, please refer to JEP 332: > ??? http://openjdk.java.net/jeps/332 > > For the compatibility and specification update, please refer to CSR > 8202625: > ??? https://bugs.openjdk.java.net/browse/JDK-8202625 > > Note that we are using the sandbox for the development right now. For > more information, please refer to Bradford's previous email: > > http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html > > Thanks & Regards, > Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Sat Jun 9 02:45:13 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 8 Jun 2018 19:45:13 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> Message-ID: > BaseSSLSocketImpl.java > ---------------------- Update: http://hg.openjdk.java.net/jdk/sandbox/rev/bad9f4c7eeec Update to handle EOFException and requireCloseNotify property. Xuelei On 6/7/2018 10:28 AM, Bradford Wetmore wrote: > Also reviewed SSLSocketFactoryImpl.java > > > BaseSSLSocketImpl.java > ---------------------- > I don't see where requireCloseNotify is actually being used in the > remaining code.? If you are removing this functionality, you should > probably be calling that out in your CSR. > > SSLSessionContextImpl.java > -------------------------- > The only change here was to reorder the import of Vector (obsolete) and > update the copyright?? May I ask why?? If this was somehow a netbeans > suggestion, there were several other things that could be updated that > seem more important.? e.g.? 37-39 could be made final.? 207: unnecessary > unboxing. > > Brad > > > > > On 6/6/2018 5:45 PM, Bradford Wetmore wrote: >> Today, I looked over SunJSSE.java, Utilities.java, and >> module-info.java. ??Mostly nits below, some style things. >> >> >> Utilities.java >> -------------- >> >> 39:? hexDigits can be private. >> >> 42:? Extra level of indent.? 4 or 8. >> >> 39-41:? Nits: When variables are static finals, they are usually >> written uppercase. >> >> 115:? Extra " " and can we get SNI cap'd? >> >> HostName for? server name indication >> -> >> HostName for Server Name Indication >> >> 150:? Minor Nit:? You're concating ("+") and then using >> StringBuilder.append(), instead of simply append chaining which might >> be slightly more efficient. >> >> 167-217:? The code looks ok, but this might be reworked to take better >> advantage of StringBuilder.append() chaining, rather than the mix of >> concat and append here now.? e.g. what you did with toHexString(long). >> I see much of the same code repeated over and over here.? Can be done >> later. >> >> Brad >> >> >> >> On 6/3/2018 9:43 PM, Xuelei Fan wrote: >>> Hi, >>> >>> Here it the 2nd full webrev: >>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >>> >>> and the delta update to the 1st webrev: >>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >>> >>> Xuelei >>> >>> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> I'd like to invite you to review the TLS 1.3 implementation.? I >>>> appreciate it if I could have compatibility and specification >>>> feedback before May 31, 2018, and implementation feedback before >>>> June 7, 2018. >>>> >>>> Here is the webrev: >>>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>>> >>>> The formal TLS 1.3 specification is not finalized yet, although it >>>> had been approved to be a standard.? The implementation is based on >>>> the draft version 28: >>>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>>> >>>> For the overall description of this enhancement, please refer to JEP >>>> 332: >>>> ???? http://openjdk.java.net/jeps/332 >>>> >>>> For the compatibility and specification update, please refer to CSR >>>> 8202625: >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>>> >>>> Note that we are using the sandbox for the development right now. >>>> For more information, please refer to Bradford's previous email: >>>> >>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>>> >>>> >>>> Thanks & Regards, >>>> Xuelei From bradford.wetmore at oracle.com Sat Jun 9 02:55:16 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 8 Jun 2018 19:55:16 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> Message-ID: <1a02a29e-b3e2-b82b-9d7b-ee20765b785f@oracle.com> CipherSuite.java ---------------- 74: There is a mix of ciphersuite initialization styles, which I find confusing. In the *_OF_12, you pass the MAC of M_NULL, with H_* being used for PRF/HASH, which is also used for the MAC value for new suites, IIUC. Would you consider specifying both in the enum constructor rather than M_NULL? KeyExchange keyExchange, SSLCipher cipher, MacAlg macAlg, HashAlg hashAlg) to_12 0x0018, false, "SSL_DH_anon_WITH_RC4_128_MD5", "", ProtocolVersion.PROTOCOLS_TO_T12, K_DH_ANON, B_RC4_128, M_MD5, H_SHA256), of_12 0x00A2, true, "TLS_DHE_DSS_WITH_AES_128_GCM_SHA256", "", ProtocolVersion.PROTOCOLS_OF_12, K_DHE_DSS, B_AES_128_GCM, M_NULL, H_SHA256), -> K_DHE_DSS, B_AES_128_GCM, H_SHA256, H_SHA256), 124-287: All of a sudden the indention style changed, and then corrected itself back a little later at the "non-enabled" suites. Can you remove these extra spaces here? 262: What is the point of the aliases argument in the constructor? Was the idea to provide a mapping between suites we originally created with the SSL_ prefix vs the more current TLS_ prefix we used in the later TLS protocols? There is only an empty string in every constructor, so this code doesn't do anything. 377: Maybe provide the RFC numbers (e.g. 4346, 5469, 5246, etc) for reference? 455: This "other values" info is way out of date. If anything, I would suggest we simply provide a link at the top of this file to the https (not http) page, and be done with it. 803/814/824/867: I'm concerned of the performance impact of repeatedly iterating over 300+ ciphersuite ids/names using values(). You should benchmark and see if it makes sense to switch to using a HashMap (or even TreeMap) here. For the limited number of Protocols (< 10 for TLSv1.x), this approach is fine, but this has quite a bit larger search space. 840: Is this else/break needed? 863: This @throws is incorrect. 869 returns an emptyList instead of an Exception. 891: "...with currently installed providers"? This wording is strange, since it's all part of the SunJSSE provider. Can you just say "name unsupported"? 910: Can you please add a quick comment as to why/when you want a keyExchange == null. i.e. TLSv1.3. It took me a while to figure out when you would ever have a keyExchange==null. 995: For readability, you can line this up using a 80 char line. K_RSA ("RSA", true, false, NAMED_GROUP_NONE), ...deleted... SSLSessionImpl.java ------------------- 90: I think we need to revisit this decision, but not now. SSLServerSocketImpl.java ------------------------ 160: You should allow multiple changes between server to client, and switch enabled protocols/ciphersuites accordingly. SSLConfiguration.java --------------------- 99: This is a followup to the comment from last night. tls13VN is pretty much set, let's get this temporary stuff out of here. 108: Should we reverse the two tests here? Checking for System property and then not checking for a SunTlsExtendedMasterSecret would be a faster option in the false case, vs driving the JCE lookup machinery and then checking whether we'll be using it or not. SSLSocketImpl.java ------------------ 28: I'm not a fan of unnecessarily expanding the imports. Netbeans has/had a default of 5, but apparently turned it off by default in favor of single class imports. 76: Are you set on the name conContext? I'm still not 100% sure what it stands for. Alternate transportContext or connectionContext? 92: trustNameService could be private and all in caps. 102-269: Any chance of combining the commonalities of these different constructors into 1, and then do the constructor-specific things at the end? It will help with future maintenance to not have to make the same changes in multiple places. 484: A couple comments here would be appreciated about what these App* classes do. The old comments in App[InputStream would be sufficient, plus some of the other comments stripped out inside the class: Read data if needed ... notice that the connection guarantees that handshake, alert, and change cipher spec data streams are handled as they arrive, so we never see them here. Nice job on this refactoring in this class, there was a heck of a lot of cruft in this file after 20+ years. I am anxious to see how the rest of the code is laid out. TransportContext.java --------------------- 90: Any chance of combining these 3 constructors into 1? Almost identical duplicate code here. 682-683: These can be final. Thanks, Brad On 6/8/2018 10:21 AM, Xuelei Fan wrote: > Here is the 3rd full webrev: > ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.02 > > and the delta update to the 1st webrev: > ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.01 > > Xuelei > > On 6/3/2018 9:43 PM, Xuelei Fan wrote: >> Hi, >> >> Here it the 2nd full webrev: >> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >> >> and the delta update to the 1st webrev: >> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >> >> Xuelei >> >> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>> Hi, >>> >>> I'd like to invite you to review the TLS 1.3 implementation.? I >>> appreciate it if I could have compatibility and specification >>> feedback before May 31, 2018, and implementation feedback before June >>> 7, 2018. >>> >>> Here is the webrev: >>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>> >>> The formal TLS 1.3 specification is not finalized yet, although it >>> had been approved to be a standard.? The implementation is based on >>> the draft version 28: >>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>> >>> For the overall description of this enhancement, please refer to JEP >>> 332: >>> ???? http://openjdk.java.net/jeps/332 >>> >>> For the compatibility and specification update, please refer to CSR >>> 8202625: >>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>> >>> Note that we are using the sandbox for the development right now. >>> For more information, please refer to Bradford's previous email: >>> >>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>> >>> Thanks & Regards, >>> Xuelei From xuelei.fan at oracle.com Sat Jun 9 03:38:43 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 8 Jun 2018 20:38:43 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> Message-ID: <18ffd12c-91a6-c941-5a7b-063755ac6d76@oracle.com> Update: http://hg.openjdk.java.net/jdk/sandbox/rev/a02692615745 Code clean up for SSLSessionContextImpl.java On 6/7/2018 10:28 AM, Bradford Wetmore wrote: > > SSLSessionContextImpl.java > -------------------------- > The only change here was to reorder the import of Vector (obsolete) and > update the copyright?? May I ask why? It was NetBeans. > If this was somehow a netbeans > suggestion, there were several other things that could be updated that > seem more important.? e.g.? 37-39 could be made final.? 207: unnecessary > unboxing. > Yes, it is a good time to clean up the code. Thanks, Xuelei > Brad > > > > > On 6/6/2018 5:45 PM, Bradford Wetmore wrote: >> Today, I looked over SunJSSE.java, Utilities.java, and >> module-info.java. ??Mostly nits below, some style things. >> >> >> Utilities.java >> -------------- >> >> 39:? hexDigits can be private. >> >> 42:? Extra level of indent.? 4 or 8. >> >> 39-41:? Nits: When variables are static finals, they are usually >> written uppercase. >> >> 115:? Extra " " and can we get SNI cap'd? >> >> HostName for? server name indication >> -> >> HostName for Server Name Indication >> >> 150:? Minor Nit:? You're concating ("+") and then using >> StringBuilder.append(), instead of simply append chaining which might >> be slightly more efficient. >> >> 167-217:? The code looks ok, but this might be reworked to take better >> advantage of StringBuilder.append() chaining, rather than the mix of >> concat and append here now.? e.g. what you did with toHexString(long). >> I see much of the same code repeated over and over here.? Can be done >> later. >> >> Brad >> >> >> >> On 6/3/2018 9:43 PM, Xuelei Fan wrote: >>> Hi, >>> >>> Here it the 2nd full webrev: >>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >>> >>> and the delta update to the 1st webrev: >>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >>> >>> Xuelei >>> >>> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> I'd like to invite you to review the TLS 1.3 implementation.? I >>>> appreciate it if I could have compatibility and specification >>>> feedback before May 31, 2018, and implementation feedback before >>>> June 7, 2018. >>>> >>>> Here is the webrev: >>>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>>> >>>> The formal TLS 1.3 specification is not finalized yet, although it >>>> had been approved to be a standard.? The implementation is based on >>>> the draft version 28: >>>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>>> >>>> For the overall description of this enhancement, please refer to JEP >>>> 332: >>>> ???? http://openjdk.java.net/jeps/332 >>>> >>>> For the compatibility and specification update, please refer to CSR >>>> 8202625: >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>>> >>>> Note that we are using the sandbox for the development right now. >>>> For more information, please refer to Bradford's previous email: >>>> >>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>>> >>>> >>>> Thanks & Regards, >>>> Xuelei From jamil.j.nimeh at oracle.com Sat Jun 9 06:00:34 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 8 Jun 2018 23:00:34 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <1a02a29e-b3e2-b82b-9d7b-ee20765b785f@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> <1a02a29e-b3e2-b82b-9d7b-ee20765b785f@oracle.com> Message-ID: <639e5b65-bad8-f69c-291a-1fc2c9cfcb63@oracle.com> Hi Brad, just one follow-up to your CipherSuite comment, please see below. --Jamil On 06/08/2018 07:55 PM, Bradford Wetmore wrote: > > CipherSuite.java > ---------------- > 74:? There is a mix of ciphersuite initialization styles, which I find > confusing.? In the *_OF_12, you pass the MAC of M_NULL, with H_* being > used for PRF/HASH, which is also used for the MAC value for new > suites, IIUC.? Would you consider specifying both in the enum > constructor rather than M_NULL? > > ??? KeyExchange keyExchange, SSLCipher cipher, > ??? MacAlg macAlg, HashAlg hashAlg) > > to_12 > ??????????? 0x0018, false, "SSL_DH_anon_WITH_RC4_128_MD5", "", > ??????????? ProtocolVersion.PROTOCOLS_TO_T12, > ??????????? K_DH_ANON, B_RC4_128, M_MD5, H_SHA256), > > of_12 > ??????????? 0x00A2, true, "TLS_DHE_DSS_WITH_AES_128_GCM_SHA256", "", > ??????????? ProtocolVersion.PROTOCOLS_OF_12, > ??????????? K_DHE_DSS, B_AES_128_GCM, M_NULL, H_SHA256), > -> > ??????????? K_DHE_DSS, B_AES_128_GCM, H_SHA256, H_SHA256), These two suites may not be the best comparison, since you have a non-AEAD stream cipher up against AES-GCM.? For the latter, I think M_MULL in the MacAlg field is the right thing because GCM doesn't have a separate HMAC.? The authentication is performed through GHASH.? The only place for SHA-256 in this suite is for the PRF, IIUC.? As a second data point ChaCha20-Poly1305 suites (when we eventually do them) would also use M_NULL for the MacAlg since Poly1305 takes care of the authentication internally and SHA-256 is just used with PRF and/or HKDF in the TLS 1.3 case. > > 124-287:? All of a sudden the indention style changed, and then > corrected itself back a little later at the "non-enabled" suites. Can > you remove these extra spaces here? > > 262:? What is the point of the aliases argument in the constructor?? > Was the idea to provide a mapping between suites we originally created > with the SSL_ prefix vs the more current TLS_ prefix we used in the > later TLS protocols?? There is only an empty string in every > constructor, so this code doesn't do anything. > > 377:? Maybe provide the RFC numbers (e.g. 4346, 5469, 5246, etc) for > reference? > > 455:? This "other values" info is way out of date.? If anything, I > would suggest we simply provide a link at the top of this file to the > https (not http) page, and be done with it. > > 803/814/824/867:? I'm concerned of the performance impact of > repeatedly iterating over 300+ ciphersuite ids/names using values().? > You should benchmark and see if it makes sense to switch to using a > HashMap (or even TreeMap) here.? For the limited number of Protocols > (< 10 for TLSv1.x), this approach is fine, but this has quite a bit > larger search space. > > 840:? Is this else/break needed? > > 863:? This @throws is incorrect.? 869 returns an emptyList instead of > an Exception. > > 891:? "...with currently installed providers"?? This wording is > strange, since it's all part of the SunJSSE provider.? Can you just > say "name unsupported"? > > 910:? Can you please add a quick comment as to why/when you want a > keyExchange == null.? i.e. TLSv1.3.? It took me a while to figure out > when you would ever have a keyExchange==null. > > 995:? For readability, you can line this up using a 80 char line. > > ??? K_RSA?????????? ("RSA",??????????? true,? false, NAMED_GROUP_NONE), > ??? ...deleted... > > > SSLSessionImpl.java > ------------------- > 90:? I think we need to revisit this decision, but not now. > > > SSLServerSocketImpl.java > ------------------------ > 160:? You should allow multiple changes between server to client, and > switch enabled protocols/ciphersuites accordingly. > > > SSLConfiguration.java > --------------------- > 99:? This is a followup to the comment from last night.? tls13VN is > pretty much set, let's get this temporary stuff out of here. > > 108:? Should we reverse the two tests here?? Checking for System > property and then not checking for a SunTlsExtendedMasterSecret would > be a faster option in the false case, vs driving the JCE lookup > machinery and then checking whether we'll be using it or not. > > > SSLSocketImpl.java > ------------------ > 28:? I'm not a fan of unnecessarily expanding the imports. Netbeans > has/had a default of 5, but apparently turned it off by default in > favor of single class imports. > > 76:? Are you set on the name conContext?? I'm still not 100% sure what > it stands for.? Alternate transportContext or connectionContext? > > 92:? trustNameService could be private and all in caps. > > 102-269:? Any chance of combining the commonalities of these different > constructors into 1, and then do the constructor-specific things at > the end?? It will help with future maintenance to not have to make the > same changes in multiple places. > > 484:? A couple comments here would be appreciated about what these > App* classes do.? The old comments in App[InputStream would be > sufficient, plus some of the other comments stripped out inside the > class: > > ???? Read data if needed ... notice that the connection guarantees > ???? that handshake, alert, and change cipher spec data streams are > ???? handled as they arrive, so we never see them here. > > Nice job on this refactoring in this class, there was a heck of a lot > of cruft in this file after 20+ years.? I am anxious to see how the > rest of the code is laid out. > > > TransportContext.java > --------------------- > 90:? Any chance of combining these 3 constructors into 1?? Almost > identical duplicate code here. > > 682-683:? These can be final. > > > Thanks, > > Brad > > > > On 6/8/2018 10:21 AM, Xuelei Fan wrote: >> Here is the 3rd full webrev: >> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.02 >> >> and the delta update to the 1st webrev: >> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.01 >> >> Xuelei >> >> On 6/3/2018 9:43 PM, Xuelei Fan wrote: >>> Hi, >>> >>> Here it the 2nd full webrev: >>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >>> >>> and the delta update to the 1st webrev: >>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >>> >>> Xuelei >>> >>> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> I'd like to invite you to review the TLS 1.3 implementation.? I >>>> appreciate it if I could have compatibility and specification >>>> feedback before May 31, 2018, and implementation feedback before >>>> June 7, 2018. >>>> >>>> Here is the webrev: >>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>>> >>>> The formal TLS 1.3 specification is not finalized yet, although it >>>> had been approved to be a standard.? The implementation is based on >>>> the draft version 28: >>>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>>> >>>> For the overall description of this enhancement, please refer to >>>> JEP 332: >>>> ???? http://openjdk.java.net/jeps/332 >>>> >>>> For the compatibility and specification update, please refer to CSR >>>> 8202625: >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>>> >>>> Note that we are using the sandbox for the development right now.? >>>> For more information, please refer to Bradford's previous email: >>>> >>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>>> >>>> >>>> Thanks & Regards, >>>> Xuelei From sean.coffey at oracle.com Sat Jun 9 09:42:06 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Sat, 9 Jun 2018 10:42:06 +0100 Subject: SSLLogger.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> <12F8F4BF-F46C-4F0C-ABC2-162D1BADBCF1@oracle.com> <7f438619-0555-4860-63a3-ffd6270da97b@oracle.com> <81ac5d21-4315-3df5-c65e-9a518f797211@oracle.com> <4555CC11-AE7F-4B3E-B1C0-89B8DBA3B78B@oracle.com> <72191acc-b6d3-7ec1-8d62-e2164ddc4ac6@oracle.com> <2B36A4B3-C64F-46C4-9F05-3DC716E5B844@oracle.com> Message-ID: <5ec248d4-208c-9cea-370a-b0950e3ec930@oracle.com> Some comments on SSLLogger also : formatCaller() uses getStackTrace() to walk the stack. It's probably more expensive than using the newer Stackwalker class. Could it be replaced with something like : > ???????? return StackWalker.getInstance().walk(s -> > ???????????????? s.dropWhile((f -> > f.getClassName().startsWith("sun.security.ssl.SSLLogger"))) > ???????????????????????? .map(f -> f.getClassName() + ":" + > f.getLineNumber()) > ???????????????????????? .findFirst().orElse("unknown caller")); Looks like this method is not used : > 406 private static boolean isLoggerImpl(StackTraceElement ste) { > 407 String cn = ste.getClassName(); > 408 System.out.println("class name: " + cn); > 409 return cn.equals("sun.security.ssl.SSLLogger"); > 410 } Also the SSLSimpleFormatter class has dateFormat variable stored in a ThreadLocal. Is there a reason for that ? regards, Sean. On 08/06/2018 02:40, Xuelei Fan wrote: > I got your ideas.? Let's see if we can make a change, a little bit later. > > Thanks, > Xuelei > > On 6/7/2018 6:23 PM, Weijun Wang wrote: >> My final comment on this class: >> >> Since SSLConsoleLogger is a Logger child, its log(..., params) method >> should follow the Logger::log spec, which has >> >> ???????? /** >> ????????? * Logs a message with resource bundle and an optional list of >> ????????? * parameters. >> ????????? * ... >> ????????? * @param format the string message format in {@link >> ????????? * java.text.MessageFormat} format, (or a key in the message >> ????????? * catalog if {@code bundle} is not {@code null}); can be >> {@code null}. >> ????????? * @param params an optional list of parameters to the >> message (may be >> ????????? * none). >> ????????? * ... >> ????????? */ >> ???????? public void log(Level level, ResourceBundle bundle, String >> format, >> ???????????????? Object... params); >> >> Especially, the String parameter is in MessageFormat format (that's >> why it's named "format" but not "message"). However, >> SSLConsoleLogger::log is always called with format being a plain >> string and params are stacked in the output separated by command and >> newline. >> >> My opinion is that this is not the normal style of using a Logger and >> we should not allow system logger (through -Djavax.net.debug=). If >> you still see benefit in that, can we make this change at the moment? >> >> -??????????????????? logger.log(level, msg, formatted); >> +??????????????????? if (logger instanceof SSLConsoleLogger) { >> +??????????????????????? logger.log(level, msg, formatted); >> +??????????????????? } else { >> +??????????????????????? logger.log(level, msg + ": " + formatted); >> +??????????????????? } >> >> Thanks >> Max >> >>> On Jun 7, 2018, at 11:24 AM, Weijun Wang >>> wrote: >>> >>> I think I understand. So if a user sets it to empty, they will also >>> need to create a customized logger/formatter like SSLLogger that is >>> able to output a parameter without a placeholder in msg. >>> >>> --Max >>> >>>> On Jun 7, 2018, at 9:51 AM, Xuelei Fan wrote: >>>> >>>> In this implementation, the SunJSSE logging is updated to (the >>>> class comment lines): >>>> >>>> /** >>>> * Implementation of SSL logger. >>>> * >>>> * If the system property "javax.net.debug" is not defined, the >>>> debug logging >>>> * is turned off.? If the system property "javax.net.debug" is >>>> defined as >>>> * empty, the debug logger is specified by >>>> System.getLogger("javax.net.ssl"), >>>> * and applications can customize and configure the logger or use >>>> external >>>> * logging mechanisms.? If the system property "javax.net.debug" is >>>> defined >>>> * and non-empty, a private debug logger implemented in this class >>>> is used. >>>> */ >>>> >>>> On 6/6/2018 6:37 PM, Weijun Wang wrote: >>>>> But will any application use the logger named "javax.net.debug"?? >>>>> I think that's only for JSSE. >>>> If using System Logger, the "javax.net.debug" system property will >>>> be used to turn on/off the logger (define with empty or not defined). >>>> >>>> Xuelei >>>> >>>>>> On Jun 7, 2018, at 9:35 AM, Xuelei Fan? >>>>>> wrote: >>>>>> >>>>>> I see your concerns now.? Currently, we don't fine the format if >>>>>> using System logger.? Applications can define the format and >>>>>> output style for themselves if needed. That's also the purpose >>>>>> why we introduce the System Logger in the provider. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Sat Jun 9 15:15:31 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 9 Jun 2018 08:15:31 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <637c1aa7-a62f-ecae-7b7d-d261aae36573@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <637c1aa7-a62f-ecae-7b7d-d261aae36573@oracle.com> Message-ID: <8f8f6d5c-86f3-3128-6d54-6b7d0e03fbc5@oracle.com> Update: http://hg.openjdk.java.net/jdk/sandbox/rev/2d7e08d730b6 On 6/7/2018 7:36 PM, Bradford Wetmore wrote: > > I'm working my way through CipherSuite.java, slow going as I'm making > sure all of the ciphersuites got updated to the new format. > > SSLServerSocketFactoryImpl.java > ------------------------------- > This comment is actually an overall comment in other files in your > review.? Typically we don't make changes just for style (e.g.?? foo () > -> foo() , lines 56/73), but I'm guessing since so much has changed, > you're just going to clean things up now?? So I'm wondering why you > didn't do it in line /75/80/82/87/89/etc.? I'm all for making this > change now since the world is changing anyway. > > 38/73:? Why not just make it one line?? It's under 80 chars. > > 41:? context can be final. > Updated. > > CipherSuite.java > ---------------- > 28-33:? Just wondering why you chose to enumerate all of the java.util.*; > The IDE did it automatically. > > ProtocolVersion.java > -------------------- > 29-32:? Same question about enumerating all instances. > > 41:? And in SSLConfiguration: 99-101.? Why not just get rid of this now? > ?It's going to be 0x0304 in the final RFC. > Interop testing depends on it right now. The System property will be remove before we ship the produce. > 49:? I believe this protocol number is your anticipated number, I don't > see it mentioned anywhere in the current DTLS spec: > > ??? https://tools.ietf.org/html/draft-ietf-tls-dtls13-26 > > Just alluded to in section 5.3, but I haven't see anything in my further > IETF scanning about a specific DTLS version number having been assigned. > > Later down, you mention DTLS 1.3 quite a bit (e.g. PROTOCOLS_TO_13), is > this going to cause any adverse reactions since there is no DTLS 1.3 > implementation yet? > I removed DTLS 1.3 as we don't actually support it right now. > 95:? Why does this comment say 1.3 if this is a _OF_30? > > 136-146:? These "T" names are a little non-intuitive. > PROTOCOLS_TO_TLS11?? Should there be a similar for _TO_TLS13?? What > about PROTCOLS_TO_DTLS*? > Updated. > 229:? I probably don't understand the callers of this code well enough. > If DTLS, you return true if it's DLTS10/12/13 or later.? But false if > less.? Why are you allowing DTLS 1.0 and all later (unknown) versions? > Same question for the TLS arm.?? Why fail earlier than SSLv3, and allow > above TLSv1.3?? Also suggest you move the 243 into the else arm. > I added a comment for this method. It is used to check if the requested version number is beyond the minimal supported numbers. For example, if client request ox0304, because of version negotiation, 0x0303 (TLS 1.2) should be negotiated. However, if the requested number is 0x0101, the receiver should reject the connection as the version number is too small to be supported. > 289:? You already checked this condition in 285-287 above.? And then 304 > is no longer needed. > Good catch! Thanks, Xuelei > Brad > > > > > On 6/7/2018 10:28 AM, Bradford Wetmore wrote: >> Also reviewed SSLSocketFactoryImpl.java >> >> >> BaseSSLSocketImpl.java >> ---------------------- >> I don't see where requireCloseNotify is actually being used in the >> remaining code.? If you are removing this functionality, you should >> probably be calling that out in your CSR. >> >> SSLSessionContextImpl.java >> -------------------------- >> The only change here was to reorder the import of Vector (obsolete) >> and update the copyright?? May I ask why?? If this was somehow a >> netbeans suggestion, there were several other things that could be >> updated that seem more important.? e.g.? 37-39 could be made final. >> 207: unnecessary unboxing. >> >> Brad >> >> >> >> >> On 6/6/2018 5:45 PM, Bradford Wetmore wrote: >>> Today, I looked over SunJSSE.java, Utilities.java, and >>> module-info.java. ??Mostly nits below, some style things. >>> >>> >>> Utilities.java >>> -------------- >>> >>> 39:? hexDigits can be private. >>> >>> 42:? Extra level of indent.? 4 or 8. >>> >>> 39-41:? Nits: When variables are static finals, they are usually >>> written uppercase. >>> >>> 115:? Extra " " and can we get SNI cap'd? >>> >>> HostName for? server name indication >>> -> >>> HostName for Server Name Indication >>> >>> 150:? Minor Nit:? You're concating ("+") and then using >>> StringBuilder.append(), instead of simply append chaining which might >>> be slightly more efficient. >>> >>> 167-217:? The code looks ok, but this might be reworked to take >>> better advantage of StringBuilder.append() chaining, rather than the >>> mix of concat and append here now.? e.g. what you did with >>> toHexString(long). I see much of the same code repeated over and over >>> here.? Can be done later. >>> >>> Brad >>> >>> >>> >>> On 6/3/2018 9:43 PM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> Here it the 2nd full webrev: >>>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >>>> >>>> and the delta update to the 1st webrev: >>>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >>>> >>>> Xuelei >>>> >>>> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> I'd like to invite you to review the TLS 1.3 implementation.? I >>>>> appreciate it if I could have compatibility and specification >>>>> feedback before May 31, 2018, and implementation feedback before >>>>> June 7, 2018. >>>>> >>>>> Here is the webrev: >>>>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>>>> >>>>> The formal TLS 1.3 specification is not finalized yet, although it >>>>> had been approved to be a standard.? The implementation is based on >>>>> the draft version 28: >>>>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>>>> >>>>> For the overall description of this enhancement, please refer to >>>>> JEP 332: >>>>> ???? http://openjdk.java.net/jeps/332 >>>>> >>>>> For the compatibility and specification update, please refer to CSR >>>>> 8202625: >>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>>>> >>>>> Note that we are using the sandbox for the development right now. >>>>> For more information, please refer to Bradford's previous email: >>>>> >>>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>>>> >>>>> >>>>> Thanks & Regards, >>>>> Xuelei From anthony.scarpino at oracle.com Sat Jun 9 16:51:14 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Sat, 9 Jun 2018 09:51:14 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <1a02a29e-b3e2-b82b-9d7b-ee20765b785f@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> <1a02a29e-b3e2-b82b-9d7b-ee20765b785f@oracle.com> Message-ID: <2f23c4b3-7549-529e-c601-e31679a67aca@oracle.com> On 06/08/2018 07:55 PM, Bradford Wetmore wrote: [...] > > TransportContext.java > --------------------- > 90:? Any chance of combining these 3 constructors into 1?? Almost > identical duplicate code here. > I have some code to change this already. Tony From xuelei.fan at oracle.com Sun Jun 10 04:55:20 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 9 Jun 2018 21:55:20 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> Message-ID: <3597d28d-59a7-e684-7661-6453bdfc83a4@oracle.com> Hi Valerie, All good catches! I made a code clean up in the update: http://hg.openjdk.java.net/jdk/sandbox/rev/38c2a4078033 Thanks, Xuelei On 6/8/2018 5:16 PM, Valerie Peng wrote: > Hi Xuelei, > > > > Will this.requestedServerNames ever be null? This field is initialized > in constructors with Collections.xxxList(...) method. > > Are the two private fields "peerPrincipal" and "localPrincipal" really > used? There are two pkg private methods, setPeer/LocalPrincipal(...) > which sets their values, however, I don't see these two fields used > inside this class. > > line 232, 240, 248, 264, - 273: Are we sure that we want to throw > RuntimeException? It seems too generic? > > Quite some more fields are initialized in one constructor (line 191) > than the other one (line 175), e.g. peerCerts, compressionMethod, > negotiatedMaxFragLen (and more). Is such difference expected? The > ordering of initialization is also different which may be error prone > for future maintenance. > > That's all I have for today. Will continue review next Monday. > Valerie > > On 5/25/2018 4:45 PM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 implementation.? I >> appreciate it if I could have compatibility and specification feedback >> before May 31, 2018, and implementation feedback before June 7, 2018. >> >> Here is the webrev: >> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> The formal TLS 1.3 specification is not finalized yet, although it had >> been approved to be a standard.? The implementation is based on the >> draft version 28: >> https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >> >> For the overall description of this enhancement, please refer to JEP 332: >> http://openjdk.java.net/jeps/332 >> >> For the compatibility and specification update, please refer to CSR >> 8202625: >> https://bugs.openjdk.java.net/browse/JDK-8202625 >> >> Note that we are using the sandbox for the development right now. For >> more information, please refer to Bradford's previous email: >> >> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >> >> Thanks & Regards, >> Xuelei > From xuelei.fan at oracle.com Sun Jun 10 20:41:30 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 10 Jun 2018 13:41:30 -0700 Subject: SSLLogger.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <5ec248d4-208c-9cea-370a-b0950e3ec930@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <4af1f50c-f190-cd3c-36eb-46d785e5ffe0@oracle.com> <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> <12F8F4BF-F46C-4F0C-ABC2-162D1BADBCF1@oracle.com> <7f438619-0555-4860-63a3-ffd6270da97b@oracle.com> <81ac5d21-4315-3df5-c65e-9a518f797211@oracle.com> <4555CC11-AE7F-4B3E-B1C0-89B8DBA3B78B@oracle.com> <72191acc-b6d3-7ec1-8d62-e2164ddc4ac6@oracle.com> <2B36A4B3-C64F-46C4-9F05-3DC716E5B844@oracle.com> <5ec248d4-208c-9cea-370a-b0950e3ec930@oracle.com> Message-ID: Update: http://hg.openjdk.java.net/jdk/sandbox/rev/e4fe7c97b1de On 6/9/2018 2:42 AM, Se?n Coffey wrote: > Some comments on SSLLogger also : > > formatCaller() uses getStackTrace() to walk the stack. It's probably > more expensive than using the newer Stackwalker class. Could it be > replaced with something like : > >> ???????? return StackWalker.getInstance().walk(s -> >> ???????????????? s.dropWhile((f -> >> f.getClassName().startsWith("sun.security.ssl.SSLLogger"))) >> ???????????????????????? .map(f -> f.getClassName() + ":" + >> f.getLineNumber()) >> ???????????????????????? .findFirst().orElse("unknown caller")); > Good point! > Looks like this method is not used : > >> 406 private static boolean isLoggerImpl(StackTraceElement ste) { >> 407 String cn = ste.getClassName(); >> 408 System.out.println("class name: " + cn); >> 409 return cn.equals("sun.security.ssl.SSLLogger"); >> 410 } > Removed. > Also the SSLSimpleFormatter class has dateFormat variable stored in a > ThreadLocal. Is there a reason for that ? > SimpleDateFormat is not multiple thread-safe. There were some expected issues if using SimpleDateFormat instance directly in multiple threads environment. Thanks, Xuelei > regards, > Sean. > > > On 08/06/2018 02:40, Xuelei Fan wrote: >> I got your ideas.? Let's see if we can make a change, a little bit later. >> >> Thanks, >> Xuelei >> >> On 6/7/2018 6:23 PM, Weijun Wang wrote: >>> My final comment on this class: >>> >>> Since SSLConsoleLogger is a Logger child, its log(..., params) method >>> should follow the Logger::log spec, which has >>> >>> ???????? /** >>> ????????? * Logs a message with resource bundle and an optional list of >>> ????????? * parameters. >>> ????????? * ... >>> ????????? * @param format the string message format in {@link >>> ????????? * java.text.MessageFormat} format, (or a key in the message >>> ????????? * catalog if {@code bundle} is not {@code null}); can be >>> {@code null}. >>> ????????? * @param params an optional list of parameters to the >>> message (may be >>> ????????? * none). >>> ????????? * ... >>> ????????? */ >>> ???????? public void log(Level level, ResourceBundle bundle, String >>> format, >>> ???????????????? Object... params); >>> >>> Especially, the String parameter is in MessageFormat format (that's >>> why it's named "format" but not "message"). However, >>> SSLConsoleLogger::log is always called with format being a plain >>> string and params are stacked in the output separated by command and >>> newline. >>> >>> My opinion is that this is not the normal style of using a Logger and >>> we should not allow system logger (through -Djavax.net.debug=). If >>> you still see benefit in that, can we make this change at the moment? >>> >>> -??????????????????? logger.log(level, msg, formatted); >>> +??????????????????? if (logger instanceof SSLConsoleLogger) { >>> +??????????????????????? logger.log(level, msg, formatted); >>> +??????????????????? } else { >>> +??????????????????????? logger.log(level, msg + ": " + formatted); >>> +??????????????????? } >>> >>> Thanks >>> Max >>> >>>> On Jun 7, 2018, at 11:24 AM, Weijun Wang >>>> wrote: >>>> >>>> I think I understand. So if a user sets it to empty, they will also >>>> need to create a customized logger/formatter like SSLLogger that is >>>> able to output a parameter without a placeholder in msg. >>>> >>>> --Max >>>> >>>>> On Jun 7, 2018, at 9:51 AM, Xuelei Fan wrote: >>>>> >>>>> In this implementation, the SunJSSE logging is updated to (the >>>>> class comment lines): >>>>> >>>>> /** >>>>> * Implementation of SSL logger. >>>>> * >>>>> * If the system property "javax.net.debug" is not defined, the >>>>> debug logging >>>>> * is turned off.? If the system property "javax.net.debug" is >>>>> defined as >>>>> * empty, the debug logger is specified by >>>>> System.getLogger("javax.net.ssl"), >>>>> * and applications can customize and configure the logger or use >>>>> external >>>>> * logging mechanisms.? If the system property "javax.net.debug" is >>>>> defined >>>>> * and non-empty, a private debug logger implemented in this class >>>>> is used. >>>>> */ >>>>> >>>>> On 6/6/2018 6:37 PM, Weijun Wang wrote: >>>>>> But will any application use the logger named "javax.net.debug"? >>>>>> I think that's only for JSSE. >>>>> If using System Logger, the "javax.net.debug" system property will >>>>> be used to turn on/off the logger (define with empty or not defined). >>>>> >>>>> Xuelei >>>>> >>>>>>> On Jun 7, 2018, at 9:35 AM, Xuelei Fan >>>>>>> wrote: >>>>>>> >>>>>>> I see your concerns now.? Currently, we don't fine the format if >>>>>>> using System logger.? Applications can define the format and >>>>>>> output style for themselves if needed. That's also the purpose >>>>>>> why we introduce the System Logger in the provider. >>>> >>> > From xuelei.fan at oracle.com Mon Jun 11 04:52:35 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 10 Jun 2018 21:52:35 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <639e5b65-bad8-f69c-291a-1fc2c9cfcb63@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> <1a02a29e-b3e2-b82b-9d7b-ee20765b785f@oracle.com> <639e5b65-bad8-f69c-291a-1fc2c9cfcb63@oracle.com> Message-ID: <17e518b7-7167-174a-c764-fac9d8955f8e@oracle.com> Update: http://hg.openjdk.java.net/jdk/sandbox/rev/da9979451b7a On 6/8/2018 11:00 PM, Jamil Nimeh wrote: > Hi Brad, just one follow-up to your CipherSuite comment, please see below. > > --Jamil > > > On 06/08/2018 07:55 PM, Bradford Wetmore wrote: >> >> CipherSuite.java >> ---------------- >> 74:? There is a mix of ciphersuite initialization styles, which I find >> confusing.? In the *_OF_12, you pass the MAC of M_NULL, with H_* being >> used for PRF/HASH, which is also used for the MAC value for new >> suites, IIUC.? Would you consider specifying both in the enum >> constructor rather than M_NULL? >> >> ??? KeyExchange keyExchange, SSLCipher cipher, >> ??? MacAlg macAlg, HashAlg hashAlg) >> >> to_12 >> ??????????? 0x0018, false, "SSL_DH_anon_WITH_RC4_128_MD5", "", >> ??????????? ProtocolVersion.PROTOCOLS_TO_T12, >> ??????????? K_DH_ANON, B_RC4_128, M_MD5, H_SHA256), >> >> of_12 >> ??????????? 0x00A2, true, "TLS_DHE_DSS_WITH_AES_128_GCM_SHA256", "", >> ??????????? ProtocolVersion.PROTOCOLS_OF_12, >> ??????????? K_DHE_DSS, B_AES_128_GCM, M_NULL, H_SHA256), >> -> >> ??????????? K_DHE_DSS, B_AES_128_GCM, H_SHA256, H_SHA256), > These two suites may not be the best comparison, since you have a > non-AEAD stream cipher up against AES-GCM.? For the latter, I think > M_MULL in the MacAlg field is the right thing because GCM doesn't have a > separate HMAC.? The authentication is performed through GHASH.? The only > place for SHA-256 in this suite is for the PRF, IIUC.? As a second data > point ChaCha20-Poly1305 suites (when we eventually do them) would also > use M_NULL for the MacAlg since Poly1305 takes care of the > authentication internally and SHA-256 is just used with PRF and/or HKDF > in the TLS 1.3 case. I agreed with Jamil. >> >> 124-287:? All of a sudden the indention style changed, and then >> corrected itself back a little later at the "non-enabled" suites. Can >> you remove these extra spaces here? >> Removed. >> 262:? What is the point of the aliases argument in the constructor? >> Was the idea to provide a mapping between suites we originally created >> with the SSL_ prefix vs the more current TLS_ prefix we used in the >> later TLS protocols?? There is only an empty string in every >> constructor, so this code doesn't do anything. >> Added the aliases. >> 377:? Maybe provide the RFC numbers (e.g. 4346, 5469, 5246, etc) for >> reference? >> Added. >> 455:? This "other values" info is way out of date.? If anything, I >> would suggest we simply provide a link at the top of this file to the >> https (not http) page, and be done with it. >> Updated. Move the https line to the top of the file. >> 803/814/824/867:? I'm concerned of the performance impact of >> repeatedly iterating over 300+ ciphersuite ids/names using values(). >> You should benchmark and see if it makes sense to switch to using a >> HashMap (or even TreeMap) here.? For the limited number of Protocols >> (< 10 for TLSv1.x), this approach is fine, but this has quite a bit >> larger search space. >> Good point! This enhancement now is tracked with https://bugs.openjdk.java.net/browse/JDK-8204636 >> 840:? Is this else/break needed? >> Yes. It is mostly for performance by ignoring unsupported cipher suites look up. >> 863:? This @throws is incorrect.? 869 returns an emptyList instead of >> an Exception. >> Good catch! Updated. >> 891:? "...with currently installed providers"?? This wording is >> strange, since it's all part of the SunJSSE provider.? Can you just >> say "name unsupported"? >> Updated. >> 910:? Can you please add a quick comment as to why/when you want a >> keyExchange == null.? i.e. TLSv1.3.? It took me a while to figure out >> when you would ever have a keyExchange==null. >> Added. >> 995:? For readability, you can line this up using a 80 char line. >> >> ??? K_RSA?????????? ("RSA",??????????? true,? false, NAMED_GROUP_NONE), >> ??? ...deleted... >> Yes, these lines can have a better layout. >> >> SSLSessionImpl.java >> ------------------- >> 90:? I think we need to revisit this decision, but not now. >> OK. >> >> SSLServerSocketImpl.java >> ------------------------ >> 160:? You should allow multiple changes between server to client, and >> switch enabled protocols/ciphersuites accordingly. >> Yes, multiple changes are allowed. >> >> SSLConfiguration.java >> --------------------- >> 99:? This is a followup to the comment from last night.? tls13VN is >> pretty much set, let's get this temporary stuff out of here. >> It's for interop testing right now. The code will be removed before we shop the produce. The issue is tracked with: https://bugs.openjdk.java.net/browse/JDK-8204636 >> 108:? Should we reverse the two tests here?? Checking for System >> property and then not checking for a SunTlsExtendedMasterSecret would >> be a faster option in the false case, vs driving the JCE lookup >> machinery and then checking whether we'll be using it or not. >> Good catch! Updated. >> >> SSLSocketImpl.java >> ------------------ >> 28:? I'm not a fan of unnecessarily expanding the imports. Netbeans >> has/had a default of 5, but apparently turned it off by default in >> favor of single class imports. >> I'm a fan of expanding the imports now. It is more clear about the imported classes and the packet of a particular class. For example, we can use: import java.net.*; import java.io.*; Or import java.net.Socket; import java.io.StringReader; If using the "*" option, we don't actually know if Socket is in packet java.net or java.io. So if IDE has made the update, I'm not included to update them back any more. >> 76:? Are you set on the name conContext?? I'm still not 100% sure what >> it stands for.? Alternate transportContext or connectionContext? >> The name is implying connection context, but it is an instance of TransportContext. Do you like, traContext, for transport context? I'd like to use a short name as it is used a lot that it is easy to exceed the 80 character per line limit. >> 92:? trustNameService could be private and all in caps. >> Updated. >> 102-269:? Any chance of combining the commonalities of these different >> constructors into 1, and then do the constructor-specific things at >> the end?? It will help with future maintenance to not have to make the >> same changes in multiple places. >> It is not clear to me now. The issue is tracked with: https://bugs.openjdk.java.net/browse/JDK-8204636 >> 484:? A couple comments here would be appreciated about what these >> App* classes do.? The old comments in App[InputStream would be >> sufficient, plus some of the other comments stripped out inside the >> class: >> >> ???? Read data if needed ... notice that the connection guarantees >> ???? that handshake, alert, and change cipher spec data streams are >> ???? handled as they arrive, so we never see them here. >> Updated. >> Nice job on this refactoring in this class, there was a heck of a lot >> of cruft in this file after 20+ years.? I am anxious to see how the >> rest of the code is laid out. >> >> >> TransportContext.java >> --------------------- >> 90:? Any chance of combining these 3 constructors into 1?? Almost >> identical duplicate code here. >> This issue had been addressed in one of Tony's changesets: http://hg.openjdk.java.net/jdk/sandbox/rev/b152d06ed6a9 >> 682-683:? These can be final. >> Updated. Thanks, Xuelei >> >> Thanks, >> >> Brad >> >> >> >> On 6/8/2018 10:21 AM, Xuelei Fan wrote: >>> Here is the 3rd full webrev: >>> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.02 >>> >>> and the delta update to the 1st webrev: >>> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.01 >>> >>> Xuelei >>> >>> On 6/3/2018 9:43 PM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> Here it the 2nd full webrev: >>>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >>>> >>>> and the delta update to the 1st webrev: >>>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >>>> >>>> Xuelei >>>> >>>> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> I'd like to invite you to review the TLS 1.3 implementation.? I >>>>> appreciate it if I could have compatibility and specification >>>>> feedback before May 31, 2018, and implementation feedback before >>>>> June 7, 2018. >>>>> >>>>> Here is the webrev: >>>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>>>> >>>>> The formal TLS 1.3 specification is not finalized yet, although it >>>>> had been approved to be a standard.? The implementation is based on >>>>> the draft version 28: >>>>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>>>> >>>>> For the overall description of this enhancement, please refer to >>>>> JEP 332: >>>>> ???? http://openjdk.java.net/jeps/332 >>>>> >>>>> For the compatibility and specification update, please refer to CSR >>>>> 8202625: >>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>>>> >>>>> Note that we are using the sandbox for the development right now. >>>>> For more information, please refer to Bradford's previous email: >>>>> >>>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>>>> >>>>> >>>>> Thanks & Regards, >>>>> Xuelei > From weijun.wang at oracle.com Mon Jun 11 05:37:48 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 11 Jun 2018 13:37:48 +0800 Subject: SSLContextImpl.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> <53FFA825-DB0C-44A5-AFB5-DC14397848FB@oracle.com> <06F6CA08-DF0D-4B08-82DE-92E1FE8E360C@oracle.com> <2800cda6-cc4c-30f8-b373-4a8cd1e224da@oracle.com> <6c2d18c9-15a6-b181-78b0-023b63384c79@oracle.com> <59766BBD-78D0-4344-9FF6-94C05A237412@oracle.com> <514480CA-93F0-4861-BB30-F0D5042276B3@oracle.com> <1a1dd474-7a17-d0f4-d3ef-4898cc030f1d@oracle.com> Message-ID: The protocols (for example, SSLParameters::getProtocols) are now from new to old, which is opposite from the previous order. Why make this change? 41 * Instances of this class are immutable after the context is initialized. You mean instances of child of this class? It looks like this class itself can be init() multiple times. 414 return Arrays.asList(suites.toArray(new CipherSuite[0])); Is this better than new ArrayList(suites)? 940 candidates = new ProtocolVersion[refactored.size()]; 941 candidates = refactored.toArray(candidates); Why not candidates = refactored.toArray(new ProtocolVersion[refactored.size()]); 943 System.out.println(refactored.toString()); Please remove. Another thing in CipherSuite.java: 803 static CipherSuite nameOf(String ciperSuiteName) { Why isn't this method named valueOf()? No other comment. Thanks Max From daniel.fuchs at oracle.com Mon Jun 11 09:28:51 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 11 Jun 2018 10:28:51 +0100 Subject: SSLLogger.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> <12F8F4BF-F46C-4F0C-ABC2-162D1BADBCF1@oracle.com> <7f438619-0555-4860-63a3-ffd6270da97b@oracle.com> <81ac5d21-4315-3df5-c65e-9a518f797211@oracle.com> <4555CC11-AE7F-4B3E-B1C0-89B8DBA3B78B@oracle.com> <72191acc-b6d3-7ec1-8d62-e2164ddc4ac6@oracle.com> <2B36A4B3-C64F-46C4-9F05-3DC716E5B844@oracle.com> <5ec248d4-208c-9cea-370a-b0950e3ec930@oracle.com> Message-ID: <08eeb515-478d-5e00-8303-f7f2347afec9@oracle.com> Hi Xuelei, Just a note that it might be a better idea to rework the implementation of SSLLogger/SSLConsoleLogger a bit in order to have SSLLogger implement System.Logger. This would ensure that the SSLLogger class is skipped when looking for the caller, when the underlying logger is a logger returned by System.getogger() and the backend is java.util.logging. Otherwise the caller will appear to be the static methods defined on the SSLLogger class itself. best regards, -- daniel On 10/06/2018 21:41, Xuelei Fan wrote: > Update: http://hg.openjdk.java.net/jdk/sandbox/rev/e4fe7c97b1de > > On 6/9/2018 2:42 AM, Se?n Coffey wrote: >> Some comments on SSLLogger also : >> >> formatCaller() uses getStackTrace() to walk the stack. It's probably >> more expensive than using the newer Stackwalker class. Could it be >> replaced with something like : >> >>> ???????? return StackWalker.getInstance().walk(s -> >>> ???????????????? s.dropWhile((f -> >>> f.getClassName().startsWith("sun.security.ssl.SSLLogger"))) >>> ???????????????????????? .map(f -> f.getClassName() + ":" + >>> f.getLineNumber()) >>> ???????????????????????? .findFirst().orElse("unknown caller")); >> > Good point! From xuelei.fan at oracle.com Mon Jun 11 13:51:40 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 11 Jun 2018 06:51:40 -0700 Subject: SSLLogger.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <08eeb515-478d-5e00-8303-f7f2347afec9@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <908480B6-4D9B-464B-8A8C-DB25FA5D923D@oracle.com> <12F8F4BF-F46C-4F0C-ABC2-162D1BADBCF1@oracle.com> <7f438619-0555-4860-63a3-ffd6270da97b@oracle.com> <81ac5d21-4315-3df5-c65e-9a518f797211@oracle.com> <4555CC11-AE7F-4B3E-B1C0-89B8DBA3B78B@oracle.com> <72191acc-b6d3-7ec1-8d62-e2164ddc4ac6@oracle.com> <2B36A4B3-C64F-46C4-9F05-3DC716E5B844@oracle.com> <5ec248d4-208c-9cea-370a-b0950e3ec930@oracle.com> <08eeb515-478d-5e00-8303-f7f2347afec9@oracle.com> Message-ID: <2fff99a3-aaa7-cac1-e640-b23cc4956a8a@oracle.com> Hi Daniel, It's a good idea. I added your comment to the TLS 1.3 implementation issues tracking enhancement: https://bugs.openjdk.java.net/browse/JDK-8204636 Thanks, Xuelei On 6/11/2018 2:28 AM, Daniel Fuchs wrote: > Hi Xuelei, > > Just a note that it might be a better idea to rework > the implementation of SSLLogger/SSLConsoleLogger a > bit in order to have SSLLogger implement System.Logger. > This would? ensure that the SSLLogger class is skipped > when looking for the caller, when the underlying logger > is a logger returned by System.getogger() and the backend > is java.util.logging. Otherwise the caller will appear > to be the static methods defined on the SSLLogger class > itself. > > best regards, > > -- daniel > > > On 10/06/2018 21:41, Xuelei Fan wrote: >> Update: http://hg.openjdk.java.net/jdk/sandbox/rev/e4fe7c97b1de >> >> On 6/9/2018 2:42 AM, Se?n Coffey wrote: >>> Some comments on SSLLogger also : >>> >>> formatCaller() uses getStackTrace() to walk the stack. It's probably >>> more expensive than using the newer Stackwalker class. Could it be >>> replaced with something like : >>> >>>> ???????? return StackWalker.getInstance().walk(s -> >>>> ???????????????? s.dropWhile((f -> >>>> f.getClassName().startsWith("sun.security.ssl.SSLLogger"))) >>>> ???????????????????????? .map(f -> f.getClassName() + ":" + >>>> f.getLineNumber()) >>>> ???????????????????????? .findFirst().orElse("unknown caller")); >>> >> Good point! From xuelei.fan at oracle.com Mon Jun 11 14:32:25 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 11 Jun 2018 07:32:25 -0700 Subject: SSLContextImpl.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> <53FFA825-DB0C-44A5-AFB5-DC14397848FB@oracle.com> <06F6CA08-DF0D-4B08-82DE-92E1FE8E360C@oracle.com> <2800cda6-cc4c-30f8-b373-4a8cd1e224da@oracle.com> <6c2d18c9-15a6-b181-78b0-023b63384c79@oracle.com> <59766BBD-78D0-4344-9FF6-94C05A237412@oracle.com> <514480CA-93F0-4861-BB30-F0D5042276B3@oracle.com> <1a1dd474-7a17-d0f4-d3ef-4898cc030f1d@oracle.com> Message-ID: Update: http://hg.openjdk.java.net/jdk/sandbox/rev/12e20a7d6e26 On 6/10/2018 10:37 PM, Weijun Wang wrote: > The protocols (for example, SSLParameters::getProtocols) are now from new to old, which is opposite from the previous order. Why make this change? > > 41 * Instances of this class are immutable after the context is initialized. > > You mean instances of child of this class? It looks like this class itself can be init() multiple times. > Good catch! It it used to remind the implementation of this class. Reword to: Implementation note: Instances of this class and the child classes are immutable, except that the context initialization (SSLContext.init()) may reset the key, trust managers and source of secure random. > 414 return Arrays.asList(suites.toArray(new CipherSuite[0])); > > Is this better than new ArrayList(suites)? > I don't think so. Updated to use ArrayList. > 940 candidates = new ProtocolVersion[refactored.size()]; > 941 candidates = refactored.toArray(candidates); > > Why not candidates = refactored.toArray(new ProtocolVersion[refactored.size()]); > Hm, it's better. > 943 System.out.println(refactored.toString()); > > Please remove. > Good catch! > Another thing in CipherSuite.java: > > 803 static CipherSuite nameOf(String ciperSuiteName) { > > Why isn't this method named valueOf()? > There is a default builtin valueOf(String) method for enum type. Thanks, Xuelei > No other comment. > > Thanks > Max > From weijun.wang at oracle.com Mon Jun 11 14:36:39 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 11 Jun 2018 22:36:39 +0800 Subject: SSLContextImpl.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> <53FFA825-DB0C-44A5-AFB5-DC14397848FB@oracle.com> <06F6CA08-DF0D-4B08-82DE-92E1FE8E360C@oracle.com> <2800cda6-cc4c-30f8-b373-4a8cd1e224da@oracle.com> <6c2d18c9-15a6-b181-78b0-023b63384c79@oracle.com> <59766BBD-78D0-4344-9FF6-94C05A237412@oracle.com> <514480CA-93F0-4861-BB30-F0D5042276B3@oracle.com> <1a1dd474-7a17-d0f4-d3ef-4898cc030f1d@oracle.com> Message-ID: <9CFCEC56-8AEC-4F41-81D7-77CC7AF13C3D@oracle.com> > On Jun 11, 2018, at 10:32 PM, Xuelei Fan wrote: > >> >> Another thing in CipherSuite.java: >> 803 static CipherSuite nameOf(String ciperSuiteName) { >> Why isn't this method named valueOf()? > There is a default builtin valueOf(String) method for enum type. Ah, I see. But given the return type is a value, maybe simply of()? nameOf() sounds like it would return a name. --Max From xuelei.fan at oracle.com Mon Jun 11 14:54:11 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 11 Jun 2018 07:54:11 -0700 Subject: SSLContextImpl.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: <9CFCEC56-8AEC-4F41-81D7-77CC7AF13C3D@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> <53FFA825-DB0C-44A5-AFB5-DC14397848FB@oracle.com> <06F6CA08-DF0D-4B08-82DE-92E1FE8E360C@oracle.com> <2800cda6-cc4c-30f8-b373-4a8cd1e224da@oracle.com> <6c2d18c9-15a6-b181-78b0-023b63384c79@oracle.com> <59766BBD-78D0-4344-9FF6-94C05A237412@oracle.com> <514480CA-93F0-4861-BB30-F0D5042276B3@oracle.com> <1a1dd474-7a17-d0f4-d3ef-4898cc030f1d@oracle.com> <9CFCEC56-8AEC-4F41-81D7-77CC7AF13C3D@oracle.com> Message-ID: On 6/11/2018 7:36 AM, Weijun Wang wrote: > > >> On Jun 11, 2018, at 10:32 PM, Xuelei Fan wrote: >> >>> >>> Another thing in CipherSuite.java: >>> 803 static CipherSuite nameOf(String ciperSuiteName) { >>> Why isn't this method named valueOf()? >> There is a default builtin valueOf(String) method for enum type. > > Ah, I see. But given the return type is a value, maybe simply of()? > > nameOf() sounds like it would return a name. > I hesitated among nameOf(), ofName() and of() for a while. Good if you have a preference. As there are a few more nameOf() methods defined in other classes. I will find a chance to update them all. Thanks, Xuelei From weijun.wang at oracle.com Mon Jun 11 14:59:26 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 11 Jun 2018 22:59:26 +0800 Subject: SSLContextImpl.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> <53FFA825-DB0C-44A5-AFB5-DC14397848FB@oracle.com> <06F6CA08-DF0D-4B08-82DE-92E1FE8E360C@oracle.com> <2800cda6-cc4c-30f8-b373-4a8cd1e224da@oracle.com> <6c2d18c9-15a6-b181-78b0-023b63384c79@oracle.com> <59766BBD-78D0-4344-9FF6-94C05A237412@oracle.com> <514480CA-93F0-4861-BB30-F0D5042276B3@oracle.com> <1a1dd474-7a17-d0f4-d3ef-4898cc030f1d@oracle.com> Message-ID: > On Jun 11, 2018, at 10:32 PM, Xuelei Fan wrote: > >> The protocols (for example, SSLParameters::getProtocols) are now from new to old, which is opposite from the previous order. Why make this change? You didn't answer this. >> 41 * Instances of this class are immutable after the context is initialized. >> You mean instances of child of this class? It looks like this class itself can be init() multiple times. > Good catch! It it used to remind the implementation of this class. Reword to: > Implementation note: Instances of this class and the child classes are immutable, except that the context initialization (SSLContext.init()) may reset the key, trust managers and source of secure random. Maybe we can use a separate class to manage protocol/ciphersuite, and it can be real immutable. --Max From xuelei.fan at oracle.com Mon Jun 11 15:17:30 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 11 Jun 2018 08:17:30 -0700 Subject: SSLContextImpl.java (was Re: Code Review Request: TLS 1.3 Implementation) In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <7f7e1c70-0bf9-cbd1-f740-54f66db64d8b@oracle.com> <218CC720-DEC5-4117-824D-600BCB86C2F0@oracle.com> <5B2220D5-893A-43D4-860E-8954AE4B0544@oracle.com> <53FFA825-DB0C-44A5-AFB5-DC14397848FB@oracle.com> <06F6CA08-DF0D-4B08-82DE-92E1FE8E360C@oracle.com> <2800cda6-cc4c-30f8-b373-4a8cd1e224da@oracle.com> <6c2d18c9-15a6-b181-78b0-023b63384c79@oracle.com> <59766BBD-78D0-4344-9FF6-94C05A237412@oracle.com> <514480CA-93F0-4861-BB30-F0D5042276B3@oracle.com> <1a1dd474-7a17-d0f4-d3ef-4898cc030f1d@oracle.com> Message-ID: On 6/11/2018 7:59 AM, Weijun Wang wrote: > > >> On Jun 11, 2018, at 10:32 PM, Xuelei Fan wrote: >> >>> The protocols (for example, SSLParameters::getProtocols) are now from new to old, which is opposite from the previous order. Why make this change? > > You didn't answer this. > I missed this one. The update is mainly for protocol preferences. Previously, the older protocol presents first. Other part of the implementation may have to revert the order so that it can fit into the new "supported_versions" extension, where requires preference order. >>> 41 * Instances of this class are immutable after the context is initialized. >>> You mean instances of child of this class? It looks like this class itself can be init() multiple times. >> Good catch! It it used to remind the implementation of this class. Reword to: >> Implementation note: Instances of this class and the child classes are immutable, except that the context initialization (SSLContext.init()) may reset the key, trust managers and source of secure random. > > Maybe we can use a separate class to manage protocol/ciphersuite, and it can be real immutable. > It may be something we can try. I will think about it later. Thanks, Xuelei From valerie.peng at oracle.com Mon Jun 11 18:16:29 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 11 Jun 2018 11:16:29 -0700 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: <5a34abf0-37c3-55b2-5500-bb5a4f4648b9@oracle.com> References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> <00792b59-64ef-c406-fe37-02756310ec0a@oracle.com> <57f19cae-50e1-066e-cfc2-47678eb493ea@oracle.com> <5a34abf0-37c3-55b2-5500-bb5a4f4648b9@oracle.com> Message-ID: Looks good~ Valerie On 6/8/2018 4:52 PM, Xuelei Fan wrote: > Update: http://hg.openjdk.java.net/jdk/sandbox/rev/ad4c1c488574 > > This update cleans the unused methods in RSASignature.java. > > Xuelei > > On 6/7/2018 5:25 PM, Xuelei Fan wrote: >> On 6/7/2018 3:27 PM, Valerie Peng wrote: >>> Hi Xuelei, >>> >>> There seems to be inconsistency >>> in whether you can override the internal md5, sha1 digest objects >>> through the engineSetParameter(String, Object) call. >> I agreed.? The use of RSASignature is limited in the provider. The >> engineSetParameter() is not used so we don't allow the method in the >> implementation. >> >>> Assuming we no longer need to override the internal digest objects, >>> we can remove getInternalInstance(), setHashes(...). >> I agreed. >> >>> Also, not sure how useful is RSASignature.getInstance() as it simply >>> calls JsseJce.getSignature(JsseJce.SIGNATURE_SSLRSA); >>> >> The calls to JsseJce.getSignature() are mainly to use the specific >> FIPS SunJSSE.cryptoProvider.? Although FIPS is an old experimental >> feature, we don't remove it from the provider yet. So you may see >> some unusual use of getInstance() that calling into JsseJce impl. >> >> Thanks, >> Xuelei >> >>> Still looking at more files, just thought that I will get this to >>> you first. >>> >>> Valerie >>> >>> >>> On 2/20/2018 11:57 AM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> I'd like to invite you to review the TLS 1.3 full handshake >>>> implementation.? I appreciate it if I could have feedback before >>>> March 9, 2018. >>>> >>>> In the "JDK-8185576: New handshake implementation" [1] code review >>>> around, I was trying to re-org the TLS handshaking implementation >>>> in the >>>> SunJSSE provider.? If you had reviewed that part, you can start >>>> from the following webrev that based on the update of JDK-8185576: >>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.00 >>>> >>>> If you would like start from earlier, here is the webrev that >>>> contains the handshaking implementation re-org in JDK-8185576: >>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>>> >>>> >>>> This changeset only implements the full handshake of TLS 1.3, >>>> rather then a fully implementation of the latest TLS 1.3 draft [2]. >>>> >>>> In this implementation, I removed: >>>> 1. the KRB5 cipher suite implementation. >>>> Please let me know if you are still using KRB5 cipher suite.? I may >>>> not add them back if no objections. >>>> >>>> 2. OCSP stapling. >>>> This feature will be added back later. >>>> >>>> Resumption and key update, and more features may be added later. >>>> >>>> Thanks & Regards, >>>> Xuelei >>>> >>>> [1]: >>>> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016642.html >>>> >>>> [2]: https://tools.ietf.org/html/draft-ietf-tls-tls13-24 >>> From valerie.peng at oracle.com Mon Jun 11 18:21:21 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 11 Jun 2018 11:21:21 -0700 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: <80740395-1d45-2bf8-439e-c08235d5914a@oracle.com> References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> <38e2cb45-002b-6e56-f4e0-84f2361f3556@oracle.com> <80740395-1d45-2bf8-439e-c08235d5914a@oracle.com> Message-ID: <8e8afc70-8042-f909-0dfd-48789cf8aa52@oracle.com> Sure. Changes look fine. Valerie On 6/8/2018 12:54 PM, Xuelei Fan wrote: > > http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.02 > > Update: http://hg.openjdk.java.net/jdk/sandbox/rev/f4c7a97a1275 > > On 6/8/2018 12:19 PM, Valerie Peng wrote: >> Hi Xuelei, >> >> >> >> Some typos, line 139: minial -> minimal, line 144: caculate -> >> calculate, minial -> minimal >> When constructing PSSParameterSpec object on line 174, I think it's >> better to specify new MGF1ParameterSpec(hash) instead of null. >> Although current RSASSA-PSS signature algorithm impl in SunRsaSign >> provider will use the same message digest algorithm if no >> MGF1ParameterSpec is specified. However, this is somewhat a gray area >> and maybe better to be explicit >> > Good catches!? Fixed in the above changeset. > >> Do we need a constructor with both NamedGroup and SigAlgParamSpec? >> NamedGroup is for EC and SigAlgParamSpec is for RSASSA-PSS, they >> shouldn't co-exist in the same scheme, right? >> > So far, they cannot co-exist in the same scheme.? I would like to make > an update together with the following coding style. > >> There are currently 5 constructors in SignatureScheme class, I find >> the ordering of arguments somewhat confusing. The required arguments >> should appear first and we can add optional ones after them. Easier >> to read this way, at least for me... >> > It makes senses to me. > > I plan to do it later, maybe after we merge to the mainline.? Here is > the JBS bug I used to track the issues: > ???? https://bugs.openjdk.java.net/browse/JDK-8204636 > > Thanks, > Xuelei > >> That's it for this class. More to review. >> Thanks, >> Valerie >> >> On 2/20/2018 11:57 AM, Xuelei Fan wrote: >>> Hi, >>> >>> I'd like to invite you to review the TLS 1.3 full handshake >>> implementation.? I appreciate it if I could have feedback before >>> March 9, 2018. >>> >>> In the "JDK-8185576: New handshake implementation" [1] code review >>> around, I was trying to re-org the TLS handshaking implementation in >>> the >>> SunJSSE provider.? If you had reviewed that part, you can start from >>> the following webrev that based on the update of JDK-8185576: >>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.00 >>> >>> If you would like start from earlier, here is the webrev that >>> contains the handshaking implementation re-org in JDK-8185576: >>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>> >>> >>> This changeset only implements the full handshake of TLS 1.3, rather >>> then a fully implementation of the latest TLS 1.3 draft [2]. >>> >>> In this implementation, I removed: >>> 1. the KRB5 cipher suite implementation. >>> Please let me know if you are still using KRB5 cipher suite. I may >>> not add them back if no objections. >>> >>> 2. OCSP stapling. >>> This feature will be added back later. >>> >>> Resumption and key update, and more features may be added later. >>> >>> Thanks & Regards, >>> Xuelei >>> >>> [1]: >>> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016642.html >>> >>> [2]: https://tools.ietf.org/html/draft-ietf-tls-tls13-24 >> From cole at coleferrier.com Mon Jun 11 22:14:31 2018 From: cole at coleferrier.com (Cole Ferrier) Date: Mon, 11 Jun 2018 15:14:31 -0700 Subject: JDK-6722928 Support SSPI as a native JGSS-API provider - Current Status In-Reply-To: References: Message-ID: Thanks for your time reading this. (Sorry for the dupe post if it comes through, joined the list and resent) I am trying to setup a java client that runs in windows and needs to present a ticket to get access to a service. No delegation is required. We are running Java 8/Windows 10 and running into needing to change both the registry setting to enable access to the SessionKey and some group policies around UAC. This is not ideal from a security perspective. I was hoping that the Java community was making progress on this front especially since it sounds like from some other articles, Credential Guard further locks this down. I found: https://www.mail-archive.com/security-dev at openjdk.java.net/msg05291.html https://www.mail-archive.com/security-dev at openjdk.java.net/msg15532.html and: http://cr.openjdk.java.net/~weijun/6722928/ What is the current status of this? Should it compile and run in Java 8? or does it depend on the recently committed: https://bugs.openjdk.java.net/browse/JDK-8200468 Trying to understand out options with respect to getting SSO for this java client to work. On Mon, Jun 11, 2018 at 3:10 PM, Cole Ferrier wrote: > Thanks for your time reading this. > > I am trying to setup a java client that runs in windows and needs to > present a ticket to get access to a service. > > No delegation is required. > > We are running Java 8/Windows 10 and running into needing to change both > the registry setting to enable access to the SessionKey and some group > policies around UAC. > This is not ideal from a security perspective. > > I was hoping that the Java community was making progress on this front > especially since it sounds like from some other articles, Credential Guard > further locks this down. > > I found: > > https://www.mail-archive.com/security-dev at openjdk.java.net/msg05291.html > https://www.mail-archive.com/security-dev at openjdk.java.net/msg15532.html > > and: > > http://cr.openjdk.java.net/~weijun/6722928/ > > What is the current status of this? Should it compile and run in Java 8? > or does it depend on the recently committed: > > https://bugs.openjdk.java.net/browse/JDK-8200468 > > Trying to understand out options with respect to getting SSO for this java > client to work. > > Cole Ferrier > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Mon Jun 11 22:44:49 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 11 Jun 2018 15:44:49 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> Message-ID: Hi Xuelei, - If no child class intended, class may be made final. - line 99-101 and 120-133: delete as the comments said so? - I have some doubt on line 191 and 198, does "noSniExtension/Matcher" means "no SNI Extension/Matcher"? If yes, it seems that the condition should be ?? if (serverNames.isEmpty() || noSniExtension) { - Essentially getEnabledExtensions(SSLHandshake, ProtocolVersion) is almost same as getEnabledExtensions(SSLHandshake, List. It looks possible to refactor the impl to minimize code duplication. But this is no big deal. Thanks, Valerie On 5/25/2018 4:45 PM, Xuelei Fan wrote: > Hi, > > I'd like to invite you to review the TLS 1.3 implementation.? I > appreciate it if I could have compatibility and specification feedback > before May 31, 2018, and implementation feedback before June 7, 2018. > > Here is the webrev: > ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > The formal TLS 1.3 specification is not finalized yet, although it had > been approved to be a standard.? The implementation is based on the > draft version 28: > ??? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 > > For the overall description of this enhancement, please refer to JEP 332: > ??? http://openjdk.java.net/jeps/332 > > For the compatibility and specification update, please refer to CSR > 8202625: > ??? https://bugs.openjdk.java.net/browse/JDK-8202625 > > Note that we are using the sandbox for the development right now. For > more information, please refer to Bradford's previous email: > > http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html > > Thanks & Regards, > Xuelei From cole at coleferrier.com Mon Jun 11 22:10:48 2018 From: cole at coleferrier.com (Cole Ferrier) Date: Mon, 11 Jun 2018 15:10:48 -0700 Subject: JDK-6722928 Support SSPI as a native JGSS-API provider - Current Status Message-ID: Thanks for your time reading this. I am trying to setup a java client that runs in windows and needs to present a ticket to get access to a service. No delegation is required. We are running Java 8/Windows 10 and running into needing to change both the registry setting to enable access to the SessionKey and some group policies around UAC. This is not ideal from a security perspective. I was hoping that the Java community was making progress on this front especially since it sounds like from some other articles, Credential Guard further locks this down. I found: https://www.mail-archive.com/security-dev at openjdk.java.net/msg05291.html https://www.mail-archive.com/security-dev at openjdk.java.net/msg15532.html and: http://cr.openjdk.java.net/~weijun/6722928/ What is the current status of this? Should it compile and run in Java 8? or does it depend on the recently committed: https://bugs.openjdk.java.net/browse/JDK-8200468 Trying to understand out options with respect to getting SSO for this java client to work. Cole Ferrier -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradford.wetmore at oracle.com Tue Jun 12 00:14:01 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 11 Jun 2018 17:14:01 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <8f8f6d5c-86f3-3128-6d54-6b7d0e03fbc5@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <637c1aa7-a62f-ecae-7b7d-d261aae36573@oracle.com> <8f8f6d5c-86f3-3128-6d54-6b7d0e03fbc5@oracle.com> Message-ID: >> ProtocolVersion.java >> -------------------- >> Later down, you mention DTLS 1.3 quite a bit (e.g. PROTOCOLS_TO_13), >> is this going to cause any adverse reactions since there is no DTLS >> 1.3 implementation yet? >> > I removed DTLS 1.3 as we don't actually support it right now. Ok. Too late now, but I suppose you could have left it as a comment. static final ProtocolVersion[] PROTOCOLS_TO_13 = new ProtocolVersion[] { TLS13, TLS12, TLS11, TLS10, SSL30, /* DTLS13, */ DTLS12, DTLS10 }; >> 95:? Why does this comment say 1.3 if this is a _OF_30? >> >> 136-146:? These "T" names are a little non-intuitive. >> PROTOCOLS_TO_TLS11?? Should there be a similar for _TO_TLS13?? What >> about PROTCOLS_TO_DTLS*? >> > Updated. Thanks. >> 229:? I probably don't understand the callers of this code well >> enough. If DTLS, you return true if it's DLTS10/12/13 or later.? But >> false if less.? Why are you allowing DTLS 1.0 and all later (unknown) >> versions? Same question for the TLS arm.?? Why fail earlier than >> SSLv3, and allow above TLSv1.3?? Also suggest you move the 243 into >> the else arm. >> > I added a comment for this method.? It is used to check if the requested > version number is beyond the minimal supported numbers.? For example, if > client request ox0304, because of version negotiation, 0x0303 (TLS 1.2) > should be negotiated.? However, if the requested number is 0x0101, the > receiver should reject the connection as the version number is too small > to be supported. I see what you're doing, but I'm not understanding why we're not checking the other direction also? e.g. if (p < SSLv3 && not SSLv2) || (p > TLSv1.3 ) { Thanks, Brad >> 289:? You already checked this condition in 285-287 above.? And then >> 304 is no longer needed. >> > Good catch! > > Thanks, > Xuelei > >> Brad >> >> >> >> >> On 6/7/2018 10:28 AM, Bradford Wetmore wrote: >>> Also reviewed SSLSocketFactoryImpl.java >>> >>> >>> BaseSSLSocketImpl.java >>> ---------------------- >>> I don't see where requireCloseNotify is actually being used in the >>> remaining code.? If you are removing this functionality, you should >>> probably be calling that out in your CSR. >>> >>> SSLSessionContextImpl.java >>> -------------------------- >>> The only change here was to reorder the import of Vector (obsolete) >>> and update the copyright?? May I ask why?? If this was somehow a >>> netbeans suggestion, there were several other things that could be >>> updated that seem more important.? e.g.? 37-39 could be made final. >>> 207: unnecessary unboxing. >>> >>> Brad >>> >>> >>> >>> >>> On 6/6/2018 5:45 PM, Bradford Wetmore wrote: >>>> Today, I looked over SunJSSE.java, Utilities.java, and >>>> module-info.java. ??Mostly nits below, some style things. >>>> >>>> >>>> Utilities.java >>>> -------------- >>>> >>>> 39:? hexDigits can be private. >>>> >>>> 42:? Extra level of indent.? 4 or 8. >>>> >>>> 39-41:? Nits: When variables are static finals, they are usually >>>> written uppercase. >>>> >>>> 115:? Extra " " and can we get SNI cap'd? >>>> >>>> HostName for? server name indication >>>> -> >>>> HostName for Server Name Indication >>>> >>>> 150:? Minor Nit:? You're concating ("+") and then using >>>> StringBuilder.append(), instead of simply append chaining which >>>> might be slightly more efficient. >>>> >>>> 167-217:? The code looks ok, but this might be reworked to take >>>> better advantage of StringBuilder.append() chaining, rather than the >>>> mix of concat and append here now.? e.g. what you did with >>>> toHexString(long). I see much of the same code repeated over and >>>> over here.? Can be done later. >>>> >>>> Brad >>>> >>>> >>>> >>>> On 6/3/2018 9:43 PM, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> Here it the 2nd full webrev: >>>>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >>>>> >>>>> and the delta update to the 1st webrev: >>>>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >>>>> >>>>> Xuelei >>>>> >>>>> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>>>>> Hi, >>>>>> >>>>>> I'd like to invite you to review the TLS 1.3 implementation.? I >>>>>> appreciate it if I could have compatibility and specification >>>>>> feedback before May 31, 2018, and implementation feedback before >>>>>> June 7, 2018. >>>>>> >>>>>> Here is the webrev: >>>>>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>>>>> >>>>>> The formal TLS 1.3 specification is not finalized yet, although it >>>>>> had been approved to be a standard.? The implementation is based >>>>>> on the draft version 28: >>>>>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>>>>> >>>>>> For the overall description of this enhancement, please refer to >>>>>> JEP 332: >>>>>> ???? http://openjdk.java.net/jeps/332 >>>>>> >>>>>> For the compatibility and specification update, please refer to >>>>>> CSR 8202625: >>>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>>>>> >>>>>> Note that we are using the sandbox for the development right now. >>>>>> For more information, please refer to Bradford's previous email: >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>>>>> >>>>>> >>>>>> Thanks & Regards, >>>>>> Xuelei From bradford.wetmore at oracle.com Tue Jun 12 00:17:38 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 11 Jun 2018 17:17:38 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> Message-ID: <8ef219c4-2aec-ac2e-cfc4-708f303898f1@oracle.com> On 6/8/2018 7:45 PM, Xuelei Fan wrote: > > BaseSSLSocketImpl.java > > ---------------------- > Update: http://hg.openjdk.java.net/jdk/sandbox/rev/bad9f4c7eeec > > Update to handle EOFException and requireCloseNotify property. Couple new typo nits: 588/843/: // if no exceptio thrown -> // if no exception thrown Brad > Xuelei > > On 6/7/2018 10:28 AM, Bradford Wetmore wrote: >> Also reviewed SSLSocketFactoryImpl.java >> >> >> BaseSSLSocketImpl.java >> ---------------------- >> I don't see where requireCloseNotify is actually being used in the >> remaining code.? If you are removing this functionality, you should >> probably be calling that out in your CSR. >> >> SSLSessionContextImpl.java >> -------------------------- >> The only change here was to reorder the import of Vector (obsolete) >> and update the copyright?? May I ask why?? If this was somehow a >> netbeans suggestion, there were several other things that could be >> updated that seem more important.? e.g.? 37-39 could be made final. >> 207: unnecessary unboxing. >> >> Brad >> >> >> >> >> On 6/6/2018 5:45 PM, Bradford Wetmore wrote: >>> Today, I looked over SunJSSE.java, Utilities.java, and >>> module-info.java. ??Mostly nits below, some style things. >>> >>> >>> Utilities.java >>> -------------- >>> >>> 39:? hexDigits can be private. >>> >>> 42:? Extra level of indent.? 4 or 8. >>> >>> 39-41:? Nits: When variables are static finals, they are usually >>> written uppercase. >>> >>> 115:? Extra " " and can we get SNI cap'd? >>> >>> HostName for? server name indication >>> -> >>> HostName for Server Name Indication >>> >>> 150:? Minor Nit:? You're concating ("+") and then using >>> StringBuilder.append(), instead of simply append chaining which might >>> be slightly more efficient. >>> >>> 167-217:? The code looks ok, but this might be reworked to take >>> better advantage of StringBuilder.append() chaining, rather than the >>> mix of concat and append here now.? e.g. what you did with >>> toHexString(long). I see much of the same code repeated over and over >>> here.? Can be done later. >>> >>> Brad >>> >>> >>> >>> On 6/3/2018 9:43 PM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> Here it the 2nd full webrev: >>>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >>>> >>>> and the delta update to the 1st webrev: >>>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >>>> >>>> Xuelei >>>> >>>> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> I'd like to invite you to review the TLS 1.3 implementation.? I >>>>> appreciate it if I could have compatibility and specification >>>>> feedback before May 31, 2018, and implementation feedback before >>>>> June 7, 2018. >>>>> >>>>> Here is the webrev: >>>>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>>>> >>>>> The formal TLS 1.3 specification is not finalized yet, although it >>>>> had been approved to be a standard.? The implementation is based on >>>>> the draft version 28: >>>>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>>>> >>>>> For the overall description of this enhancement, please refer to >>>>> JEP 332: >>>>> ???? http://openjdk.java.net/jeps/332 >>>>> >>>>> For the compatibility and specification update, please refer to CSR >>>>> 8202625: >>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>>>> >>>>> Note that we are using the sandbox for the development right now. >>>>> For more information, please refer to Bradford's previous email: >>>>> >>>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>>>> >>>>> >>>>> Thanks & Regards, >>>>> Xuelei From xuelei.fan at oracle.com Tue Jun 12 00:23:59 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 11 Jun 2018 17:23:59 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> Message-ID: <4d88905a-92b0-ba00-991e-509f20276178@oracle.com> Update: http://hg.openjdk.java.net/jdk/sandbox/rev/0811eaea3cd4 On 6/11/2018 3:44 PM, Valerie Peng wrote: > Hi Xuelei, > > > > - If no child class intended, class may be made final. Updated. > - line 99-101 and 120-133: delete as the comments said so? It is used for interop testing right now. I will remove them before we ship the product. It it tracked with: https://bugs.openjdk.java.net/browse/JDK-8204636 > - I have some doubt on line 191 and 198, does "noSniExtension/Matcher" > means "no SNI Extension/Matcher"? If yes, it seems that the condition > should be > > ?? if (serverNames.isEmpty() || noSniExtension) { > The checking is a little bit confusing. If serverNames is an empty list, it may indicate one of two status: . the server names is configured to be empty, or . the server name is not configured The behaviors of the two status are different, so we introduced another flag, 'noSniExtension', which is used together with serverNames.isEmpty() to identify the status. It's confusing to me as well. Looks like we can make an improvement here. I will think more about it. > - Essentially getEnabledExtensions(SSLHandshake, ProtocolVersion) is > almost same as getEnabledExtensions(SSLHandshake, > List. It looks possible to refactor the impl to > minimize code duplication. But this is no big deal. > Good point. Updated. Thanks, Xuelei > Thanks, > Valerie > > > On 5/25/2018 4:45 PM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 implementation.? I >> appreciate it if I could have compatibility and specification feedback >> before May 31, 2018, and implementation feedback before June 7, 2018. >> >> Here is the webrev: >> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> The formal TLS 1.3 specification is not finalized yet, although it had >> been approved to be a standard.? The implementation is based on the >> draft version 28: >> ??? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >> >> For the overall description of this enhancement, please refer to JEP 332: >> ??? http://openjdk.java.net/jeps/332 >> >> For the compatibility and specification update, please refer to CSR >> 8202625: >> ??? https://bugs.openjdk.java.net/browse/JDK-8202625 >> >> Note that we are using the sandbox for the development right now. For >> more information, please refer to Bradford's previous email: >> >> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >> >> Thanks & Regards, >> Xuelei > From xuelei.fan at oracle.com Tue Jun 12 00:35:57 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 11 Jun 2018 17:35:57 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <637c1aa7-a62f-ecae-7b7d-d261aae36573@oracle.com> <8f8f6d5c-86f3-3128-6d54-6b7d0e03fbc5@oracle.com> Message-ID: On 6/11/2018 5:14 PM, Bradford Wetmore wrote: > >>> ProtocolVersion.java >>> -------------------- > >>> Later down, you mention DTLS 1.3 quite a bit (e.g. PROTOCOLS_TO_13), >>> is this going to cause any adverse reactions since there is no DTLS >>> 1.3 implementation yet? >>> >> I removed DTLS 1.3 as we don't actually support it right now. > > Ok.? Too late now, but I suppose you could have left it as a comment. > > ??? static final ProtocolVersion[] PROTOCOLS_TO_13 = > ??????? new ProtocolVersion[] { > ??????????? TLS13, TLS12, TLS11, TLS10, SSL30, > ??????????? /* DTLS13, */ DTLS12, DTLS10 > ??????? }; > Hm, much better. I'm moving too fast to use good comments sometimes. >>> 95:? Why does this comment say 1.3 if this is a _OF_30? >>> >>> 136-146:? These "T" names are a little non-intuitive. >>> PROTOCOLS_TO_TLS11?? Should there be a similar for _TO_TLS13?? What >>> about PROTCOLS_TO_DTLS*? >>> >> Updated. > > Thanks. > >>> 229:? I probably don't understand the callers of this code well >>> enough. If DTLS, you return true if it's DLTS10/12/13 or later.? But >>> false if less.? Why are you allowing DTLS 1.0 and all later (unknown) >>> versions? Same question for the TLS arm.?? Why fail earlier than >>> SSLv3, and allow above TLSv1.3?? Also suggest you move the 243 into >>> the else arm. >>> >> I added a comment for this method.? It is used to check if the >> requested version number is beyond the minimal supported numbers.? For >> example, if client request ox0304, because of version negotiation, >> 0x0303 (TLS 1.2) should be negotiated.? However, if the requested >> number is 0x0101, the receiver should reject the connection as the >> version number is too small to be supported. > > I see what you're doing, but I'm not understanding why we're not > checking the other direction also? > > e.g.? if (p < SSLv3 && not SSLv2) || (p > TLSv1.3 ) { > Per TLS 1.2 version negotiation specification, the higher number is not limited. For example, if client request for TLS 1.9, the server can response with TLS 1.2. If the version if 1.9, this method does not reject it here. However, it may be not necessary in practice. Thanks, Xuelei > Thanks, > > Brad > > >>> 289:? You already checked this condition in 285-287 above.? And then >>> 304 is no longer needed. >>> >> Good catch! >> >> Thanks, >> Xuelei >> >>> Brad >>> >>> >>> >>> >>> On 6/7/2018 10:28 AM, Bradford Wetmore wrote: >>>> Also reviewed SSLSocketFactoryImpl.java >>>> >>>> >>>> BaseSSLSocketImpl.java >>>> ---------------------- >>>> I don't see where requireCloseNotify is actually being used in the >>>> remaining code.? If you are removing this functionality, you should >>>> probably be calling that out in your CSR. >>>> >>>> SSLSessionContextImpl.java >>>> -------------------------- >>>> The only change here was to reorder the import of Vector (obsolete) >>>> and update the copyright?? May I ask why?? If this was somehow a >>>> netbeans suggestion, there were several other things that could be >>>> updated that seem more important.? e.g.? 37-39 could be made final. >>>> 207: unnecessary unboxing. >>>> >>>> Brad >>>> >>>> >>>> >>>> >>>> On 6/6/2018 5:45 PM, Bradford Wetmore wrote: >>>>> Today, I looked over SunJSSE.java, Utilities.java, and >>>>> module-info.java. ??Mostly nits below, some style things. >>>>> >>>>> >>>>> Utilities.java >>>>> -------------- >>>>> >>>>> 39:? hexDigits can be private. >>>>> >>>>> 42:? Extra level of indent.? 4 or 8. >>>>> >>>>> 39-41:? Nits: When variables are static finals, they are usually >>>>> written uppercase. >>>>> >>>>> 115:? Extra " " and can we get SNI cap'd? >>>>> >>>>> HostName for? server name indication >>>>> -> >>>>> HostName for Server Name Indication >>>>> >>>>> 150:? Minor Nit:? You're concating ("+") and then using >>>>> StringBuilder.append(), instead of simply append chaining which >>>>> might be slightly more efficient. >>>>> >>>>> 167-217:? The code looks ok, but this might be reworked to take >>>>> better advantage of StringBuilder.append() chaining, rather than >>>>> the mix of concat and append here now.? e.g. what you did with >>>>> toHexString(long). I see much of the same code repeated over and >>>>> over here.? Can be done later. >>>>> >>>>> Brad >>>>> >>>>> >>>>> >>>>> On 6/3/2018 9:43 PM, Xuelei Fan wrote: >>>>>> Hi, >>>>>> >>>>>> Here it the 2nd full webrev: >>>>>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >>>>>> >>>>>> and the delta update to the 1st webrev: >>>>>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >>>>>> >>>>>> Xuelei >>>>>> >>>>>> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I'd like to invite you to review the TLS 1.3 implementation.? I >>>>>>> appreciate it if I could have compatibility and specification >>>>>>> feedback before May 31, 2018, and implementation feedback before >>>>>>> June 7, 2018. >>>>>>> >>>>>>> Here is the webrev: >>>>>>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>>>>>> >>>>>>> The formal TLS 1.3 specification is not finalized yet, although >>>>>>> it had been approved to be a standard.? The implementation is >>>>>>> based on the draft version 28: >>>>>>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>>>>>> >>>>>>> For the overall description of this enhancement, please refer to >>>>>>> JEP 332: >>>>>>> ???? http://openjdk.java.net/jeps/332 >>>>>>> >>>>>>> For the compatibility and specification update, please refer to >>>>>>> CSR 8202625: >>>>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>>>>>> >>>>>>> Note that we are using the sandbox for the development right now. >>>>>>> For more information, please refer to Bradford's previous email: >>>>>>> >>>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>>>>>> >>>>>>> >>>>>>> Thanks & Regards, >>>>>>> Xuelei From xuelei.fan at oracle.com Tue Jun 12 00:38:29 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 11 Jun 2018 17:38:29 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <8ef219c4-2aec-ac2e-cfc4-708f303898f1@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <8ef219c4-2aec-ac2e-cfc4-708f303898f1@oracle.com> Message-ID: <58890c95-9886-208a-0b11-cd9f1adbccb5@oracle.com> On 6/11/2018 5:17 PM, Bradford Wetmore wrote: > > > On 6/8/2018 7:45 PM, Xuelei Fan wrote: >> ?> BaseSSLSocketImpl.java >> ?> ---------------------- >> Update: http://hg.openjdk.java.net/jdk/sandbox/rev/bad9f4c7eeec >> >> Update to handle EOFException and requireCloseNotify property. > > Couple new typo nits: > > 588/843/: > // if no exceptio thrown > -> > // if no exception thrown > Ooops! Updated in my local workspace. I will integrate it with my next changeset. Thanks, Xuelei > Brad > > >> Xuelei >> >> On 6/7/2018 10:28 AM, Bradford Wetmore wrote: >>> Also reviewed SSLSocketFactoryImpl.java >>> >>> >>> BaseSSLSocketImpl.java >>> ---------------------- >>> I don't see where requireCloseNotify is actually being used in the >>> remaining code.? If you are removing this functionality, you should >>> probably be calling that out in your CSR. >>> >>> SSLSessionContextImpl.java >>> -------------------------- >>> The only change here was to reorder the import of Vector (obsolete) >>> and update the copyright?? May I ask why?? If this was somehow a >>> netbeans suggestion, there were several other things that could be >>> updated that seem more important.? e.g.? 37-39 could be made final. >>> 207: unnecessary unboxing. >>> >>> Brad >>> >>> >>> >>> >>> On 6/6/2018 5:45 PM, Bradford Wetmore wrote: >>>> Today, I looked over SunJSSE.java, Utilities.java, and >>>> module-info.java. ??Mostly nits below, some style things. >>>> >>>> >>>> Utilities.java >>>> -------------- >>>> >>>> 39:? hexDigits can be private. >>>> >>>> 42:? Extra level of indent.? 4 or 8. >>>> >>>> 39-41:? Nits: When variables are static finals, they are usually >>>> written uppercase. >>>> >>>> 115:? Extra " " and can we get SNI cap'd? >>>> >>>> HostName for? server name indication >>>> -> >>>> HostName for Server Name Indication >>>> >>>> 150:? Minor Nit:? You're concating ("+") and then using >>>> StringBuilder.append(), instead of simply append chaining which >>>> might be slightly more efficient. >>>> >>>> 167-217:? The code looks ok, but this might be reworked to take >>>> better advantage of StringBuilder.append() chaining, rather than the >>>> mix of concat and append here now.? e.g. what you did with >>>> toHexString(long). I see much of the same code repeated over and >>>> over here.? Can be done later. >>>> >>>> Brad >>>> >>>> >>>> >>>> On 6/3/2018 9:43 PM, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> Here it the 2nd full webrev: >>>>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >>>>> >>>>> and the delta update to the 1st webrev: >>>>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >>>>> >>>>> Xuelei >>>>> >>>>> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>>>>> Hi, >>>>>> >>>>>> I'd like to invite you to review the TLS 1.3 implementation.? I >>>>>> appreciate it if I could have compatibility and specification >>>>>> feedback before May 31, 2018, and implementation feedback before >>>>>> June 7, 2018. >>>>>> >>>>>> Here is the webrev: >>>>>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>>>>> >>>>>> The formal TLS 1.3 specification is not finalized yet, although it >>>>>> had been approved to be a standard.? The implementation is based >>>>>> on the draft version 28: >>>>>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>>>>> >>>>>> For the overall description of this enhancement, please refer to >>>>>> JEP 332: >>>>>> ???? http://openjdk.java.net/jeps/332 >>>>>> >>>>>> For the compatibility and specification update, please refer to >>>>>> CSR 8202625: >>>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>>>>> >>>>>> Note that we are using the sandbox for the development right now. >>>>>> For more information, please refer to Bradford's previous email: >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>>>>> >>>>>> >>>>>> Thanks & Regards, >>>>>> Xuelei From bradford.wetmore at oracle.com Tue Jun 12 00:56:47 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 11 Jun 2018 17:56:47 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <17e518b7-7167-174a-c764-fac9d8955f8e@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> <1a02a29e-b3e2-b82b-9d7b-ee20765b785f@oracle.com> <639e5b65-bad8-f69c-291a-1fc2c9cfcb63@oracle.com> <17e518b7-7167-174a-c764-fac9d8955f8e@oracle.com> Message-ID: <0b5409f4-a562-62c0-aaf0-eee76616b86e@oracle.com> >>> CipherSuite.java >>> ---------------- >>> 74:? There is a mix of ciphersuite initialization styles, which I >>> find confusing. >>> >> These two suites may not be the best comparison, since you have a >> non-AEAD stream cipher up against AES-GCM.? For the latter, I think >> M_MULL in the MacAlg field is the right thing because GCM doesn't have >> a separate HMAC.? The authentication is performed through GHASH.? The >> only place for SHA-256 in this suite is for the PRF, IIUC.? As a >> second data point ChaCha20-Poly1305 suites (when we eventually do >> them) would also use M_NULL for the MacAlg since Poly1305 takes care >> of the authentication internally and SHA-256 is just used with PRF >> and/or HKDF in the TLS 1.3 case. >> > I agreed with Jamil. Makes perfect sense now, thanks. >>> 262:? What is the point of the aliases argument in the constructor? >>> Was the idea to provide a mapping between suites we originally >>> created with the SSL_ prefix vs the more current TLS_ prefix we used >>> in the later TLS protocols?? There is only an empty string in every >>> constructor, so this code doesn't do anything. >>> > Added the aliases. Great, thanks. Once minor formatting comment which would help comparability/readability. Take or leave it. SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA( 0x0016, true, "SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA", "TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA", ProtocolVersion.PROTOCOLS_TO_12, K_DHE_RSA, B_3DES, M_SHA, H_SHA256), -> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA( 0x0016, true, "SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA", "TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA", ProtocolVersion.PROTOCOLS_TO_12, K_DHE_RSA, B_3DES, M_SHA, H_SHA256), >>> 803/814/824/867:? I'm concerned of the performance impact of >>> repeatedly iterating over 300+ ciphersuite ids/names using values(). >>> You should benchmark and see if it makes sense to switch to using a >>> HashMap (or even TreeMap) here.? For the limited number of Protocols >>> (< 10 for TLSv1.x), this approach is fine, but this has quite a bit >>> larger search space. >>> > Good point!? This enhancement now is tracked with > ??? https://bugs.openjdk.java.net/browse/JDK-8204636 Good, thanks. >>> 840:? Is this else/break needed? >>> > Yes.? It is mostly for performance by ignoring unsupported cipher suites > look up. Ah, because they are coming out of .values() ordered, and the unsupported are at the end. Can you change the comment: the following cipher suites are not supported. -> values() is ordered, remaining cipher suites are not supported. >>> SSLServerSocketImpl.java >>> ------------------------ >>> 160:? You should allow multiple changes between server to client, and >>> switch enabled protocols/ciphersuites accordingly. >>> > Yes, multiple changes are allowed. I didn't see a change here. If you go from server (default) to client, and then back again, shouldn't you reset to the original server values? And set sslConfig.useClientMode() e.g. sslServerSocket.setUseClientMode(true); sslServerSocket.setUseClientMode(false); The current code won't change back to server. >>> >>> SSLConfiguration.java >>> --------------------- 40: There is a new unused import here. >>> SSLSocketImpl.java >>> ------------------ >>> 28:? I'm not a fan of unnecessarily expanding the imports. Netbeans >>> has/had a default of 5, but apparently turned it off by default in >>> favor of single class imports. >>> > I'm a fan of expanding the imports now.? It is more clear about the > imported classes and the packet of a particular class. > > For example, we can use: > import java.net.*; > import java.io.*; > > Or > import java.net.Socket; > import java.io.StringReader; > > If using the "*" option, we don't actually know if Socket is in packet > java.net or java.io.? So if IDE has made the update, I'm not included to > update them back any more. Just seems like a lot of extra necessary cruft when you have lots of specifics (e.g. >5 like in SSLEngineImpl.java), but that's just my personal preference. And IDEs can be set to do all kinds of formatting. :) >>> 76:? Are you set on the name conContext?? I'm still not 100% sure >>> what it stands for.? Alternate transportContext or connectionContext? >>> > The name is implying connection context, but it is an instance of > TransportContext.? Do you like, traContext, for transport context?? I'd > like to use a short name as it is used a lot that it is easy to exceed > the 80 character per line limit. Nothing really jump at me. Brad >>> 92:? trustNameService could be private and all in caps. >>> > Updated. > >>> 102-269:? Any chance of combining the commonalities of these >>> different constructors into 1, and then do the constructor-specific >>> things at the end?? It will help with future maintenance to not have >>> to make the same changes in multiple places. >>> > It is not clear to me now.? The issue is tracked with: > ??? https://bugs.openjdk.java.net/browse/JDK-8204636 > >>> 484:? A couple comments here would be appreciated about what these >>> App* classes do.? The old comments in App[InputStream would be >>> sufficient, plus some of the other comments stripped out inside the >>> class: >>> >>> ???? Read data if needed ... notice that the connection guarantees >>> ???? that handshake, alert, and change cipher spec data streams are >>> ???? handled as they arrive, so we never see them here. >>> > Updated. > >>> Nice job on this refactoring in this class, there was a heck of a lot >>> of cruft in this file after 20+ years.? I am anxious to see how the >>> rest of the code is laid out. >>> >>> >>> TransportContext.java >>> --------------------- >>> 90:? Any chance of combining these 3 constructors into 1?? Almost >>> identical duplicate code here. >>> > This issue had been addressed in one of Tony's changesets: > ?? http://hg.openjdk.java.net/jdk/sandbox/rev/b152d06ed6a9 > >>> 682-683:? These can be final. >>> > Updated. > > Thanks, > Xuelei > >>> >>> Thanks, >>> >>> Brad >>> >>> >>> >>> On 6/8/2018 10:21 AM, Xuelei Fan wrote: >>>> Here is the 3rd full webrev: >>>> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.02 >>>> >>>> and the delta update to the 1st webrev: >>>> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.01 >>>> >>>> Xuelei >>>> >>>> On 6/3/2018 9:43 PM, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> Here it the 2nd full webrev: >>>>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >>>>> >>>>> and the delta update to the 1st webrev: >>>>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >>>>> >>>>> Xuelei >>>>> >>>>> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>>>>> Hi, >>>>>> >>>>>> I'd like to invite you to review the TLS 1.3 implementation.? I >>>>>> appreciate it if I could have compatibility and specification >>>>>> feedback before May 31, 2018, and implementation feedback before >>>>>> June 7, 2018. >>>>>> >>>>>> Here is the webrev: >>>>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>>>>> >>>>>> The formal TLS 1.3 specification is not finalized yet, although it >>>>>> had been approved to be a standard.? The implementation is based >>>>>> on the draft version 28: >>>>>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>>>>> >>>>>> For the overall description of this enhancement, please refer to >>>>>> JEP 332: >>>>>> ???? http://openjdk.java.net/jeps/332 >>>>>> >>>>>> For the compatibility and specification update, please refer to >>>>>> CSR 8202625: >>>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>>>>> >>>>>> Note that we are using the sandbox for the development right now. >>>>>> For more information, please refer to Bradford's previous email: >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>>>>> >>>>>> >>>>>> Thanks & Regards, >>>>>> Xuelei >> From xuelei.fan at oracle.com Tue Jun 12 01:36:12 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 11 Jun 2018 18:36:12 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <0b5409f4-a562-62c0-aaf0-eee76616b86e@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> <1a02a29e-b3e2-b82b-9d7b-ee20765b785f@oracle.com> <639e5b65-bad8-f69c-291a-1fc2c9cfcb63@oracle.com> <17e518b7-7167-174a-c764-fac9d8955f8e@oracle.com> <0b5409f4-a562-62c0-aaf0-eee76616b86e@oracle.com> Message-ID: <0fc1f9f2-7718-1cbb-59b2-82b800e473ee@oracle.com> On 6/11/2018 5:56 PM, Bradford Wetmore wrote: <...skipped...> >>>> 262:? What is the point of the aliases argument in the constructor? >>>> Was the idea to provide a mapping between suites we originally >>>> created with the SSL_ prefix vs the more current TLS_ prefix we used >>>> in the later TLS protocols?? There is only an empty string in every >>>> constructor, so this code doesn't do anything. >>>> >> Added the aliases. > > Great, thanks.? Once minor formatting comment which would help > comparability/readability.? Take or leave it. > > ??? SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA( > ??????????? 0x0016, true, "SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA", > ??????????? "TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA", > ??????????? ProtocolVersion.PROTOCOLS_TO_12, > ??????????? K_DHE_RSA, B_3DES, M_SHA, H_SHA256), > -> > ??? SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA( > ??????????? 0x0016, true, "SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA", > ????????????????????????? "TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA", > ??????????? ProtocolVersion.PROTOCOLS_TO_12, > ??????????? K_DHE_RSA, B_3DES, M_SHA, H_SHA256), > It looks really nice, and I will take it. Updated in my local workspace, will push later in my next changeset. <...skipped...> >>>> 840:? Is this else/break needed? >>>> >> Yes.? It is mostly for performance by ignoring unsupported cipher >> suites look up. > > Ah, because they are coming out of .values() ordered, and the > unsupported are at the end.? Can you change the comment: > > the following cipher suites are not supported. > -> > values() is ordered, remaining cipher suites are not supported. > Updated. > >>>> SSLServerSocketImpl.java >>>> ------------------------ >>>> 160:? You should allow multiple changes between server to client, >>>> and switch enabled protocols/ciphersuites accordingly. >>>> >> Yes, multiple changes are allowed. > > I didn't see a change here.? If you go from server (default) to client, > and then back again, shouldn't you reset to the original server values? > And set sslConfig.useClientMode() > > e.g. > ??? sslServerSocket.setUseClientMode(true); > ??? sslServerSocket.setUseClientMode(false); > > The current code won't change back to server. > I may miss something. I think, it is able to change back. sslServerSocket.setUseClientMode(true) -> if it is server mode, set to use client mode; and if using default protocols, set to use client default protocols; if using default cipher suites, set to use client default cipher suites. sslConfig is set to use client mode. sslServerSocket.setUseClientMode(false); if it is client mode, set to use server mode; and id using default protocols, set to use server default protocols; if using default cipher suites, set to use server default cipher suites. sslConfig is set to use server mode. Thanks, Xuelei From weijun.wang at oracle.com Tue Jun 12 01:43:26 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 12 Jun 2018 09:43:26 +0800 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <0fc1f9f2-7718-1cbb-59b2-82b800e473ee@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> <1a02a29e-b3e2-b82b-9d7b-ee20765b785f@oracle.com> <639e5b65-bad8-f69c-291a-1fc2c9cfcb63@oracle.com> <17e518b7-7167-174a-c764-fac9d8955f8e@oracle.com> <0b5409f4-a562-62c0-aaf0-eee76616b86e@oracle.com> <0fc1f9f2-7718-1cbb-59b2-82b800e473ee@oracle.com> Message-ID: <5B69B917-C011-4661-AE03-653CF5B2E123@oracle.com> I was also thinking about the name. Why don't we always make the enum field identical to the name (including the unsupported ones)? Then we don't need a name property and valueOf() automagically works. --Max > On Jun 12, 2018, at 9:36 AM, Xuelei Fan wrote: > > > > On 6/11/2018 5:56 PM, Bradford Wetmore wrote: > <...skipped...> >>>>> 262: What is the point of the aliases argument in the constructor? Was the idea to provide a mapping between suites we originally created with the SSL_ prefix vs the more current TLS_ prefix we used in the later TLS protocols? There is only an empty string in every constructor, so this code doesn't do anything. >>>>> >>> Added the aliases. >> Great, thanks. Once minor formatting comment which would help comparability/readability. Take or leave it. >> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA( >> 0x0016, true, "SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA", >> "TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA", >> ProtocolVersion.PROTOCOLS_TO_12, >> K_DHE_RSA, B_3DES, M_SHA, H_SHA256), >> -> >> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA( >> 0x0016, true, "SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA", >> "TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA", >> ProtocolVersion.PROTOCOLS_TO_12, >> K_DHE_RSA, B_3DES, M_SHA, H_SHA256), > It looks really nice, and I will take it. Updated in my local workspace, will push later in my next changeset. From xuelei.fan at oracle.com Tue Jun 12 02:58:11 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 11 Jun 2018 19:58:11 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <5B69B917-C011-4661-AE03-653CF5B2E123@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> <1a02a29e-b3e2-b82b-9d7b-ee20765b785f@oracle.com> <639e5b65-bad8-f69c-291a-1fc2c9cfcb63@oracle.com> <17e518b7-7167-174a-c764-fac9d8955f8e@oracle.com> <0b5409f4-a562-62c0-aaf0-eee76616b86e@oracle.com> <0fc1f9f2-7718-1cbb-59b2-82b800e473ee@oracle.com> <5B69B917-C011-4661-AE03-653CF5B2E123@oracle.com> Message-ID: On 6/11/2018 6:43 PM, Weijun Wang wrote: > I was also thinking about the name. Why don't we always make the enum field identical to the name (including the unsupported ones)? Then we don't need a name property and valueOf() automagically works. > Hm, looks like we can do this way as the names are always caps. I will think about it more later. Thanks, Xuelei > --Max > >> On Jun 12, 2018, at 9:36 AM, Xuelei Fan wrote: >> >> >> >> On 6/11/2018 5:56 PM, Bradford Wetmore wrote: >> <...skipped...> >>>>>> 262: What is the point of the aliases argument in the constructor? Was the idea to provide a mapping between suites we originally created with the SSL_ prefix vs the more current TLS_ prefix we used in the later TLS protocols? There is only an empty string in every constructor, so this code doesn't do anything. >>>>>> >>>> Added the aliases. >>> Great, thanks. Once minor formatting comment which would help comparability/readability. Take or leave it. >>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA( >>> 0x0016, true, "SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA", >>> "TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA", >>> ProtocolVersion.PROTOCOLS_TO_12, >>> K_DHE_RSA, B_3DES, M_SHA, H_SHA256), >>> -> >>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA( >>> 0x0016, true, "SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA", >>> "TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA", >>> ProtocolVersion.PROTOCOLS_TO_12, >>> K_DHE_RSA, B_3DES, M_SHA, H_SHA256), >> It looks really nice, and I will take it. Updated in my local workspace, will push later in my next changeset. > From xuelei.fan at oracle.com Tue Jun 12 03:47:03 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 11 Jun 2018 20:47:03 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <0fc1f9f2-7718-1cbb-59b2-82b800e473ee@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> <1a02a29e-b3e2-b82b-9d7b-ee20765b785f@oracle.com> <639e5b65-bad8-f69c-291a-1fc2c9cfcb63@oracle.com> <17e518b7-7167-174a-c764-fac9d8955f8e@oracle.com> <0b5409f4-a562-62c0-aaf0-eee76616b86e@oracle.com> <0fc1f9f2-7718-1cbb-59b2-82b800e473ee@oracle.com> Message-ID: <3db2448f-9a32-66b1-c3c3-26539965c23d@oracle.com> Update: http://hg.openjdk.java.net/jdk/sandbox/rev/ae0cd8b2e2c2 Xuelei On 6/11/2018 6:36 PM, Xuelei Fan wrote: > > > On 6/11/2018 5:56 PM, Bradford Wetmore wrote: > <...skipped...> >>>>> 262:? What is the point of the aliases argument in the constructor? >>>>> Was the idea to provide a mapping between suites we originally >>>>> created with the SSL_ prefix vs the more current TLS_ prefix we >>>>> used in the later TLS protocols?? There is only an empty string in >>>>> every constructor, so this code doesn't do anything. >>>>> >>> Added the aliases. >> >> Great, thanks.? Once minor formatting comment which would help >> comparability/readability.? Take or leave it. >> >> ???? SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA( >> ???????????? 0x0016, true, "SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA", >> ???????????? "TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA", >> ???????????? ProtocolVersion.PROTOCOLS_TO_12, >> ???????????? K_DHE_RSA, B_3DES, M_SHA, H_SHA256), >> -> >> ???? SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA( >> ???????????? 0x0016, true, "SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA", >> ?????????????????????????? "TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA", >> ???????????? ProtocolVersion.PROTOCOLS_TO_12, >> ???????????? K_DHE_RSA, B_3DES, M_SHA, H_SHA256), >> > It looks really nice, and I will take it.? Updated in my local > workspace, will push later in my next changeset. > > <...skipped...> >>>>> 840:? Is this else/break needed? >>>>> >>> Yes.? It is mostly for performance by ignoring unsupported cipher >>> suites look up. >> >> Ah, because they are coming out of .values() ordered, and the >> unsupported are at the end.? Can you change the comment: >> >> the following cipher suites are not supported. >> -> >> values() is ordered, remaining cipher suites are not supported. >> > Updated. > >> >>>>> SSLServerSocketImpl.java >>>>> ------------------------ >>>>> 160:? You should allow multiple changes between server to client, >>>>> and switch enabled protocols/ciphersuites accordingly. >>>>> >>> Yes, multiple changes are allowed. >> >> I didn't see a change here.? If you go from server (default) to >> client, and then back again, shouldn't you reset to the original >> server values? And set sslConfig.useClientMode() >> >> e.g. >> ???? sslServerSocket.setUseClientMode(true); >> ???? sslServerSocket.setUseClientMode(false); >> >> The current code won't change back to server. >> > I may miss something.? I think, it is able to change back. > > sslServerSocket.setUseClientMode(true) -> > ? if it is server mode, set to use client mode; and if using default > protocols, set to use client default protocols; if using default cipher > suites, set to use client default cipher suites.? sslConfig is set to > use client mode. > > sslServerSocket.setUseClientMode(false); > ? if it is client mode, set to use server mode; and id using default > protocols, set to use server default protocols; if using default cipher > suites, set to use server default cipher suites.? sslConfig is set to > use server mode. > > Thanks, > Xuelei From weijun.wang at oracle.com Tue Jun 12 06:14:16 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 12 Jun 2018 14:14:16 +0800 Subject: JDK-6722928 Support SSPI as a native JGSS-API provider - Current Status In-Reply-To: References: Message-ID: > On Jun 12, 2018, at 6:14 AM, Cole Ferrier wrote: > > Thanks for your time reading this. (Sorry for the dupe post if it comes through, joined the list and resent) > > I am trying to setup a java client that runs in windows and needs to present a ticket to get access to a service. > > No delegation is required. > > We are running Java 8/Windows 10 and running into needing to change both the registry setting to enable access to the SessionKey and some group policies around UAC. > This is not ideal from a security perspective. > > I was hoping that the Java community was making progress on this front especially since it sounds like from some other articles, Credential Guard further locks this down. > > I found: > > https://www.mail-archive.com/security-dev at openjdk.java.net/msg05291.html > https://www.mail-archive.com/security-dev at openjdk.java.net/msg15532.html > > and: > > http://cr.openjdk.java.net/~weijun/6722928/ This is a prototype. It's not complete and not product-quality ready. > > What is the current status of this? Should it compile and run in Java 8? or does it depend on the recently committed: > > https://bugs.openjdk.java.net/browse/JDK-8200468 Yes. That said, there is no reason why JDK-8200468 cannot be backpored to JDK 8. --Weijun > > Cole Ferrier > From sean.mullan at oracle.com Tue Jun 12 18:13:57 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 12 Jun 2018 14:13:57 -0400 Subject: RFR: 8196141: Add GoDaddy root certificates In-Reply-To: <9ed4fc73-c133-7c00-fbbe-8b5af5dec965@oracle.com> References: <9ed4fc73-c133-7c00-fbbe-8b5af5dec965@oracle.com> Message-ID: <4122875c-4763-506b-98e9-03e3fcd9dab5@oracle.com> Looks good to me. --Sean On 5/31/18 11:40 PM, Rajan Halade wrote: > Please review this fix to add GoDaddy root certificates to cacerts. > > Webrev: http://cr.openjdk.java.net/~rhalade/8196141/webrev.00/ > > Thanks, > Rajan From valerie.peng at oracle.com Tue Jun 12 19:07:21 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 12 Jun 2018 12:07:21 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <4d88905a-92b0-ba00-991e-509f20276178@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <4d88905a-92b0-ba00-991e-509f20276178@oracle.com> Message-ID: <27ea184f-9610-4030-ffcc-e555910c76a5@oracle.com> I see. Maybe document what you explained for these flags would help. Update looks good. Thanks, Valerie On 6/11/2018 5:23 PM, Xuelei Fan wrote: > Update: http://hg.openjdk.java.net/jdk/sandbox/rev/0811eaea3cd4 > > On 6/11/2018 3:44 PM, Valerie Peng wrote: >> Hi Xuelei, >> >> >> >> - If no child class intended, class may be made final. > Updated. > >> - line 99-101 and 120-133: delete as the comments said so? > It is used for interop testing right now.? I will remove them before > we ship the product.? It it tracked with: > ?? https://bugs.openjdk.java.net/browse/JDK-8204636 > >> - I have some doubt on line 191 and 198, does >> "noSniExtension/Matcher" means "no SNI Extension/Matcher"? If yes, it >> seems that the condition should be >> >> ??? if (serverNames.isEmpty() || noSniExtension) { >> > The checking is a little bit confusing.? If serverNames is an empty > list, it may indicate one of two status: > . the server names is configured to be empty, or > . the server name is not configured > > The behaviors of the two status are different, so we introduced > another flag, 'noSniExtension', which is used together with > serverNames.isEmpty() to identify the status. > > It's confusing to me as well.? Looks like we can make an improvement > here.? I will think more about it. > >> - Essentially getEnabledExtensions(SSLHandshake, ProtocolVersion) is >> almost same as getEnabledExtensions(SSLHandshake, >> List. It looks possible to refactor the impl to >> minimize code duplication. But this is no big deal. >> > Good point.? Updated. > > Thanks, > Xuelei > >> Thanks, >> Valerie >> >> >> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>> Hi, >>> >>> I'd like to invite you to review the TLS 1.3 implementation. I >>> appreciate it if I could have compatibility and specification >>> feedback before May 31, 2018, and implementation feedback before >>> June 7, 2018. >>> >>> Here is the webrev: >>> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>> >>> The formal TLS 1.3 specification is not finalized yet, although it >>> had been approved to be a standard.? The implementation is based on >>> the draft version 28: >>> ??? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>> >>> For the overall description of this enhancement, please refer to JEP >>> 332: >>> ??? http://openjdk.java.net/jeps/332 >>> >>> For the compatibility and specification update, please refer to CSR >>> 8202625: >>> ??? https://bugs.openjdk.java.net/browse/JDK-8202625 >>> >>> Note that we are using the sandbox for the development right now. >>> For more information, please refer to Bradford's previous email: >>> >>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>> >>> >>> Thanks & Regards, >>> Xuelei >> From bradford.wetmore at oracle.com Tue Jun 12 21:55:17 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 12 Jun 2018 14:55:17 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <637c1aa7-a62f-ecae-7b7d-d261aae36573@oracle.com> <8f8f6d5c-86f3-3128-6d54-6b7d0e03fbc5@oracle.com> Message-ID: <326984a0-1f15-4b2d-4f55-c84434b9f362@oracle.com> >> I see what you're doing, but I'm not understanding why we're not >> checking the other direction also? >> >> e.g.? if (p < SSLv3 && not SSLv2) || (p > TLSv1.3 ) { >> > Per TLS 1.2 version negotiation specification, the higher number is not > limited.? For example, if client request for TLS 1.9, the server can > response with TLS 1.2.?? If the version if 1.9, this method does not > reject it here.? However, it may be not necessary in practice. Ah, Appendix E.1 of RFC 5246. If a TLS server receives a ClientHello containing a version number greater than the highest version supported by the server, it MUST reply according to the highest version supported by the server. Thanks. Brad > Thanks, > Xuelei > >> Thanks, >> >> Brad >> >> >>>> 289:? You already checked this condition in 285-287 above.? And then >>>> 304 is no longer needed. >>>> >>> Good catch! >>> >>> Thanks, >>> Xuelei >>> >>>> Brad >>>> >>>> >>>> >>>> >>>> On 6/7/2018 10:28 AM, Bradford Wetmore wrote: >>>>> Also reviewed SSLSocketFactoryImpl.java >>>>> >>>>> >>>>> BaseSSLSocketImpl.java >>>>> ---------------------- >>>>> I don't see where requireCloseNotify is actually being used in the >>>>> remaining code.? If you are removing this functionality, you should >>>>> probably be calling that out in your CSR. >>>>> >>>>> SSLSessionContextImpl.java >>>>> -------------------------- >>>>> The only change here was to reorder the import of Vector (obsolete) >>>>> and update the copyright?? May I ask why?? If this was somehow a >>>>> netbeans suggestion, there were several other things that could be >>>>> updated that seem more important.? e.g.? 37-39 could be made final. >>>>> 207: unnecessary unboxing. >>>>> >>>>> Brad >>>>> >>>>> >>>>> >>>>> >>>>> On 6/6/2018 5:45 PM, Bradford Wetmore wrote: >>>>>> Today, I looked over SunJSSE.java, Utilities.java, and >>>>>> module-info.java. ??Mostly nits below, some style things. >>>>>> >>>>>> >>>>>> Utilities.java >>>>>> -------------- >>>>>> >>>>>> 39:? hexDigits can be private. >>>>>> >>>>>> 42:? Extra level of indent.? 4 or 8. >>>>>> >>>>>> 39-41:? Nits: When variables are static finals, they are usually >>>>>> written uppercase. >>>>>> >>>>>> 115:? Extra " " and can we get SNI cap'd? >>>>>> >>>>>> HostName for? server name indication >>>>>> -> >>>>>> HostName for Server Name Indication >>>>>> >>>>>> 150:? Minor Nit:? You're concating ("+") and then using >>>>>> StringBuilder.append(), instead of simply append chaining which >>>>>> might be slightly more efficient. >>>>>> >>>>>> 167-217:? The code looks ok, but this might be reworked to take >>>>>> better advantage of StringBuilder.append() chaining, rather than >>>>>> the mix of concat and append here now.? e.g. what you did with >>>>>> toHexString(long). I see much of the same code repeated over and >>>>>> over here.? Can be done later. >>>>>> >>>>>> Brad >>>>>> >>>>>> >>>>>> >>>>>> On 6/3/2018 9:43 PM, Xuelei Fan wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Here it the 2nd full webrev: >>>>>>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >>>>>>> >>>>>>> and the delta update to the 1st webrev: >>>>>>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >>>>>>> >>>>>>> Xuelei >>>>>>> >>>>>>> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'd like to invite you to review the TLS 1.3 implementation.? I >>>>>>>> appreciate it if I could have compatibility and specification >>>>>>>> feedback before May 31, 2018, and implementation feedback before >>>>>>>> June 7, 2018. >>>>>>>> >>>>>>>> Here is the webrev: >>>>>>>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>>>>>>> >>>>>>>> The formal TLS 1.3 specification is not finalized yet, although >>>>>>>> it had been approved to be a standard.? The implementation is >>>>>>>> based on the draft version 28: >>>>>>>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>>>>>>> >>>>>>>> For the overall description of this enhancement, please refer to >>>>>>>> JEP 332: >>>>>>>> ???? http://openjdk.java.net/jeps/332 >>>>>>>> >>>>>>>> For the compatibility and specification update, please refer to >>>>>>>> CSR 8202625: >>>>>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>>>>>>> >>>>>>>> Note that we are using the sandbox for the development right >>>>>>>> now. For more information, please refer to Bradford's previous >>>>>>>> email: >>>>>>>> >>>>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>>>>>>> >>>>>>>> >>>>>>>> Thanks & Regards, >>>>>>>> Xuelei From bradford.wetmore at oracle.com Tue Jun 12 22:29:17 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 12 Jun 2018 15:29:17 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <0fc1f9f2-7718-1cbb-59b2-82b800e473ee@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> <1a02a29e-b3e2-b82b-9d7b-ee20765b785f@oracle.com> <639e5b65-bad8-f69c-291a-1fc2c9cfcb63@oracle.com> <17e518b7-7167-174a-c764-fac9d8955f8e@oracle.com> <0b5409f4-a562-62c0-aaf0-eee76616b86e@oracle.com> <0fc1f9f2-7718-1cbb-59b2-82b800e473ee@oracle.com> Message-ID: <749ca8b0-9287-6ed1-82e2-5fcc1bd23d47@oracle.com> On 6/11/2018 6:36 PM, Xuelei Fan wrote: >>>>> SSLServerSocketImpl.java >>>>> ------------------------ >>>>> 160:? You should allow multiple changes between server to client, >>>>> and switch enabled protocols/ciphersuites accordingly. >>>>> >>> Yes, multiple changes are allowed. >> >> I didn't see a change here.? If you go from server (default) to >> client, and then back again, shouldn't you reset to the original >> server values? And set sslConfig.useClientMode() >> >> e.g. >> ???? sslServerSocket.setUseClientMode(true); >> ???? sslServerSocket.setUseClientMode(false); >> >> The current code won't change back to server. >> > I may miss something.? I think, it is able to change back. > > sslServerSocket.setUseClientMode(true) -> > ? if it is server mode, set to use client mode; and if using default > protocols, set to use client default protocols; if using default cipher > suites, set to use client default cipher suites.? sslConfig is set to > use client mode. > > sslServerSocket.setUseClientMode(false); > ? if it is client mode, set to use server mode; and id using default > protocols, set to use server default protocols; if using default cipher > suites, set to use server default cipher suites.? sslConfig is set to > use server mode. You're right, I misread the code. Thanks for bearing with me. Can we move this sslConfig code (157-167) to a method in SSLConfiguration instead? The logic here in SSLServerSocketImpl uses sslContext.* 8 times (e.g. sslContext.getDefaultProtocolVersions(!useClientMode)). This code is very implementation-dependent on SSLConfiguration's internals, and thus a good encapsulation candidate. Brad From xuelei.fan at oracle.com Tue Jun 12 23:40:33 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 12 Jun 2018 16:40:33 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <749ca8b0-9287-6ed1-82e2-5fcc1bd23d47@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> <1a02a29e-b3e2-b82b-9d7b-ee20765b785f@oracle.com> <639e5b65-bad8-f69c-291a-1fc2c9cfcb63@oracle.com> <17e518b7-7167-174a-c764-fac9d8955f8e@oracle.com> <0b5409f4-a562-62c0-aaf0-eee76616b86e@oracle.com> <0fc1f9f2-7718-1cbb-59b2-82b800e473ee@oracle.com> <749ca8b0-9287-6ed1-82e2-5fcc1bd23d47@oracle.com> Message-ID: <2b868343-7485-4628-af2f-91e17fcb7bd0@oracle.com> On 6/12/2018 3:29 PM, Bradford Wetmore wrote: > > > On 6/11/2018 6:36 PM, Xuelei Fan wrote: >>>>>> SSLServerSocketImpl.java >>>>>> ------------------------ >>>>>> 160:? You should allow multiple changes between server to client, >>>>>> and switch enabled protocols/ciphersuites accordingly. >>>>>> >>>> Yes, multiple changes are allowed. >>> >>> I didn't see a change here.? If you go from server (default) to >>> client, and then back again, shouldn't you reset to the original >>> server values? And set sslConfig.useClientMode() >>> >>> e.g. >>> ???? sslServerSocket.setUseClientMode(true); >>> ???? sslServerSocket.setUseClientMode(false); >>> >>> The current code won't change back to server. >>> >> I may miss something.? I think, it is able to change back. >> >> sslServerSocket.setUseClientMode(true) -> >> ?? if it is server mode, set to use client mode; and if using default >> protocols, set to use client default protocols; if using default >> cipher suites, set to use client default cipher suites.? sslConfig is >> set to use client mode. >> >> sslServerSocket.setUseClientMode(false); >> ?? if it is client mode, set to use server mode; and id using default >> protocols, set to use server default protocols; if using default >> cipher suites, set to use server default cipher suites.? sslConfig is >> set to use server mode. > > You're right, I misread the code.? Thanks for bearing with me. > > Can we move this sslConfig code (157-167) to a method in > SSLConfiguration instead?? The logic here in SSLServerSocketImpl uses > sslContext.* 8 times (e.g. > sslContext.getDefaultProtocolVersions(!useClientMode)).? This code is > very implementation-dependent on SSLConfiguration's internals, and thus > a good encapsulation candidate. > Good point! I will do it later. The enhancement is tracked with: https://bugs.openjdk.java.net/browse/JDK-8204636 Thanks, Xuelei From bradford.wetmore at oracle.com Wed Jun 13 00:43:48 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 12 Jun 2018 17:43:48 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> Message-ID: <169041b4-a869-a11c-e362-13dc762ba92e@oracle.com> I really don't have much to say about SSLEngineImpl. I like the refactoring you've done. Just some nits. Ignore my previous suggestion about conContext, after seeing it a bit more often, it makes sense now. SSLSocketImpl.java ------------------ 72: I noticed you removed the public here from SSLEngineImpl, and there wasn't one from SSLServerSocketImpl, but public is still here in SSLSocketImpl. Maybe we can remove it? Is there a reason to keep it public? SSLEngineImpl.java ------------------ 116: You could put this on one line if you want. 122-123: Indent 8 spaces here. 757: At line 735, you use CipherSuite.validValuesOf(suites); but here you use: ProtocolVersion.namesOf(protocols); Seems like it's basically the same kind of method, do you want to make the names consistent. Brad On 6/8/2018 10:21 AM, Xuelei Fan wrote: > Here is the 3rd full webrev: > ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.02 > > and the delta update to the 1st webrev: > ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.01 > > Xuelei > > On 6/3/2018 9:43 PM, Xuelei Fan wrote: >> Hi, >> >> Here it the 2nd full webrev: >> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >> >> and the delta update to the 1st webrev: >> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >> >> Xuelei >> >> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>> Hi, >>> >>> I'd like to invite you to review the TLS 1.3 implementation.? I >>> appreciate it if I could have compatibility and specification >>> feedback before May 31, 2018, and implementation feedback before June >>> 7, 2018. >>> >>> Here is the webrev: >>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>> >>> The formal TLS 1.3 specification is not finalized yet, although it >>> had been approved to be a standard.? The implementation is based on >>> the draft version 28: >>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>> >>> For the overall description of this enhancement, please refer to JEP >>> 332: >>> ???? http://openjdk.java.net/jeps/332 >>> >>> For the compatibility and specification update, please refer to CSR >>> 8202625: >>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>> >>> Note that we are using the sandbox for the development right now. >>> For more information, please refer to Bradford's previous email: >>> >>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>> >>> Thanks & Regards, >>> Xuelei From rajan.halade at oracle.com Wed Jun 13 01:51:32 2018 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 12 Jun 2018 18:51:32 -0700 Subject: RFR: 8204923: Restore Symantec root verisignclass2g2ca Message-ID: <8eb1b21a-760b-2dc5-1643-c3704b5008f2@oracle.com> Please review this fix to restore verisignclass2g2ca root. Webrev: http://cr.openjdk.java.net/~rhalade/8204923/webrev.00/ Thanks, Rajan From xuelei.fan at oracle.com Wed Jun 13 02:49:53 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 12 Jun 2018 19:49:53 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <169041b4-a869-a11c-e362-13dc762ba92e@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> <169041b4-a869-a11c-e362-13dc762ba92e@oracle.com> Message-ID: On 6/12/2018 5:43 PM, Bradford Wetmore wrote: > I really don't have much to say about SSLEngineImpl.? I like the > refactoring you've done.? Just some nits. > > Ignore my previous suggestion about conContext, after seeing it a bit > more often, it makes sense now. > > SSLSocketImpl.java > ------------------ > 72:? I noticed you removed the public here from SSLEngineImpl, and there > wasn't one from SSLServerSocketImpl, but public is still here in > SSLSocketImpl.? Maybe we can remove it?? Is there a reason to keep it > public? > I tried, but SSLSocketImpl is used by sun.net.www.protocol.https.HttpsClient.java. > > SSLEngineImpl.java > ------------------ > 116:? You could put this on one line if you want. > Yes, it is exactly 80 characters. > 122-123:? Indent 8 spaces here. > If using 8 spaces, the line exceeds 80 characters. I normally have 4 spaces then, and have a blank line followed. > 757:? At line 735, you use > > CipherSuite.validValuesOf(suites); > > but here you use: > > ProtocolVersion.namesOf(protocols); > > Seems like it's basically the same kind of method, do you want to make > the names consistent. > There is a little bit different. The validValuesOf() method will check if the suite are supported or not. About the name, we can make an improvement. This enhancement is tracked with: https://bugs.openjdk.java.net/browse/JDK-8204636 Thanks, Xuelei > Brad > > > On 6/8/2018 10:21 AM, Xuelei Fan wrote: >> Here is the 3rd full webrev: >> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.02 >> >> and the delta update to the 1st webrev: >> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.01 >> >> Xuelei >> >> On 6/3/2018 9:43 PM, Xuelei Fan wrote: >>> Hi, >>> >>> Here it the 2nd full webrev: >>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >>> >>> and the delta update to the 1st webrev: >>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >>> >>> Xuelei >>> >>> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> I'd like to invite you to review the TLS 1.3 implementation.? I >>>> appreciate it if I could have compatibility and specification >>>> feedback before May 31, 2018, and implementation feedback before >>>> June 7, 2018. >>>> >>>> Here is the webrev: >>>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>>> >>>> The formal TLS 1.3 specification is not finalized yet, although it >>>> had been approved to be a standard.? The implementation is based on >>>> the draft version 28: >>>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>>> >>>> For the overall description of this enhancement, please refer to JEP >>>> 332: >>>> ???? http://openjdk.java.net/jeps/332 >>>> >>>> For the compatibility and specification update, please refer to CSR >>>> 8202625: >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>>> >>>> Note that we are using the sandbox for the development right now. >>>> For more information, please refer to Bradford's previous email: >>>> >>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>>> >>>> >>>> Thanks & Regards, >>>> Xuelei From xuelei.fan at oracle.com Wed Jun 13 05:25:57 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 12 Jun 2018 22:25:57 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> Message-ID: Update: http://hg.openjdk.java.net/jdk/sandbox/rev/2b4ae319412b This update enable RSASSA-PSS signature algorithm for TLS 1.2, and improve the SSLSocket close implementation. Xuelei On 6/8/2018 10:21 AM, Xuelei Fan wrote: > Here is the 3rd full webrev: > ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.02 > > and the delta update to the 1st webrev: > ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.01 > > Xuelei > > On 6/3/2018 9:43 PM, Xuelei Fan wrote: >> Hi, >> >> Here it the 2nd full webrev: >> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >> >> and the delta update to the 1st webrev: >> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >> >> Xuelei >> >> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>> Hi, >>> >>> I'd like to invite you to review the TLS 1.3 implementation.? I >>> appreciate it if I could have compatibility and specification >>> feedback before May 31, 2018, and implementation feedback before June >>> 7, 2018. >>> >>> Here is the webrev: >>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>> >>> The formal TLS 1.3 specification is not finalized yet, although it >>> had been approved to be a standard.? The implementation is based on >>> the draft version 28: >>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>> >>> For the overall description of this enhancement, please refer to JEP >>> 332: >>> ???? http://openjdk.java.net/jeps/332 >>> >>> For the compatibility and specification update, please refer to CSR >>> 8202625: >>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>> >>> Note that we are using the sandbox for the development right now. >>> For more information, please refer to Bradford's previous email: >>> >>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>> >>> Thanks & Regards, >>> Xuelei From sean.mullan at oracle.com Wed Jun 13 12:17:35 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 13 Jun 2018 08:17:35 -0400 Subject: RFR 8177334: Update xmldsig implementation to Apache Santuario 2.1.1 In-Reply-To: <2C946CE7-6E09-45B0-AC46-7C0C2EE505AB@oracle.com> References: <2C946CE7-6E09-45B0-AC46-7C0C2EE505AB@oracle.com> Message-ID: <8506b60c-e6a0-ca46-6add-829485229ae9@oracle.com> In StorageResolver.java: 41 private static final com.sun.org.slf4j.internal.Logger LOG = 42 com.sun.org.slf4j.internal.LoggerFactory.getLogger(StorageResolver.class); Shouldn't the previous code using java.util.logging.Logger be retained? There is no com.sun.org.slf4j package in the JDK. --Sean On 5/24/18 1:50 AM, Weijun Wang wrote: > Please review the change at > > webrev: http://cr.openjdk.java.net/~weijun/8177334/webrev.00/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8203460 > > New features include the support of SHA-224 and SHA-3 MessageMethod, and RSASSA-PSS SignatureMethods. > > The change is done in 2 steps: > > 1. Copying files from Apache Santuario Release 2.1.1 [1]. Making cosmetic changes like changing package names. > > 2. More changes, including > > a. Applying patches in OpenJDK that were not pushed to Apache Santuario (yet) > b. Using the RSASSA-PSS Signature algorithm in OpenJDK, because we don't have names like SHA256withRSAandMGF1 > c. Copying standard digest method and signature method names into public API (see the CSR) > > For your convenience, there is a separate webrev for step 2 above at > > http://cr.openjdk.java.net/~weijun/8177334/changes/ > > Thanks > Max > > [1] http://www.apache.org/dyn/closer.lua/santuario/java-library/2_1_1/xmlsec-2.1.1-source-release.zip > From sean.mullan at oracle.com Wed Jun 13 12:22:59 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 13 Jun 2018 08:22:59 -0400 Subject: RFR: 8204923: Restore Symantec root verisignclass2g2ca In-Reply-To: <8eb1b21a-760b-2dc5-1643-c3704b5008f2@oracle.com> References: <8eb1b21a-760b-2dc5-1643-c3704b5008f2@oracle.com> Message-ID: Looks good. --Sean On 6/12/18 9:51 PM, Rajan Halade wrote: > Please review this fix to restore verisignclass2g2ca root. > > Webrev: http://cr.openjdk.java.net/~rhalade/8204923/webrev.00/ > > Thanks, > Rajan From weijun.wang at oracle.com Wed Jun 13 12:32:09 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 13 Jun 2018 20:32:09 +0800 Subject: RFR 8177334: Update xmldsig implementation to Apache Santuario 2.1.1 In-Reply-To: <8506b60c-e6a0-ca46-6add-829485229ae9@oracle.com> References: <2C946CE7-6E09-45B0-AC46-7C0C2EE505AB@oracle.com> <8506b60c-e6a0-ca46-6add-829485229ae9@oracle.com> Message-ID: <8807F6F0-C8BE-4946-BD57-DACFE5060720@oracle.com> I've created my own Logger.java and LoggerFactory.java in com.sun.org.slf4j.internal. They has a slf4j-style interface but use java.util.logging.Logger inside. --Max [1] http://cr.openjdk.java.net/~weijun/8177334/webrev.01/src/java.xml.crypto/share/classes/com/sun/org/slf4j/internal/LoggerFactory.java.html [2] http://cr.openjdk.java.net/~weijun/8177334/webrev.01/src/java.xml.crypto/share/classes/com/sun/org/slf4j/internal/Logger.java.html > On Jun 13, 2018, at 8:17 PM, Sean Mullan wrote: > > In StorageResolver.java: > > 41 private static final com.sun.org.slf4j.internal.Logger LOG = > 42 com.sun.org.slf4j.internal.LoggerFactory.getLogger(StorageResolver.class); > > Shouldn't the previous code using java.util.logging.Logger be retained? There is no com.sun.org.slf4j package in the JDK. > > --Sean > > On 5/24/18 1:50 AM, Weijun Wang wrote: >> Please review the change at >> webrev: http://cr.openjdk.java.net/~weijun/8177334/webrev.00/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8203460 >> New features include the support of SHA-224 and SHA-3 MessageMethod, and RSASSA-PSS SignatureMethods. >> The change is done in 2 steps: >> 1. Copying files from Apache Santuario Release 2.1.1 [1]. Making cosmetic changes like changing package names. >> 2. More changes, including >> a. Applying patches in OpenJDK that were not pushed to Apache Santuario (yet) >> b. Using the RSASSA-PSS Signature algorithm in OpenJDK, because we don't have names like SHA256withRSAandMGF1 >> c. Copying standard digest method and signature method names into public API (see the CSR) >> For your convenience, there is a separate webrev for step 2 above at >> http://cr.openjdk.java.net/~weijun/8177334/changes/ >> Thanks >> Max >> [1] http://www.apache.org/dyn/closer.lua/santuario/java-library/2_1_1/xmlsec-2.1.1-source-release.zip From xuelei.fan at oracle.com Wed Jun 13 17:02:42 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 13 Jun 2018 10:02:42 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> Message-ID: <000d9d25-1f49-6129-df9a-ab38af20c050@oracle.com> AlpnExtension.java ------------------ line 145-153, 354-365 If the extension is not available, the applicationProtocol is not set to empty. Update: http://hg.openjdk.java.net/jdk/sandbox/rev/d0728b0f98f9 Xuelei On 6/8/2018 10:21 AM, Xuelei Fan wrote: > Here is the 3rd full webrev: > ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.02 > > and the delta update to the 1st webrev: > ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.01 > > Xuelei > > On 6/3/2018 9:43 PM, Xuelei Fan wrote: >> Hi, >> >> Here it the 2nd full webrev: >> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >> >> and the delta update to the 1st webrev: >> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >> >> Xuelei >> >> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>> Hi, >>> >>> I'd like to invite you to review the TLS 1.3 implementation.? I >>> appreciate it if I could have compatibility and specification >>> feedback before May 31, 2018, and implementation feedback before June >>> 7, 2018. >>> >>> Here is the webrev: >>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>> >>> The formal TLS 1.3 specification is not finalized yet, although it >>> had been approved to be a standard.? The implementation is based on >>> the draft version 28: >>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>> >>> For the overall description of this enhancement, please refer to JEP >>> 332: >>> ???? http://openjdk.java.net/jeps/332 >>> >>> For the compatibility and specification update, please refer to CSR >>> 8202625: >>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>> >>> Note that we are using the sandbox for the development right now. >>> For more information, please refer to Bradford's previous email: >>> >>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>> >>> Thanks & Regards, >>> Xuelei From anthony.scarpino at oracle.com Wed Jun 13 21:21:29 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 13 Jun 2018 14:21:29 -0700 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> Message-ID: <9d937ff5-0932-ef50-2135-a8e89a7f1533@oracle.com> I found some commented out code that I will remove in CertificateMessage, lines 1300-1319 on my next push unless this should be uncommented. In SupportedVersionsExtension.java, HRRSupportedVersionsProducer and HRRSupportedVersionReproducer could be merged with a boolean in the constructor to define it as a producer or reproducer. The only difference right now between the classes is whether to put HRR_SUPPORTED_VERSIONS in the handshakeExtension. But it is minor is ok as is. Most of the files I've gone through are small nits and spelling that I will update. Tony From anthony.scarpino at oracle.com Thu Jun 14 04:46:34 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 13 Jun 2018 21:46:34 -0700 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: <9d937ff5-0932-ef50-2135-a8e89a7f1533@oracle.com> References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> <9d937ff5-0932-ef50-2135-a8e89a7f1533@oracle.com> Message-ID: DTLSRecord.java & SSLRecord.java The two variables below not used. They weren't used before the code restructuring either. maxDataSizeMinusOneByteRecord maxAlertRecordSize Tony On 06/13/2018 02:21 PM, Anthony Scarpino wrote: > I found some commented out code that I will remove in > CertificateMessage, lines 1300-1319 on my next push unless this should > be uncommented. > > In SupportedVersionsExtension.java, HRRSupportedVersionsProducer and > HRRSupportedVersionReproducer could be merged with a boolean in the > constructor to define it as a producer or reproducer.? The only > difference right now between the classes is whether to put > HRR_SUPPORTED_VERSIONS in the handshakeExtension.? But it is minor is ok > as is. > > Most of the files I've gone through are small nits and spelling that I > will update. > > Tony > From xuelei.fan at oracle.com Thu Jun 14 15:29:55 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 14 Jun 2018 08:29:55 -0700 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> <9d937ff5-0932-ef50-2135-a8e89a7f1533@oracle.com> Message-ID: <9fd465c9-25ae-3084-9841-e11cdf71398a@oracle.com> All good catches! Thanks, Xuelei On 6/13/2018 9:46 PM, Anthony Scarpino wrote: > DTLSRecord.java & SSLRecord.java > The two variables below not used.? They weren't used before the code > restructuring either. > ? maxDataSizeMinusOneByteRecord > ? maxAlertRecordSize > > > Tony > > On 06/13/2018 02:21 PM, Anthony Scarpino wrote: >> I found some commented out code that I will remove in >> CertificateMessage, lines 1300-1319 on my next push unless this should >> be uncommented. >> >> In SupportedVersionsExtension.java, HRRSupportedVersionsProducer and >> HRRSupportedVersionReproducer could be merged with a boolean in the >> constructor to define it as a producer or reproducer.? The only >> difference right now between the classes is whether to put >> HRR_SUPPORTED_VERSIONS in the handshakeExtension.? But it is minor is >> ok as is. >> >> Most of the files I've gone through are small nits and spelling that I >> will update. >> >> Tony >> > From sean.mullan at oracle.com Thu Jun 14 18:19:47 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 14 Jun 2018 14:19:47 -0400 Subject: RFR 8177334: Update xmldsig implementation to Apache Santuario 2.1.1 In-Reply-To: <8807F6F0-C8BE-4946-BD57-DACFE5060720@oracle.com> References: <2C946CE7-6E09-45B0-AC46-7C0C2EE505AB@oracle.com> <8506b60c-e6a0-ca46-6add-829485229ae9@oracle.com> <8807F6F0-C8BE-4946-BD57-DACFE5060720@oracle.com> Message-ID: Here are some comments so far. I should be able to finish reviewing this by tomorrow. - src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/utils/EncryptionConstants.java - src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/utils/EncryptionElementProxy.java Can we remove these 2 files since it looks like they are for XML Encryption? - src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/DigestMethod.java - src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/SignatureMethod.java Add @since 11 to the new constants. - src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/stax/ext/XMLSecurityConstants.java Can we remove this since it is for the stax impl? --Sean On 6/13/18 8:32 AM, Weijun Wang wrote: > I've created my own Logger.java and LoggerFactory.java in com.sun.org.slf4j.internal. They has a slf4j-style interface but use java.util.logging.Logger inside. > > --Max > > [1] http://cr.openjdk.java.net/~weijun/8177334/webrev.01/src/java.xml.crypto/share/classes/com/sun/org/slf4j/internal/LoggerFactory.java.html > [2] http://cr.openjdk.java.net/~weijun/8177334/webrev.01/src/java.xml.crypto/share/classes/com/sun/org/slf4j/internal/Logger.java.html > >> On Jun 13, 2018, at 8:17 PM, Sean Mullan wrote: >> >> In StorageResolver.java: >> >> 41 private static final com.sun.org.slf4j.internal.Logger LOG = >> 42 com.sun.org.slf4j.internal.LoggerFactory.getLogger(StorageResolver.class); >> >> Shouldn't the previous code using java.util.logging.Logger be retained? There is no com.sun.org.slf4j package in the JDK. >> >> --Sean >> >> On 5/24/18 1:50 AM, Weijun Wang wrote: >>> Please review the change at >>> webrev: http://cr.openjdk.java.net/~weijun/8177334/webrev.00/ >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8203460 >>> New features include the support of SHA-224 and SHA-3 MessageMethod, and RSASSA-PSS SignatureMethods. >>> The change is done in 2 steps: >>> 1. Copying files from Apache Santuario Release 2.1.1 [1]. Making cosmetic changes like changing package names. >>> 2. More changes, including >>> a. Applying patches in OpenJDK that were not pushed to Apache Santuario (yet) >>> b. Using the RSASSA-PSS Signature algorithm in OpenJDK, because we don't have names like SHA256withRSAandMGF1 >>> c. Copying standard digest method and signature method names into public API (see the CSR) >>> For your convenience, there is a separate webrev for step 2 above at >>> http://cr.openjdk.java.net/~weijun/8177334/changes/ >>> Thanks >>> Max >>> [1] http://www.apache.org/dyn/closer.lua/santuario/java-library/2_1_1/xmlsec-2.1.1-source-release.zip > From weijun.wang at oracle.com Fri Jun 15 00:18:40 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 15 Jun 2018 08:18:40 +0800 Subject: RFR 8177334: Update xmldsig implementation to Apache Santuario 2.1.1 In-Reply-To: References: <2C946CE7-6E09-45B0-AC46-7C0C2EE505AB@oracle.com> <8506b60c-e6a0-ca46-6add-829485229ae9@oracle.com> <8807F6F0-C8BE-4946-BD57-DACFE5060720@oracle.com> Message-ID: > On Jun 15, 2018, at 2:19 AM, Sean Mullan wrote: > > Here are some comments so far. I should be able to finish reviewing this by tomorrow. > > - src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/utils/EncryptionConstants.java The MessageDigest algorithms are registered under "http://www.w3.org/2001/04/xmlenc#", so this single constant is retained. I didn't move the constant to somewhere else or just inline it, because I want to modify the Santuario code as little as possible. > - src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/utils/EncryptionElementProxy.java Good catch. This should have been removed, but my script got the added comment block wrong. > > Can we remove these 2 files since it looks like they are for XML Encryption? > > - src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/DigestMethod.java > - src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/SignatureMethod.java > > Add @since 11 to the new constants. Added. > > - src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/stax/ext/XMLSecurityConstants.java > > Can we remove this since it is for the stax impl? Yes. I remember the generateBytes() method there was used by something not in stax, but I cannot find it now. No new webrev posted. Thanks Max > > --Sean > > > On 6/13/18 8:32 AM, Weijun Wang wrote: >> I've created my own Logger.java and LoggerFactory.java in com.sun.org.slf4j.internal. They has a slf4j-style interface but use java.util.logging.Logger inside. >> --Max >> [1] http://cr.openjdk.java.net/~weijun/8177334/webrev.01/src/java.xml.crypto/share/classes/com/sun/org/slf4j/internal/LoggerFactory.java.html >> [2] http://cr.openjdk.java.net/~weijun/8177334/webrev.01/src/java.xml.crypto/share/classes/com/sun/org/slf4j/internal/Logger.java.html >>> On Jun 13, 2018, at 8:17 PM, Sean Mullan wrote: >>> >>> In StorageResolver.java: >>> >>> 41 private static final com.sun.org.slf4j.internal.Logger LOG = >>> 42 com.sun.org.slf4j.internal.LoggerFactory.getLogger(StorageResolver.class); >>> >>> Shouldn't the previous code using java.util.logging.Logger be retained? There is no com.sun.org.slf4j package in the JDK. >>> >>> --Sean >>> >>> On 5/24/18 1:50 AM, Weijun Wang wrote: >>>> Please review the change at >>>> webrev: http://cr.openjdk.java.net/~weijun/8177334/webrev.00/ >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8203460 >>>> New features include the support of SHA-224 and SHA-3 MessageMethod, and RSASSA-PSS SignatureMethods. >>>> The change is done in 2 steps: >>>> 1. Copying files from Apache Santuario Release 2.1.1 [1]. Making cosmetic changes like changing package names. >>>> 2. More changes, including >>>> a. Applying patches in OpenJDK that were not pushed to Apache Santuario (yet) >>>> b. Using the RSASSA-PSS Signature algorithm in OpenJDK, because we don't have names like SHA256withRSAandMGF1 >>>> c. Copying standard digest method and signature method names into public API (see the CSR) >>>> For your convenience, there is a separate webrev for step 2 above at >>>> http://cr.openjdk.java.net/~weijun/8177334/changes/ >>>> Thanks >>>> Max >>>> [1] http://www.apache.org/dyn/closer.lua/santuario/java-library/2_1_1/xmlsec-2.1.1-source-release.zip From xuelei.fan at oracle.com Fri Jun 15 13:53:46 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 15 Jun 2018 06:53:46 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> Message-ID: SSLCipher.java -------------- In the implementation, the key usage impacts the write side only. I think the read side should also limit the key usage. The crypto limit issues applies to TLS 1.2 and prior versions as well. Xuelei On 6/8/2018 10:21 AM, Xuelei Fan wrote: > Here is the 3rd full webrev: > ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.02 > > and the delta update to the 1st webrev: > ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.01 > > Xuelei > > On 6/3/2018 9:43 PM, Xuelei Fan wrote: >> Hi, >> >> Here it the 2nd full webrev: >> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >> >> and the delta update to the 1st webrev: >> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >> >> Xuelei >> >> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>> Hi, >>> >>> I'd like to invite you to review the TLS 1.3 implementation.? I >>> appreciate it if I could have compatibility and specification >>> feedback before May 31, 2018, and implementation feedback before June >>> 7, 2018. >>> >>> Here is the webrev: >>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>> >>> The formal TLS 1.3 specification is not finalized yet, although it >>> had been approved to be a standard.? The implementation is based on >>> the draft version 28: >>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>> >>> For the overall description of this enhancement, please refer to JEP >>> 332: >>> ???? http://openjdk.java.net/jeps/332 >>> >>> For the compatibility and specification update, please refer to CSR >>> 8202625: >>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>> >>> Note that we are using the sandbox for the development right now. >>> For more information, please refer to Bradford's previous email: >>> >>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>> >>> Thanks & Regards, >>> Xuelei From xuelei.fan at oracle.com Fri Jun 15 14:56:53 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 15 Jun 2018 07:56:53 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> Message-ID: <8bcd4b22-753d-0b83-4138-fe338575c5b4@oracle.com> SSLExtension.java ----------------- The "supported_versions" can be used in TLS 1.2 ClientHello, per the specification: Implementations of TLS 1.3 which choose to support prior versions of TLS SHOULD support TLS 1.2. Servers MUST be prepared to receive ClientHellos that include this extension but do not include 0x0304 in the list of versions. Although, the extension cannot be use in ServerHello for TLS 1.2 and prior versions: A server which negotiates a version of TLS prior to TLS 1.3 MUST set ServerHello.version and MUST NOT send the "supported_versions" extension. Xuelei On 6/8/2018 10:21 AM, Xuelei Fan wrote: > Here is the 3rd full webrev: > ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.02 > > and the delta update to the 1st webrev: > ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.01 > > Xuelei > > On 6/3/2018 9:43 PM, Xuelei Fan wrote: >> Hi, >> >> Here it the 2nd full webrev: >> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >> >> and the delta update to the 1st webrev: >> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >> >> Xuelei >> >> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>> Hi, >>> >>> I'd like to invite you to review the TLS 1.3 implementation.? I >>> appreciate it if I could have compatibility and specification >>> feedback before May 31, 2018, and implementation feedback before June >>> 7, 2018. >>> >>> Here is the webrev: >>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>> >>> The formal TLS 1.3 specification is not finalized yet, although it >>> had been approved to be a standard.? The implementation is basedon >>> the draft version 28: >>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>> >>> For the overall description of this enhancement, please refer to JEP >>> 332: >>> ???? http://openjdk.java.net/jeps/332 >>> >>> For the compatibility and specification update, please refer to CSR >>> 8202625: >>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>> >>> Note that we are using the sandbox for the development right now. >>> For more information, please refer to Bradford's previous email: >>> >>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>> >>> Thanks & Regards, >>> Xuelei From anthony.scarpino at oracle.com Fri Jun 15 16:27:57 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 15 Jun 2018 09:27:57 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> Message-ID: On 06/15/2018 06:53 AM, Xuelei Fan wrote: > SSLCipher.java > -------------- > In the implementation, the key usage impacts the write side only.?? I > think the read side should also limit the key usage. I remember it being discussed many many months ago we at first planned to do the read side, but then decided it was not necessary. Are we changing the decision? > > The crypto limit issues applies to TLS 1.2 and prior versions as well. I know we talked about doing this but I believe we decided against doing this because in prior versions can ignore HelloRequest and other complications that could cause sessions to be disconnected. I think it was also a nice to have but 1.3 was more important, prior version could be done later. > > Xuelei > > On 6/8/2018 10:21 AM, Xuelei Fan wrote: >> Here is the 3rd full webrev: >> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.02 >> >> and the delta update to the 1st webrev: >> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.01 >> >> Xuelei >> >> On 6/3/2018 9:43 PM, Xuelei Fan wrote: >>> Hi, >>> >>> Here it the 2nd full webrev: >>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >>> >>> and the delta update to the 1st webrev: >>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >>> >>> Xuelei >>> >>> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> I'd like to invite you to review the TLS 1.3 implementation.? I >>>> appreciate it if I could have compatibility and specification >>>> feedback before May 31, 2018, and implementation feedback before >>>> June 7, 2018. >>>> >>>> Here is the webrev: >>>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>>> >>>> The formal TLS 1.3 specification is not finalized yet, although it >>>> had been approved to be a standard.? The implementation is based on >>>> the draft version 28: >>>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>>> >>>> For the overall description of this enhancement, please refer to JEP >>>> 332: >>>> ???? http://openjdk.java.net/jeps/332 >>>> >>>> For the compatibility and specification update, please refer to CSR >>>> 8202625: >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>>> >>>> Note that we are using the sandbox for the development right now. >>>> For more information, please refer to Bradford's previous email: >>>> >>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>>> >>>> >>>> Thanks & Regards, >>>> Xuelei From xuelei.fan at oracle.com Fri Jun 15 17:00:14 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 15 Jun 2018 10:00:14 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> Message-ID: <387e42e4-17ad-f04f-8f1e-6f3df0c4c0f5@oracle.com> On 6/15/2018 9:27 AM, Anthony Scarpino wrote: > On 06/15/2018 06:53 AM, Xuelei Fan wrote: >> SSLCipher.java >> -------------- >> In the implementation, the key usage impacts the write side only.?? I >> think the read side should also limit the key usage. > > I remember it being discussed many many months ago we at first planned > to do the read side, but then decided it was not necessary.? Are we > changing the decision? > It is a little bit tricky that the key and iv update triggers the write side key/iv update only. If the peer does not implement the key usage limit, and the local read a large bunch of data, there is a risk to exceed the key usage limit. It might worthy an improvement by adding the read side key usage limit later. >> >> The crypto limit issues applies to TLS 1.2 and prior versions as well. > > I know we talked about doing this but I believe we decided against doing > this because in prior versions can ignore HelloRequest and other > complications that could cause sessions to be disconnected.? I think it > was also a nice to have but 1.3 was more important, prior version could > be done later. > Yes, we can do it later. I added a track in the JBS: https://bugs.openjdk.java.net/browse/JDK-8204636 Xuelei >> >> Xuelei >> >> On 6/8/2018 10:21 AM, Xuelei Fan wrote: >>> Here is the 3rd full webrev: >>> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.02 >>> >>> and the delta update to the 1st webrev: >>> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.01 >>> >>> Xuelei >>> >>> On 6/3/2018 9:43 PM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> Here it the 2nd full webrev: >>>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >>>> >>>> and the delta update to the 1st webrev: >>>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >>>> >>>> Xuelei >>>> >>>> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> I'd like to invite you to review the TLS 1.3 implementation.? I >>>>> appreciate it if I could have compatibility and specification >>>>> feedback before May 31, 2018, and implementation feedback before >>>>> June 7, 2018. >>>>> >>>>> Here is the webrev: >>>>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>>>> >>>>> The formal TLS 1.3 specification is not finalized yet, although it >>>>> had been approved to be a standard.? The implementation is based on >>>>> the draft version 28: >>>>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>>>> >>>>> For the overall description of this enhancement, please refer to >>>>> JEP 332: >>>>> ???? http://openjdk.java.net/jeps/332 >>>>> >>>>> For the compatibility and specification update, please refer to CSR >>>>> 8202625: >>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>>>> >>>>> Note that we are using the sandbox for the development right now. >>>>> For more information, please refer to Bradford's previous email: >>>>> >>>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>>>> >>>>> >>>>> Thanks & Regards, >>>>> Xuelei > From sean.mullan at oracle.com Fri Jun 15 18:41:45 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 15 Jun 2018 14:41:45 -0400 Subject: RFR 8177334: Update xmldsig implementation to Apache Santuario 2.1.1 In-Reply-To: References: <2C946CE7-6E09-45B0-AC46-7C0C2EE505AB@oracle.com> <8506b60c-e6a0-ca46-6add-829485229ae9@oracle.com> <8807F6F0-C8BE-4946-BD57-DACFE5060720@oracle.com> Message-ID: <0f9e6742-5e8c-aabb-b621-5282ca75afe4@oracle.com> On 6/14/18 8:18 PM, Weijun Wang wrote: >> On Jun 15, 2018, at 2:19 AM, Sean Mullan wrote: >> >> Here are some comments so far. I should be able to finish reviewing this by tomorrow. >> >> - src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/utils/EncryptionConstants.java > The MessageDigest algorithms are registered under"http://www.w3.org/2001/04/xmlenc#", so this single constant is retained. I didn't move the constant to somewhere else or just inline it, because I want to modify the Santuario code as little as possible. Ok. I don't have any further comments. --Sean From valerie.peng at oracle.com Fri Jun 15 20:08:51 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 15 Jun 2018 13:08:51 -0700 Subject: RFR [11] CSR for "Add Brainpool ECC support (RFC 5639)" Message-ID: <6b785a17-2258-cb61-0103-e5a9ff828e1e@oracle.com> Hi Can someone help reviewing the CSR for Adding Brainpool ECC support? https://bugs.openjdk.java.net/browse/JDK-8204836 Thanks, Valerie From xuelei.fan at oracle.com Fri Jun 15 21:10:36 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 15 Jun 2018 14:10:36 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <8bcd4b22-753d-0b83-4138-fe338575c5b4@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> <8bcd4b22-753d-0b83-4138-fe338575c5b4@oracle.com> Message-ID: <275fe430-9376-7e0a-86f1-1e42c4328efa@oracle.com> Update: http://hg.openjdk.java.net/jdk/sandbox/rev/125890684a60 Supports supported_versions extension for TLS 1.2 and prior versions. Xuelei On 6/15/2018 7:56 AM, Xuelei Fan wrote: > SSLExtension.java > ----------------- > The "supported_versions" can be used in TLS 1.2 ClientHello, per the > specification: > > ?? Implementations of TLS 1.3 which choose to support prior > ?? versions of TLS SHOULD support TLS 1.2.? Servers MUST be prepared to > ?? receive ClientHellos that include this extension but do not include > ?? 0x0304 in the list of versions. > > Although, the extension cannot be use in ServerHello for TLS 1.2 and > prior versions: > > ?? A server which negotiates a version of TLS prior to TLS 1.3 MUST set > ?? ServerHello.version and MUST NOT send the "supported_versions" > ?? extension. > > Xuelei > > On 6/8/2018 10:21 AM, Xuelei Fan wrote: >> Here is the 3rd full webrev: >> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.02 >> >> and the delta update to the 1st webrev: >> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.01 >> >> Xuelei >> >> On 6/3/2018 9:43 PM, Xuelei Fan wrote: >>> Hi, >>> >>> Here it the 2nd full webrev: >>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >>> >>> and the delta update to the 1st webrev: >>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >>> >>> Xuelei >>> >>> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> I'd like to invite you to review the TLS 1.3 implementation.? I >>>> appreciate it if I could have compatibility and specification >>>> feedback before May 31, 2018, and implementation feedback before >>>> June 7, 2018. >>>> >>>> Here is the webrev: >>>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>>> >>>> The formal TLS 1.3 specification is not finalized yet, although it >>>> had been approved to be a standard.? The implementation is basedon >>>> the draft version 28: >>>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>>> >>>> For the overall description of this enhancement, please refer to JEP >>>> 332: >>>> ???? http://openjdk.java.net/jeps/332 >>>> >>>> For the compatibility and specification update, please refer to CSR >>>> 8202625: >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>>> >>>> Note that we are using the sandbox for the development right now. >>>> For more information, please refer to Bradford's previous email: >>>> >>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>>> >>>> >>>> Thanks & Regards, >>>> Xuelei From xuelei.fan at oracle.com Mon Jun 18 15:48:02 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 18 Jun 2018 08:48:02 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> Message-ID: <73c794d3-0afa-1243-c31b-1fa5caae9a9d@oracle.com> CertificateMessage.java X509TrustManagerImpl.java X509KeyManagerImpl.java ------------------------- These implementation has not consider the impact of RSASSA-PSS key type. Xuelei On 6/8/2018 10:21 AM, Xuelei Fan wrote: > Here is the 3rd full webrev: > ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.02 > > and the delta update to the 1st webrev: > ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.01 > > Xuelei > > On 6/3/2018 9:43 PM, Xuelei Fan wrote: >> Hi, >> >> Here it the 2nd full webrev: >> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >> >> and the delta update to the 1st webrev: >> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >> >> Xuelei >> >> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>> Hi, >>> >>> I'd like to invite you to review the TLS 1.3 implementation.? I >>> appreciate it if I could have compatibility and specification >>> feedback before May 31, 2018, and implementation feedback before June >>> 7, 2018. >>> >>> Here is the webrev: >>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>> >>> The formal TLS 1.3 specification is not finalized yet, although it >>> had been approved to be a standard.? The implementation is based on >>> the draft version 28: >>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>> >>> For the overall description of this enhancement, please refer to JEP >>> 332: >>> ???? http://openjdk.java.net/jeps/332 >>> >>> For the compatibility and specification update, please refer to CSR >>> 8202625: >>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>> >>> Note that we are using the sandbox for the development right now. >>> For more information, please refer to Bradford's previous email: >>> >>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>> >>> Thanks & Regards, >>> Xuelei From valerie.peng at oracle.com Mon Jun 18 19:28:16 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 18 Jun 2018 12:28:16 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> Message-ID: Hi Xuelei, Looks fine. -line 39, I didn't find info on extended master secret extension in RFC 5746? It looks like the original comment which refers to RFC7627 "Transport Layer Security (TLS) Session Hash anf Extended Master Secret Extension" matches better. Looks fine. Valerie ** On 5/25/2018 4:45 PM, Xuelei Fan wrote: > Hi, > > I'd like to invite you to review the TLS 1.3 implementation.? I > appreciate it if I could have compatibility and specification feedback > before May 31, 2018, and implementation feedback before June 7, 2018. > > Here is the webrev: > ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > The formal TLS 1.3 specification is not finalized yet, although it had > been approved to be a standard.? The implementation is based on the > draft version 28: > ??? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 > > For the overall description of this enhancement, please refer to JEP 332: > ??? http://openjdk.java.net/jeps/332 > > For the compatibility and specification update, please refer to CSR > 8202625: > ??? https://bugs.openjdk.java.net/browse/JDK-8202625 > > Note that we are using the sandbox for the development right now. For > more information, please refer to Bradford's previous email: > > http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html > > Thanks & Regards, > Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Mon Jun 18 19:38:03 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 18 Jun 2018 21:38:03 +0200 Subject: Zip Slip documentation Message-ID: <5b280a1a.1c69fb81.3f8d0.25d1@mx.google.com> Hello, according to Snyk?s Zip Slip vulnerability report (the issue with file Name traversal by extracted Archives) was also sent to Oracle and since Java.util.zip.ZipEntry is a low-Level api the proper Action is changes to the documentation. https://github.com/snyk/zip-slip-vulnerability I wonder if those changes are already published and where they are. (I am aware I wont get an answer if it is not yet published, but in that case the statement in the repo should be corrected to ?not yet documented?). Does the enhanced documentation also talk about the other classical Problems with Archive file entries like absolute path, control characters (linefeed) and illegal (for the local filesystem) characters? Does it also Mention Backslash? If not, I would think a warning might be needed for ZipEntry.getName. The reason I am Looking into this is, because the solution with preparing the file path of canonized file names and parent is not Always possible if it will not directly be extracted or if the Performance Impact might be too high. For that reason rejecting some bad characters and structures on the string Level might be a good Thing (even if that would be a dangerous blacklist construct). Gruss Bernd -- http://bernd.eckenfels.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Mon Jun 18 20:24:53 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 18 Jun 2018 13:24:53 -0700 Subject: RFR [11] JDK-8204152: SignedObject throws NullPointerException for null keys with an initialized Signature object Message-ID: Hi Can someone please help review this fix for addressing JCK test failure? Changes are very trivial, just check for null and thrown InvalidKeyException instead of letting NPE be thrown later. Bug: https://bugs.openjdk.java.net/browse/JDK-8204152 Webrev: http://cr.openjdk.java.net/~valeriep/8204152/webrev.00/ I have verified the fix by re-running the JCK tests. Thanks, Valerie From ecki at zusammenkunft.net Mon Jun 18 20:26:51 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 18 Jun 2018 22:26:51 +0200 Subject: RFR [11] CSR for "Add Brainpool ECC support (RFC 5639)" Message-ID: <5b28158a.1c69fb81.da9dc.2500@mx.google.com> Hello, not a Reviewer, but some Questions on the CSR: - Are there other CSRs for including in TLS? - I also wonder if PKI (CA Signatures) will work out of the box then (OID aliases?) - Does PKCS11 require additional changes? (especially for the Government use mentioned in the justification HSMs are often mandatory) Gruss Bernd -- http://bernd.eckenfels.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From Xuelei.Fan at Oracle.Com Mon Jun 18 20:53:39 2018 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Mon, 18 Jun 2018 13:53:39 -0700 Subject: RFR [11] JDK-8204152: SignedObject throws NullPointerException for null keys with an initialized Signature object In-Reply-To: References: Message-ID: Looks fine to me. Xuelei > On Jun 18, 2018, at 1:24 PM, Valerie Peng wrote: > > Hi > > Can someone please help review this fix for addressing JCK test failure? > Changes are very trivial, just check for null and thrown InvalidKeyException instead of letting NPE be thrown later. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8204152 > Webrev: http://cr.openjdk.java.net/~valeriep/8204152/webrev.00/ > > I have verified the fix by re-running the JCK tests. > > Thanks, > Valerie From xuelei.fan at oracle.com Tue Jun 19 00:01:41 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 18 Jun 2018 17:01:41 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> Message-ID: <852fe54f-b72d-51b4-d398-855607f5e598@oracle.com> On 6/18/2018 12:28 PM, Valerie Peng wrote: > Hi Xuelei, > > > Looks fine. > > -line 39, I didn't find info on extended master secret extension in RFC > 5746? It looks like the original comment which refers to RFC7627 > "Transport Layer Security (TLS) Session Hash anf Extended Master Secret > Extension" matches better. > Yes, RFC 7627 should be used instead. > > Looks fine. > Thanks! Xuelei > Valerie > > ** > On 5/25/2018 4:45 PM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 implementation.? I >> appreciate it if I could have compatibility and specification feedback >> before May 31, 2018, and implementation feedback before June 7, 2018. >> >> Here is the webrev: >> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> The formal TLS 1.3 specification is not finalized yet, although it had >> been approved to be a standard.? The implementation is based on the >> draft version 28: >> https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >> >> For the overall description of this enhancement, please refer to JEP 332: >> http://openjdk.java.net/jeps/332 >> >> For the compatibility and specification update, please refer to CSR >> 8202625: >> https://bugs.openjdk.java.net/browse/JDK-8202625 >> >> Note that we are using the sandbox for the development right now. For >> more information, please refer to Bradford's previous email: >> >> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >> >> Thanks & Regards, >> Xuelei > From xuelei.fan at oracle.com Tue Jun 19 16:09:34 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 19 Jun 2018 09:09:34 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> Message-ID: ECPointFormatsExtension.java PredefinedDHParameterSpecs.java SSLAlgorithmConstraints.java SSLAlgorithmDecomposer.java --------------------------- Looks fine to me, except the copyright year of PredefinedDHParameterSpecs and SSLAlgorithmDecomposer. Updated in the following changeset. http://hg.openjdk.java.net/jdk/sandbox/rev/b472b5917a1b Thanks, Xuelei On 6/8/2018 10:21 AM, Xuelei Fan wrote: > Here is the 3rd full webrev: > ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.02 > > and the delta update to the 1st webrev: > ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.01 > > Xuelei > > On 6/3/2018 9:43 PM, Xuelei Fan wrote: >> Hi, >> >> Here it the 2nd full webrev: >> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >> >> and the delta update to the 1st webrev: >> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >> >> Xuelei >> >> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>> Hi, >>> >>> I'd like to invite you to review the TLS 1.3 implementation.? I >>> appreciate it if I could have compatibility and specification >>> feedback before May 31, 2018, and implementation feedback before June >>> 7, 2018. >>> >>> Here is the webrev: >>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>> >>> The formal TLS 1.3 specification is not finalized yet, although it >>> had been approved to be a standard.? The implementation is based on >>> the draft version 28: >>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>> >>> For the overall description of this enhancement, please refer to JEP >>> 332: >>> ???? http://openjdk.java.net/jeps/332 >>> >>> For the compatibility and specification update, please refer to CSR >>> 8202625: >>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>> >>> Note that we are using the sandbox for the development right now. >>> For more information, please refer to Bradford's previous email: >>> >>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>> >>> Thanks & Regards, >>> Xuelei From valerie.peng at oracle.com Tue Jun 19 19:19:09 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 19 Jun 2018 12:19:09 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> Message-ID: <51930350-b432-df63-3e2d-152c017421dc@oracle.com> Hi Xuelei, Just questions and some nits. looks good looks good - line 98: for unsupported digest, maybe we should consider throw exceptions. It's easier to find out where the support needs to be added if we fail early. - Just wondering why we need difference classes of SecretKeyDerivationGenerator (i.e. S30/T10/T12MaterSecretKeyDerivationGenerator instances), it seems that they all use LegacyMasterKeyDerivation class. The enum already has name which indicates the protocol version, is the SSLKeyDerivationGenerator passed around by itself and you are using its class to find out the protocol version? Or, is there other reason for this? - line 71: add a default to catch the unsupported ProtocolVersion case? - line 319: check params or assert params to be null? I assume it'll be null as it seems to be not used. Thanks, Valerie On 5/25/2018 4:45 PM, Xuelei Fan wrote: > Hi, > > I'd like to invite you to review the TLS 1.3 implementation.? I > appreciate it if I could have compatibility and specification feedback > before May 31, 2018, and implementation feedback before June 7, 2018. > > Here is the webrev: > ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > The formal TLS 1.3 specification is not finalized yet, although it had > been approved to be a standard.? The implementation is based on the > draft version 28: > ??? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 > > For the overall description of this enhancement, please refer to JEP 332: > ??? http://openjdk.java.net/jeps/332 > > For the compatibility and specification update, please refer to CSR > 8202625: > ??? https://bugs.openjdk.java.net/browse/JDK-8202625 > > Note that we are using the sandbox for the development right now. For > more information, please refer to Bradford's previous email: > > http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html > > Thanks & Regards, > Xuelei From anthony.scarpino at oracle.com Tue Jun 19 22:56:07 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 19 Jun 2018 15:56:07 -0700 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> Message-ID: <5d0bc6d3-8c2e-d22a-428e-d1a6863171f3@oracle.com> Read side key limit change at: http://hg.openjdk.java.net/jdk/sandbox/rev/6210466cf1ac Tony From gromero at linux.vnet.ibm.com Wed Jun 20 01:13:02 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 19 Jun 2018 22:13:02 -0300 Subject: RFC: Add new JCA provider to support hardware RNGs In-Reply-To: <993c258a-57ae-d29d-2368-faac5b4d3cb1@linux.vnet.ibm.com> References: <993c258a-57ae-d29d-2368-faac5b4d3cb1@linux.vnet.ibm.com> Message-ID: Sorry for resending it. I missed a few MLs. -- Hi, Please, could I get comments on the following change? Since it's related to security, I would be glad if security experts could also comment on that. webrev: http://cr.openjdk.java.net/~gromero/POWER9/darn/v6_rebased/ It introduces a way to get benefits from hardware instructions in userspace that can delivery a random number and so be used to speed up and avoid blocking in some SecureRandom methods, notably generateSeed() and nextBytes(), without loosing the random number quality. Particularly on Power, the new POWER9 CPUs introduced a hardware instruction called 'darn' that can be used for that purpose. The main idea is to add a new JCA provider called "HWTRNG" (if no better name is suggested), adding new helper methods that can then be intrinsified and that will be used by generateSeed() and nextBytes(). In that sense, this change also adds the proper mechanisms in the Interpreter, C1 Compiler, and C2 compiler (for PPC64, but also paving the way for other platforms) to intrinsify these helper methods that will be used in the end by generateSeed() and nextBytes() methods. The added helpers are: byte[] getRandomSequence0(int) byte[] getRandomSequence1(byte[]) long validRandomLong(void) long randomLong(void) The helpers also take care of checking if the returned random number is valid and attempt 10 times (as recommended by ISA) get a valid random number before falling back to a software alternative (HWTRNG is based mostly on JCA provider NativePRNG and so the fall back mechanism will use the exactly same methods found in NativePRNG and hence behave similarly. Nonetheless, in my experience such a hardware failures (which are the main cause of a returned invalid random number) are quite rare: in my tests I was never able to exhaust the HW RNG and force it to generate an invalid random number). The user, besides having to specify explicitly the use of a non-default provider (HWTRNG), will have to unlock the VM experimental options to effectively use the hardware RNG as an unique random source by passing options "-XX:+UnlockExperimentalVMOptions -XX:+UseRANDOMIntrinsics". On Power, for the Interpreter and C1 Compiler, besides avoiding the blocking effect of a low entropy on /dev/random, I was able to get about 126 Mbps (3x higher than the version without 'darn') on generaSeed() and nextBytes(). The maximum theoretical value on a POWER9 machine is usually 128 Mbps. I'll address the details about the file headers (Copyright, dates, authors, versions, etc) after I get some feedback about this change. Thanks in advance. Best regards, Gustavo From valerie.peng at oracle.com Wed Jun 20 02:07:43 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 19 Jun 2018 19:07:43 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> Message-ID: <9eb9e4b0-eb9b-80bf-d1b2-90e97ad9a408@oracle.com> Hi Xuelei, These look fine. - kind of strange to see SSLKeyAgreement extends SSLKeyAgreementGenerator... Normally, the naming convention implies one generates the other. - same method name as in SSLKeyDerivationGenerator. I assume that this is intentional as both are meant to derive keys, but with different parameters? Still have a few more left to review. Valerie On 5/25/2018 4:45 PM, Xuelei Fan wrote: > Hi, > > I'd like to invite you to review the TLS 1.3 implementation.? I > appreciate it if I could have compatibility and specification feedback > before May 31, 2018, and implementation feedback before June 7, 2018. > > Here is the webrev: > ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > The formal TLS 1.3 specification is not finalized yet, although it had > been approved to be a standard.? The implementation is based on the > draft version 28: > ??? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 > > For the overall description of this enhancement, please refer to JEP 332: > ??? http://openjdk.java.net/jeps/332 > > For the compatibility and specification update, please refer to CSR > 8202625: > ??? https://bugs.openjdk.java.net/browse/JDK-8202625 > > Note that we are using the sandbox for the development right now. For > more information, please refer to Bradford's previous email: > > http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html > > Thanks & Regards, > Xuelei From xuelei.fan at oracle.com Wed Jun 20 16:44:00 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 20 Jun 2018 09:44:00 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <51930350-b432-df63-3e2d-152c017421dc@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <51930350-b432-df63-3e2d-152c017421dc@oracle.com> Message-ID: <8faa62dd-c577-d881-4982-283ece94d992@oracle.com> Update: http://hg.openjdk.java.net/jdk/sandbox/rev/1cc2f6afa943 On 6/19/2018 12:19 PM, Valerie Peng wrote: > Hi Xuelei, > > Just questions and some nits. > > > looks good > > > looks good > > > - line 98: for unsupported digest, maybe we should consider throw > exceptions. It's easier to find out where the support needs to be added > if we fail early. > Good point! > > - Just wondering why we need difference classes of > SecretKeyDerivationGenerator (i.e. > S30/T10/T12MaterSecretKeyDerivationGenerator instances), it seems that > they all use LegacyMasterKeyDerivation class. The enum already has name > which indicates the protocol version, is the SSLKeyDerivationGenerator > passed around by itself and you are using its class to find out the > protocol version? Or, is there other reason for this? > It was designed to use the new key derivation APIs. It looks unusual now as there is no key derivation APIs yet. Updated by removing the S30/T10/T12MaterSecretKeyDerivationGenerator classes. > > - line 71: add a default to catch the unsupported ProtocolVersion case? The default case is considered in the final "return null" clause. > - line 319: check params or assert params to be null? I assume it'll be > null as it seems to be not used. The caller might use non-null params, potentially. I would like to ignore the params and checking, as if it is not used in this implementation. Thanks, Xuelei > > Thanks, > Valerie > > On 5/25/2018 4:45 PM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 implementation.? I >> appreciate it if I could have compatibility and specification feedback >> before May 31, 2018, and implementation feedback before June 7, 2018. >> >> Here is the webrev: >> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> The formal TLS 1.3 specification is not finalized yet, although it had >> been approved to be a standard.? The implementation is based on the >> draft version 28: >> ??? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >> >> For the overall description of this enhancement, please refer to JEP 332: >> ??? http://openjdk.java.net/jeps/332 >> >> For the compatibility and specification update, please refer to CSR >> 8202625: >> ??? https://bugs.openjdk.java.net/browse/JDK-8202625 >> >> Note that we are using the sandbox for the development right now. For >> more information, please refer to Bradford's previous email: >> >> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >> >> Thanks & Regards, >> Xuelei > From xuelei.fan at oracle.com Wed Jun 20 16:58:12 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 20 Jun 2018 09:58:12 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <9eb9e4b0-eb9b-80bf-d1b2-90e97ad9a408@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <9eb9e4b0-eb9b-80bf-d1b2-90e97ad9a408@oracle.com> Message-ID: On 6/19/2018 7:07 PM, Valerie Peng wrote: > Hi Xuelei, > > > > > > > > These look fine. > > > - kind of strange to see SSLKeyAgreement extends > SSLKeyAgreementGenerator... Normally, the naming convention implies one > generates the other. > The name should be more like SSLKeyAgreementKeyDerivationGenerator. It is too long, so I used a short one, SSLKeyAgreementGenerator. But yes, it is confusing. Maybe, SSLKAKDGenerator? > > > - same method name as in SSLKeyDerivationGenerator. I assume that this > is intentional as both are meant to derive keys, but with different > parameters? > Yes. SSLKeyAgreementGenerator is used for key agreement key generation for public keys (DHE/ECDHE/RSA). While SSLKeyDerivationGenerator is used for secret key derivation with shared secrets (with an additional 'secretKey' parameter). Two classes are defined just in case the two different functions are mixed. Xuelei > Still have a few more left to review. > Valerie > > On 5/25/2018 4:45 PM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 implementation.? I >> appreciate it if I could have compatibility and specification feedback >> before May 31, 2018, and implementation feedback before June 7, 2018. >> >> Here is the webrev: >> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> The formal TLS 1.3 specification is not finalized yet, although it had >> been approved to be a standard.? The implementation is based on the >> draft version 28: >> ??? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >> >> For the overall description of this enhancement, please refer to JEP 332: >> ??? http://openjdk.java.net/jeps/332 >> >> For the compatibility and specification update, please refer to CSR >> 8202625: >> ??? https://bugs.openjdk.java.net/browse/JDK-8202625 >> >> Note that we are using the sandbox for the development right now. For >> more information, please refer to Bradford's previous email: >> >> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >> >> Thanks & Regards, >> Xuelei > From ecki at zusammenkunft.net Wed Jun 20 20:05:55 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 20 Jun 2018 20:05:55 +0000 Subject: RFC: Add new JCA provider to support hardware RNGs In-Reply-To: <993c258a-57ae-d29d-2368-faac5b4d3cb1@linux.vnet.ibm.com> References: <993c258a-57ae-d29d-2368-faac5b4d3cb1@linux.vnet.ibm.com> Message-ID: Just a FYI under Linux when you read from urandom the Linux kernel will always XOR with random bytes generated with x64 rdrand instruction (arch_get_random_lomg() - if supported). Since it is a XOR it does not have to trust the quality of this black box hardware implementation. I would not implement a generator which does not have its own software whitening. (And most likely there is no need for one different than urandom on Linux). If you do implement whitening I would use a DRBG construction and no longer use a (low state) SHA1PRNG. Gruss Bernd Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: core-libs-dev on behalf of Gustavo Romero Sent: Wednesday, June 20, 2018 2:59:47 AM To: core-libs-dev; security-dev Cc: vladimir.kozlov at oracle.com; Doerr, Martin Subject: RFC: Add new JCA provider to support hardware RNGs Hi, Please, could I get comments on the following change? Since it's related to security, I would be glad if security experts could also comment on that. webrev: http://cr.openjdk.java.net/~gromero/POWER9/darn/v6_rebased/ It introduces a way to get benefits from hardware instructions in userspace that can delivery a random number and so be used to speed up and avoid blocking in some SecureRandom methods, notably generateSeed() and nextBytes(), without loosing the random number quality. Particularly on Power, the new POWER9 CPUs introduced a hardware instruction called 'darn' that can be used for that purpose. The main idea is to add a new JCA provider called "HWTRNG" (if no better name is suggested), adding new helper methods that can then be intrinsified and that will be used by generateSeed() and nextBytes(). In that sense, this change also adds the proper mechanisms in the Interpreter, C1 Compiler, and C2 compiler (for PPC64, but also paving the way for other platforms) to intrinsify these helper methods that will be used in the end by generateSeed() and nextBytes() methods. The added helpers are: byte[] getRandomSequence0(int) byte[] getRandomSequence1(byte[]) long validRandomLong(void) long randomLong(void) The helpers also take care of checking if the returned random number is valid and attempt 10 times (as recommended by ISA) get a valid random number before falling back to a software alternative (HWTRNG is based mostly on JCA provider NativePRNG and so the fall back mechanism will use the exactly same methods found in NativePRNG and hence behave similarly. Nonetheless, in my experience such a hardware failures (which are the main cause of a returned invalid random number) are quite rare: in my tests I was never able to exhaust the HW RNG and force it to generate an invalid random number). The user, besides having to specify explicitly the use of a non-default provider (HWTRNG), will have to unlock the VM experimental options to effectively use the hardware RNG as an unique random source by passing options "-XX:+UnlockExperimentalVMOptions -XX:+UseRANDOMIntrinsics". On Power, for the Interpreter and C1 Compiler, besides avoiding the blocking effect of a low entropy on /dev/random, I was able to get about 126 Mbps (3x higher than the version without 'darn') on generaSeed() and nextBytes(). The maximum theoretical value on a POWER9 machine is usually 128 Mbps. I'll address the details about the file headers (Copyright, dates, authors, versions, etc) after I get some feedback about this change. Thanks in advance. Best regards, Gustavo -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradford.wetmore at oracle.com Wed Jun 20 22:29:35 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 20 Jun 2018 15:29:35 -0700 Subject: RFR [11] CSR for "Add Brainpool ECC support (RFC 5639)" In-Reply-To: <6b785a17-2258-cb61-0103-e5a9ff828e1e@oracle.com> References: <6b785a17-2258-cb61-0103-e5a9ff828e1e@oracle.com> Message-ID: <50fd19d7-8355-f224-5e67-f9e6778bf1fc@oracle.com> I see you left out the smaller curves (160/192/224). The discussion between Adam/Tobias varied between leaving them out and including, I'm guessing there was no compelling reason to include? Brad On 6/15/2018 1:08 PM, Valerie Peng wrote: > Hi > > Can someone help reviewing the CSR for Adding Brainpool ECC support? > > https://bugs.openjdk.java.net/browse/JDK-8204836 > > Thanks, > > Valerie > From weijun.wang at oracle.com Wed Jun 20 22:49:49 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 21 Jun 2018 06:49:49 +0800 Subject: RFR CSR 8205446: Add RSASSA-PSS Signature support to SunMSCAPI Message-ID: Please review the CSR at https://bugs.openjdk.java.net/browse/JDK-8205446. With RSASSA-PSS on Windows, TLS 1.3 is not complete. Thanks Max From valerie.peng at oracle.com Wed Jun 20 22:51:49 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 20 Jun 2018 15:51:49 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <9eb9e4b0-eb9b-80bf-d1b2-90e97ad9a408@oracle.com> Message-ID: <725bb17b-adcf-bc71-0b09-bca8c916bc7b@oracle.com> On 6/20/2018 9:58 AM, Xuelei Fan wrote: > On 6/19/2018 7:07 PM, Valerie Peng wrote: >> Hi Xuelei, >> >> >> >> >> >> >> >> >> These look fine. >> >> >> - kind of strange to see SSLKeyAgreement extends >> SSLKeyAgreementGenerator... Normally, the naming convention implies >> one generates the other. >> > The name should be more like SSLKeyAgreementKeyDerivationGenerator.? > It is too long, so I used a short one, SSLKeyAgreementGenerator.? But > yes, it is confusing. Maybe, SSLKAKDGenerator? I am not too good at naming either. Given the complexity of TLS implementation, maybe we don't concatenate KeyAgreementKeyDerivation, but just use a new term like KeyNegotiation or KeyExchange? Just food for thought. Thanks, Valerie > >> >> >> - same method name as in SSLKeyDerivationGenerator. I assume that >> this is intentional as both are meant to derive keys, but with >> different parameters? >> > Yes.? SSLKeyAgreementGenerator is used for key agreement key > generation for public keys (DHE/ECDHE/RSA).? While > SSLKeyDerivationGenerator is used for secret key derivation with > shared secrets (with an additional 'secretKey' parameter).? Two > classes are defined just in case the two different functions are mixed. > > Xuelei > >> Still have a few more left to review. >> Valerie >> >> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>> Hi, >>> >>> I'd like to invite you to review the TLS 1.3 implementation. I >>> appreciate it if I could have compatibility and specification >>> feedback before May 31, 2018, and implementation feedback before >>> June 7, 2018. >>> >>> Here is the webrev: >>> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>> >>> The formal TLS 1.3 specification is not finalized yet, although it >>> had been approved to be a standard.? The implementation is based on >>> the draft version 28: >>> ??? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>> >>> For the overall description of this enhancement, please refer to JEP >>> 332: >>> ??? http://openjdk.java.net/jeps/332 >>> >>> For the compatibility and specification update, please refer to CSR >>> 8202625: >>> ??? https://bugs.openjdk.java.net/browse/JDK-8202625 >>> >>> Note that we are using the sandbox for the development right now. >>> For more information, please refer to Bradford's previous email: >>> >>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>> >>> >>> Thanks & Regards, >>> Xuelei >> From valerie.peng at oracle.com Wed Jun 20 22:54:20 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 20 Jun 2018 15:54:20 -0700 Subject: RFR [11] CSR for "Add Brainpool ECC support (RFC 5639)" In-Reply-To: <50fd19d7-8355-f224-5e67-f9e6778bf1fc@oracle.com> References: <6b785a17-2258-cb61-0103-e5a9ff828e1e@oracle.com> <50fd19d7-8355-f224-5e67-f9e6778bf1fc@oracle.com> Message-ID: <4d9b1fd1-552a-be42-0ea1-a7b36bbba411@oracle.com> Yes, I suppose so. I'd also incline to leave out the smaller curves. Basing on the latest patch from Tobias, it does not have the 160/192/224 curves.Valerie On 6/20/2018 3:29 PM, Bradford Wetmore wrote: > I see you left out the smaller curves (160/192/224).? The discussion > between Adam/Tobias varied between leaving them out and including, I'm > guessing there was no compelling reason to include? > > Brad > > > On 6/15/2018 1:08 PM, Valerie Peng wrote: >> Hi >> >> Can someone help reviewing the CSR for Adding Brainpool ECC support? >> >> https://bugs.openjdk.java.net/browse/JDK-8204836 >> >> Thanks, >> >> Valerie >> From weijun.wang at oracle.com Wed Jun 20 22:56:21 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 21 Jun 2018 06:56:21 +0800 Subject: RFR CSR 8205446: Add RSASSA-PSS Signature support to SunMSCAPI In-Reply-To: References: Message-ID: <41F8B3EF-D3F5-4496-A390-3CCED9937077@oracle.com> Oops, I meant "without it TLS 1.3 is not complete". > On Jun 21, 2018, at 6:49 AM, Weijun Wang wrote: > > Please review the CSR at https://bugs.openjdk.java.net/browse/JDK-8205446. With RSASSA-PSS on Windows, TLS 1.3 is not complete. > > Thanks > Max > From bradford.wetmore at oracle.com Wed Jun 20 22:56:44 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 20 Jun 2018 15:56:44 -0700 Subject: RFR CSR 8205446: Add RSASSA-PSS Signature support to SunMSCAPI In-Reply-To: References: Message-ID: <25584fe6-f62a-8952-71ef-bafc6f5d7d5c@oracle.com> On 6/20/2018 3:49 PM, Weijun Wang wrote: > Please review the CSR at > https://bugs.openjdk.java.net/browse/JDK-8205446. > With RSASSA-PSS on Windows, TLS 1.3 is not complete. In JDK-8205445, do you want to updated to include v2.2 as well like you did in the CSR? JDK-8205446: stored inside Windows keystore -> stored inside a native Windows keystore In the Specification, you should point to a 10 docset, or better yet 11 if it's available. Reviewed. Brad From weijun.wang at oracle.com Wed Jun 20 23:01:54 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 21 Jun 2018 07:01:54 +0800 Subject: RFR CSR 8205446: Add RSASSA-PSS Signature support to SunMSCAPI In-Reply-To: <25584fe6-f62a-8952-71ef-bafc6f5d7d5c@oracle.com> References: <25584fe6-f62a-8952-71ef-bafc6f5d7d5c@oracle.com> Message-ID: <9C2A3E76-128F-4A0E-8C28-4C76F24C90FB@oracle.com> All done. I cannot find a JDK 11 docset and I updated it to 10. Thanks Max > On Jun 21, 2018, at 6:56 AM, Bradford Wetmore wrote: > > > > On 6/20/2018 3:49 PM, Weijun Wang wrote: > > Please review the CSR at > > https://bugs.openjdk.java.net/browse/JDK-8205446. > > Without RSASSA-PSS on Windows, TLS 1.3 is not complete. > > In JDK-8205445, do you want to updated to include v2.2 as well like you did in the CSR? > > JDK-8205446: > stored inside Windows keystore > -> > stored inside a native Windows keystore > > In the Specification, you should point to a 10 docset, or better yet 11 if it's available. > > Reviewed. > > Brad From valerie.peng at oracle.com Wed Jun 20 23:06:41 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 20 Jun 2018 16:06:41 -0700 Subject: RFR [11] CSR for "Add Brainpool ECC support (RFC 5639)" In-Reply-To: <5b28158a.1c69fb81.da9dc.2500@mx.google.com> References: <5b28158a.1c69fb81.da9dc.2500@mx.google.com> Message-ID: <46ebf4bd-ba09-657b-3c88-c884400edc36@oracle.com> Are you asking about CSR or existing bug for including Brainpool support in TLS? I saw some bugs which mentions errors/exceptions which brainpool is used, e.g. JSSE has https://bugs.openjdk.java.net/browse/JDK-7189107, key tool has https://bugs.openjdk.java.net/browse/JDK-8201290. After this brainpool support is integrated, it'll be easier to re-evaluate these. As for PKCS11, Tobias tested this against a 3rd party PKCS11 library and the result is positive if I recall correctly. Thanks, Valerie On 6/18/2018 1:26 PM, Bernd Eckenfels wrote: > > Hello, > > not a Reviewer, but some Questions on the CSR: > > * Are there other CSRs for including in TLS? > * I also wonder if PKI (CA Signatures) will work out of the box then > (OID aliases?) > * Does PKCS11 require additional changes? (especially for the > Government use mentioned in the justification HSMs are often > mandatory) > > Gruss > > Bernd > > -- > http://bernd.eckenfels.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Thu Jun 21 01:15:26 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 20 Jun 2018 18:15:26 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> Message-ID: <3d00cae7-fec3-6542-5d21-cd4857358923@oracle.com> Hi Xuelei, - line 2, why is the copyright year changed from 2015 only to 2003 and 2018? Don't we normally preserve the first year and only update/add the second year? - line 110, instead of erroring out, I wonder if it's better to call createPossessions(handshakeContext) and only error out if the result is more than one. - line 421 and 464, RSA is left out for these two cases, is this asymmetry (comparing to line 381 and 494) intentional? - line 2, for a new file, shouldn't there be only one year, i.e. 2018? - line 219, is this INSTANCE really used? I did a quick search and didn't find reference to it. - line 309, why is EC mentioned here? Typo perhaps? - line 2, for a new file, shouldn't there be only one year, i.e. 2018? - line 89, typo: "producing" should be "consuming" - line 107, typo: "not" should be "no" Thanks, Valerie On 5/25/2018 4:45 PM, Xuelei Fan wrote: > Hi, > > I'd like to invite you to review the TLS 1.3 implementation.? I > appreciate it if I could have compatibility and specification feedback > before May 31, 2018, and implementation feedback before June 7, 2018. > > Here is the webrev: > ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > The formal TLS 1.3 specification is not finalized yet, although it had > been approved to be a standard.? The implementation is based on the > draft version 28: > ??? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 > > For the overall description of this enhancement, please refer to JEP 332: > ??? http://openjdk.java.net/jeps/332 > > For the compatibility and specification update, please refer to CSR > 8202625: > ??? https://bugs.openjdk.java.net/browse/JDK-8202625 > > Note that we are using the sandbox for the development right now. For > more information, please refer to Bradford's previous email: > > http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html > > Thanks & Regards, > Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From sibabrata.sahoo at oracle.com Thu Jun 21 06:58:17 2018 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Wed, 20 Jun 2018 23:58:17 -0700 (PDT) Subject: [11] RFR: JDK-8205111: Develop new Test to verify different key types for supported TLS protocols. Message-ID: <528299c6-d5a1-4564-9dd7-7f0e1b8a7c89@default> Hi Xuelei, Please review the patch for, JBS: https://bugs.openjdk.java.net/browse/JDK-8205111 Webrev: http://cr.openjdk.java.net/~ssahoo/8205111/webrev.00/ Change: This Test file verifies all TLS protocols with the supported keytypes. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From sha.jiang at oracle.com Thu Jun 21 09:17:09 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Thu, 21 Jun 2018 17:17:09 +0800 Subject: [11] RFR: JDK-8205111: Develop new Test to verify different key types for supported TLS protocols. In-Reply-To: <528299c6-d5a1-4564-9dd7-7f0e1b8a7c89@default> References: <528299c6-d5a1-4564-9dd7-7f0e1b8a7c89@default> Message-ID: <909797c3-2221-0917-a706-c530cb64d962@oracle.com> Hi Siba, ?165???????? System.setProperty("jdk.tls13.version", "7F1C"); This property may be unnecessary. JSSE server and client just use the same TLS 1.3 version number, regardless of what the number is. ?322???????? KeyStore ts = KeyStore.getInstance("JKS"); ?323???????? KeyStore ks = KeyStore.getInstance("JKS"); Would it be better to use PKCS12? ?424???????????? // EC private key related to cert endEntityCertStrs[0]. ?451???????????? // EC private key related to cert endEntityCertStrs[0]. ?489???????????? // RSA private key related to cert endEntityCertStrs[0]. ?581???????????? // RSA private key related to cert endEntityCertStrs[0]. ?... What's the mean of these comments? ?220???????? void doServerSide() throws Exception ?288???????? void doClientSide() throws Exception Could you apply try-with-resources to sslServerSocket and sslSocket in the above two methods? ?157???? private volatile static boolean clientRenegoReady = false; ?... ?246???????????????????? while (!clientRenegoReady) { ?247???????????????????????? System.out.println("Waiting for ClientHello"); ?248???????????????????????? Thread.sleep(50); ?249???????????????????? } Why does clientRenegoReady exist? I don't see the value of clientRenegoReady is changed. Because clientRenegoReady always is false, so "while (!clientRenegoReady)" should be as the same as "while(true)". And, what's the purpose of this while block? I assume you want to make sure that server doesn't exit before the second handshaking finishes. If true, in practice, do you get the case: Before client side socket I/O closes, server already exits? In addition, why not building case combinations in the codes? It would not be easy to maintain so many hard-coded combinations in @run lines. And generally, this style may increase gross test execution time. Best regards, John Jiang On 21/06/2018 14:58, Sibabrata Sahoo wrote: > > Hi Xuelei, > > Please review the patch for, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8205111 > > Webrev: http://cr.openjdk.java.net/~ssahoo/8205111/webrev.00/ > > > Change: > > This Test file verifies all TLS protocols with the supported keytypes. > > Thanks, > > Siba > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Jun 21 11:12:53 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 21 Jun 2018 19:12:53 +0800 Subject: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI Message-ID: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com> Please take a review on this change http://cr.openjdk.java.net/~weijun/8205445/webrev.00/ and the release note at https://bugs.openjdk.java.net/browse/JDK-8205471 The code change adds RSASSA-PSS signature support to the SunMSCAPI provider. Several notes: 1. CryptoAPI (which SunMSCAPI is based on and now a deprecated technology) does not support RSASSA-PSS. In fact, CNG [1] is used to perform the signing and verification. This is certainly not a perfect solution and we are thinking of support CNG in a more sophisticated way in future releases of JDK. 2. For unknown reason, the newly added verification code for RSASSA-PSS does not work correctly (precisely, ::NCryptTranslateHandle returns NTE_INVALID_PARAMETER). A fallback mechanism is added into mscapi/RSASignature.java. A SunRsaSign Signature object is actually used when a SunMSCAPI Signature is initialized to verify an RSASSA-PSS signature. 3. It looks like CNG only supports PSSParamterSpec with the same message hash algorithm and MGF1 hash algorithm, because there is only one algorithm field in BCRYPT_PSS_PADDING_INFO [2]. This is checked when setting the parameter. 4. It looks like CNG only supports RSASSA-PSS using these hash algorithms: SHA-1, SHA-256, SHA-384, and SHA-512. This is not checked at parameter setting but sign() will throw a SignatureException saying "Unrecognised hash algorithm". Since the verify() side uses a fallback SunRsaSign signature, other hash algorithms are supported. Thanks Max [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375529(v=vs.85).aspx [3] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx From xuelei.fan at oracle.com Thu Jun 21 13:58:06 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 21 Jun 2018 06:58:06 -0700 Subject: [11] RFR: JDK-8205111: Develop new Test to verify different key types for supported TLS protocols. In-Reply-To: <528299c6-d5a1-4564-9dd7-7f0e1b8a7c89@default> References: <528299c6-d5a1-4564-9dd7-7f0e1b8a7c89@default> Message-ID: <9dc623cc-67bd-32ec-d657-008cab3200a1@oracle.com> Note that rsa_pss_pss cannot work with TLS_RSA_WITH cipher suites, as this algorithm is limited to signature whiel TLS_RSA cipher suites need key encipherment. In lines 135-156, you can replace the TLS_RSA cipher suite with DHE or ECDHE_RSA. For the re-handshake part, please read/write something after the call to startHandshake() in each side. Otherwise, the key-update and session resumption may not complete before socket close. Otherwise, looks fine to me. Thanks, Xuelei On 6/20/2018 11:58 PM, Sibabrata Sahoo wrote: > Hi Xuelei, > > Please review the patch for, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8205111 > > Webrev: http://cr.openjdk.java.net/~ssahoo/8205111/webrev.00/ > > Change: > > This Test file verifies all TLS protocols with the supported keytypes. > > Thanks, > > Siba > From weijun.wang at oracle.com Thu Jun 21 14:31:20 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 21 Jun 2018 22:31:20 +0800 Subject: RFR 8201815: Use Mozilla Public Suffix List In-Reply-To: References: <35BB388A-D2BA-4936-827F-B211E379A2DF@oracle.com> <539c8303-a2b4-d217-6817-d28925cd0e27@oracle.com> <0ED42EC2-C0E2-4DFB-BD63-0BB5C121FA85@oracle.com> <61048D27-07DB-4283-82E6-B7909296171F@oracle.com> <792D6BE1-1563-4953-BE5D-F60905D39483@oracle.com> <550260ec-9470-4f88-e1a0-05ee1ef62a4f@oracle.com> Message-ID: <215F0E29-1C04-43EB-894D-152A17A9993C@oracle.com> Ping again. I still need code review for the other changes. The latest webrev is at http://cr.openjdk.java.net/~weijun/8201815/webrev.01 The only change since webrev.00 is in GendataPublicSuffixList.gmk. Thanks Max > On May 24, 2018, at 8:47 PM, Magnus Ihse Bursie wrote: > > On 2018-05-24 06:52, Weijun Wang wrote: >> Good. It's now simply >> >> $(GENDATA_PUBLICSUFFIXLIST): $(GENDATA_PUBLICSUFFIXLIST_SRC) $(BUILD_TOOLS) >> $(call LogInfo, Generating public suffix list) >> $(call MakeDir, $(@D)) >> $(RM) $@ >> $(TOOL_PUBLICSUFFIXLIST) $< $@ >> $(CHMOD) 444 $@ >> >> Thanks >> Max > Great! Looks good to me now. > > I've forgotten that we started using .DELETE_ON_ERROR. Thanks for reminding me Erik. :) > > /Magnus > >> >>> On May 24, 2018, at 12:30 AM, Erik Joelsson wrote: >>> >>> On 2018-05-23 03:54, Magnus Ihse Bursie wrote: >>>> mv should not modify attributes. cp will, but mv should not. >>>> >>>> Your solution might fail in the (admittedly unlikely) case that the build is interrupted before the chmod but after the mv. In that case, an incremental rebuild will not see that anything is missing. >>>> >>>> I believe the other cases that you quote are also incorrect. >>>> >>>> But I'd like to hear Erik's input on this as well. >>> We have the pseudo target .DELETE_ON_ERROR defined globally (in MakeBase.gmk) which causes make to delete the target of any failed or interrupted recipe. This should actually remove any need for using .tmp files and mv on the last line. We still have a lot of those constructs around since forever though. The recipe copied here (and the two other examples) are based on a template from very early build-infra makefile history and do not represent current best practices. If anything I would recommend getting rid of the .tmp and mv completely, but if you prefer both belt and suspenders, putting the move last should be the correct construct. >>> >>> /Erik >>>> /Magnus >>>> >>>>> 23 maj 2018 kl. 02:01 skrev Weijun Wang : >>>>> >>>>> >>>>> >>>>>> On May 23, 2018, at 4:21 AM, Magnus Ihse Bursie wrote: >>>>>> >>>>>> ... but you should switch order on the chmod and the mv in the new gensrc file, so the mv comes last. >>>>> I thought it's safer to call CHMOD last so MV won't change file mode back. (I'm not saying it will, just afraid.) >>>>> >>>>> In below cases, CHMOD is called after MV/CP. >>>>> >>>>> gendata/Gendata-java.base.gmk >>>>> 59- $(MV) $@.tmp $@ >>>>> 60: $(CHMOD) 444 $@ >>>>> 61- >>>>> >>>>> common/JavaCompilation.gmk >>>>> 80- $(CP) $$< $$@ >>>>> 81: $(CHMOD) -f ug+w $$@ >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>>> /Magnus >>>>>> >>>>>>> 22 maj 2018 kl. 17:44 skrev Erik Joelsson : >>>>>>> >>>>>>> Build changes look ok. >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> >>>>>>>> On 2018-05-22 08:25, Weijun Wang wrote: >>>>>>>> Please take a review at >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~weijun/8201815/webrev.00/ >>>>>>>> >>>>>>>> With this change, We switch from a home-grown public suffix list (implemented in sun/net/RegisteredDomain.java) to Mozilla's PSL. The PSL data was re-encoded as a zip file with entries for different TLDs. >>>>>>>> >>>>>>>> There is no plan to update the data in a different channel other than a JDK release. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max > From xuelei.fan at oracle.com Thu Jun 21 15:07:06 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 21 Jun 2018 08:07:06 -0700 Subject: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI In-Reply-To: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com> References: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com> Message-ID: <7ad6e500-57c8-2a45-838e-a0ff75d03fd8@oracle.com> Hi Weijun, The release note and the following notes look reasonable to me. For the implementation part, could it be a little bit more straightforward if wrapping the new attributes (pss/pssParams/fallbackSignature) and codes (if pss/fallbackSignature, etc) in the PSS subclass? Did you want to remove the debug code in the security.cpp? It seems that they are not used any more. Xuelei On 6/21/2018 4:12 AM, Weijun Wang wrote: > Please take a review on this change > > http://cr.openjdk.java.net/~weijun/8205445/webrev.00/ > > and the release note at > > https://bugs.openjdk.java.net/browse/JDK-8205471 > > The code change adds RSASSA-PSS signature support to the SunMSCAPI provider. > > Several notes: > > 1. CryptoAPI (which SunMSCAPI is based on and now a deprecated technology) does not support RSASSA-PSS. In fact, CNG [1] is used to perform the signing and verification. This is certainly not a perfect solution and we are thinking of support CNG in a more sophisticated way in future releases of JDK. > > 2. For unknown reason, the newly added verification code for RSASSA-PSS does not work correctly (precisely, ::NCryptTranslateHandle returns NTE_INVALID_PARAMETER). A fallback mechanism is added into mscapi/RSASignature.java. A SunRsaSign Signature object is actually used when a SunMSCAPI Signature is initialized to verify an RSASSA-PSS signature. > > 3. It looks like CNG only supports PSSParamterSpec with the same message hash algorithm and MGF1 hash algorithm, because there is only one algorithm field in BCRYPT_PSS_PADDING_INFO [2]. This is checked when setting the parameter. > > 4. It looks like CNG only supports RSASSA-PSS using these hash algorithms: SHA-1, SHA-256, SHA-384, and SHA-512. This is not checked at parameter setting but sign() will throw a SignatureException saying "Unrecognised hash algorithm". Since the verify() side uses a fallback SunRsaSign signature, other hash algorithms are supported. > > Thanks > Max > > [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx > [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375529(v=vs.85).aspx > [3] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx > From weijun.wang at oracle.com Thu Jun 21 15:23:21 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 21 Jun 2018 23:23:21 +0800 Subject: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI In-Reply-To: <7ad6e500-57c8-2a45-838e-a0ff75d03fd8@oracle.com> References: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com> <7ad6e500-57c8-2a45-838e-a0ff75d03fd8@oracle.com> Message-ID: <40781CC8-0D81-4182-B070-3122AD9E88FE@oracle.com> > On Jun 21, 2018, at 11:07 PM, Xuelei Fan wrote: > > Hi Weijun, > > The release note and the following notes look reasonable to me. > > For the implementation part, could it be a little bit more straightforward if wrapping the new attributes (pss/pssParams/fallbackSignature) and codes (if pss/fallbackSignature, etc) in the PSS subclass? Sounds good. I'll try it. > > Did you want to remove the debug code in the security.cpp? It seems that they are not used any more. Sure I can. Thanks Max > > Xuelei > > On 6/21/2018 4:12 AM, Weijun Wang wrote: >> Please take a review on this change >> http://cr.openjdk.java.net/~weijun/8205445/webrev.00/ >> and the release note at >> https://bugs.openjdk.java.net/browse/JDK-8205471 >> The code change adds RSASSA-PSS signature support to the SunMSCAPI provider. >> Several notes: >> 1. CryptoAPI (which SunMSCAPI is based on and now a deprecated technology) does not support RSASSA-PSS. In fact, CNG [1] is used to perform the signing and verification. This is certainly not a perfect solution and we are thinking of support CNG in a more sophisticated way in future releases of JDK. >> 2. For unknown reason, the newly added verification code for RSASSA-PSS does not work correctly (precisely, ::NCryptTranslateHandle returns NTE_INVALID_PARAMETER). A fallback mechanism is added into mscapi/RSASignature.java. A SunRsaSign Signature object is actually used when a SunMSCAPI Signature is initialized to verify an RSASSA-PSS signature. >> 3. It looks like CNG only supports PSSParamterSpec with the same message hash algorithm and MGF1 hash algorithm, because there is only one algorithm field in BCRYPT_PSS_PADDING_INFO [2]. This is checked when setting the parameter. >> 4. It looks like CNG only supports RSASSA-PSS using these hash algorithms: SHA-1, SHA-256, SHA-384, and SHA-512. This is not checked at parameter setting but sign() will throw a SignatureException saying "Unrecognised hash algorithm". Since the verify() side uses a fallback SunRsaSign signature, other hash algorithms are supported. >> Thanks >> Max >> [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx >> [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375529(v=vs.85).aspx >> [3] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx From erik.joelsson at oracle.com Thu Jun 21 16:25:18 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 21 Jun 2018 09:25:18 -0700 Subject: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI In-Reply-To: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com> References: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com> Message-ID: <107535b7-5489-a2c9-0433-b25488fc42d3@oracle.com> Build change looks good. /Erik On 2018-06-21 04:12, Weijun Wang wrote: > Please take a review on this change > > http://cr.openjdk.java.net/~weijun/8205445/webrev.00/ > > and the release note at > > https://bugs.openjdk.java.net/browse/JDK-8205471 > > The code change adds RSASSA-PSS signature support to the SunMSCAPI provider. > > Several notes: > > 1. CryptoAPI (which SunMSCAPI is based on and now a deprecated technology) does not support RSASSA-PSS. In fact, CNG [1] is used to perform the signing and verification. This is certainly not a perfect solution and we are thinking of support CNG in a more sophisticated way in future releases of JDK. > > 2. For unknown reason, the newly added verification code for RSASSA-PSS does not work correctly (precisely, ::NCryptTranslateHandle returns NTE_INVALID_PARAMETER). A fallback mechanism is added into mscapi/RSASignature.java. A SunRsaSign Signature object is actually used when a SunMSCAPI Signature is initialized to verify an RSASSA-PSS signature. > > 3. It looks like CNG only supports PSSParamterSpec with the same message hash algorithm and MGF1 hash algorithm, because there is only one algorithm field in BCRYPT_PSS_PADDING_INFO [2]. This is checked when setting the parameter. > > 4. It looks like CNG only supports RSASSA-PSS using these hash algorithms: SHA-1, SHA-256, SHA-384, and SHA-512. This is not checked at parameter setting but sign() will throw a SignatureException saying "Unrecognised hash algorithm". Since the verify() side uses a fallback SunRsaSign signature, other hash algorithms are supported. > > Thanks > Max > > [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx > [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375529(v=vs.85).aspx > [3] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx > From valerie.peng at oracle.com Thu Jun 21 20:10:00 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 21 Jun 2018 13:10:00 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> Message-ID: <7ee1df99-65b1-40b6-142c-99e2d3e4bb6c@oracle.com> - line 175, the exception message seems not right, clientAlias is a private key entry with no cert chain stored. - line 56, instead of returning null, I wonder if we should throw exception to catch unsupported type early. That's all. Valerie On 5/25/2018 4:45 PM, Xuelei Fan wrote: > Hi, > > I'd like to invite you to review the TLS 1.3 implementation.? I > appreciate it if I could have compatibility and specification feedback > before May 31, 2018, and implementation feedback before June 7, 2018. > > Here is the webrev: > ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > The formal TLS 1.3 specification is not finalized yet, although it had > been approved to be a standard.? The implementation is based on the > draft version 28: > ??? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 > > For the overall description of this enhancement, please refer to JEP 332: > ??? http://openjdk.java.net/jeps/332 > > For the compatibility and specification update, please refer to CSR > 8202625: > ??? https://bugs.openjdk.java.net/browse/JDK-8202625 > > Note that we are using the sandbox for the development right now. For > more information, please refer to Bradford's previous email: > > http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html > > Thanks & Regards, > Xuelei From gromero at linux.vnet.ibm.com Thu Jun 21 21:37:34 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 21 Jun 2018 18:37:34 -0300 Subject: RFC: Add new JCA provider to support hardware RNGs In-Reply-To: References: <993c258a-57ae-d29d-2368-faac5b4d3cb1@linux.vnet.ibm.com> Message-ID: Hi Bernd, Thanks for your comments. On 06/20/2018 05:05 PM, Bernd Eckenfels wrote: > Just a FYI under Linux when you read from urandom the Linux kernel will always XOR with random bytes generated with x64 rdrand instruction (arch_get_random_lomg() - if supported). Since it is a XOR it does not have to trust the quality of this black box hardware implementation. Yes, I know to some extent how the use of rdrand on Intel by Linux generated debates in the past. > I would not implement a generator which does not have its own software whitening. (And most likely there is no need for one different than urandom on Linux). If you do implement whitening I would use a DRBG construction and no longer use a (low state) SHA1PRNG. My main concern to use 'darn' on Power was to get some additional speed and throughput on obtaining true random numbers (or on cases where /dev/random - which blocks - was preferred to /dev/urandom). That concern seems valid specially when the code is not JITed yet by the C2 compiler (so for Interpreted and C1 Compiler). Anyway, the idea to have a separated provider and that the use of the intrinsic is by no means enabled by default is to let the user to decide if he/she wants to use that kind of generator. I think OpenSSL disabled by default the use of rdrand similarly but let the user to enable it if desired? The idea of DRBG looks valid. I took SHA1PRNG as a fallback. But if DRBG would be used for whitening that would need a seed from /dev/urandom? (I'm trying to think the impact on performance here). Best regards, Gustavo > Gruss > Bernd > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ________________________________ > From: core-libs-dev on behalf of Gustavo Romero > Sent: Wednesday, June 20, 2018 2:59:47 AM > To: core-libs-dev; security-dev > Cc: vladimir.kozlov at oracle.com; Doerr, Martin > Subject: RFC: Add new JCA provider to support hardware RNGs > > Hi, > > Please, could I get comments on the following change? > > Since it's related to security, I would be glad if security > experts could also comment on that. > > webrev: http://cr.openjdk.java.net/~gromero/POWER9/darn/v6_rebased/ > > It introduces a way to get benefits from hardware instructions in userspace > that can delivery a random number and so be used to speed up and avoid > blocking in some SecureRandom methods, notably generateSeed() and > nextBytes(), without loosing the random number quality. Particularly on > Power, the new POWER9 CPUs introduced a hardware instruction called 'darn' > that can be used for that purpose. > > The main idea is to add a new JCA provider called "HWTRNG" (if no better > name is suggested), adding new helper methods that can then be intrinsified > and that will be used by generateSeed() and nextBytes(). In that sense, > this change also adds the proper mechanisms in the Interpreter, > C1 Compiler, and C2 compiler (for PPC64, but also paving the way for other > platforms) to intrinsify these helper methods that will be used in the end > by generateSeed() and nextBytes() methods. The added helpers are: > > byte[] getRandomSequence0(int) > byte[] getRandomSequence1(byte[]) > long validRandomLong(void) > long randomLong(void) > > The helpers also take care of checking if the returned random number is > valid and attempt 10 times (as recommended by ISA) get a valid random > number before falling back to a software alternative (HWTRNG is based > mostly on JCA provider NativePRNG and so the fall back mechanism will use > the exactly same methods found in NativePRNG and hence behave similarly. > Nonetheless, in my experience such a hardware failures (which are the main > cause of a returned invalid random number) are quite rare: in my tests I > was never able to exhaust the HW RNG and force it to generate an invalid > random number). > > The user, besides having to specify explicitly the use of a non-default > provider (HWTRNG), will have to unlock the VM experimental options to > effectively use the hardware RNG as an unique random source by passing > options "-XX:+UnlockExperimentalVMOptions -XX:+UseRANDOMIntrinsics". > > On Power, for the Interpreter and C1 Compiler, besides avoiding the > blocking effect of a low entropy on /dev/random, I was able to get about > 126 Mbps (3x higher than the version without 'darn') on generaSeed() and > nextBytes(). The maximum theoretical value on a POWER9 machine is usually > 128 Mbps. > > I'll address the details about the file headers (Copyright, dates, authors, > versions, etc) after I get some feedback about this change. > > > Thanks in advance. > > Best regards, > Gustavo > From xuelei.fan at oracle.com Fri Jun 22 04:30:09 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 21 Jun 2018 21:30:09 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <3d00cae7-fec3-6542-5d21-cd4857358923@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <3d00cae7-fec3-6542-5d21-cd4857358923@oracle.com> Message-ID: <51981c99-bb32-d51f-edb2-eb3e30ae2498@oracle.com> Update: http://hg.openjdk.java.net/jdk/sandbox/rev/76025c6c6e29 On 6/21/2018 1:10 PM, Valerie Peng wrote: > - line 175, the exception message seems not right, clientAlias is a > private key entry with no cert chain stored. Good catch! > - line 56, instead of returning null, I wonder if we should throw > exception to catch unsupported type early. The 'null' returned value is useful when the key type does not support X.509 authentication. It is a common case. Using return value may be more lightweight than using exception. On 6/20/2018 6:15 PM, Valerie Peng wrote: > Hi Xuelei, > > > - line 2, why is the copyright year changed from 2015 only to 2003 and > 2018? Don't we normally preserve the first year and only update/add the > second year? Update. > - line 110, instead of erroring out, I wonder if it's better to call > createPossessions(handshakeContext) and only error out if the result is > more than one. Good catch! The createPossessions(handshakeContext) is not used so it is not necessary to implement this interface any more. Removed this interface and the method. > - line 421 and 464, RSA is left out for these two cases, is this > asymmetry (comparing to line 381 and 494) intentional? > The block started from line 381 is asymmetry to line 494; line 412 to line 464. RSA is in the right block accordingly. > > - line 2, for a new file, shouldn't there be only one year, i.e. 2018? > - line 219, is this INSTANCE really used? I did a quick search and > didn't find reference to it. > - line 309, why is EC mentioned here? Typo perhaps? > All good catches! > > - line 2, for a new file, shouldn't there be only one year, i.e. 2018? > - line 89, typo: "producing" should be "consuming" > - line 107, typo: "not" should be "no" > Updated. Thanks, Xuelei > Thanks, > Valerie > > On 5/25/2018 4:45 PM, Xuelei Fan wrote: >> Hi, >> >> I'd like to invite you to review the TLS 1.3 implementation.? I >> appreciate it if I could have compatibility and specification feedback >> before May 31, 2018, and implementation feedback before June 7, 2018. >> >> Here is the webrev: >> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >> >> The formal TLS 1.3 specification is not finalized yet, although it had >> been approved to be a standard.? The implementation is based on the >> draft version 28: >> https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >> >> For the overall description of this enhancement, please refer to JEP 332: >> http://openjdk.java.net/jeps/332 >> >> For the compatibility and specification update, please refer to CSR >> 8202625: >> https://bugs.openjdk.java.net/browse/JDK-8202625 >> >> Note that we are using the sandbox for the development right now. For >> more information, please refer to Bradford's previous email: >> >> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >> >> Thanks & Regards, >> Xuelei > From weijun.wang at oracle.com Fri Jun 22 05:39:30 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 22 Jun 2018 13:39:30 +0800 Subject: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI In-Reply-To: <40781CC8-0D81-4182-B070-3122AD9E88FE@oracle.com> References: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com> <7ad6e500-57c8-2a45-838e-a0ff75d03fd8@oracle.com> <40781CC8-0D81-4182-B070-3122AD9E88FE@oracle.com> Message-ID: <6C5264A2-3651-4832-AA96-E6B9838CCC67@oracle.com> Webrev updated at http://cr.openjdk.java.net/~weijun/8205445/webrev.01 I think I found a bug in SunRsaSign of the RSASSA-PSS signature. Fixed and added a test. BTW, I commented out the debug code in security.cpp. Once there is a bug I can use it. Thanks Max > On Jun 21, 2018, at 11:23 PM, Weijun Wang wrote: > > > >> On Jun 21, 2018, at 11:07 PM, Xuelei Fan wrote: >> >> Hi Weijun, >> >> The release note and the following notes look reasonable to me. >> >> For the implementation part, could it be a little bit more straightforward if wrapping the new attributes (pss/pssParams/fallbackSignature) and codes (if pss/fallbackSignature, etc) in the PSS subclass? > > Sounds good. I'll try it. > >> >> Did you want to remove the debug code in the security.cpp? It seems that they are not used any more. > > Sure I can. > > Thanks > Max > >> >> Xuelei >> >> On 6/21/2018 4:12 AM, Weijun Wang wrote: >>> Please take a review on this change >>> http://cr.openjdk.java.net/~weijun/8205445/webrev.00/ >>> and the release note at >>> https://bugs.openjdk.java.net/browse/JDK-8205471 >>> The code change adds RSASSA-PSS signature support to the SunMSCAPI provider. >>> Several notes: >>> 1. CryptoAPI (which SunMSCAPI is based on and now a deprecated technology) does not support RSASSA-PSS. In fact, CNG [1] is used to perform the signing and verification. This is certainly not a perfect solution and we are thinking of support CNG in a more sophisticated way in future releases of JDK. >>> 2. For unknown reason, the newly added verification code for RSASSA-PSS does not work correctly (precisely, ::NCryptTranslateHandle returns NTE_INVALID_PARAMETER). A fallback mechanism is added into mscapi/RSASignature.java. A SunRsaSign Signature object is actually used when a SunMSCAPI Signature is initialized to verify an RSASSA-PSS signature. >>> 3. It looks like CNG only supports PSSParamterSpec with the same message hash algorithm and MGF1 hash algorithm, because there is only one algorithm field in BCRYPT_PSS_PADDING_INFO [2]. This is checked when setting the parameter. >>> 4. It looks like CNG only supports RSASSA-PSS using these hash algorithms: SHA-1, SHA-256, SHA-384, and SHA-512. This is not checked at parameter setting but sign() will throw a SignatureException saying "Unrecognised hash algorithm". Since the verify() side uses a fallback SunRsaSign signature, other hash algorithms are supported. >>> Thanks >>> Max >>> [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx >>> [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375529(v=vs.85).aspx >>> [3] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx > From dan.z.zhou at oracle.com Fri Jun 22 08:26:17 2018 From: dan.z.zhou at oracle.com (Dora Zhou) Date: Fri, 22 Jun 2018 16:26:17 +0800 Subject: [11]RFR 8194152: sun/security/tools/jarsigner/AltProvider.java failed on de-DE locale Message-ID: <09f92268-fe4d-3c57-0ffb-d93d9703974d@oracle.com> Hello, Please help review the fix for JDK-8194152. Thank you. The test compares output with expected error messages in English, set locale to en-US so that the output are not translated into other languages. Bug: https://bugs.openjdk.java.net/browse/JDK-8194152 Webrev: http://cr.openjdk.java.net/~ljiang/8194152/webrev/ Regards, Dora -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Fri Jun 22 13:22:27 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 22 Jun 2018 06:22:27 -0700 Subject: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI In-Reply-To: <6C5264A2-3651-4832-AA96-E6B9838CCC67@oracle.com> References: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com> <7ad6e500-57c8-2a45-838e-a0ff75d03fd8@oracle.com> <40781CC8-0D81-4182-B070-3122AD9E88FE@oracle.com> <6C5264A2-3651-4832-AA96-E6B9838CCC67@oracle.com> Message-ID: <83db6a65-5c54-8764-a8ef-42b4edb9f581@oracle.com> Looks fine to me. Thanks, Xuelei On 6/21/2018 10:39 PM, Weijun Wang wrote: > Webrev updated at > > http://cr.openjdk.java.net/~weijun/8205445/webrev.01 > > I think I found a bug in SunRsaSign of the RSASSA-PSS signature. Fixed and added a test. > > BTW, I commented out the debug code in security.cpp. Once there is a bug I can use it. > > Thanks > Max > >> On Jun 21, 2018, at 11:23 PM, Weijun Wang wrote: >> >> >> >>> On Jun 21, 2018, at 11:07 PM, Xuelei Fan wrote: >>> >>> Hi Weijun, >>> >>> The release note and the following notes look reasonable to me. >>> >>> For the implementation part, could it be a little bit more straightforward if wrapping the new attributes (pss/pssParams/fallbackSignature) and codes (if pss/fallbackSignature, etc) in the PSS subclass? >> >> Sounds good. I'll try it. >> >>> >>> Did you want to remove the debug code in the security.cpp? It seems that they are not used any more. >> >> Sure I can. >> >> Thanks >> Max >> >>> >>> Xuelei >>> >>> On 6/21/2018 4:12 AM, Weijun Wang wrote: >>>> Please take a review on this change >>>> http://cr.openjdk.java.net/~weijun/8205445/webrev.00/ >>>> and the release note at >>>> https://bugs.openjdk.java.net/browse/JDK-8205471 >>>> The code change adds RSASSA-PSS signature support to the SunMSCAPI provider. >>>> Several notes: >>>> 1. CryptoAPI (which SunMSCAPI is based on and now a deprecated technology) does not support RSASSA-PSS. In fact, CNG [1] is used to perform the signing and verification. This is certainly not a perfect solution and we are thinking of support CNG in a more sophisticated way in future releases of JDK. >>>> 2. For unknown reason, the newly added verification code for RSASSA-PSS does not work correctly (precisely, ::NCryptTranslateHandle returns NTE_INVALID_PARAMETER). A fallback mechanism is added into mscapi/RSASignature.java. A SunRsaSign Signature object is actually used when a SunMSCAPI Signature is initialized to verify an RSASSA-PSS signature. >>>> 3. It looks like CNG only supports PSSParamterSpec with the same message hash algorithm and MGF1 hash algorithm, because there is only one algorithm field in BCRYPT_PSS_PADDING_INFO [2]. This is checked when setting the parameter. >>>> 4. It looks like CNG only supports RSASSA-PSS using these hash algorithms: SHA-1, SHA-256, SHA-384, and SHA-512. This is not checked at parameter setting but sign() will throw a SignatureException saying "Unrecognised hash algorithm". Since the verify() side uses a fallback SunRsaSign signature, other hash algorithms are supported. >>>> Thanks >>>> Max >>>> [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx >>>> [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375529(v=vs.85).aspx >>>> [3] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx >> > From sean.coffey at oracle.com Fri Jun 22 14:50:01 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 22 Jun 2018 15:50:01 +0100 Subject: RFR: 8148188: Enhance the security libraries to record events of interest Message-ID: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> Following on from the recent JDK-8203629 code review, I'd like to propose enhancements on how we can record events in security libs. The introduction of the JFR libraries can give us much better ways of examining JDK actions. For the initial phase, I'm looking to enhance some key security library events in JDK 11 so that they can be either recorded to JFR, logged to a traditional logger, or both. Examples of how useful JFR recordings could be can be seen here : http://cr.openjdk.java.net/~coffeys/event_snaps/X509Event_1.png http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_1.png http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_2.png http://cr.openjdk.java.net/~coffeys/event_snaps/TLSEvent_1.png securityProp_2.png gives an example of how the JFR recording can be queried to quickly locate events of interest (in this case, code setting the jdk.tls.* Security properties). I still need to clean up the TLSEvents testcase to improve test coverage and hope to do that in coming days. JBS record : * https://bugs.openjdk.java.net/browse/JDK-8148188 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v1/webrev/ -- Regards, Sean. -------------- next part -------------- An HTML attachment was scrubbed... URL: From naoto.sato at oracle.com Fri Jun 22 17:26:17 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 22 Jun 2018 10:26:17 -0700 Subject: [11]RFR 8194152: sun/security/tools/jarsigner/AltProvider.java failed on de-DE locale In-Reply-To: <09f92268-fe4d-3c57-0ffb-d93d9703974d@oracle.com> References: <09f92268-fe4d-3c57-0ffb-d93d9703974d@oracle.com> Message-ID: Hi Dora, You could move those two lines that sets the locale to en-US before the for-loop, so that if "args" contains -J-Duser.language/country then it can override the default en-US. The JIRA issue needs noreg-self label. Naoto On 6/22/18 1:26 AM, Dora Zhou wrote: > Hello, > > Please help review the fix for JDK-8194152. Thank you. > > The test compares output with expected error messages in English, set > locale to en-US so that the output are not translated into other languages. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8194152 > Webrev: http://cr.openjdk.java.net/~ljiang/8194152/webrev/ > > > Regards, > Dora From jamil.j.nimeh at oracle.com Fri Jun 22 18:18:00 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 22 Jun 2018 11:18:00 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> Message-ID: <7f1560b6-2389-b374-e4e1-b1de9afa6a0d@oracle.com> * DHKeyExchange.java o 177-192: Am I missing something or does isRecovering get defined as false and never gets set to true within the lifetime of the variable?? Do we still need this? o 178: Nit/typo: "recove" --> "recover" o 207-210: Catching Exception seems really broad.? Can you cover all your checked exception cases with GeneralSecurityException and just let the unchecked exceptions throw as-is without wrapping them inside RuntimeException? * DHServerKeyExchange.java o 69-71: Can the p/g/y fields be final? More on the way. --Jamil > > On 6/8/2018 10:21 AM, Xuelei Fan wrote: >> Here is the 3rd full webrev: >> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.02 >> >> and the delta update to the 1st webrev: >> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.01 >> >> Xuelei >> >> On 6/3/2018 9:43 PM, Xuelei Fan wrote: >>> Hi, >>> >>> Here it the 2nd full webrev: >>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >>> >>> and the delta update to the 1st webrev: >>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >>> >>> Xuelei >>> >>> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> I'd like to invite you to review the TLS 1.3 implementation.? I >>>> appreciate it if I could have compatibility and specification >>>> feedback before May 31, 2018, and implementation feedback before >>>> June 7, 2018. >>>> >>>> Here is the webrev: >>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>>> >>>> The formal TLS 1.3 specification is not finalized yet, although it >>>> had been approved to be a standard.? The implementation is based on >>>> the draft version 28: >>>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>>> >>>> For the overall description of this enhancement, please refer to >>>> JEP 332: >>>> ???? http://openjdk.java.net/jeps/332 >>>> >>>> For the compatibility and specification update, please refer to CSR >>>> 8202625: >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>>> >>>> Note that we are using the sandbox for the development right now.? >>>> For more information, please refer to Bradford's previous email: >>>> >>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>>> >>>> >>>> Thanks & Regards, >>>> Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Fri Jun 22 18:30:02 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 22 Jun 2018 11:30:02 -0700 Subject: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI In-Reply-To: <6C5264A2-3651-4832-AA96-E6B9838CCC67@oracle.com> References: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com> <7ad6e500-57c8-2a45-838e-a0ff75d03fd8@oracle.com> <40781CC8-0D81-4182-B070-3122AD9E88FE@oracle.com> <6C5264A2-3651-4832-AA96-E6B9838CCC67@oracle.com> Message-ID: <7668a378-b061-64b2-2873-12ef7fa38dfa@oracle.com> Max, Good catch on the SunRsaSign provider bug. Looking at the changes, I think we may have to fine-grain the check on the ensureInit() call, i.e. use ensureInit(boolean sign) instead of ensureInit(), as the current method only ensures that at least one of the privKey, pubKey or fallbackSignature is non-null, I think it should check the right one is non-null, i.e. sign -> privKey, verify -> pubKey/fallbackSignature. In the PSS class engineInitVerify(...) method if the specified key is a MSCAPI public key, then fallbackSignature is set to null and the native verifyPssSignedHash method is used, right? Thanks, Valerie On 6/21/2018 10:39 PM, Weijun Wang wrote: > Webrev updated at > > http://cr.openjdk.java.net/~weijun/8205445/webrev.01 > > I think I found a bug in SunRsaSign of the RSASSA-PSS signature. Fixed and added a test. > > BTW, I commented out the debug code in security.cpp. Once there is a bug I can use it. > > Thanks > Max > >> On Jun 21, 2018, at 11:23 PM, Weijun Wang wrote: >> >> >> >>> On Jun 21, 2018, at 11:07 PM, Xuelei Fan wrote: >>> >>> Hi Weijun, >>> >>> The release note and the following notes look reasonable to me. >>> >>> For the implementation part, could it be a little bit more straightforward if wrapping the new attributes (pss/pssParams/fallbackSignature) and codes (if pss/fallbackSignature, etc) in the PSS subclass? >> Sounds good. I'll try it. >> >>> Did you want to remove the debug code in the security.cpp? It seems that they are not used any more. >> Sure I can. >> >> Thanks >> Max >> >>> Xuelei >>> >>> On 6/21/2018 4:12 AM, Weijun Wang wrote: >>>> Please take a review on this change >>>> http://cr.openjdk.java.net/~weijun/8205445/webrev.00/ >>>> and the release note at >>>> https://bugs.openjdk.java.net/browse/JDK-8205471 >>>> The code change adds RSASSA-PSS signature support to the SunMSCAPI provider. >>>> Several notes: >>>> 1. CryptoAPI (which SunMSCAPI is based on and now a deprecated technology) does not support RSASSA-PSS. In fact, CNG [1] is used to perform the signing and verification. This is certainly not a perfect solution and we are thinking of support CNG in a more sophisticated way in future releases of JDK. >>>> 2. For unknown reason, the newly added verification code for RSASSA-PSS does not work correctly (precisely, ::NCryptTranslateHandle returns NTE_INVALID_PARAMETER). A fallback mechanism is added into mscapi/RSASignature.java. A SunRsaSign Signature object is actually used when a SunMSCAPI Signature is initialized to verify an RSASSA-PSS signature. >>>> 3. It looks like CNG only supports PSSParamterSpec with the same message hash algorithm and MGF1 hash algorithm, because there is only one algorithm field in BCRYPT_PSS_PADDING_INFO [2]. This is checked when setting the parameter. >>>> 4. It looks like CNG only supports RSASSA-PSS using these hash algorithms: SHA-1, SHA-256, SHA-384, and SHA-512. This is not checked at parameter setting but sign() will throw a SignatureException saying "Unrecognised hash algorithm". Since the verify() side uses a fallback SunRsaSign signature, other hash algorithms are supported. >>>> Thanks >>>> Max >>>> [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx >>>> [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375529(v=vs.85).aspx >>>> [3] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Fri Jun 22 20:12:23 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 22 Jun 2018 13:12:23 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <7f1560b6-2389-b374-e4e1-b1de9afa6a0d@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> <7f1560b6-2389-b374-e4e1-b1de9afa6a0d@oracle.com> Message-ID: All good catches! I will push the changeset soon after the testing. On 6/22/2018 11:18 AM, Jamil Nimeh wrote: > * DHKeyExchange.java > o 177-192: Am I missing something or does isRecovering get defined > as false and never gets set to true within the lifetime of the > variable?? Do we still need this? Yes, it is used in case the generated DH key does not meet the quality. I missed the code to set isRecovering to true. Thanks, Xuelei > o 178: Nit/typo: "recove" --> "recover" > o 207-210: Catching Exception seems really broad.? Can you cover > all your checked exception cases with GeneralSecurityException > and just let the unchecked exceptions throw as-is without > wrapping them inside RuntimeException? > * DHServerKeyExchange.java > o 69-71: Can the p/g/y fields be final? > > More on the way. > > --Jamil >> >> On 6/8/2018 10:21 AM, Xuelei Fan wrote: >>> Here is the 3rd full webrev: >>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.02 >>> >>> and the delta update to the 1st webrev: >>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.01 >>> >>> Xuelei >>> >>> On 6/3/2018 9:43 PM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> Here it the 2nd full webrev: >>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >>>> >>>> and the delta update to the 1st webrev: >>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >>>> >>>> Xuelei >>>> >>>> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> I'd like to invite you to review the TLS 1.3 implementation.? I >>>>> appreciate it if I could have compatibility and specification >>>>> feedback before May 31, 2018, and implementation feedback before >>>>> June 7, 2018. >>>>> >>>>> Here is the webrev: >>>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>>>> >>>>> The formal TLS 1.3 specification is not finalized yet, although it >>>>> had been approved to be a standard.? The implementation is based on >>>>> the draft version 28: >>>>> https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>>>> >>>>> For the overall description of this enhancement, please refer to >>>>> JEP 332: >>>>> http://openjdk.java.net/jeps/332 >>>>> >>>>> For the compatibility and specification update, please refer to CSR >>>>> 8202625: >>>>> https://bugs.openjdk.java.net/browse/JDK-8202625 >>>>> >>>>> Note that we are using the sandbox for the development right now. >>>>> For more information, please refer to Bradford's previous email: >>>>> >>>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>>>> >>>>> >>>>> Thanks & Regards, >>>>> Xuelei > From weijun.wang at oracle.com Fri Jun 22 22:23:28 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 23 Jun 2018 06:23:28 +0800 Subject: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI In-Reply-To: <7668a378-b061-64b2-2873-12ef7fa38dfa@oracle.com> References: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com> <7ad6e500-57c8-2a45-838e-a0ff75d03fd8@oracle.com> <40781CC8-0D81-4182-B070-3122AD9E88FE@oracle.com> <6C5264A2-3651-4832-AA96-E6B9838CCC67@oracle.com> <7668a378-b061-64b2-2873-12ef7fa38dfa@oracle.com> Message-ID: <5AFA267F-05A7-474A-9779-FB80120E9DF0@oracle.com> > On Jun 23, 2018, at 2:30 AM, Valerie Peng wrote: > > Max, > > Good catch on the SunRsaSign provider bug. > > Looking at the changes, I think we may have to fine-grain the check on the ensureInit() call, i.e. > > use ensureInit(boolean sign) instead of ensureInit(), as the current method only ensures that at least one of the privKey, pubKey or fallbackSignature is non-null, I think it should check the right one is non-null, i.e. sign -> privKey, verify -> pubKey/fallbackSignature. Could anything go wrong? This method just ensures one of initSign() or initVerify() is called. > > In the PSS class engineInitVerify(...) method if the specified key is a MSCAPI public key, then fallbackSignature is set to null and the native verifyPssSignedHash method is used, right? Yes. The native method only fails when trying to import from a blob. Thanks Max > > Thanks, > > Valerie > > On 6/21/2018 10:39 PM, Weijun Wang wrote: >> Webrev updated at >> >> >> http://cr.openjdk.java.net/~weijun/8205445/webrev.01 >> >> >> I think I found a bug in SunRsaSign of the RSASSA-PSS signature. Fixed and added a test. >> >> BTW, I commented out the debug code in security.cpp. Once there is a bug I can use it. >> >> Thanks >> Max >> >> >>> On Jun 21, 2018, at 11:23 PM, Weijun Wang >>> wrote: >>> >>> >>> >>> >>>> On Jun 21, 2018, at 11:07 PM, Xuelei Fan >>>> wrote: >>>> >>>> Hi Weijun, >>>> >>>> The release note and the following notes look reasonable to me. >>>> >>>> For the implementation part, could it be a little bit more straightforward if wrapping the new attributes (pss/pssParams/fallbackSignature) and codes (if pss/fallbackSignature, etc) in the PSS subclass? >>>> >>> Sounds good. I'll try it. >>> >>> >>>> Did you want to remove the debug code in the security.cpp? It seems that they are not used any more. >>>> >>> Sure I can. >>> >>> Thanks >>> Max >>> >>> >>>> Xuelei >>>> >>>> On 6/21/2018 4:12 AM, Weijun Wang wrote: >>>> >>>>> Please take a review on this change >>>>> >>>>> http://cr.openjdk.java.net/~weijun/8205445/webrev.00/ >>>>> >>>>> and the release note at >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8205471 >>>>> >>>>> The code change adds RSASSA-PSS signature support to the SunMSCAPI provider. >>>>> Several notes: >>>>> 1. CryptoAPI (which SunMSCAPI is based on and now a deprecated technology) does not support RSASSA-PSS. In fact, CNG [1] is used to perform the signing and verification. This is certainly not a perfect solution and we are thinking of support CNG in a more sophisticated way in future releases of JDK. >>>>> 2. For unknown reason, the newly added verification code for RSASSA-PSS does not work correctly (precisely, ::NCryptTranslateHandle returns NTE_INVALID_PARAMETER). A fallback mechanism is added into mscapi/RSASignature.java. A SunRsaSign Signature object is actually used when a SunMSCAPI Signature is initialized to verify an RSASSA-PSS signature. >>>>> 3. It looks like CNG only supports PSSParamterSpec with the same message hash algorithm and MGF1 hash algorithm, because there is only one algorithm field in BCRYPT_PSS_PADDING_INFO [2]. This is checked when setting the parameter. >>>>> 4. It looks like CNG only supports RSASSA-PSS using these hash algorithms: SHA-1, SHA-256, SHA-384, and SHA-512. This is not checked at parameter setting but sign() will throw a SignatureException saying "Unrecognised hash algorithm". Since the verify() side uses a fallback SunRsaSign signature, other hash algorithms are supported. >>>>> Thanks >>>>> Max >>>>> [1] >>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx >>>>> >>>>> [2] >>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa375529(v=vs.85).aspx >>>>> >>>>> [3] >>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx > From weijun.wang at oracle.com Fri Jun 22 22:33:26 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 23 Jun 2018 06:33:26 +0800 Subject: RFR 8201815: Use Mozilla Public Suffix List In-Reply-To: <215F0E29-1C04-43EB-894D-152A17A9993C@oracle.com> References: <35BB388A-D2BA-4936-827F-B211E379A2DF@oracle.com> <539c8303-a2b4-d217-6817-d28925cd0e27@oracle.com> <0ED42EC2-C0E2-4DFB-BD63-0BB5C121FA85@oracle.com> <61048D27-07DB-4283-82E6-B7909296171F@oracle.com> <792D6BE1-1563-4953-BE5D-F60905D39483@oracle.com> <550260ec-9470-4f88-e1a0-05ee1ef62a4f@oracle.com> <215F0E29-1C04-43EB-894D-152A17A9993C@oracle.com> Message-ID: Updated webrev at http://cr.openjdk.java.net/~weijun/8201815/webrev.02 The only change is in SocketPermission.java. Thanks Max > On Jun 21, 2018, at 10:31 PM, Weijun Wang wrote: > > Ping again. > > I still need code review for the other changes. The latest webrev is at > > http://cr.openjdk.java.net/~weijun/8201815/webrev.01 > > The only change since webrev.00 is in GendataPublicSuffixList.gmk. > > Thanks > Max > >> On May 24, 2018, at 8:47 PM, Magnus Ihse Bursie wrote: >> >> On 2018-05-24 06:52, Weijun Wang wrote: >>> Good. It's now simply >>> >>> $(GENDATA_PUBLICSUFFIXLIST): $(GENDATA_PUBLICSUFFIXLIST_SRC) $(BUILD_TOOLS) >>> $(call LogInfo, Generating public suffix list) >>> $(call MakeDir, $(@D)) >>> $(RM) $@ >>> $(TOOL_PUBLICSUFFIXLIST) $< $@ >>> $(CHMOD) 444 $@ >>> >>> Thanks >>> Max >> Great! Looks good to me now. >> >> I've forgotten that we started using .DELETE_ON_ERROR. Thanks for reminding me Erik. :) >> >> /Magnus >> >>> >>>> On May 24, 2018, at 12:30 AM, Erik Joelsson wrote: >>>> >>>> On 2018-05-23 03:54, Magnus Ihse Bursie wrote: >>>>> mv should not modify attributes. cp will, but mv should not. >>>>> >>>>> Your solution might fail in the (admittedly unlikely) case that the build is interrupted before the chmod but after the mv. In that case, an incremental rebuild will not see that anything is missing. >>>>> >>>>> I believe the other cases that you quote are also incorrect. >>>>> >>>>> But I'd like to hear Erik's input on this as well. >>>> We have the pseudo target .DELETE_ON_ERROR defined globally (in MakeBase.gmk) which causes make to delete the target of any failed or interrupted recipe. This should actually remove any need for using .tmp files and mv on the last line. We still have a lot of those constructs around since forever though. The recipe copied here (and the two other examples) are based on a template from very early build-infra makefile history and do not represent current best practices. If anything I would recommend getting rid of the .tmp and mv completely, but if you prefer both belt and suspenders, putting the move last should be the correct construct. >>>> >>>> /Erik >>>>> /Magnus >>>>> >>>>>> 23 maj 2018 kl. 02:01 skrev Weijun Wang : >>>>>> >>>>>> >>>>>> >>>>>>> On May 23, 2018, at 4:21 AM, Magnus Ihse Bursie wrote: >>>>>>> >>>>>>> ... but you should switch order on the chmod and the mv in the new gensrc file, so the mv comes last. >>>>>> I thought it's safer to call CHMOD last so MV won't change file mode back. (I'm not saying it will, just afraid.) >>>>>> >>>>>> In below cases, CHMOD is called after MV/CP. >>>>>> >>>>>> gendata/Gendata-java.base.gmk >>>>>> 59- $(MV) $@.tmp $@ >>>>>> 60: $(CHMOD) 444 $@ >>>>>> 61- >>>>>> >>>>>> common/JavaCompilation.gmk >>>>>> 80- $(CP) $$< $$@ >>>>>> 81: $(CHMOD) -f ug+w $$@ >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>>> 22 maj 2018 kl. 17:44 skrev Erik Joelsson : >>>>>>>> >>>>>>>> Build changes look ok. >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>> >>>>>>>>> On 2018-05-22 08:25, Weijun Wang wrote: >>>>>>>>> Please take a review at >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~weijun/8201815/webrev.00/ >>>>>>>>> >>>>>>>>> With this change, We switch from a home-grown public suffix list (implemented in sun/net/RegisteredDomain.java) to Mozilla's PSL. The PSL data was re-encoded as a zip file with entries for different TLDs. >>>>>>>>> >>>>>>>>> There is no plan to update the data in a different channel other than a JDK release. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Max >> > From xuelei.fan at oracle.com Fri Jun 22 22:45:06 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 22 Jun 2018 15:45:06 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> <7f1560b6-2389-b374-e4e1-b1de9afa6a0d@oracle.com> Message-ID: <2d5f578d-550a-b2b6-439b-0dff8d8353f0@oracle.com> Update: http://hg.openjdk.java.net/jdk/sandbox/rev/63ab0dfe3dbb Except the issues in this thread, this update also include changes to set signature parameters after key initialization, so that the provider of Signature instance is the same as its key provider if needed. We have fixed the SunMSCAPI RSASSA-PSS signature issue, and the test sun/security/mscapi/ShortRSAKeyWithinTLS.java passed now. The test is removed from the ProblemList.txt. I don't think it is really necessary, but just in case there is a compatibility impact, I updated the RSA size limit from 512 to 511. The sun/security/pkcs11/KeyStore/ClientAuth.sh, which uses 511 RSA key, is removed from the ProblemList.txt. Thanks, Xuelei On 6/22/2018 1:12 PM, Xuelei Fan wrote: > All good catches!? I will push the changeset soon after the testing. > > On 6/22/2018 11:18 AM, Jamil Nimeh wrote: >> ? * DHKeyExchange.java >> ????? o 177-192: Am I missing something or does isRecovering get defined >> ??????? as false and never gets set to true within the lifetime of the >> ??????? variable?? Do we still need this? > Yes, it is used in case the generated DH key does not meet the quality. > I missed the code to set isRecovering to true. > > Thanks, > Xuelei > >> ????? o 178: Nit/typo: "recove" --> "recover" >> ????? o 207-210: Catching Exception seems really broad.? Can you cover >> ??????? all your checked exception cases with GeneralSecurityException >> ??????? and just let the unchecked exceptions throw as-is without >> ??????? wrapping them inside RuntimeException? >> ? * DHServerKeyExchange.java >> ????? o 69-71: Can the p/g/y fields be final? >> >> More on the way. >> >> --Jamil >>> >>> On 6/8/2018 10:21 AM, Xuelei Fan wrote: >>>> Here is the 3rd full webrev: >>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.02 >>>> >>>> and the delta update to the 1st webrev: >>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.01 >>>> >>>> Xuelei >>>> >>>> On 6/3/2018 9:43 PM, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> Here it the 2nd full webrev: >>>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >>>>> >>>>> and the delta update to the 1st webrev: >>>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >>>>> >>>>> Xuelei >>>>> >>>>> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>>>>> Hi, >>>>>> >>>>>> I'd like to invite you to review the TLS 1.3 implementation.? I >>>>>> appreciate it if I could have compatibility and specification >>>>>> feedback before May 31, 2018, and implementation feedback before >>>>>> June 7, 2018. >>>>>> >>>>>> Here is the webrev: >>>>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>>>>> >>>>>> The formal TLS 1.3 specification is not finalized yet, although it >>>>>> had been approved to be a standard.? The implementation is based >>>>>> on the draft version 28: >>>>>> https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>>>>> >>>>>> For the overall description of this enhancement, please refer to >>>>>> JEP 332: >>>>>> http://openjdk.java.net/jeps/332 >>>>>> >>>>>> For the compatibility and specification update, please refer to >>>>>> CSR 8202625: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8202625 >>>>>> >>>>>> Note that we are using the sandbox for the development right now. >>>>>> For more information, please refer to Bradford's previous email: >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>>>>> >>>>>> >>>>>> Thanks & Regards, >>>>>> Xuelei >> From valerie.peng at oracle.com Sat Jun 23 00:35:11 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 22 Jun 2018 17:35:11 -0700 Subject: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI In-Reply-To: <5AFA267F-05A7-474A-9779-FB80120E9DF0@oracle.com> References: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com> <7ad6e500-57c8-2a45-838e-a0ff75d03fd8@oracle.com> <40781CC8-0D81-4182-B070-3122AD9E88FE@oracle.com> <6C5264A2-3651-4832-AA96-E6B9838CCC67@oracle.com> <7668a378-b061-64b2-2873-12ef7fa38dfa@oracle.com> <5AFA267F-05A7-474A-9779-FB80120E9DF0@oracle.com> Message-ID: <47e0f5d3-a46a-5708-9164-8b556f45ce60@oracle.com> On 6/22/2018 3:23 PM, Weijun Wang wrote: >> On Jun 23, 2018, at 2:30 AM, Valerie Peng wrote: >> >> Max, >> >> Good catch on the SunRsaSign provider bug. >> >> Looking at the changes, I think we may have to fine-grain the check on the ensureInit() call, i.e. >> >> use ensureInit(boolean sign) instead of ensureInit(), as the current method only ensures that at least one of the privKey, pubKey or fallbackSignature is non-null, I think it should check the right one is non-null, i.e. sign -> privKey, verify -> pubKey/fallbackSignature. > Could anything go wrong? This method just ensures one of initSign() or initVerify() is called. Only when the initSign()/initVerify() does not match the subsequent calls of sign()/verify() I suppose. Valerie >> In the PSS class engineInitVerify(...) method if the specified key is a MSCAPI public key, then fallbackSignature is set to null and the native verifyPssSignedHash method is used, right? > Yes. The native method only fails when trying to import from a blob. > > Thanks > Max > >> Thanks, >> >> Valerie >> >> On 6/21/2018 10:39 PM, Weijun Wang wrote: >>> Webrev updated at >>> >>> >>> http://cr.openjdk.java.net/~weijun/8205445/webrev.01 >>> >>> >>> I think I found a bug in SunRsaSign of the RSASSA-PSS signature. Fixed and added a test. >>> >>> BTW, I commented out the debug code in security.cpp. Once there is a bug I can use it. >>> >>> Thanks >>> Max >>> >>> >>>> On Jun 21, 2018, at 11:23 PM, Weijun Wang >>>> wrote: >>>> >>>> >>>> >>>> >>>>> On Jun 21, 2018, at 11:07 PM, Xuelei Fan >>>>> wrote: >>>>> >>>>> Hi Weijun, >>>>> >>>>> The release note and the following notes look reasonable to me. >>>>> >>>>> For the implementation part, could it be a little bit more straightforward if wrapping the new attributes (pss/pssParams/fallbackSignature) and codes (if pss/fallbackSignature, etc) in the PSS subclass? >>>>> >>>> Sounds good. I'll try it. >>>> >>>> >>>>> Did you want to remove the debug code in the security.cpp? It seems that they are not used any more. >>>>> >>>> Sure I can. >>>> >>>> Thanks >>>> Max >>>> >>>> >>>>> Xuelei >>>>> >>>>> On 6/21/2018 4:12 AM, Weijun Wang wrote: >>>>> >>>>>> Please take a review on this change >>>>>> >>>>>> http://cr.openjdk.java.net/~weijun/8205445/webrev.00/ >>>>>> >>>>>> and the release note at >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8205471 >>>>>> >>>>>> The code change adds RSASSA-PSS signature support to the SunMSCAPI provider. >>>>>> Several notes: >>>>>> 1. CryptoAPI (which SunMSCAPI is based on and now a deprecated technology) does not support RSASSA-PSS. In fact, CNG [1] is used to perform the signing and verification. This is certainly not a perfect solution and we are thinking of support CNG in a more sophisticated way in future releases of JDK. >>>>>> 2. For unknown reason, the newly added verification code for RSASSA-PSS does not work correctly (precisely, ::NCryptTranslateHandle returns NTE_INVALID_PARAMETER). A fallback mechanism is added into mscapi/RSASignature.java. A SunRsaSign Signature object is actually used when a SunMSCAPI Signature is initialized to verify an RSASSA-PSS signature. >>>>>> 3. It looks like CNG only supports PSSParamterSpec with the same message hash algorithm and MGF1 hash algorithm, because there is only one algorithm field in BCRYPT_PSS_PADDING_INFO [2]. This is checked when setting the parameter. >>>>>> 4. It looks like CNG only supports RSASSA-PSS using these hash algorithms: SHA-1, SHA-256, SHA-384, and SHA-512. This is not checked at parameter setting but sign() will throw a SignatureException saying "Unrecognised hash algorithm". Since the verify() side uses a fallback SunRsaSign signature, other hash algorithms are supported. >>>>>> Thanks >>>>>> Max >>>>>> [1] >>>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx >>>>>> >>>>>> [2] >>>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa375529(v=vs.85).aspx >>>>>> >>>>>> [3] >>>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx From weijun.wang at oracle.com Sat Jun 23 00:40:58 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 23 Jun 2018 08:40:58 +0800 Subject: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI In-Reply-To: <47e0f5d3-a46a-5708-9164-8b556f45ce60@oracle.com> References: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com> <7ad6e500-57c8-2a45-838e-a0ff75d03fd8@oracle.com> <40781CC8-0D81-4182-B070-3122AD9E88FE@oracle.com> <6C5264A2-3651-4832-AA96-E6B9838CCC67@oracle.com> <7668a378-b061-64b2-2873-12ef7fa38dfa@oracle.com> <5AFA267F-05A7-474A-9779-FB80120E9DF0@oracle.com> <47e0f5d3-a46a-5708-9164-8b556f45ce60@oracle.com> Message-ID: <55A55402-DDA5-483B-B548-18E096BB0765@oracle.com> > On Jun 23, 2018, at 8:35 AM, Valerie Peng wrote: > > On 6/22/2018 3:23 PM, Weijun Wang wrote: >>> On Jun 23, 2018, at 2:30 AM, Valerie Peng wrote: >>> >>> Max, >>> >>> Good catch on the SunRsaSign provider bug. >>> >>> Looking at the changes, I think we may have to fine-grain the check on the ensureInit() call, i.e. >>> >>> use ensureInit(boolean sign) instead of ensureInit(), as the current method only ensures that at least one of the privKey, pubKey or fallbackSignature is non-null, I think it should check the right one is non-null, i.e. sign -> privKey, verify -> pubKey/fallbackSignature. >> Could anything go wrong? This method just ensures one of initSign() or initVerify() is called. > Only when the initSign()/initVerify() does not match the subsequent calls of sign()/verify() I suppose. I see what you mean. The Signature class takes care of it: public final byte[] sign() throws SignatureException { if (state == SIGN) { return engineSign(); } throw new SignatureException("object not initialized for " + "signing"); } Thanks Max > Valerie >>> In the PSS class engineInitVerify(...) method if the specified key is a MSCAPI public key, then fallbackSignature is set to null and the native verifyPssSignedHash method is used, right? >> Yes. The native method only fails when trying to import from a blob. >> >> Thanks >> Max >> >>> Thanks, >>> >>> Valerie >>> >>> On 6/21/2018 10:39 PM, Weijun Wang wrote: >>>> Webrev updated at >>>> >>>> http://cr.openjdk.java.net/~weijun/8205445/webrev.01 >>>> >>>> >>>> I think I found a bug in SunRsaSign of the RSASSA-PSS signature. Fixed and added a test. >>>> >>>> BTW, I commented out the debug code in security.cpp. Once there is a bug I can use it. >>>> >>>> Thanks >>>> Max >>>> >>>> >>>>> On Jun 21, 2018, at 11:23 PM, Weijun Wang >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> On Jun 21, 2018, at 11:07 PM, Xuelei Fan >>>>>> wrote: >>>>>> >>>>>> Hi Weijun, >>>>>> >>>>>> The release note and the following notes look reasonable to me. >>>>>> >>>>>> For the implementation part, could it be a little bit more straightforward if wrapping the new attributes (pss/pssParams/fallbackSignature) and codes (if pss/fallbackSignature, etc) in the PSS subclass? >>>>>> >>>>> Sounds good. I'll try it. >>>>> >>>>> >>>>>> Did you want to remove the debug code in the security.cpp? It seems that they are not used any more. >>>>>> >>>>> Sure I can. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> >>>>>> Xuelei >>>>>> >>>>>> On 6/21/2018 4:12 AM, Weijun Wang wrote: >>>>>> >>>>>>> Please take a review on this change >>>>>>> http://cr.openjdk.java.net/~weijun/8205445/webrev.00/ >>>>>>> >>>>>>> and the release note at >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8205471 >>>>>>> >>>>>>> The code change adds RSASSA-PSS signature support to the SunMSCAPI provider. >>>>>>> Several notes: >>>>>>> 1. CryptoAPI (which SunMSCAPI is based on and now a deprecated technology) does not support RSASSA-PSS. In fact, CNG [1] is used to perform the signing and verification. This is certainly not a perfect solution and we are thinking of support CNG in a more sophisticated way in future releases of JDK. >>>>>>> 2. For unknown reason, the newly added verification code for RSASSA-PSS does not work correctly (precisely, ::NCryptTranslateHandle returns NTE_INVALID_PARAMETER). A fallback mechanism is added into mscapi/RSASignature.java. A SunRsaSign Signature object is actually used when a SunMSCAPI Signature is initialized to verify an RSASSA-PSS signature. >>>>>>> 3. It looks like CNG only supports PSSParamterSpec with the same message hash algorithm and MGF1 hash algorithm, because there is only one algorithm field in BCRYPT_PSS_PADDING_INFO [2]. This is checked when setting the parameter. >>>>>>> 4. It looks like CNG only supports RSASSA-PSS using these hash algorithms: SHA-1, SHA-256, SHA-384, and SHA-512. This is not checked at parameter setting but sign() will throw a SignatureException saying "Unrecognised hash algorithm". Since the verify() side uses a fallback SunRsaSign signature, other hash algorithms are supported. >>>>>>> Thanks >>>>>>> Max >>>>>>> [1] >>>>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx >>>>>>> >>>>>>> [2] >>>>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa375529(v=vs.85).aspx >>>>>>> >>>>>>> [3] >>>>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx > From erik.gahlin at oracle.com Sun Jun 24 13:21:33 2018 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Sun, 24 Jun 2018 15:21:33 +0200 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> Message-ID: <5B2F9ADD.1040809@oracle.com> Hi Sean, Some of the changes in the webrev belongs to JDK-8203629 and should be removed for clarity. Some initial comments: default.jfc, profile.jfr: The events should not have control="enable-exceptions". The purpose of the control attribute is so to provide parameterized configuration of events for JMC. As it is now, the security events will be enabled when a user turns on the exception events. X509CertEvent: You should use milliseconds since epoch to represent a date instead of a string value, i.e. @Label("Valid From") @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) public long validFrom; @Label("Valid Until") @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) public long validUntil; This following annotation adds little value @Description("Details of Security Property") I would either remove the annotation, or provide information that helps a user understand the event. For instance, what is X509, and what kind of certificates are we talking about? @Category("Java Application") I'm a bit worried that we will pollute the "Java Application" namespace if we add lots of JDK events in that category. We may want to add a new top level category "Java Development Kit", analogous to the "Java Virtual Machine" category, and put all security related events in subcategory, perhaps called "Security". @Label("X509Cert") The label should be human readable name, with spaces, title cased etc. I would recommend "X.509 Certificate". In general, avoid abbreviations like "certs" and instead use labels such as "Certificate Chain". The label should be short and not a full sentence. For details see, https://docs.oracle.com/javase/10/docs/api/jdk/jfr/Label.html I think it would be good to separate testing of JFR and logging into different files / tests. I would prefer that the test name is the same as the event prefixed with "Test", i.e TestX509CertificateEvent, as this is the pattern used by other JFR tests. I reworked one of the tests to how I like to see it: /* * @test * @key jfr * @library /test/lib * @run main/othervm jdk.jfr.event.security.TestX509CertificateEvent */ public class TestX509CertificateEvent { private static final String CERTIFICATE_1 = "..."; private static final String CERTIFICATE_2 = "..."; public static void main(String... args) throws CertificateException { Recording r = new Recording(); r.enable(EventNames.X509Certificate).withoutStackTrace(); r.start(); CertificateFactory cf = CertificateFactory.getInstance("X.509"); cf.generateCertificate(new ByteArrayInputStream(CERTIFICATE_1.getBytes())); cf.generateCertificate(new ByteArrayInputStream(CERTIFICATE_2.getBytes())); // Make sure only one event per certificate cf.generateCertificate(new ByteArrayInputStream(CERTIFICATE_1.getBytes())); cf.generateCertificate(new ByteArrayInputStream(CERTIFICATE_2.getBytes())); r.stop(); List events = Events.fromRecording(r); Asserts.assertEquals(events.size(), 2, "Expected two X.509 Certificate events"); assertEvent(events, "1000", "SHA256withRSA", "CN=SSLCertificate, O=SomeCompany", "CN=Intermediate CA Cert, O=SomeCompany", "RSA", 2048); assertEvent(events, "1000", "SHA256withRSA", "CN=SSLCertificate, O=SomeCompany", "CN=Intermediate CA Cert, O=SomeCompany", "RSA", 2048); } private static void assertEvent(List events, String certID, String algId, String subject, String issuer, String keyType, int length) throws Exception { for (RecordedEvent e : events) { if (e.getString("serialNumber").equals(certID)) { Events.assertField(e, "algId").equal(algId); ... return; } } System.out.println(events); throw new Exception("Could not find event with Cert ID: " + certID); } } The reworked example uses the Events.assertField method, which will give context if the assertion fails. Keeping the test simple, means it can be analyzed quickly if it fails in testing. There is no new test framework to learn, or methods to search for, and it is usually not hard to determine if the failure is product, test or infrastructure related, and what component (team) should be assigned the issue. The use of EventNames.X509Certificate means all occurrences of the event can be tracked done in an IDE using find by reference. Thanks Erik > Following on from the recent JDK-8203629 code review, I'd like to > propose enhancements on how we can record events in security libs. The > introduction of the JFR libraries can give us much better ways of > examining JDK actions. For the initial phase, I'm looking to enhance > some key security library events in JDK 11 so that they can be either > recorded to JFR, logged to a traditional logger, or both. > > Examples of how useful JFR recordings could be can be seen here : > > http://cr.openjdk.java.net/~coffeys/event_snaps/X509Event_1.png > http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_1.png > http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_2.png > http://cr.openjdk.java.net/~coffeys/event_snaps/TLSEvent_1.png > > securityProp_2.png gives an example of how the JFR recording can be > queried to quickly locate events of interest (in this case, code > setting the jdk.tls.* Security properties). I still need to clean up > the TLSEvents testcase to improve test coverage and hope to do that in > coming days. > > JBS record : > * https://bugs.openjdk.java.net/browse/JDK-8148188 > > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v1/webrev/ > From weijun.wang at oracle.com Mon Jun 25 01:22:17 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 25 Jun 2018 09:22:17 +0800 Subject: RFR 8202608: CommonSeeder test needs a white-box testing mechanism to replace the default entropy source Message-ID: Please take a review at http://cr.openjdk.java.net/~weijun/8202608/webrev.00/ I added a patched SeedGenerator and remove the reflection calls. A comment in AbstractDrbg.java removed. That's not a trusted application, it's evil. Thanks Max From dan.z.zhou at oracle.com Mon Jun 25 07:04:16 2018 From: dan.z.zhou at oracle.com (Dora Zhou) Date: Mon, 25 Jun 2018 15:04:16 +0800 Subject: [11]RFR 8196213: sun/security/tools/jarsigner/warnings/NoTimestampTest.java test fails on ar_SA locale. Message-ID: <915dfad2-a373-77f7-c5a0-38df52ca9e70@oracle.com> Hello, Please help review the fix for JDK-8196213. Thank you. Set default locale to en-US so that the output display the date using Gregorian Calendar and Latn numbering system(0~9). Bug: https://bugs.openjdk.java.net/browse/JDK-8196213 Webrev: http://cr.openjdk.java.net/~ljiang/8196213/webrev/ Regards, Dora From dan.z.zhou at oracle.com Mon Jun 25 07:37:39 2018 From: dan.z.zhou at oracle.com (Dora Zhou) Date: Mon, 25 Jun 2018 15:37:39 +0800 Subject: [11]RFR 8194152: sun/security/tools/jarsigner/AltProvider.java failed on de-DE locale In-Reply-To: References: Message-ID: <44ed6c3a-4a19-fec3-edff-d9de27882c29@oracle.com> Hi Naoto, Thanks a lot for the review. I have made suggested changes, Kindly have a look at: http://cr.openjdk.java.net/~ljiang/8194152/webrev.01/ Regards, Dora > From: naoto.sato at oracle.com > To: dan.z.zhou at oracle.com, i18n-dev at openjdk.java.net, core-libs-dev at openjdk.java.net, security-dev at openjdk.java.net > Sent: Saturday, June 23, 2018 1:23:50 AM GMT +08:00 Beijing / Chongqing / Hong Kong / Urumqi > Subject: Re: [11]RFR 8194152: sun/security/tools/jarsigner/AltProvider.java failed on de-DE locale > > Hi Dora, > > You could move those two lines that sets the locale to en-US before the > for-loop, so that if "args" contains -J-Duser.language/country then it > can override the default en-US. > > The JIRA issue needs noreg-self label. > > Naoto > > On 6/22/18 1:26 AM, Dora Zhou wrote: >> Hello, >> >> Please help review the fix for JDK-8194152. Thank you. >> >> The test compares output with expected error messages in English, set >> locale to en-US so that the output are not translated into other languages. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8194152 >> Webrev: http://cr.openjdk.java.net/~ljiang/8194152/webrev/ >> >> >> Regards, >> Dora From sha.jiang at oracle.com Mon Jun 25 09:50:59 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Mon, 25 Jun 2018 17:50:59 +0800 Subject: RFR[11] JDK-8203007: Address missing block coverage for ChaCha20 and Poly1305 algorithms Message-ID: <0d555115-1c36-9744-0541-1975eecc4303@oracle.com> Hi, This patch introduces three new tests to enhance code coverage for ChaCha20 and Poly1305 algorithms. Issue: https://bugs.openjdk.java.net/browse/JDK-8203007 Webrev: http://cr.openjdk.java.net/~jjiang/8203007/webrev.00/ Best regards, John Jiang From adam.petcher at oracle.com Mon Jun 25 12:49:49 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 25 Jun 2018 08:49:49 -0400 Subject: RFR 8203228: Branch-free output conversion for X25519 and X448 In-Reply-To: References: Message-ID: <31ab6859-caca-2f54-387d-be4c22fffc29@oracle.com> It would be nice to get this X25519/X448 enhancement into JDK 11. If anyone has some time to review this in the next day or so, I would appreciate it. On 5/15/2018 2:42 PM, Adam Petcher wrote: > Webrev: http://cr.openjdk.java.net/~apetcher/8203228/webrev.00/ > > Please review the change for this leftover task from the X25519/X448 > JEP. The current code uses BigInteger to convert the final result from > a field element to a byte array that can be used to derive a key. > Using branch-free operations instead of BigInteger will protect this > secret from certain side-channel attacks. > > The output conversion is done entirely by the asByteArray method of > IntegerPolynomial, which is implemented by limbsToByteArray. For this > change, I took the branch-free output conversion routine from the > Poly1305 field and pushed it into the parent class. I had to > generalize it a bit in order to deal with the peculiarities of the > X25519/X448 fields and their representations. I also made > addModPowerTwo branch free, because this was a relatively simple > change once the rest was done. But this method is not used by > X25519/X448. > > In addition to running the full regression test suite, I also ran some > benchmarks on X25519 and X448 to confirm that performance wasn't > impacted. Not surprising, since this method is only called once per > key generation/agreement operation. > From xuelei.fan at oracle.com Mon Jun 25 15:16:26 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 25 Jun 2018 08:16:26 -0700 Subject: Code Review Request: TLS 1.3 Implementation In-Reply-To: <73c794d3-0afa-1243-c31b-1fa5caae9a9d@oracle.com> References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com> <8ec6bbac-96e3-57d5-1996-ca367628a405@oracle.com> <00000bae-d589-7378-41c9-40089806ecf5@oracle.com> <73c794d3-0afa-1243-c31b-1fa5caae9a9d@oracle.com> Message-ID: <4ab577bf-d379-eac6-e6c4-47944eeb395b@oracle.com> Update: http://hg.openjdk.java.net/jdk/sandbox/rev/32a737f51e37 Xuelei On 6/18/2018 8:48 AM, Xuelei Fan wrote: > CertificateMessage.java > X509TrustManagerImpl.java > X509KeyManagerImpl.java > ------------------------- > These implementation has not consider the impact of RSASSA-PSS key type. > > Xuelei > > > On 6/8/2018 10:21 AM, Xuelei Fan wrote: >> Here is the 3rd full webrev: >> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.02 >> >> and the delta update to the 1st webrev: >> ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.01 >> >> Xuelei >> >> On 6/3/2018 9:43 PM, Xuelei Fan wrote: >>> Hi, >>> >>> Here it the 2nd full webrev: >>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >>> >>> and the delta update to the 1st webrev: >>> ?? http://cr.openjdk.java.net/~xuelei/8196584/webrev-delta.00/ >>> >>> Xuelei >>> >>> On 5/25/2018 4:45 PM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> I'd like to invite you to review the TLS 1.3 implementation.? I >>>> appreciate it if I could have compatibility and specification >>>> feedback before May 31, 2018, and implementation feedback before >>>> June 7, 2018. >>>> >>>> Here is the webrev: >>>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>>> >>>> The formal TLS 1.3 specification is not finalized yet, although it >>>> had been approved to be a standard.? The implementation is based on >>>> the draft version 28: >>>> ???? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 >>>> >>>> For the overall description of this enhancement, please refer to JEP >>>> 332: >>>> ???? http://openjdk.java.net/jeps/332 >>>> >>>> For the compatibility and specification update, please refer to CSR >>>> 8202625: >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8202625 >>>> >>>> Note that we are using the sandbox for the development right now. >>>> For more information, please refer to Bradford's previous email: >>>> >>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html >>>> >>>> >>>> Thanks & Regards, >>>> Xuelei From naoto.sato at oracle.com Mon Jun 25 16:03:55 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 25 Jun 2018 09:03:55 -0700 Subject: [11]RFR 8194152: sun/security/tools/jarsigner/AltProvider.java failed on de-DE locale In-Reply-To: <44ed6c3a-4a19-fec3-edff-d9de27882c29@oracle.com> References: <44ed6c3a-4a19-fec3-edff-d9de27882c29@oracle.com> Message-ID: <67097d88-8657-6bf2-8e45-3bdc52a2ffea@oracle.com> Looks good. Naoto On 6/25/18 12:37 AM, Dora Zhou wrote: > Hi Naoto, > > Thanks a lot for the review. > I have made suggested changes, Kindly have a look at: > http://cr.openjdk.java.net/~ljiang/8194152/webrev.01/ > > > Regards, > Dora > >> From: naoto.sato at oracle.com >> To: dan.z.zhou at oracle.com, i18n-dev at openjdk.java.net, >> core-libs-dev at openjdk.java.net, security-dev at openjdk.java.net >> Sent: Saturday, June 23, 2018 1:23:50 AM GMT +08:00 Beijing / >> Chongqing / Hong Kong / Urumqi >> Subject: Re: [11]RFR 8194152: >> sun/security/tools/jarsigner/AltProvider.java failed on de-DE locale >> >> Hi Dora, >> >> You could move those two lines that sets the locale to en-US before the >> for-loop, so that if "args" contains -J-Duser.language/country then it >> can override the default en-US. >> >> The JIRA issue needs noreg-self label. >> >> Naoto >> >> On 6/22/18 1:26 AM, Dora Zhou wrote: >>> Hello, >>> >>> Please help review the fix for JDK-8194152. Thank you. >>> >>> The test compares output with expected error messages in English, set >>> locale to en-US so that the output are not translated into other >>> languages. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8194152 >>> Webrev: http://cr.openjdk.java.net/~ljiang/8194152/webrev/ >>> >>> >>> Regards, >>> Dora > From naoto.sato at oracle.com Mon Jun 25 16:43:42 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 25 Jun 2018 09:43:42 -0700 Subject: [11]RFR 8196213: sun/security/tools/jarsigner/warnings/NoTimestampTest.java test fails on ar_SA locale. In-Reply-To: <915dfad2-a373-77f7-c5a0-38df52ca9e70@oracle.com> References: <915dfad2-a373-77f7-c5a0-38df52ca9e70@oracle.com> Message-ID: <49bcf97c-0eec-4481-9114-918baa6b4f48@oracle.com> Looks good. Naoto On 6/25/18 12:04 AM, Dora Zhou wrote: > Hello, > > Please help review the fix for JDK-8196213. Thank you. > Set default locale to en-US so that the output display the date using > Gregorian Calendar and Latn numbering system(0~9). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196213 > Webrev: http://cr.openjdk.java.net/~ljiang/8196213/webrev/ > > > Regards, > Dora > From valerie.peng at oracle.com Mon Jun 25 19:00:35 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 25 Jun 2018 12:00:35 -0700 Subject: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI In-Reply-To: <55A55402-DDA5-483B-B548-18E096BB0765@oracle.com> References: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com> <7ad6e500-57c8-2a45-838e-a0ff75d03fd8@oracle.com> <40781CC8-0D81-4182-B070-3122AD9E88FE@oracle.com> <6C5264A2-3651-4832-AA96-E6B9838CCC67@oracle.com> <7668a378-b061-64b2-2873-12ef7fa38dfa@oracle.com> <5AFA267F-05A7-474A-9779-FB80120E9DF0@oracle.com> <47e0f5d3-a46a-5708-9164-8b556f45ce60@oracle.com> <55A55402-DDA5-483B-B548-18E096BB0765@oracle.com> Message-ID: Great, that's good then. Valerie On 6/22/2018 5:40 PM, Weijun Wang wrote: > >> On Jun 23, 2018, at 8:35 AM, Valerie Peng wrote: >> >> On 6/22/2018 3:23 PM, Weijun Wang wrote: >>>> On Jun 23, 2018, at 2:30 AM, Valerie Peng wrote: >>>> >>>> Max, >>>> >>>> Good catch on the SunRsaSign provider bug. >>>> >>>> Looking at the changes, I think we may have to fine-grain the check on the ensureInit() call, i.e. >>>> >>>> use ensureInit(boolean sign) instead of ensureInit(), as the current method only ensures that at least one of the privKey, pubKey or fallbackSignature is non-null, I think it should check the right one is non-null, i.e. sign -> privKey, verify -> pubKey/fallbackSignature. >>> Could anything go wrong? This method just ensures one of initSign() or initVerify() is called. >> Only when the initSign()/initVerify() does not match the subsequent calls of sign()/verify() I suppose. > I see what you mean. > > The Signature class takes care of it: > > public final byte[] sign() throws SignatureException { > if (state == SIGN) { > return engineSign(); > } > throw new SignatureException("object not initialized for " + > "signing"); > } > > Thanks > Max > >> Valerie >>>> In the PSS class engineInitVerify(...) method if the specified key is a MSCAPI public key, then fallbackSignature is set to null and the native verifyPssSignedHash method is used, right? >>> Yes. The native method only fails when trying to import from a blob. >>> >>> Thanks >>> Max >>> >>>> Thanks, >>>> >>>> Valerie >>>> >>>> On 6/21/2018 10:39 PM, Weijun Wang wrote: >>>>> Webrev updated at >>>>> >>>>> http://cr.openjdk.java.net/~weijun/8205445/webrev.01 >>>>> >>>>> >>>>> I think I found a bug in SunRsaSign of the RSASSA-PSS signature. Fixed and added a test. >>>>> >>>>> BTW, I commented out the debug code in security.cpp. Once there is a bug I can use it. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> >>>>>> On Jun 21, 2018, at 11:23 PM, Weijun Wang >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Jun 21, 2018, at 11:07 PM, Xuelei Fan >>>>>>> wrote: >>>>>>> >>>>>>> Hi Weijun, >>>>>>> >>>>>>> The release note and the following notes look reasonable to me. >>>>>>> >>>>>>> For the implementation part, could it be a little bit more straightforward if wrapping the new attributes (pss/pssParams/fallbackSignature) and codes (if pss/fallbackSignature, etc) in the PSS subclass? >>>>>>> >>>>>> Sounds good. I'll try it. >>>>>> >>>>>> >>>>>>> Did you want to remove the debug code in the security.cpp? It seems that they are not used any more. >>>>>>> >>>>>> Sure I can. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> >>>>>>> Xuelei >>>>>>> >>>>>>> On 6/21/2018 4:12 AM, Weijun Wang wrote: >>>>>>> >>>>>>>> Please take a review on this change >>>>>>>> http://cr.openjdk.java.net/~weijun/8205445/webrev.00/ >>>>>>>> >>>>>>>> and the release note at >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8205471 >>>>>>>> >>>>>>>> The code change adds RSASSA-PSS signature support to the SunMSCAPI provider. >>>>>>>> Several notes: >>>>>>>> 1. CryptoAPI (which SunMSCAPI is based on and now a deprecated technology) does not support RSASSA-PSS. In fact, CNG [1] is used to perform the signing and verification. This is certainly not a perfect solution and we are thinking of support CNG in a more sophisticated way in future releases of JDK. >>>>>>>> 2. For unknown reason, the newly added verification code for RSASSA-PSS does not work correctly (precisely, ::NCryptTranslateHandle returns NTE_INVALID_PARAMETER). A fallback mechanism is added into mscapi/RSASignature.java. A SunRsaSign Signature object is actually used when a SunMSCAPI Signature is initialized to verify an RSASSA-PSS signature. >>>>>>>> 3. It looks like CNG only supports PSSParamterSpec with the same message hash algorithm and MGF1 hash algorithm, because there is only one algorithm field in BCRYPT_PSS_PADDING_INFO [2]. This is checked when setting the parameter. >>>>>>>> 4. It looks like CNG only supports RSASSA-PSS using these hash algorithms: SHA-1, SHA-256, SHA-384, and SHA-512. This is not checked at parameter setting but sign() will throw a SignatureException saying "Unrecognised hash algorithm". Since the verify() side uses a fallback SunRsaSign signature, other hash algorithms are supported. >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> [1] >>>>>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx >>>>>>>> >>>>>>>> [2] >>>>>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa375529(v=vs.85).aspx >>>>>>>> >>>>>>>> [3] >>>>>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx From sean.coffey at oracle.com Mon Jun 25 20:22:10 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 25 Jun 2018 21:22:10 +0100 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: <5B2F9ADD.1040809@oracle.com> References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> Message-ID: <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> Many thanks for the review comments Erik. Replies inline. On 24/06/2018 14:21, Erik Gahlin wrote: > Hi Sean, > > Some of the changes in the webrev belongs to JDK-8203629 and should be > removed for clarity. > > Some initial comments: > > default.jfc, profile.jfr: > The events should not have control="enable-exceptions". The purpose of > the control attribute is so to provide parameterized configuration of > events for JMC.? As it is now, the security events will be enabled > when a user turns on the exception events. Makes sense. I'll remove that parameter. > > X509CertEvent: > You should use milliseconds since epoch to represent a date instead of > a string value, i.e. > > ??? @Label("Valid From") > ??? @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) > ??? public long validFrom; > > ??? @Label("Valid Until") > ??? @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) > ??? public long validUntil; > The CertificateValidity class operates on Date Object values. I'll work with the Date.getTime() method then (and update the Logger formatting) > This following annotation adds little value > > @Description("Details of Security Property") > > I would either remove the annotation, or provide information that > helps a user understand the event. For instance, what is X509, and > what kind of certificates are we talking about? Yes - that looks like the wrong Description. I'll review all of these fields. > > @Category("Java Application") > > I'm a bit worried that we will pollute the "Java Application" > namespace if we add lots of JDK events in that category. We may want > to add a new top level category "Java Development Kit", analogous to > the "Java Virtual Machine" category, and put all security related > events in subcategory, perhaps called "Security". Yes - Open to suggestions. "Security" sounds like a good suggestion. > > @Label("X509Cert") > > The label should be human readable name, with spaces, title cased etc. > I would recommend "X.509 Certificate". In general, avoid abbreviations > like "certs" and instead use labels such as "Certificate Chain". The > label should be short and not a full sentence. > > For details see, > https://docs.oracle.com/javase/10/docs/api/jdk/jfr/Label.html > > I think it would be good to separate testing of JFR and logging into > different files / tests. I would prefer that the test name is the same > as the event prefixed with "Test", i.e TestX509CertificateEvent, as > this is the pattern used by other JFR tests. > I'll take a look at that pattern again. I've separated out the current tests into an (a) outer test to analyze the logger output and (b) the inner test which checks for JFR correctness. I did include extra logic to make sure that the EventHelper configuration was working correctly. "Events.assertField" looks very helpful. Thanks for the pointer. Let me take on board the suggestions below and get a new webrev out on Tuesday. regards, Sean. > I reworked one of the tests to how I like to see it: > > /* > ?* @test > ?* @key jfr > ?* @library /test/lib > ?* @run main/othervm jdk.jfr.event.security.TestX509CertificateEvent > ?*/ > public class TestX509CertificateEvent { > > ??? private static final String CERTIFICATE_1 = "..."; > ??? private static final String CERTIFICATE_2 = "..."; > > ??? public static void main(String... args) throws CertificateException { > > ???????? Recording r = new Recording(); > ???????? r.enable(EventNames.X509Certificate).withoutStackTrace(); > ???????? r.start(); > > ???????? CertificateFactory cf = CertificateFactory.getInstance("X.509"); > ???????? cf.generateCertificate(new > ByteArrayInputStream(CERTIFICATE_1.getBytes())); > ???????? cf.generateCertificate(new > ByteArrayInputStream(CERTIFICATE_2.getBytes())); > > ???????? // Make sure only one event per certificate > ???????? cf.generateCertificate(new > ByteArrayInputStream(CERTIFICATE_1.getBytes())); > ???????? cf.generateCertificate(new > ByteArrayInputStream(CERTIFICATE_2.getBytes())); > > ???????? r.stop(); > > ???????? List events = Events.fromRecording(r); > ???????? Asserts.assertEquals(events.size(), 2, "Expected two X.509 > Certificate events"); > > ???????? assertEvent(events, "1000", "SHA256withRSA", > ??????????????????? "CN=SSLCertificate, O=SomeCompany", > ??????????????????? "CN=Intermediate CA Cert, O=SomeCompany", > ???????????????????? "RSA", 2048); > ???????? assertEvent(events, "1000", "SHA256withRSA", > ??????????????????? "CN=SSLCertificate, O=SomeCompany", > ??????????????????? "CN=Intermediate CA Cert, O=SomeCompany", > ???????????????????? "RSA", 2048); > ??? } > > ??? private static void assertEvent(List events, String > certID, String algId, String subject, > ??????????? String issuer, String keyType, int length) throws Exception { > > ??????? for (RecordedEvent e : events) { > ??????????? if (e.getString("serialNumber").equals(certID)) { > ??????????????? Events.assertField(e, "algId").equal(algId); > ??????????????? ... > ??????????????? return; > ??????????? } > ??????? } > ??????? System.out.println(events); > ??????? throw new Exception("Could not find event with Cert ID: " + > certID); > ??? } > } > > The reworked example uses the Events.assertField method, which will > give context if the assertion fails. Keeping the test simple, means it > can be analyzed quickly if it fails in testing. There is no new test > framework to learn, or methods to search for, and it is usually not > hard to determine if the failure is product, test or infrastructure > related, and what component (team) should be assigned the issue. The > use of EventNames.X509Certificate means all occurrences of the event > can be tracked done in an IDE using find by reference. > > Thanks > Erik > >> Following on from the recent JDK-8203629 code review, I'd like to >> propose enhancements on how we can record events in security libs. >> The introduction of the JFR libraries can give us much better ways of >> examining JDK actions. For the initial phase, I'm looking to enhance >> some key security library events in JDK 11 so that they can be either >> recorded to JFR, logged to a traditional logger, or both. >> >> Examples of how useful JFR recordings could be can be seen here : >> >> http://cr.openjdk.java.net/~coffeys/event_snaps/X509Event_1.png >> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_1.png >> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_2.png >> http://cr.openjdk.java.net/~coffeys/event_snaps/TLSEvent_1.png >> >> securityProp_2.png gives an example of how the JFR recording can be >> queried to quickly locate events of interest (in this case, code >> setting the jdk.tls.* Security properties). I still need to clean up >> the TLSEvents testcase to improve test coverage and hope to do that >> in coming days. >> >> JBS record : >> ?* https://bugs.openjdk.java.net/browse/JDK-8148188 >> >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v1/webrev/ >> > From anthony.scarpino at oracle.com Mon Jun 25 22:07:01 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 25 Jun 2018 15:07:01 -0700 Subject: RFR 8203228: Branch-free output conversion for X25519 and X448 In-Reply-To: <31ab6859-caca-2f54-387d-be4c22fffc29@oracle.com> References: <31ab6859-caca-2f54-387d-be4c22fffc29@oracle.com> Message-ID: <52fa8aaf-2fca-b9ed-8c64-e74334a76a1c@oracle.com> The change looks fine to me Tony On 06/25/2018 05:49 AM, Adam Petcher wrote: > It would be nice to get this X25519/X448 enhancement into JDK 11. If > anyone has some time to review this in the next day or so, I would > appreciate it. > > > On 5/15/2018 2:42 PM, Adam Petcher wrote: >> Webrev: http://cr.openjdk.java.net/~apetcher/8203228/webrev.00/ >> >> Please review the change for this leftover task from the X25519/X448 >> JEP. The current code uses BigInteger to convert the final result from >> a field element to a byte array that can be used to derive a key. >> Using branch-free operations instead of BigInteger will protect this >> secret from certain side-channel attacks. >> >> The output conversion is done entirely by the asByteArray method of >> IntegerPolynomial, which is implemented by limbsToByteArray. For this >> change, I took the branch-free output conversion routine from the >> Poly1305 field and pushed it into the parent class. I had to >> generalize it a bit in order to deal with the peculiarities of the >> X25519/X448 fields and their representations. I also made >> addModPowerTwo branch free, because this was a relatively simple >> change once the rest was done. But this method is not used by >> X25519/X448. >> >> In addition to running the full regression test suite, I also ran some >> benchmarks on X25519 and X448 to confirm that performance wasn't >> impacted. Not surprising, since this method is only called once per >> key generation/agreement operation. >> > From xuelei.fan at oracle.com Tue Jun 26 02:25:28 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 25 Jun 2018 19:25:28 -0700 Subject: RFR 8202299: Java Keystore fails to load PKCS12/PFX certificates created in WindowsServer2016 In-Reply-To: <90C07E52-F88F-4FA1-9272-D90A009E3C55@oracle.com> References: <0A68EB2D-D19D-4D7D-ADF8-971758D15303@oracle.com> <575f6ca0-e115-c998-f0ea-30df7527f3bc@oracle.com> <90C07E52-F88F-4FA1-9272-D90A009E3C55@oracle.com> Message-ID: Looks fine to me. webrev.00 looks more straightforward to me. I did not see too much benefit to use functional programming in webrev.01. I will let you make the final decision. Xuelei On 5/17/2018 9:00 PM, Weijun Wang wrote: >> >> Seems more complicated and harder to understand that code. > > Not really. > > The former > > 373 byte[] keyInfo; > 374 while (true) { > 375 try { > 376 // Use JCE > 377 SecretKey skey = getPBEKey(password); > 378 Cipher cipher = Cipher.getInstance( > 379 mapPBEParamsToAlgorithm(algOid, algParams)); > 380 cipher.init(Cipher.DECRYPT_MODE, skey, algParams); > 381 keyInfo = cipher.doFinal(encryptedKey); > 382 break; > 383 } catch (Exception e) { > 384 if (password.length == 0) { > 385 // Retry using an empty password > 386 // without a NULL terminator. > 387 password = new char[1]; > 388 continue; > 389 } > 390 throw e; > 391 } > 392 } > > becomes > > 394 byte[] keyInfo = RetryWithZero.run(pass -> { > 395 // Use JCE > 396 SecretKey skey = getPBEKey(pass); > 397 Cipher cipher = Cipher.getInstance( > 398 mapPBEParamsToAlgorithm(algOid, algParams)); > 399 cipher.init(Cipher.DECRYPT_MODE, skey, algParams); > 400 return cipher.doFinal(encryptedKey); > 401 }, password); > > I would say it's clearer and pretty standard functional programming. > > Thanks > Max > From xuelei.fan at oracle.com Tue Jun 26 02:39:43 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 25 Jun 2018 19:39:43 -0700 Subject: RFR 8202608: CommonSeeder test needs a white-box testing mechanism to replace the default entropy source In-Reply-To: References: Message-ID: Looks fine to me. Thanks, Xuelei On 6/24/2018 6:22 PM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8202608/webrev.00/ > > I added a patched SeedGenerator and remove the reflection calls. > > A comment in AbstractDrbg.java removed. That's not a trusted application, it's evil. > > Thanks > Max > From weijun.wang at oracle.com Tue Jun 26 02:40:19 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 26 Jun 2018 10:40:19 +0800 Subject: RFR 8202299: Java Keystore fails to load PKCS12/PFX certificates created in WindowsServer2016 In-Reply-To: References: <0A68EB2D-D19D-4D7D-ADF8-971758D15303@oracle.com> <575f6ca0-e115-c998-f0ea-30df7527f3bc@oracle.com> <90C07E52-F88F-4FA1-9272-D90A009E3C55@oracle.com> Message-ID: <6A3A9E4B-B707-4A66-A09E-B733CC0B6CDB@oracle.com> Thanks for the code review. My feeling is that this is a very good chance to use functional programming, where a repeated pattern is abstracted to a general method that calls independent actions. I'd choose webrev.01. --Max > On Jun 26, 2018, at 10:25 AM, Xuelei Fan wrote: > > Looks fine to me. > > webrev.00 looks more straightforward to me. I did not see too much benefit to use functional programming in webrev.01. I will let you make the final decision. > > Xuelei > > On 5/17/2018 9:00 PM, Weijun Wang wrote: >>> >>> Seems more complicated and harder to understand that code. >> Not really. >> The former >> 373 byte[] keyInfo; >> 374 while (true) { >> 375 try { >> 376 // Use JCE >> 377 SecretKey skey = getPBEKey(password); >> 378 Cipher cipher = Cipher.getInstance( >> 379 mapPBEParamsToAlgorithm(algOid, algParams)); >> 380 cipher.init(Cipher.DECRYPT_MODE, skey, algParams); >> 381 keyInfo = cipher.doFinal(encryptedKey); >> 382 break; >> 383 } catch (Exception e) { >> 384 if (password.length == 0) { >> 385 // Retry using an empty password >> 386 // without a NULL terminator. >> 387 password = new char[1]; >> 388 continue; >> 389 } >> 390 throw e; >> 391 } >> 392 } >> becomes >> 394 byte[] keyInfo = RetryWithZero.run(pass -> { >> 395 // Use JCE >> 396 SecretKey skey = getPBEKey(pass); >> 397 Cipher cipher = Cipher.getInstance( >> 398 mapPBEParamsToAlgorithm(algOid, algParams)); >> 399 cipher.init(Cipher.DECRYPT_MODE, skey, algParams); >> 400 return cipher.doFinal(encryptedKey); >> 401 }, password); >> I would say it's clearer and pretty standard functional programming. >> Thanks >> Max From sibabrata.sahoo at oracle.com Tue Jun 26 07:09:33 2018 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Tue, 26 Jun 2018 00:09:33 -0700 (PDT) Subject: [11] RFR: JDK-8205111: Develop new Test to verify different key types for supported TLS protocols. In-Reply-To: <9dc623cc-67bd-32ec-d657-008cab3200a1@oracle.com> References: <528299c6-d5a1-4564-9dd7-7f0e1b8a7c89@default> <9dc623cc-67bd-32ec-d657-008cab3200a1@oracle.com> Message-ID: <23445427-9aed-4412-8226-ecd53687b179@default> Hi Xuelei, Please review the updated webrev: http://cr.openjdk.java.net/~ssahoo/8205111/webrev.01/ - Now rsa_pss_pss* uses " DHE or ECDHE_RSA " ciphers for TLSv1.2 which is working fine now. - Additional code added for " read/write " after re-handshake. John, - PKCS12 used instead of JKS. - Comment section for private key updated. - try with resource used for socket. - "clientRenegoReady" variable is actually used and updated. Please check the Client section too. It is used for re-handshake completion. Yes it Is working as expected. - Multiple @run added to have the flexibility to change the parameter(Cipher) which are not in order(shuffled). Thanks, Siba -----Original Message----- From: Xuelei Fan Sent: Thursday, June 21, 2018 7:28 PM To: Sibabrata Sahoo ; security-dev at openjdk.java.net Subject: Re: [11] RFR: JDK-8205111: Develop new Test to verify different key types for supported TLS protocols. Note that rsa_pss_pss cannot work with TLS_RSA_WITH cipher suites, as this algorithm is limited to signature whiel TLS_RSA cipher suites need key encipherment. In lines 135-156, you can replace the TLS_RSA cipher suite with DHE or ECDHE_RSA. For the re-handshake part, please read/write something after the call to startHandshake() in each side. Otherwise, the key-update and session resumption may not complete before socket close. Otherwise, looks fine to me. Thanks, Xuelei On 6/20/2018 11:58 PM, Sibabrata Sahoo wrote: > Hi Xuelei, > > Please review the patch for, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8205111 > > Webrev: http://cr.openjdk.java.net/~ssahoo/8205111/webrev.00/ > > Change: > > This Test file verifies all TLS protocols with the supported keytypes. > > Thanks, > > Siba > From amy.lu at oracle.com Tue Jun 26 09:20:18 2018 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 26 Jun 2018 17:20:18 +0800 Subject: [11] RFR 8205673: Problem list RmiRegistrySslTest.java and RmiSslBootstrapTest.sh Message-ID: <6bdad50f-4ac0-3595-d483-681b98fe4911@oracle.com> sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java Above two tests have been failing on all platforms (JDK-8205653) since JDK-8196584. Please review the patch to add these tests to ProblemList.txt until a full fix is developed. Thanks, Amy --- old/test/jdk/ProblemList.txt??? 2018-06-26 14:44:21.000000000 +0800 +++ new/test/jdk/ProblemList.txt??? 2018-06-26 14:44:21.000000000 +0800 @@ -542,6 +542,9 @@ ?com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java 8030957 aix-all ?com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java 8030957 aix-all +sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh 8205653 generic-all +sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java 8205653 generic-all + ?############################################################################ ?# jdk_jmx From chris.hegarty at oracle.com Tue Jun 26 10:45:47 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 26 Jun 2018 11:45:47 +0100 Subject: RFR [11] 8205671: Remove HTTP Client tests erroneously problem listed by the TLS 1.3 integration Message-ID: Seems that the integration of TLS 1.3 erroneously added a number of HTTP Client tests to the ProblemList. Previous to the TLS 1.3 push, work was done to ensure that the HTTP Client tests ran successfully with the changes in the TLS 1.3 branch. These tests should not have been problem listed. diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -561,22 +561,6 @@ java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 macosx-all -java/net/httpclient/ConcurrentResponses.java 8204977 generic-all -java/net/httpclient/DigestEchoClientSSL.java 8204977 generic-all -java/net/httpclient/EncodedCharsInURI.java 8204977 generic-all -java/net/httpclient/FlowAdapterSubscriberTest.java 8204977 generic-all -java/net/httpclient/ImmutableFlowItems.java 8204977 generic-all -java/net/httpclient/ManyRequests.java 8204977 generic-all -java/net/httpclient/ManyRequests2.java 8204977 generic-all -java/net/httpclient/SplitResponseSSL.java 8204977 generic-all -java/net/httpclient/http2/BasicTest.java 8204977 generic-all -java/net/httpclient/http2/ContinuationFrameTest.java 8204977 generic-all -java/net/httpclient/ProxyAuthDisabledSchemesSSL.java 8204977 generic-all -java/net/httpclient/RequestBodyTest.java 8204977 generic-all -java/net/httpclient/SmokeTest.java 8204977 generic-all -java/net/httpclient/CancelledResponse.java 8204977 solaris-all -java/net/httpclient/InvalidSSLContextTest.java 8204980 generic-all - ############################################################################ # jdk_nio -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.x.mcmahon at oracle.com Tue Jun 26 10:49:07 2018 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 26 Jun 2018 11:49:07 +0100 Subject: RFR [11] 8205671: Remove HTTP Client tests erroneously problem listed by the TLS 1.3 integration In-Reply-To: References: Message-ID: <5B321A23.3080106@oracle.com> Looks good Chris. - Michael. On 26/06/2018, 11:45, Chris Hegarty wrote: > Seems that the integration of TLS 1.3 erroneously added a number of > HTTP Client tests to the ProblemList. Previous to the TLS 1.3 push, > work was done to ensure that the HTTP Client tests ran successfully > with the changes in the TLS 1.3 branch. These tests should not have > been problem listed. > > diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -561,22 +561,6 @@ > > > java/net/DatagramSocket/SendDatagramToBadAddress.java > 7143960 macosx-all > > > -java/net/httpclient/ConcurrentResponses.java > 8204977 generic-all > -java/net/httpclient/DigestEchoClientSSL.java > 8204977 generic-all > -java/net/httpclient/EncodedCharsInURI.java > 8204977 generic-all > -java/net/httpclient/FlowAdapterSubscriberTest.java > 8204977 generic-all > -java/net/httpclient/ImmutableFlowItems.java > 8204977 generic-all > -java/net/httpclient/ManyRequests.java > 8204977 generic-all > -java/net/httpclient/ManyRequests2.java > 8204977 generic-all > -java/net/httpclient/SplitResponseSSL.java > 8204977 generic-all > -java/net/httpclient/http2/BasicTest.java > 8204977 generic-all > -java/net/httpclient/http2/ContinuationFrameTest.java > 8204977 generic-all > -java/net/httpclient/ProxyAuthDisabledSchemesSSL.java > 8204977 generic-all > -java/net/httpclient/RequestBodyTest.java > 8204977 generic-all > -java/net/httpclient/SmokeTest.java > 8204977 generic-all > -java/net/httpclient/CancelledResponse.java > 8204977 solaris-all > -java/net/httpclient/InvalidSSLContextTest.java > 8204980 generic-all > - > ############################################################################ > > > # jdk_nio > > > -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Tue Jun 26 10:50:12 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 26 Jun 2018 11:50:12 +0100 Subject: RFR [11] 8205671: Remove HTTP Client tests erroneously problem listed by the TLS 1.3 integration In-Reply-To: References: Message-ID: Looks good to me Chris. best, -- daniel On 26/06/2018 11:45, Chris Hegarty wrote: > Seems that the integration of TLS 1.3 erroneously added a number of HTTP > Client tests to the ProblemList. Previous to the TLS 1.3 push, work was > done to ensure that the HTTP Client tests ran successfully with the > changes in the TLS 1.3 branch. These tests should not have been problem > listed. > > diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -561,22 +561,6 @@ > > > ?java/net/DatagramSocket/SendDatagramToBadAddress.java > 7143960 macosx-all > > > -java/net/httpclient/ConcurrentResponses.java? ? ? ? ? ? ? ? ? ? 8204977 > generic-all > -java/net/httpclient/DigestEchoClientSSL.java? ? ? ? ? ? ? ? ? ? 8204977 > generic-all > -java/net/httpclient/EncodedCharsInURI.java? ? ? ? ? ? ? ? ? ? ? 8204977 > generic-all > -java/net/httpclient/FlowAdapterSubscriberTest.java? ? ? ? ? ? ? 8204977 > generic-all > -java/net/httpclient/ImmutableFlowItems.java ? ? ? ? ? ? ? ? ? ? 8204977 > generic-all > -java/net/httpclient/ManyRequests.java ? ? ? ? ? ? ? ? ? ? ? ? ? 8204977 > generic-all > -java/net/httpclient/ManyRequests2.java? ? ? ? ? ? ? ? ? ? ? ? ? 8204977 > generic-all > -java/net/httpclient/SplitResponseSSL.java ? ? ? ? ? ? ? ? ? ? ? 8204977 > generic-all > -java/net/httpclient/http2/BasicTest.java? ? ? ? ? ? ? ? ? ? ? ? 8204977 > generic-all > -java/net/httpclient/http2/ContinuationFrameTest.java? ? ? ? ? ? 8204977 > generic-all > -java/net/httpclient/ProxyAuthDisabledSchemesSSL.java? ? ? ? ? ? 8204977 > generic-all > -java/net/httpclient/RequestBodyTest.java? ? ? ? ? ? ? ? ? ? ? ? 8204977 > generic-all > -java/net/httpclient/SmokeTest.java? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 8204977 > generic-all > -java/net/httpclient/CancelledResponse.java? ? ? ? ? ? ? ? ? ? ? 8204977 > solaris-all > -java/net/httpclient/InvalidSSLContextTest.java? ? ? ? ? ? ? ? ? 8204980 > generic-all > - > ?############################################################################ > > > ?# jdk_nio > > > -Chris. From Xuelei.Fan at Oracle.Com Tue Jun 26 13:15:44 2018 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Tue, 26 Jun 2018 06:15:44 -0700 Subject: [11] RFR 8205673: Problem list RmiRegistrySslTest.java and RmiSslBootstrapTest.sh In-Reply-To: <6bdad50f-4ac0-3595-d483-681b98fe4911@oracle.com> References: <6bdad50f-4ac0-3595-d483-681b98fe4911@oracle.com> Message-ID: Looks fine to me. Thanks, Xuelei > On Jun 26, 2018, at 2:20 AM, Amy Lu wrote: > > sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh > sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java > > Above two tests have been failing on all platforms (JDK-8205653) since JDK-8196584. > > Please review the patch to add these tests to ProblemList.txt until a full fix is developed. > > Thanks, > Amy > > --- old/test/jdk/ProblemList.txt 2018-06-26 14:44:21.000000000 +0800 > +++ new/test/jdk/ProblemList.txt 2018-06-26 14:44:21.000000000 +0800 > @@ -542,6 +542,9 @@ > com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java 8030957 aix-all > com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java 8030957 aix-all > > +sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh 8205653 generic-all > +sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java 8205653 generic-all > + > ############################################################################ > > # jdk_jmx > From xuelei.fan at oracle.com Tue Jun 26 14:29:31 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 26 Jun 2018 07:29:31 -0700 Subject: [11] RFR: JDK-8205111: Develop new Test to verify different key types for supported TLS protocols. In-Reply-To: <23445427-9aed-4412-8226-ecd53687b179@default> References: <528299c6-d5a1-4564-9dd7-7f0e1b8a7c89@default> <9dc623cc-67bd-32ec-d657-008cab3200a1@oracle.com> <23445427-9aed-4412-8226-ecd53687b179@default> Message-ID: <3d84d8d4-f7d6-2a5d-f661-4f3438da5d15@oracle.com> Looks fine to me. Thanks, Xuelei On 6/26/2018 12:09 AM, Sibabrata Sahoo wrote: > Hi Xuelei, > > Please review the updated webrev: http://cr.openjdk.java.net/~ssahoo/8205111/webrev.01/ > > - Now rsa_pss_pss* uses " DHE or ECDHE_RSA " ciphers for TLSv1.2 which is working fine now. > - Additional code added for " read/write " after re-handshake. > > John, > - PKCS12 used instead of JKS. > - Comment section for private key updated. > - try with resource used for socket. > - "clientRenegoReady" variable is actually used and updated. Please check the Client section too. It is used for re-handshake completion. Yes it Is working as expected. > - Multiple @run added to have the flexibility to change the parameter(Cipher) which are not in order(shuffled). > > Thanks, > Siba > > -----Original Message----- > From: Xuelei Fan > Sent: Thursday, June 21, 2018 7:28 PM > To: Sibabrata Sahoo ; security-dev at openjdk.java.net > Subject: Re: [11] RFR: JDK-8205111: Develop new Test to verify different key types for supported TLS protocols. > > Note that rsa_pss_pss cannot work with TLS_RSA_WITH cipher suites, as this algorithm is limited to signature whiel TLS_RSA cipher suites need key encipherment. In lines 135-156, you can replace the TLS_RSA cipher suite with DHE or ECDHE_RSA. > > For the re-handshake part, please read/write something after the call to > startHandshake() in each side. Otherwise, the key-update and session resumption may not complete before socket close. > > Otherwise, looks fine to me. > > Thanks, > Xuelei > > On 6/20/2018 11:58 PM, Sibabrata Sahoo wrote: >> Hi Xuelei, >> >> Please review the patch for, >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8205111 >> >> Webrev: http://cr.openjdk.java.net/~ssahoo/8205111/webrev.00/ >> >> Change: >> >> This Test file verifies all TLS protocols with the supported keytypes. >> >> Thanks, >> >> Siba >> From sean.coffey at oracle.com Tue Jun 26 22:18:45 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 26 Jun 2018 23:18:45 +0100 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> Message-ID: <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> Erik, I rebased the patch with TLS v1.3 integration today. I hadn't realized how much the handshaker code had changed. Hopefully, I'll get a review from security dev team on that front. Regards the JFR semantics, I believe the edits should match majority of requests . I still have a preference for the test infra design for these new logger/JFR tests used in version 1 of webrev. I think it makes sense to keep the test functionality together - no sense in separating them out into different components IMO. Also, some of the edits to the JFR testing were made to test for the new dual log/record functionality. I might catch up with you tomorrow to see what the best arrangement would be. http://cr.openjdk.java.net/~coffeys/webrev.8148188.v2/webrev/ regards, Sean. On 25/06/2018 21:22, Se?n Coffey wrote: > Many thanks for the review comments Erik. Replies inline. > > > On 24/06/2018 14:21, Erik Gahlin wrote: >> Hi Sean, >> >> Some of the changes in the webrev belongs to JDK-8203629 and should >> be removed for clarity. >> >> Some initial comments: >> >> default.jfc, profile.jfr: >> The events should not have control="enable-exceptions". The purpose >> of the control attribute is so to provide parameterized configuration >> of events for JMC.? As it is now, the security events will be enabled >> when a user turns on the exception events. > Makes sense. I'll remove that parameter. >> >> X509CertEvent: >> You should use milliseconds since epoch to represent a date instead >> of a string value, i.e. >> >> ??? @Label("Valid From") >> ??? @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >> ??? public long validFrom; >> >> ??? @Label("Valid Until") >> ??? @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >> ??? public long validUntil; >> > The CertificateValidity class operates on Date Object values. I'll > work with the Date.getTime() method then (and update the Logger > formatting) >> This following annotation adds little value >> >> @Description("Details of Security Property") >> >> I would either remove the annotation, or provide information that >> helps a user understand the event. For instance, what is X509, and >> what kind of certificates are we talking about? > Yes - that looks like the wrong Description. I'll review all of these > fields. >> >> @Category("Java Application") >> >> I'm a bit worried that we will pollute the "Java Application" >> namespace if we add lots of JDK events in that category. We may want >> to add a new top level category "Java Development Kit", analogous to >> the "Java Virtual Machine" category, and put all security related >> events in subcategory, perhaps called "Security". > Yes - Open to suggestions. "Security" sounds like a good suggestion. >> >> @Label("X509Cert") >> >> The label should be human readable name, with spaces, title cased >> etc. I would recommend "X.509 Certificate". In general, avoid >> abbreviations like "certs" and instead use labels such as >> "Certificate Chain". The label should be short and not a full sentence. >> >> For details see, >> https://docs.oracle.com/javase/10/docs/api/jdk/jfr/Label.html >> >> I think it would be good to separate testing of JFR and logging into >> different files / tests. I would prefer that the test name is the >> same as the event prefixed with "Test", i.e TestX509CertificateEvent, >> as this is the pattern used by other JFR tests. >> > I'll take a look at that pattern again. I've separated out the current > tests into an (a) outer test to analyze the logger output and (b) the > inner test which checks for JFR correctness. I did include extra logic > to make sure that the EventHelper configuration was working correctly. > "Events.assertField" looks very helpful. Thanks for the pointer. > > Let me take on board the suggestions below and get a new webrev out on > Tuesday. > > regards, > Sean. > >> I reworked one of the tests to how I like to see it: >> >> /* >> ?* @test >> ?* @key jfr >> ?* @library /test/lib >> ?* @run main/othervm jdk.jfr.event.security.TestX509CertificateEvent >> ?*/ >> public class TestX509CertificateEvent { >> >> ??? private static final String CERTIFICATE_1 = "..."; >> ??? private static final String CERTIFICATE_2 = "..."; >> >> ??? public static void main(String... args) throws >> CertificateException { >> >> ???????? Recording r = new Recording(); >> r.enable(EventNames.X509Certificate).withoutStackTrace(); >> ???????? r.start(); >> >> ???????? CertificateFactory cf = >> CertificateFactory.getInstance("X.509"); >> ???????? cf.generateCertificate(new >> ByteArrayInputStream(CERTIFICATE_1.getBytes())); >> ???????? cf.generateCertificate(new >> ByteArrayInputStream(CERTIFICATE_2.getBytes())); >> >> ???????? // Make sure only one event per certificate >> ???????? cf.generateCertificate(new >> ByteArrayInputStream(CERTIFICATE_1.getBytes())); >> ???????? cf.generateCertificate(new >> ByteArrayInputStream(CERTIFICATE_2.getBytes())); >> >> ???????? r.stop(); >> >> ???????? List events = Events.fromRecording(r); >> ???????? Asserts.assertEquals(events.size(), 2, "Expected two X.509 >> Certificate events"); >> >> ???????? assertEvent(events, "1000", "SHA256withRSA", >> ??????????????????? "CN=SSLCertificate, O=SomeCompany", >> ??????????????????? "CN=Intermediate CA Cert, O=SomeCompany", >> ???????????????????? "RSA", 2048); >> ???????? assertEvent(events, "1000", "SHA256withRSA", >> ??????????????????? "CN=SSLCertificate, O=SomeCompany", >> ??????????????????? "CN=Intermediate CA Cert, O=SomeCompany", >> ???????????????????? "RSA", 2048); >> ??? } >> >> ??? private static void assertEvent(List events, >> String certID, String algId, String subject, >> ??????????? String issuer, String keyType, int length) throws >> Exception { >> >> ??????? for (RecordedEvent e : events) { >> ??????????? if (e.getString("serialNumber").equals(certID)) { >> ??????????????? Events.assertField(e, "algId").equal(algId); >> ??????????????? ... >> ??????????????? return; >> ??????????? } >> ??????? } >> ??????? System.out.println(events); >> ??????? throw new Exception("Could not find event with Cert ID: " + >> certID); >> ??? } >> } >> >> The reworked example uses the Events.assertField method, which will >> give context if the assertion fails. Keeping the test simple, means >> it can be analyzed quickly if it fails in testing. There is no new >> test framework to learn, or methods to search for, and it is usually >> not hard to determine if the failure is product, test or >> infrastructure related, and what component (team) should be assigned >> the issue. The use of EventNames.X509Certificate means all >> occurrences of the event can be tracked done in an IDE using find by >> reference. >> >> Thanks >> Erik >> >>> Following on from the recent JDK-8203629 code review, I'd like to >>> propose enhancements on how we can record events in security libs. >>> The introduction of the JFR libraries can give us much better ways >>> of examining JDK actions. For the initial phase, I'm looking to >>> enhance some key security library events in JDK 11 so that they can >>> be either recorded to JFR, logged to a traditional logger, or both. >>> >>> Examples of how useful JFR recordings could be can be seen here : >>> >>> http://cr.openjdk.java.net/~coffeys/event_snaps/X509Event_1.png >>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_1.png >>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_2.png >>> http://cr.openjdk.java.net/~coffeys/event_snaps/TLSEvent_1.png >>> >>> securityProp_2.png gives an example of how the JFR recording can be >>> queried to quickly locate events of interest (in this case, code >>> setting the jdk.tls.* Security properties). I still need to clean up >>> the TLSEvents testcase to improve test coverage and hope to do that >>> in coming days. >>> >>> JBS record : >>> ?* https://bugs.openjdk.java.net/browse/JDK-8148188 >>> >>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v1/webrev/ >>> >> > From weijun.wang at oracle.com Wed Jun 27 01:15:18 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 27 Jun 2018 09:15:18 +0800 Subject: On 8202598: [linux] keytool -certreq inconsistent with platform line.separator Message-ID: <0E5AEF12-8AD7-4866-A7D6-E4C8008A073C@oracle.com> Hi Severin and/or Andrew I'm going through all security bugs with JDK 11 in affected versions and noticed this one: 8202598: [linux] keytool -certreq inconsistent with platform line.separator https://bugs.openjdk.java.net/browse/JDK-8202598 What kind of interop issue have you observed? IMHO, \r\n is legal in a PEM file. Also, you mentioned a patch in the comment. Can I take a look? Thanks Max From sgehwolf at redhat.com Wed Jun 27 08:01:09 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 27 Jun 2018 10:01:09 +0200 Subject: On 8202598: [linux] keytool -certreq inconsistent with platform line.separator In-Reply-To: <0E5AEF12-8AD7-4866-A7D6-E4C8008A073C@oracle.com> References: <0E5AEF12-8AD7-4866-A7D6-E4C8008A073C@oracle.com> Message-ID: Hi Max, On Wed, 2018-06-27 at 09:15 +0800, Weijun Wang wrote: > Hi Severin and/or Andrew > > I'm going through all security bugs with JDK 11 in affected versions and noticed this one: > > 8202598: [linux] keytool -certreq inconsistent with platform line.separator > https://bugs.openjdk.java.net/browse/JDK-8202598 > > What kind of interop issue have you observed? IMHO, \r\n is legal in a PEM file. All we know is that this breaks interop with tools on Linux/Unix which don't expect \r\n in PEM files. > Also, you mentioned a patch in the comment. Can I take a look? I've posted a link to the JDK 8 patch in the bug report. Thanks, Severin From weijun.wang at oracle.com Wed Jun 27 08:28:08 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 27 Jun 2018 16:28:08 +0800 Subject: On 8202598: [linux] keytool -certreq inconsistent with platform line.separator In-Reply-To: References: <0E5AEF12-8AD7-4866-A7D6-E4C8008A073C@oracle.com> Message-ID: <749B5BD4-AA98-46CB-934B-706C17705806@oracle.com> > On Jun 27, 2018, at 4:01 PM, Severin Gehwolf wrote: > > Hi Max, > > On Wed, 2018-06-27 at 09:15 +0800, Weijun Wang wrote: >> Hi Severin and/or Andrew >> >> I'm going through all security bugs with JDK 11 in affected versions and noticed this one: >> >> 8202598: [linux] keytool -certreq inconsistent with platform line.separator >> https://bugs.openjdk.java.net/browse/JDK-8202598 >> >> What kind of interop issue have you observed? IMHO, \r\n is legal in a PEM file. > > All we know is that this breaks interop with tools on Linux/Unix which > don't expect \r\n in PEM files. > >> Also, you mentioned a patch in the comment. Can I take a look? > > I've posted a link to the JDK 8 patch in the bug report. A new option for keytool is too much at this stage (RDP1 begins tomorrow) and I feel uncomfortable to apply this option only to PKCS10. Now that this is reported on Linux/Unix, I assume users on those systems can easily find a workaround to s/\r\n/\n/ on the fly. Therefore I updated the Fix Version to tbd_major which means it's not necessary to fix it in JDK 11. If you find more information on what exact tool does not parse the input, please add a comment on it. I tried openssl and it has no problem. I do realize there is an inconsistency that there is only "\n" after the PEM header/footer but "\r\n" after each line. Maybe some tools are confused by this? Thanks Max > > Thanks, > Severin From weijun.wang at oracle.com Wed Jun 27 14:20:38 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 27 Jun 2018 22:20:38 +0800 Subject: RFR 8205927: Update src/java.base/share/legal/public_suffix.md to match the actual file version Message-ID: <2F5DE4AB-EF54-45B1-9A9F-48F996275C33@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8205927/webrev.00/ I missed a date and a link when pushing the change for JDK-8201815. Also, the latest MPL 2.0 uses https now. Thanks Max From tobias.wagner at n-design.de Wed Jun 27 15:28:46 2018 From: tobias.wagner at n-design.de (=?utf-8?Q?Tobias_Wagner?=) Date: Wed, 27 Jun 2018 17:28:46 +0200 Subject: RFR [11] CSR for "Add Brainpool ECC support (RFC 5639)" In-Reply-To: <46ebf4bd-ba09-657b-3c88-c884400edc36@oracle.com> References: <5b28158a.1c69fb81.da9dc.2500@mx.google.com> <46ebf4bd-ba09-657b-3c88-c884400edc36@oracle.com> Message-ID: A non-text attachment was scrubbed... Name: smime.p7m Type: application/x-pkcs7-mime Size: 10445 bytes Desc: not available URL: From tobias.wagner at n-design.de Wed Jun 27 15:48:29 2018 From: tobias.wagner at n-design.de (=?utf-8?Q?Tobias_Wagner?=) Date: Wed, 27 Jun 2018 17:48:29 +0200 Subject: AW: RFR [11] CSR for "Add Brainpool ECC support (RFC 5639)" In-Reply-To: <46ebf4bd-ba09-657b-3c88-c884400edc36@oracle.com> References: <5b28158a.1c69fb81.da9dc.2500@mx.google.com> <46ebf4bd-ba09-657b-3c88-c884400edc36@oracle.com> Message-ID: Hi Valerie and Bernd, Valerie is right, I tested my JTREG Tests against SoftHSM2 in March: http://mail.openjdk.java.net/pipermail/security-dev/2018-March/016863.html I don't think there are more PKCS#11 related issues, as SunEC is not a PKCS#11 implementation. There are only shared tests. The JTREG known answer tests use the X9.62 key format as they are used in certificates as well. I assume, brainpool public keys would work in certificates as well. I actually implemented the support for brainpool curves in TLS as well, but I had no time to provide proper JTREG tests for that, and therefore no patch yet. Regards, Tobias -- phone: +49 221 222896 17 fax: +49 221 222896 11 keybase: https://keybase.io/toebix n - d e s i g n G m b H https://n-design.de Alpenerstr. 16 50825 K?ln Deutschland / Germany Amtsgericht K?ln HRB 33766 B Gesch?ftsf?hrer Andy Kohl > -----Urspr?ngliche Nachricht----- > Von: security-dev Im Auftrag von > Valerie Peng > Gesendet: Donnerstag, 21. Juni 2018 01:07 > An: security-dev at openjdk.java.net > Betreff: Re: RFR [11] CSR for "Add Brainpool ECC support (RFC 5639)" > > Are you asking about CSR or existing bug for including Brainpool support > in TLS? > > I saw some bugs which mentions errors/exceptions which brainpool is > used, e.g. JSSE has https://bugs.openjdk.java.net/browse/JDK-7189107, > key tool has https://bugs.openjdk.java.net/browse/JDK-8201290. After > this brainpool support is integrated, it'll be easier to re-evaluate > these. > > > As for PKCS11, Tobias tested this against a 3rd party PKCS11 library and > the result is positive if I recall correctly. > > > Thanks, > Valerie > > > On 6/18/2018 1:26 PM, Bernd Eckenfels wrote: > > > Hello, > > > > not a Reviewer, but some Questions on the CSR: > > > > * Are there other CSRs for including in TLS? > * I also wonder if PKI (CA Signatures) will work out of the box > then (OID aliases?) > * Does PKCS11 require additional changes? (especially for the > Government use mentioned in the justification HSMs are often mandatory) > > > > Gruss > > Bernd > > -- > http://bernd.eckenfels.net > > > From adam.petcher at oracle.com Wed Jun 27 16:56:10 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 27 Jun 2018 12:56:10 -0400 Subject: Feedback on EdDSA API Message-ID: <79ca499f-24be-1059-7d4b-f96fcf36c9bd@oracle.com> I'm looking for some initial feedback on the proposed JCA API for EdDSA[2], which I have documented in a draft CSR ticket[1]. Any comments, concerns, suggestions, etc are appreciated. To summarize, the API for EdDSA looks a lot like the API for X25519/X448. Like X25519/X448, it does not allow the selection of arbitrary curve parameters. Though the API is flexible enough that it could be extended to allow more flexibility in the future (or immediately using provider-specific classes), if necessary. The EdDSA API is a little bit more complicated than X25519/X448, because public keys are points that cannot be expressed with a single coordinate, and because the signature scheme takes additional information related to the mode (pure, prehash, context). So we need a couple more classes to handle these complications, but otherwise the API is essentially the same as X25519/X448. [1] https://bugs.openjdk.java.net/browse/JDK-8190219 [2] https://tools.ietf.org/html/rfc8032 From xuelei.fan at oracle.com Wed Jun 27 18:57:37 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 27 Jun 2018 11:57:37 -0700 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> Message-ID: <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> Hi Sean, I may reply in several replies. PKIXMasterCertPathValidator.java -------------------------------- + CertChainEvent cce = new CertChainEvent(); + if(cce.isEnabled() || EventHelper.loggingSecurity()) { + String c = reversedCertList.stream() + .map(x -> x.getSerialNumber().toString(16)) + .collect(Collectors.joining(", ")); + EventHelper.commitCertChainEvent(cce, c); + } No matter the event or the JFR mechanism is enabled or not, the above code will create a new instance. Is the return value of cce.isEnabled() dynamically changed or static? Is there a need to support both logging and JFR? I'm new to record events. I did not get the point to use both. Thanks, Xuelei On 6/26/2018 3:18 PM, Se?n Coffey wrote: > Erik, > > I rebased the patch with TLS v1.3 integration today. I hadn't realized > how much the handshaker code had changed. Hopefully, I'll get a review > from security dev team on that front. > > Regards the JFR semantics, I believe the edits should match majority of > requests . I still have a preference for the test infra design for these > new logger/JFR tests used in version 1 of webrev. I think it makes sense > to keep the test functionality together - no sense in separating them > out into different components IMO. Also, some of the edits to the JFR > testing were made to test for the new dual log/record functionality. I > might catch up with you tomorrow to see what the best arrangement would be. > > http://cr.openjdk.java.net/~coffeys/webrev.8148188.v2/webrev/ > > regards, > Sean. > > > On 25/06/2018 21:22, Se?n Coffey wrote: >> Many thanks for the review comments Erik. Replies inline. >> >> >> On 24/06/2018 14:21, Erik Gahlin wrote: >>> Hi Sean, >>> >>> Some of the changes in the webrev belongs to JDK-8203629 and should >>> be removed for clarity. >>> >>> Some initial comments: >>> >>> default.jfc, profile.jfr: >>> The events should not have control="enable-exceptions". The purpose >>> of the control attribute is so to provide parameterized configuration >>> of events for JMC.? As it is now, the security events will be enabled >>> when a user turns on the exception events. >> Makes sense. I'll remove that parameter. >>> >>> X509CertEvent: >>> You should use milliseconds since epoch to represent a date instead >>> of a string value, i.e. >>> >>> ??? @Label("Valid From") >>> ??? @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>> ??? public long validFrom; >>> >>> ??? @Label("Valid Until") >>> ??? @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>> ??? public long validUntil; >>> >> The CertificateValidity class operates on Date Object values. I'll >> work with the Date.getTime() method then (and update the Logger >> formatting) >>> This following annotation adds little value >>> >>> @Description("Details of Security Property") >>> >>> I would either remove the annotation, or provide information that >>> helps a user understand the event. For instance, what is X509, and >>> what kind of certificates are we talking about? >> Yes - that looks like the wrong Description. I'll review all of these >> fields. >>> >>> @Category("Java Application") >>> >>> I'm a bit worried that we will pollute the "Java Application" >>> namespace if we add lots of JDK events in that category. We may want >>> to add a new top level category "Java Development Kit", analogous to >>> the "Java Virtual Machine" category, and put all security related >>> events in subcategory, perhaps called "Security". >> Yes - Open to suggestions. "Security" sounds like a good suggestion. >>> >>> @Label("X509Cert") >>> >>> The label should be human readable name, with spaces, title cased >>> etc. I would recommend "X.509 Certificate". In general, avoid >>> abbreviations like "certs" and instead use labels such as >>> "Certificate Chain". The label should be short and not a full sentence. >>> >>> For details see, >>> https://docs.oracle.com/javase/10/docs/api/jdk/jfr/Label.html >>> >>> I think it would be good to separate testing of JFR and logging into >>> different files / tests. I would prefer that the test name is the >>> same as the event prefixed with "Test", i.e TestX509CertificateEvent, >>> as this is the pattern used by other JFR tests. >>> >> I'll take a look at that pattern again. I've separated out the current >> tests into an (a) outer test to analyze the logger output and (b) the >> inner test which checks for JFR correctness. I did include extra logic >> to make sure that the EventHelper configuration was working correctly. >> "Events.assertField" looks very helpful. Thanks for the pointer. >> >> Let me take on board the suggestions below and get a new webrev out on >> Tuesday. >> >> regards, >> Sean. >> >>> I reworked one of the tests to how I like to see it: >>> >>> /* >>> ?* @test >>> ?* @key jfr >>> ?* @library /test/lib >>> ?* @run main/othervm jdk.jfr.event.security.TestX509CertificateEvent >>> ?*/ >>> public class TestX509CertificateEvent { >>> >>> ??? private static final String CERTIFICATE_1 = "..."; >>> ??? private static final String CERTIFICATE_2 = "..."; >>> >>> ??? public static void main(String... args) throws >>> CertificateException { >>> >>> ???????? Recording r = new Recording(); >>> r.enable(EventNames.X509Certificate).withoutStackTrace(); >>> ???????? r.start(); >>> >>> ???????? CertificateFactory cf = >>> CertificateFactory.getInstance("X.509"); >>> ???????? cf.generateCertificate(new >>> ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>> ???????? cf.generateCertificate(new >>> ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>> >>> ???????? // Make sure only one event per certificate >>> ???????? cf.generateCertificate(new >>> ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>> ???????? cf.generateCertificate(new >>> ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>> >>> ???????? r.stop(); >>> >>> ???????? List events = Events.fromRecording(r); >>> ???????? Asserts.assertEquals(events.size(), 2, "Expected two X.509 >>> Certificate events"); >>> >>> ???????? assertEvent(events, "1000", "SHA256withRSA", >>> ??????????????????? "CN=SSLCertificate, O=SomeCompany", >>> ??????????????????? "CN=Intermediate CA Cert, O=SomeCompany", >>> ???????????????????? "RSA", 2048); >>> ???????? assertEvent(events, "1000", "SHA256withRSA", >>> ??????????????????? "CN=SSLCertificate, O=SomeCompany", >>> ??????????????????? "CN=Intermediate CA Cert, O=SomeCompany", >>> ???????????????????? "RSA", 2048); >>> ??? } >>> >>> ??? private static void assertEvent(List events, >>> String certID, String algId, String subject, >>> ??????????? String issuer, String keyType, int length) throws >>> Exception { >>> >>> ??????? for (RecordedEvent e : events) { >>> ??????????? if (e.getString("serialNumber").equals(certID)) { >>> ??????????????? Events.assertField(e, "algId").equal(algId); >>> ??????????????? ... >>> ??????????????? return; >>> ??????????? } >>> ??????? } >>> ??????? System.out.println(events); >>> ??????? throw new Exception("Could not find event with Cert ID: " + >>> certID); >>> ??? } >>> } >>> >>> The reworked example uses the Events.assertField method, which will >>> give context if the assertion fails. Keeping the test simple, means >>> it can be analyzed quickly if it fails in testing. There is no new >>> test framework to learn, or methods to search for, and it is usually >>> not hard to determine if the failure is product, test or >>> infrastructure related, and what component (team) should be assigned >>> the issue. The use of EventNames.X509Certificate means all >>> occurrences of the event can be tracked done in an IDE using find by >>> reference. >>> >>> Thanks >>> Erik >>> >>>> Following on from the recent JDK-8203629 code review, I'd like to >>>> propose enhancements on how we can record events in security libs. >>>> The introduction of the JFR libraries can give us much better ways >>>> of examining JDK actions. For the initial phase, I'm looking to >>>> enhance some key security library events in JDK 11 so that they can >>>> be either recorded to JFR, logged to a traditional logger, or both. >>>> >>>> Examples of how useful JFR recordings could be can be seen here : >>>> >>>> http://cr.openjdk.java.net/~coffeys/event_snaps/X509Event_1.png >>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_1.png >>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_2.png >>>> http://cr.openjdk.java.net/~coffeys/event_snaps/TLSEvent_1.png >>>> >>>> securityProp_2.png gives an example of how the JFR recording can be >>>> queried to quickly locate events of interest (in this case, code >>>> setting the jdk.tls.* Security properties). I still need to clean up >>>> the TLSEvents testcase to improve test coverage and hope to do that >>>> in coming days. >>>> >>>> JBS record : >>>> ?* https://bugs.openjdk.java.net/browse/JDK-8148188 >>>> >>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v1/webrev/ >>>> >>> >> > From sean.coffey at oracle.com Wed Jun 27 19:14:04 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 27 Jun 2018 20:14:04 +0100 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> Message-ID: On 27/06/2018 19:57, Xuelei Fan wrote: > Hi Sean, > > I may reply in several replies. > > PKIXMasterCertPathValidator.java > -------------------------------- > +? CertChainEvent cce = new CertChainEvent(); > +? if(cce.isEnabled() || EventHelper.loggingSecurity()) { > +????? String c = reversedCertList.stream() > +????????????????? .map(x -> x.getSerialNumber().toString(16)) > +??????????????????????? .collect(Collectors.joining(", ")); > +???? EventHelper.commitCertChainEvent(cce, c); > +?? } > > No matter the event or the JFR mechanism is enabled or not, the above > code will create a new instance.? Is the return value of > cce.isEnabled() dynamically changed or static? This is a requirement from the JFR framework. All their event.isEnabled calls are instance methods and follow a similar pattern. The JFR team assure me that the JIT can optimize away such calls. > > Is there a need to support both logging and JFR?? I'm new to record > events.? I did not get the point to use both. I was initially hoping to concentrate on just JFR events but I got strong feedback to also consider use of Logger (esp. in cases where the jdk.jfr module is not available) regards, Sean. > > Thanks, > Xuelei > > On 6/26/2018 3:18 PM, Se?n Coffey wrote: >> Erik, >> >> I rebased the patch with TLS v1.3 integration today. I hadn't >> realized how much the handshaker code had changed. Hopefully, I'll >> get a review from security dev team on that front. >> >> Regards the JFR semantics, I believe the edits should match majority >> of requests . I still have a preference for the test infra design for >> these new logger/JFR tests used in version 1 of webrev. I think it >> makes sense to keep the test functionality together - no sense in >> separating them out into different components IMO. Also, some of the >> edits to the JFR testing were made to test for the new dual >> log/record functionality. I might catch up with you tomorrow to see >> what the best arrangement would be. >> >> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v2/webrev/ >> >> regards, >> Sean. >> >> >> On 25/06/2018 21:22, Se?n Coffey wrote: >>> Many thanks for the review comments Erik. Replies inline. >>> >>> >>> On 24/06/2018 14:21, Erik Gahlin wrote: >>>> Hi Sean, >>>> >>>> Some of the changes in the webrev belongs to JDK-8203629 and should >>>> be removed for clarity. >>>> >>>> Some initial comments: >>>> >>>> default.jfc, profile.jfr: >>>> The events should not have control="enable-exceptions". The purpose >>>> of the control attribute is so to provide parameterized >>>> configuration of events for JMC.? As it is now, the security events >>>> will be enabled when a user turns on the exception events. >>> Makes sense. I'll remove that parameter. >>>> >>>> X509CertEvent: >>>> You should use milliseconds since epoch to represent a date instead >>>> of a string value, i.e. >>>> >>>> ??? @Label("Valid From") >>>> ??? @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>>> ??? public long validFrom; >>>> >>>> ??? @Label("Valid Until") >>>> ??? @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>>> ??? public long validUntil; >>>> >>> The CertificateValidity class operates on Date Object values. I'll >>> work with the Date.getTime() method then (and update the Logger >>> formatting) >>>> This following annotation adds little value >>>> >>>> @Description("Details of Security Property") >>>> >>>> I would either remove the annotation, or provide information that >>>> helps a user understand the event. For instance, what is X509, and >>>> what kind of certificates are we talking about? >>> Yes - that looks like the wrong Description. I'll review all of >>> these fields. >>>> >>>> @Category("Java Application") >>>> >>>> I'm a bit worried that we will pollute the "Java Application" >>>> namespace if we add lots of JDK events in that category. We may >>>> want to add a new top level category "Java Development Kit", >>>> analogous to the "Java Virtual Machine" category, and put all >>>> security related events in subcategory, perhaps called "Security". >>> Yes - Open to suggestions. "Security" sounds like a good suggestion. >>>> >>>> @Label("X509Cert") >>>> >>>> The label should be human readable name, with spaces, title cased >>>> etc. I would recommend "X.509 Certificate". In general, avoid >>>> abbreviations like "certs" and instead use labels such as >>>> "Certificate Chain". The label should be short and not a full >>>> sentence. >>>> >>>> For details see, >>>> https://docs.oracle.com/javase/10/docs/api/jdk/jfr/Label.html >>>> >>>> I think it would be good to separate testing of JFR and logging >>>> into different files / tests. I would prefer that the test name is >>>> the same as the event prefixed with "Test", i.e >>>> TestX509CertificateEvent, as this is the pattern used by other JFR >>>> tests. >>>> >>> I'll take a look at that pattern again. I've separated out the >>> current tests into an (a) outer test to analyze the logger output >>> and (b) the inner test which checks for JFR correctness. I did >>> include extra logic to make sure that the EventHelper configuration >>> was working correctly. "Events.assertField" looks very helpful. >>> Thanks for the pointer. >>> >>> Let me take on board the suggestions below and get a new webrev out >>> on Tuesday. >>> >>> regards, >>> Sean. >>> >>>> I reworked one of the tests to how I like to see it: >>>> >>>> /* >>>> ?* @test >>>> ?* @key jfr >>>> ?* @library /test/lib >>>> ?* @run main/othervm jdk.jfr.event.security.TestX509CertificateEvent >>>> ?*/ >>>> public class TestX509CertificateEvent { >>>> >>>> ??? private static final String CERTIFICATE_1 = "..."; >>>> ??? private static final String CERTIFICATE_2 = "..."; >>>> >>>> ??? public static void main(String... args) throws >>>> CertificateException { >>>> >>>> ???????? Recording r = new Recording(); >>>> r.enable(EventNames.X509Certificate).withoutStackTrace(); >>>> ???????? r.start(); >>>> >>>> ???????? CertificateFactory cf = >>>> CertificateFactory.getInstance("X.509"); >>>> ???????? cf.generateCertificate(new >>>> ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>>> ???????? cf.generateCertificate(new >>>> ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>>> >>>> ???????? // Make sure only one event per certificate >>>> ???????? cf.generateCertificate(new >>>> ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>>> ???????? cf.generateCertificate(new >>>> ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>>> >>>> ???????? r.stop(); >>>> >>>> ???????? List events = Events.fromRecording(r); >>>> ???????? Asserts.assertEquals(events.size(), 2, "Expected two X.509 >>>> Certificate events"); >>>> >>>> ???????? assertEvent(events, "1000", "SHA256withRSA", >>>> ??????????????????? "CN=SSLCertificate, O=SomeCompany", >>>> ??????????????????? "CN=Intermediate CA Cert, O=SomeCompany", >>>> ???????????????????? "RSA", 2048); >>>> ???????? assertEvent(events, "1000", "SHA256withRSA", >>>> ??????????????????? "CN=SSLCertificate, O=SomeCompany", >>>> ??????????????????? "CN=Intermediate CA Cert, O=SomeCompany", >>>> ???????????????????? "RSA", 2048); >>>> ??? } >>>> >>>> ??? private static void assertEvent(List events, >>>> String certID, String algId, String subject, >>>> ??????????? String issuer, String keyType, int length) throws >>>> Exception { >>>> >>>> ??????? for (RecordedEvent e : events) { >>>> ??????????? if (e.getString("serialNumber").equals(certID)) { >>>> ??????????????? Events.assertField(e, "algId").equal(algId); >>>> ??????????????? ... >>>> ??????????????? return; >>>> ??????????? } >>>> ??????? } >>>> ??????? System.out.println(events); >>>> ??????? throw new Exception("Could not find event with Cert ID: " + >>>> certID); >>>> ??? } >>>> } >>>> >>>> The reworked example uses the Events.assertField method, which will >>>> give context if the assertion fails. Keeping the test simple, means >>>> it can be analyzed quickly if it fails in testing. There is no new >>>> test framework to learn, or methods to search for, and it is >>>> usually not hard to determine if the failure is product, test or >>>> infrastructure related, and what component (team) should be >>>> assigned the issue. The use of EventNames.X509Certificate means all >>>> occurrences of the event can be tracked done in an IDE using find >>>> by reference. >>>> >>>> Thanks >>>> Erik >>>> >>>>> Following on from the recent JDK-8203629 code review, I'd like to >>>>> propose enhancements on how we can record events in security libs. >>>>> The introduction of the JFR libraries can give us much better ways >>>>> of examining JDK actions. For the initial phase, I'm looking to >>>>> enhance some key security library events in JDK 11 so that they >>>>> can be either recorded to JFR, logged to a traditional logger, or >>>>> both. >>>>> >>>>> Examples of how useful JFR recordings could be can be seen here : >>>>> >>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/X509Event_1.png >>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_1.png >>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_2.png >>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/TLSEvent_1.png >>>>> >>>>> securityProp_2.png gives an example of how the JFR recording can >>>>> be queried to quickly locate events of interest (in this case, >>>>> code setting the jdk.tls.* Security properties). I still need to >>>>> clean up the TLSEvents testcase to improve test coverage and hope >>>>> to do that in coming days. >>>>> >>>>> JBS record : >>>>> ?* https://bugs.openjdk.java.net/browse/JDK-8148188 >>>>> >>>>> webrev : >>>>> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v1/webrev/ >>>>> >>>> >>> >> From xuelei.fan at oracle.com Wed Jun 27 19:46:49 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 27 Jun 2018 12:46:49 -0700 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> Message-ID: KeyUtil.java ------------ 167 public static String getKeyAlgorithm(Key key) { I may suggest remove this method and use Key.getAlgorithm() directly. The KeyUtil.getKeyAlgorithm() is incomplete, and may need additional maintenance if new key algorithms are added in the future. For example, in JDK 11, "RSASSA-PSS" and "XDH" are added, but we really forgot that we may need to update this file as well. On 6/27/2018 12:14 PM, Se?n Coffey wrote: > > > On 27/06/2018 19:57, Xuelei Fan wrote: >> Hi Sean, >> >> I may reply in several replies. >> >> PKIXMasterCertPathValidator.java >> -------------------------------- >> +? CertChainEvent cce = new CertChainEvent(); >> +? if(cce.isEnabled() || EventHelper.loggingSecurity()) { >> +????? String c = reversedCertList.stream() >> +????????????????? .map(x -> x.getSerialNumber().toString(16)) >> +??????????????????????? .collect(Collectors.joining(", ")); >> +???? EventHelper.commitCertChainEvent(cce, c); >> +?? } >> >> No matter the event or the JFR mechanism is enabled or not, the above >> code will create a new instance.? Is the return value of >> cce.isEnabled() dynamically changed or static? > This is a requirement from the JFR framework. All their event.isEnabled > calls are instance methods and follow a similar pattern. The JFR team > assure me that the JIT can optimize away such calls. Got it. >> >> Is there a need to support both logging and JFR?? I'm new to record >> events.? I did not get the point to use both. > I was initially hoping to concentrate on just JFR events but I got > strong feedback to also consider use of Logger (esp. in cases where the > jdk.jfr module is not available) > There are three logging mechanisms: JFR, record event log and the component debugging log. It is a little bit overloaded to me. If jdk.jfr is not available, the existing component debugging log may be used instead. I think you must have weight this decision in the past, so I will accept your decision if you want to keep it. Thanks, Xuelei > regards, > Sean. > >> >> Thanks, >> Xuelei >> >> On 6/26/2018 3:18 PM, Se?n Coffey wrote: >>> Erik, >>> >>> I rebased the patch with TLS v1.3 integration today. I hadn't >>> realized how much the handshaker code had changed. Hopefully, I'll >>> get a review from security dev team on that front. >>> >>> Regards the JFR semantics, I believe the edits should match majority >>> of requests . I still have a preference for the test infra design for >>> these new logger/JFR tests used in version 1 of webrev. I think it >>> makes sense to keep the test functionality together - no sense in >>> separating them out into different components IMO. Also, some of the >>> edits to the JFR testing were made to test for the new dual >>> log/record functionality. I might catch up with you tomorrow to see >>> what the best arrangement would be. >>> >>> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v2/webrev/ >>> >>> regards, >>> Sean. >>> >>> >>> On 25/06/2018 21:22, Se?n Coffey wrote: >>>> Many thanks for the review comments Erik. Replies inline. >>>> >>>> >>>> On 24/06/2018 14:21, Erik Gahlin wrote: >>>>> Hi Sean, >>>>> >>>>> Some of the changes in the webrev belongs to JDK-8203629 and should >>>>> be removed for clarity. >>>>> >>>>> Some initial comments: >>>>> >>>>> default.jfc, profile.jfr: >>>>> The events should not have control="enable-exceptions". The purpose >>>>> of the control attribute is so to provide parameterized >>>>> configuration of events for JMC.? As it is now, the security events >>>>> will be enabled when a user turns on the exception events. >>>> Makes sense. I'll remove that parameter. >>>>> >>>>> X509CertEvent: >>>>> You should use milliseconds since epoch to represent a date instead >>>>> of a string value, i.e. >>>>> >>>>> ??? @Label("Valid From") >>>>> ??? @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>>>> ??? public long validFrom; >>>>> >>>>> ??? @Label("Valid Until") >>>>> ??? @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>>>> ??? public long validUntil; >>>>> >>>> The CertificateValidity class operates on Date Object values. I'll >>>> work with the Date.getTime() method then (and update the Logger >>>> formatting) >>>>> This following annotation adds little value >>>>> >>>>> @Description("Details of Security Property") >>>>> >>>>> I would either remove the annotation, or provide information that >>>>> helps a user understand the event. For instance, what is X509, and >>>>> what kind of certificates are we talking about? >>>> Yes - that looks like the wrong Description. I'll review all of >>>> these fields. >>>>> >>>>> @Category("Java Application") >>>>> >>>>> I'm a bit worried that we will pollute the "Java Application" >>>>> namespace if we add lots of JDK events in that category. We may >>>>> want to add a new top level category "Java Development Kit", >>>>> analogous to the "Java Virtual Machine" category, and put all >>>>> security related events in subcategory, perhaps called "Security". >>>> Yes - Open to suggestions. "Security" sounds like a good suggestion. >>>>> >>>>> @Label("X509Cert") >>>>> >>>>> The label should be human readable name, with spaces, title cased >>>>> etc. I would recommend "X.509 Certificate". In general, avoid >>>>> abbreviations like "certs" and instead use labels such as >>>>> "Certificate Chain". The label should be short and not a full >>>>> sentence. >>>>> >>>>> For details see, >>>>> https://docs.oracle.com/javase/10/docs/api/jdk/jfr/Label.html >>>>> >>>>> I think it would be good to separate testing of JFR and logging >>>>> into different files / tests. I would prefer that the test name is >>>>> the same as the event prefixed with "Test", i.e >>>>> TestX509CertificateEvent, as this is the pattern used by other JFR >>>>> tests. >>>>> >>>> I'll take a look at that pattern again. I've separated out the >>>> current tests into an (a) outer test to analyze the logger output >>>> and (b) the inner test which checks for JFR correctness. I did >>>> include extra logic to make sure that the EventHelper configuration >>>> was working correctly. "Events.assertField" looks very helpful. >>>> Thanks for the pointer. >>>> >>>> Let me take on board the suggestions below and get a new webrev out >>>> on Tuesday. >>>> >>>> regards, >>>> Sean. >>>> >>>>> I reworked one of the tests to how I like to see it: >>>>> >>>>> /* >>>>> ?* @test >>>>> ?* @key jfr >>>>> ?* @library /test/lib >>>>> ?* @run main/othervm jdk.jfr.event.security.TestX509CertificateEvent >>>>> ?*/ >>>>> public class TestX509CertificateEvent { >>>>> >>>>> ??? private static final String CERTIFICATE_1 = "..."; >>>>> ??? private static final String CERTIFICATE_2 = "..."; >>>>> >>>>> ??? public static void main(String... args) throws >>>>> CertificateException { >>>>> >>>>> ???????? Recording r = new Recording(); >>>>> r.enable(EventNames.X509Certificate).withoutStackTrace(); >>>>> ???????? r.start(); >>>>> >>>>> ???????? CertificateFactory cf = >>>>> CertificateFactory.getInstance("X.509"); >>>>> ???????? cf.generateCertificate(new >>>>> ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>>>> ???????? cf.generateCertificate(new >>>>> ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>>>> >>>>> ???????? // Make sure only one event per certificate >>>>> ???????? cf.generateCertificate(new >>>>> ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>>>> ???????? cf.generateCertificate(new >>>>> ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>>>> >>>>> ???????? r.stop(); >>>>> >>>>> ???????? List events = Events.fromRecording(r); >>>>> ???????? Asserts.assertEquals(events.size(), 2, "Expected two X.509 >>>>> Certificate events"); >>>>> >>>>> ???????? assertEvent(events, "1000", "SHA256withRSA", >>>>> ??????????????????? "CN=SSLCertificate, O=SomeCompany", >>>>> ??????????????????? "CN=Intermediate CA Cert, O=SomeCompany", >>>>> ???????????????????? "RSA", 2048); >>>>> ???????? assertEvent(events, "1000", "SHA256withRSA", >>>>> ??????????????????? "CN=SSLCertificate, O=SomeCompany", >>>>> ??????????????????? "CN=Intermediate CA Cert, O=SomeCompany", >>>>> ???????????????????? "RSA", 2048); >>>>> ??? } >>>>> >>>>> ??? private static void assertEvent(List events, >>>>> String certID, String algId, String subject, >>>>> ??????????? String issuer, String keyType, int length) throws >>>>> Exception { >>>>> >>>>> ??????? for (RecordedEvent e : events) { >>>>> ??????????? if (e.getString("serialNumber").equals(certID)) { >>>>> ??????????????? Events.assertField(e, "algId").equal(algId); >>>>> ??????????????? ... >>>>> ??????????????? return; >>>>> ??????????? } >>>>> ??????? } >>>>> ??????? System.out.println(events); >>>>> ??????? throw new Exception("Could not find event with Cert ID: " + >>>>> certID); >>>>> ??? } >>>>> } >>>>> >>>>> The reworked example uses the Events.assertField method, which will >>>>> give context if the assertion fails. Keeping the test simple, means >>>>> it can be analyzed quickly if it fails in testing. There is no new >>>>> test framework to learn, or methods to search for, and it is >>>>> usually not hard to determine if the failure is product, test or >>>>> infrastructure related, and what component (team) should be >>>>> assigned the issue. The use of EventNames.X509Certificate means all >>>>> occurrences of the event can be tracked done in an IDE using find >>>>> by reference. >>>>> >>>>> Thanks >>>>> Erik >>>>> >>>>>> Following on from the recent JDK-8203629 code review, I'd like to >>>>>> propose enhancements on how we can record events in security libs. >>>>>> The introduction of the JFR libraries can give us much better ways >>>>>> of examining JDK actions. For the initial phase, I'm looking to >>>>>> enhance some key security library events in JDK 11 so that they >>>>>> can be either recorded to JFR, logged to a traditional logger, or >>>>>> both. >>>>>> >>>>>> Examples of how useful JFR recordings could be can be seen here : >>>>>> >>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/X509Event_1.png >>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_1.png >>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_2.png >>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/TLSEvent_1.png >>>>>> >>>>>> securityProp_2.png gives an example of how the JFR recording can >>>>>> be queried to quickly locate events of interest (in this case, >>>>>> code setting the jdk.tls.* Security properties). I still need to >>>>>> clean up the TLSEvents testcase to improve test coverage and hope >>>>>> to do that in coming days. >>>>>> >>>>>> JBS record : >>>>>> ?* https://bugs.openjdk.java.net/browse/JDK-8148188 >>>>>> >>>>>> webrev : >>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v1/webrev/ >>>>>> >>>>> >>>> >>> > From xuelei.fan at oracle.com Wed Jun 27 20:11:14 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 27 Jun 2018 13:11:14 -0700 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> Message-ID: Finished.java ------------- In each handshake, Finished messages are delivered twice. One from client, and the other one from the server side. Catch Finished message and use the final one of them should be sufficient. In the Finished.java implementation, the signal of the final Finished message is the handshakeFinished field is set to true. Please move line 582: 582 recordEvent(chc.conContext.conSession); to line 558: 556 // handshake context cleanup. 557 chc.handshakeFinished = true; 558 Please move line 632: 632 recordEvent(shc.conContext.conSession); to line 608: 606 // handshake context cleanup. 607 shc.handshakeFinished = true; 608 Please remove line 838: 838 recordEvent(shc.conContext.conSession); Please remove line 984: 984 recordEvent(chc.conContext.conSession); No more comment. Thanks, Xuelei On 6/27/2018 11:57 AM, Xuelei Fan wrote: > Hi Sean, > > I may reply in several replies. > > PKIXMasterCertPathValidator.java > -------------------------------- > +? CertChainEvent cce = new CertChainEvent(); > +? if(cce.isEnabled() || EventHelper.loggingSecurity()) { > +????? String c = reversedCertList.stream() > +????????????????? .map(x -> x.getSerialNumber().toString(16)) > +??????????????????????? .collect(Collectors.joining(", ")); > +???? EventHelper.commitCertChainEvent(cce, c); > +?? } > > No matter the event or the JFR mechanism is enabled or not, the above > code will create a new instance.? Is the return value of cce.isEnabled() > dynamically changed or static? > > Is there a need to support both logging and JFR?? I'm new to record > events.? I did not get the point to use both. > > Thanks, > Xuelei > > On 6/26/2018 3:18 PM, Se?n Coffey wrote: >> Erik, >> >> I rebased the patch with TLS v1.3 integration today. I hadn't realized >> how much the handshaker code had changed. Hopefully, I'll get a review >> from security dev team on that front. >> >> Regards the JFR semantics, I believe the edits should match majority >> of requests . I still have a preference for the test infra design for >> these new logger/JFR tests used in version 1 of webrev. I think it >> makes sense to keep the test functionality together - no sense in >> separating them out into different components IMO. Also, some of the >> edits to the JFR testing were made to test for the new dual log/record >> functionality. I might catch up with you tomorrow to see what the best >> arrangement would be. >> >> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v2/webrev/ >> >> regards, >> Sean. >> >> >> On 25/06/2018 21:22, Se?n Coffey wrote: >>> Many thanks for the review comments Erik. Replies inline. >>> >>> >>> On 24/06/2018 14:21, Erik Gahlin wrote: >>>> Hi Sean, >>>> >>>> Some of the changes in the webrev belongs to JDK-8203629 and should >>>> be removed for clarity. >>>> >>>> Some initial comments: >>>> >>>> default.jfc, profile.jfr: >>>> The events should not have control="enable-exceptions". The purpose >>>> of the control attribute is so to provide parameterized >>>> configuration of events for JMC.? As it is now, the security events >>>> will be enabled when a user turns on the exception events. >>> Makes sense. I'll remove that parameter. >>>> >>>> X509CertEvent: >>>> You should use milliseconds since epoch to represent a date instead >>>> of a string value, i.e. >>>> >>>> ??? @Label("Valid From") >>>> ??? @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>>> ??? public long validFrom; >>>> >>>> ??? @Label("Valid Until") >>>> ??? @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>>> ??? public long validUntil; >>>> >>> The CertificateValidity class operates on Date Object values. I'll >>> work with the Date.getTime() method then (and update the Logger >>> formatting) >>>> This following annotation adds little value >>>> >>>> @Description("Details of Security Property") >>>> >>>> I would either remove the annotation, or provide information that >>>> helps a user understand the event. For instance, what is X509, and >>>> what kind of certificates are we talking about? >>> Yes - that looks like the wrong Description. I'll review all of these >>> fields. >>>> >>>> @Category("Java Application") >>>> >>>> I'm a bit worried that we will pollute the "Java Application" >>>> namespace if we add lots of JDK events in that category. We may want >>>> to add a new top level category "Java Development Kit", analogous to >>>> the "Java Virtual Machine" category, and put all security related >>>> events in subcategory, perhaps called "Security". >>> Yes - Open to suggestions. "Security" sounds like a good suggestion. >>>> >>>> @Label("X509Cert") >>>> >>>> The label should be human readable name, with spaces, title cased >>>> etc. I would recommend "X.509 Certificate". In general, avoid >>>> abbreviations like "certs" and instead use labels such as >>>> "Certificate Chain". The label should be short and not a full sentence. >>>> >>>> For details see, >>>> https://docs.oracle.com/javase/10/docs/api/jdk/jfr/Label.html >>>> >>>> I think it would be good to separate testing of JFR and logging into >>>> different files / tests. I would prefer that the test name is the >>>> same as the event prefixed with "Test", i.e >>>> TestX509CertificateEvent, as this is the pattern used by other JFR >>>> tests. >>>> >>> I'll take a look at that pattern again. I've separated out the >>> current tests into an (a) outer test to analyze the logger output and >>> (b) the inner test which checks for JFR correctness. I did include >>> extra logic to make sure that the EventHelper configuration was >>> working correctly. "Events.assertField" looks very helpful. Thanks >>> for the pointer. >>> >>> Let me take on board the suggestions below and get a new webrev out >>> on Tuesday. >>> >>> regards, >>> Sean. >>> >>>> I reworked one of the tests to how I like to see it: >>>> >>>> /* >>>> ?* @test >>>> ?* @key jfr >>>> ?* @library /test/lib >>>> ?* @run main/othervm jdk.jfr.event.security.TestX509CertificateEvent >>>> ?*/ >>>> public class TestX509CertificateEvent { >>>> >>>> ??? private static final String CERTIFICATE_1 = "..."; >>>> ??? private static final String CERTIFICATE_2 = "..."; >>>> >>>> ??? public static void main(String... args) throws >>>> CertificateException { >>>> >>>> ???????? Recording r = new Recording(); >>>> r.enable(EventNames.X509Certificate).withoutStackTrace(); >>>> ???????? r.start(); >>>> >>>> ???????? CertificateFactory cf = >>>> CertificateFactory.getInstance("X.509"); >>>> ???????? cf.generateCertificate(new >>>> ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>>> ???????? cf.generateCertificate(new >>>> ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>>> >>>> ???????? // Make sure only one event per certificate >>>> ???????? cf.generateCertificate(new >>>> ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>>> ???????? cf.generateCertificate(new >>>> ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>>> >>>> ???????? r.stop(); >>>> >>>> ???????? List events = Events.fromRecording(r); >>>> ???????? Asserts.assertEquals(events.size(), 2, "Expected two X.509 >>>> Certificate events"); >>>> >>>> ???????? assertEvent(events, "1000", "SHA256withRSA", >>>> ??????????????????? "CN=SSLCertificate, O=SomeCompany", >>>> ??????????????????? "CN=Intermediate CA Cert, O=SomeCompany", >>>> ???????????????????? "RSA", 2048); >>>> ???????? assertEvent(events, "1000", "SHA256withRSA", >>>> ??????????????????? "CN=SSLCertificate, O=SomeCompany", >>>> ??????????????????? "CN=Intermediate CA Cert, O=SomeCompany", >>>> ???????????????????? "RSA", 2048); >>>> ??? } >>>> >>>> ??? private static void assertEvent(List events, >>>> String certID, String algId, String subject, >>>> ??????????? String issuer, String keyType, int length) throws >>>> Exception { >>>> >>>> ??????? for (RecordedEvent e : events) { >>>> ??????????? if (e.getString("serialNumber").equals(certID)) { >>>> ??????????????? Events.assertField(e, "algId").equal(algId); >>>> ??????????????? ... >>>> ??????????????? return; >>>> ??????????? } >>>> ??????? } >>>> ??????? System.out.println(events); >>>> ??????? throw new Exception("Could not find event with Cert ID: " + >>>> certID); >>>> ??? } >>>> } >>>> >>>> The reworked example uses the Events.assertField method, which will >>>> give context if the assertion fails. Keeping the test simple, means >>>> it can be analyzed quickly if it fails in testing. There is no new >>>> test framework to learn, or methods to search for, and it is usually >>>> not hard to determine if the failure is product, test or >>>> infrastructure related, and what component (team) should be assigned >>>> the issue. The use of EventNames.X509Certificate means all >>>> occurrences of the event can be tracked done in an IDE using find by >>>> reference. >>>> >>>> Thanks >>>> Erik >>>> >>>>> Following on from the recent JDK-8203629 code review, I'd like to >>>>> propose enhancements on how we can record events in security libs. >>>>> The introduction of the JFR libraries can give us much better ways >>>>> of examining JDK actions. For the initial phase, I'm looking to >>>>> enhance some key security library events in JDK 11 so that they can >>>>> be either recorded to JFR, logged to a traditional logger, or both. >>>>> >>>>> Examples of how useful JFR recordings could be can be seen here : >>>>> >>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/X509Event_1.png >>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_1.png >>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_2.png >>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/TLSEvent_1.png >>>>> >>>>> securityProp_2.png gives an example of how the JFR recording can be >>>>> queried to quickly locate events of interest (in this case, code >>>>> setting the jdk.tls.* Security properties). I still need to clean >>>>> up the TLSEvents testcase to improve test coverage and hope to do >>>>> that in coming days. >>>>> >>>>> JBS record : >>>>> ?* https://bugs.openjdk.java.net/browse/JDK-8148188 >>>>> >>>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v1/webrev/ >>>>> >>>> >>> >> From rajan.halade at oracle.com Wed Jun 27 20:16:08 2018 From: rajan.halade at oracle.com (Rajan Halade) Date: Wed, 27 Jun 2018 13:16:08 -0700 Subject: RFR: 8195774: Add Entrust root certificates Message-ID: <39dee0bc-2125-8f0a-f3a7-80952b0491cc@oracle.com> Please review this fix to add entrust root certificates to cacerts. Webrev: http://cr.openjdk.java.net/~rhalade/8195774/webrev.00/ Thanks, Rajan From weijun.wang at oracle.com Thu Jun 28 02:33:06 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 28 Jun 2018 10:33:06 +0800 Subject: RFR: 8195774: Add Entrust root certificates In-Reply-To: <39dee0bc-2125-8f0a-f3a7-80952b0491cc@oracle.com> References: <39dee0bc-2125-8f0a-f3a7-80952b0491cc@oracle.com> Message-ID: <508F02AA-BFF6-40CA-91BD-DC987F396E82@oracle.com> The change looks fine. Thanks Max > On Jun 28, 2018, at 4:16 AM, Rajan Halade wrote: > > Please review this fix to add entrust root certificates to cacerts. > > Webrev: http://cr.openjdk.java.net/~rhalade/8195774/webrev.00/ > > Thanks, > Rajan From sean.coffey at oracle.com Thu Jun 28 12:28:07 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 28 Jun 2018 13:28:07 +0100 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> Message-ID: <25b3ae82-5c97-ff18-d0f9-4bfea00c29cb@oracle.com> Thanks for reviewing Xuelei, I do acknowledge that the new TLS v1.3 code has greatly improved the logging output for related operations. I think the main drive with this enhancement is to use the new JFR API to capture interesting events. We can revisit the Logger requirements if there's a strong opinion from users. By default, both the new Logger and JFR output will be switched off. I've just made an edit to the JFR jfc files to disable these events. "I may suggest remove this method and use Key.getAlgorithm() directly." - Yes, great idea. Done. Thanks for feedback on Finished.java edits. I did question to myself whether fewer edits were sufficient given the client/server nature of the handshake. I've refreshed the webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v3/webrev/ some jfr side edits also : * Change label from "X.509 Certificate" to "X509 Certificate" - JFR test fails with "." usage * Move the instance field variable name in CertChainEvent to "certChain" - JFR tests discourage use of? "ID" in "certIDs" regards, Sean. On 27/06/2018 21:11, Xuelei Fan wrote: > Finished.java > ------------- > In each handshake, Finished messages are delivered twice.? One from > client, and the other one from the server side.? Catch Finished > message and use the final one of them should be sufficient. > > In the Finished.java implementation, the signal of the final Finished > message is the handshakeFinished field is set to true. > > Please move line 582: > ?582???????????? recordEvent(chc.conContext.conSession); > to line 558: > ?556???????????????? // handshake context cleanup. > ?557???????????????? chc.handshakeFinished = true; > ?558 > > Please move line 632: > ?632???????????? recordEvent(shc.conContext.conSession); > to line 608: > ?606???????????????? // handshake context cleanup. > ?607???????????????? shc.handshakeFinished = true; > ?608 > > Please remove line 838: > ?838???????????? recordEvent(shc.conContext.conSession); > > Please remove line 984: > ?984???????????? recordEvent(chc.conContext.conSession); > > No more comment. > > Thanks, > Xuelei > > On 6/27/2018 11:57 AM, Xuelei Fan wrote: >> Hi Sean, >> >> I may reply in several replies. >> >> PKIXMasterCertPathValidator.java >> -------------------------------- >> +? CertChainEvent cce = new CertChainEvent(); >> +? if(cce.isEnabled() || EventHelper.loggingSecurity()) { >> +????? String c = reversedCertList.stream() >> +????????????????? .map(x -> x.getSerialNumber().toString(16)) >> +??????????????????????? .collect(Collectors.joining(", ")); >> +???? EventHelper.commitCertChainEvent(cce, c); >> +?? } >> >> No matter the event or the JFR mechanism is enabled or not, the above >> code will create a new instance.? Is the return value of >> cce.isEnabled() dynamically changed or static? >> >> Is there a need to support both logging and JFR?? I'm new to record >> events.? I did not get the point to use both. >> >> Thanks, >> Xuelei >> >> On 6/26/2018 3:18 PM, Se?n Coffey wrote: >>> Erik, >>> >>> I rebased the patch with TLS v1.3 integration today. I hadn't >>> realized how much the handshaker code had changed. Hopefully, I'll >>> get a review from security dev team on that front. >>> >>> Regards the JFR semantics, I believe the edits should match majority >>> of requests . I still have a preference for the test infra design >>> for these new logger/JFR tests used in version 1 of webrev. I think >>> it makes sense to keep the test functionality together - no sense in >>> separating them out into different components IMO. Also, some of the >>> edits to the JFR testing were made to test for the new dual >>> log/record functionality. I might catch up with you tomorrow to see >>> what the best arrangement would be. >>> >>> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v2/webrev/ >>> >>> regards, >>> Sean. >>> >>> >>> On 25/06/2018 21:22, Se?n Coffey wrote: >>>> Many thanks for the review comments Erik. Replies inline. >>>> >>>> >>>> On 24/06/2018 14:21, Erik Gahlin wrote: >>>>> Hi Sean, >>>>> >>>>> Some of the changes in the webrev belongs to JDK-8203629 and >>>>> should be removed for clarity. >>>>> >>>>> Some initial comments: >>>>> >>>>> default.jfc, profile.jfr: >>>>> The events should not have control="enable-exceptions". The >>>>> purpose of the control attribute is so to provide parameterized >>>>> configuration of events for JMC.? As it is now, the security >>>>> events will be enabled when a user turns on the exception events. >>>> Makes sense. I'll remove that parameter. >>>>> >>>>> X509CertEvent: >>>>> You should use milliseconds since epoch to represent a date >>>>> instead of a string value, i.e. >>>>> >>>>> ??? @Label("Valid From") >>>>> ??? @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>>>> ??? public long validFrom; >>>>> >>>>> ??? @Label("Valid Until") >>>>> ??? @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>>>> ??? public long validUntil; >>>>> >>>> The CertificateValidity class operates on Date Object values. I'll >>>> work with the Date.getTime() method then (and update the Logger >>>> formatting) >>>>> This following annotation adds little value >>>>> >>>>> @Description("Details of Security Property") >>>>> >>>>> I would either remove the annotation, or provide information that >>>>> helps a user understand the event. For instance, what is X509, and >>>>> what kind of certificates are we talking about? >>>> Yes - that looks like the wrong Description. I'll review all of >>>> these fields. >>>>> >>>>> @Category("Java Application") >>>>> >>>>> I'm a bit worried that we will pollute the "Java Application" >>>>> namespace if we add lots of JDK events in that category. We may >>>>> want to add a new top level category "Java Development Kit", >>>>> analogous to the "Java Virtual Machine" category, and put all >>>>> security related events in subcategory, perhaps called "Security". >>>> Yes - Open to suggestions. "Security" sounds like a good suggestion. >>>>> >>>>> @Label("X509Cert") >>>>> >>>>> The label should be human readable name, with spaces, title cased >>>>> etc. I would recommend "X.509 Certificate". In general, avoid >>>>> abbreviations like "certs" and instead use labels such as >>>>> "Certificate Chain". The label should be short and not a full >>>>> sentence. >>>>> >>>>> For details see, >>>>> https://docs.oracle.com/javase/10/docs/api/jdk/jfr/Label.html >>>>> >>>>> I think it would be good to separate testing of JFR and logging >>>>> into different files / tests. I would prefer that the test name is >>>>> the same as the event prefixed with "Test", i.e >>>>> TestX509CertificateEvent, as this is the pattern used by other JFR >>>>> tests. >>>>> >>>> I'll take a look at that pattern again. I've separated out the >>>> current tests into an (a) outer test to analyze the logger output >>>> and (b) the inner test which checks for JFR correctness. I did >>>> include extra logic to make sure that the EventHelper configuration >>>> was working correctly. "Events.assertField" looks very helpful. >>>> Thanks for the pointer. >>>> >>>> Let me take on board the suggestions below and get a new webrev out >>>> on Tuesday. >>>> >>>> regards, >>>> Sean. >>>> >>>>> I reworked one of the tests to how I like to see it: >>>>> >>>>> /* >>>>> ?* @test >>>>> ?* @key jfr >>>>> ?* @library /test/lib >>>>> ?* @run main/othervm jdk.jfr.event.security.TestX509CertificateEvent >>>>> ?*/ >>>>> public class TestX509CertificateEvent { >>>>> >>>>> ??? private static final String CERTIFICATE_1 = "..."; >>>>> ??? private static final String CERTIFICATE_2 = "..."; >>>>> >>>>> ??? public static void main(String... args) throws >>>>> CertificateException { >>>>> >>>>> ???????? Recording r = new Recording(); >>>>> r.enable(EventNames.X509Certificate).withoutStackTrace(); >>>>> ???????? r.start(); >>>>> >>>>> ???????? CertificateFactory cf = >>>>> CertificateFactory.getInstance("X.509"); >>>>> ???????? cf.generateCertificate(new >>>>> ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>>>> ???????? cf.generateCertificate(new >>>>> ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>>>> >>>>> ???????? // Make sure only one event per certificate >>>>> ???????? cf.generateCertificate(new >>>>> ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>>>> ???????? cf.generateCertificate(new >>>>> ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>>>> >>>>> ???????? r.stop(); >>>>> >>>>> ???????? List events = Events.fromRecording(r); >>>>> ???????? Asserts.assertEquals(events.size(), 2, "Expected two >>>>> X.509 Certificate events"); >>>>> >>>>> ???????? assertEvent(events, "1000", "SHA256withRSA", >>>>> ??????????????????? "CN=SSLCertificate, O=SomeCompany", >>>>> ??????????????????? "CN=Intermediate CA Cert, O=SomeCompany", >>>>> ???????????????????? "RSA", 2048); >>>>> ???????? assertEvent(events, "1000", "SHA256withRSA", >>>>> ??????????????????? "CN=SSLCertificate, O=SomeCompany", >>>>> ??????????????????? "CN=Intermediate CA Cert, O=SomeCompany", >>>>> ???????????????????? "RSA", 2048); >>>>> ??? } >>>>> >>>>> ??? private static void assertEvent(List events, >>>>> String certID, String algId, String subject, >>>>> ??????????? String issuer, String keyType, int length) throws >>>>> Exception { >>>>> >>>>> ??????? for (RecordedEvent e : events) { >>>>> ??????????? if (e.getString("serialNumber").equals(certID)) { >>>>> ??????????????? Events.assertField(e, "algId").equal(algId); >>>>> ??????????????? ... >>>>> ??????????????? return; >>>>> ??????????? } >>>>> ??????? } >>>>> ??????? System.out.println(events); >>>>> ??????? throw new Exception("Could not find event with Cert ID: " >>>>> + certID); >>>>> ??? } >>>>> } >>>>> >>>>> The reworked example uses the Events.assertField method, which >>>>> will give context if the assertion fails. Keeping the test simple, >>>>> means it can be analyzed quickly if it fails in testing. There is >>>>> no new test framework to learn, or methods to search for, and it >>>>> is usually not hard to determine if the failure is product, test >>>>> or infrastructure related, and what component (team) should be >>>>> assigned the issue. The use of EventNames.X509Certificate means >>>>> all occurrences of the event can be tracked done in an IDE using >>>>> find by reference. >>>>> >>>>> Thanks >>>>> Erik >>>>> >>>>>> Following on from the recent JDK-8203629 code review, I'd like to >>>>>> propose enhancements on how we can record events in security >>>>>> libs. The introduction of the JFR libraries can give us much >>>>>> better ways of examining JDK actions. For the initial phase, I'm >>>>>> looking to enhance some key security library events in JDK 11 so >>>>>> that they can be either recorded to JFR, logged to a traditional >>>>>> logger, or both. >>>>>> >>>>>> Examples of how useful JFR recordings could be can be seen here : >>>>>> >>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/X509Event_1.png >>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_1.png >>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_2.png >>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/TLSEvent_1.png >>>>>> >>>>>> securityProp_2.png gives an example of how the JFR recording can >>>>>> be queried to quickly locate events of interest (in this case, >>>>>> code setting the jdk.tls.* Security properties). I still need to >>>>>> clean up the TLSEvents testcase to improve test coverage and hope >>>>>> to do that in coming days. >>>>>> >>>>>> JBS record : >>>>>> ?* https://bugs.openjdk.java.net/browse/JDK-8148188 >>>>>> >>>>>> webrev : >>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v1/webrev/ >>>>>> >>>>> >>>> >>> From sean.coffey at oracle.com Thu Jun 28 12:32:16 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 28 Jun 2018 13:32:16 +0100 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: <5B33EC28.6090604@oracle.com> References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> <5B33EC28.6090604@oracle.com> Message-ID: Thanks for the update Erik. By default I'm proposing that the new JFR Events and Logger be disabled. As a result the event class shouldn't escape. If performance metrics highlight an issue, we should revisit. regards, Sean. On 27/06/2018 20:57, Erik Gahlin wrote: > On 2018-06-27 21:14, Se?n Coffey wrote: >> >> >> On 27/06/2018 19:57, Xuelei Fan wrote: >>> Hi Sean, >>> >>> I may reply in several replies. >>> >>> PKIXMasterCertPathValidator.java >>> -------------------------------- >>> +? CertChainEvent cce = new CertChainEvent(); >>> +? if(cce.isEnabled() || EventHelper.loggingSecurity()) { >>> +????? String c = reversedCertList.stream() >>> +????????????????? .map(x -> x.getSerialNumber().toString(16)) >>> +??????????????????????? .collect(Collectors.joining(", ")); >>> +???? EventHelper.commitCertChainEvent(cce, c); >>> +?? } >>> >>> No matter the event or the JFR mechanism is enabled or not, the >>> above code will create a new instance.? Is the return value of >>> cce.isEnabled() dynamically changed or static? >> This is a requirement from the JFR framework. All their >> event.isEnabled calls are instance methods and follow a similar >> pattern. The JFR team assure me that the JIT can optimize away such >> calls. > > The JIT will most likely not be able to optimize if the event class > escapes. > > From a JFR perspective, this would be the preferred layout: > > EventA eventA= new EventA(); > eventA.value = this.value; > eventA.commit(); > > and then do logging separately: > > System.Logger.log(DEBUG, this.value) > > With this layout, the JIT will remove the allocation and dead store. > > If it is expensive to gather the data for the event, like the > CertChainEvent above, the following pattern should be used. > > EventB eventB= new EventB (); > if (eventB.shouldCommit()) { > ?? eventB.value = calculateValue(); > ?? eventB .commit(); > } > > If JFR is not enabled, shouldCommit returns false and the JIT should > be able to remove the allocation.? This will be best from a > performance point of view, and also in my opinion from a maintenance > and readability perspective. Others may disagree. > > Erik > >>> >>> Is there a need to support both logging and JFR?? I'm new to record >>> events.? I did not get the point to use both. >> I was initially hoping to concentrate on just JFR events but I got >> strong feedback to also consider use of Logger (esp. in cases where >> the jdk.jfr module is not available) >> >> regards, >> Sean. >> >>> >>> Thanks, >>> Xuelei >>> >>> On 6/26/2018 3:18 PM, Se?n Coffey wrote: >>>> Erik, >>>> >>>> I rebased the patch with TLS v1.3 integration today. I hadn't >>>> realized how much the handshaker code had changed. Hopefully, I'll >>>> get a review from security dev team on that front. >>>> >>>> Regards the JFR semantics, I believe the edits should match >>>> majority of requests . I still have a preference for the test infra >>>> design for these new logger/JFR tests used in version 1 of webrev. >>>> I think it makes sense to keep the test functionality together - no >>>> sense in separating them out into different components IMO. Also, >>>> some of the edits to the JFR testing were made to test for the new >>>> dual log/record functionality. I might catch up with you tomorrow >>>> to see what the best arrangement would be. >>>> >>>> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v2/webrev/ >>>> >>>> regards, >>>> Sean. >>>> >>>> >>>> On 25/06/2018 21:22, Se?n Coffey wrote: >>>>> Many thanks for the review comments Erik. Replies inline. >>>>> >>>>> >>>>> On 24/06/2018 14:21, Erik Gahlin wrote: >>>>>> Hi Sean, >>>>>> >>>>>> Some of the changes in the webrev belongs to JDK-8203629 and >>>>>> should be removed for clarity. >>>>>> >>>>>> Some initial comments: >>>>>> >>>>>> default.jfc, profile.jfr: >>>>>> The events should not have control="enable-exceptions". The >>>>>> purpose of the control attribute is so to provide parameterized >>>>>> configuration of events for JMC.? As it is now, the security >>>>>> events will be enabled when a user turns on the exception events. >>>>> Makes sense. I'll remove that parameter. >>>>>> >>>>>> X509CertEvent: >>>>>> You should use milliseconds since epoch to represent a date >>>>>> instead of a string value, i.e. >>>>>> >>>>>> ??? @Label("Valid From") >>>>>> ??? @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>>>>> ??? public long validFrom; >>>>>> >>>>>> ??? @Label("Valid Until") >>>>>> ??? @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>>>>> ??? public long validUntil; >>>>>> >>>>> The CertificateValidity class operates on Date Object values. I'll >>>>> work with the Date.getTime() method then (and update the Logger >>>>> formatting) >>>>>> This following annotation adds little value >>>>>> >>>>>> @Description("Details of Security Property") >>>>>> >>>>>> I would either remove the annotation, or provide information that >>>>>> helps a user understand the event. For instance, what is X509, >>>>>> and what kind of certificates are we talking about? >>>>> Yes - that looks like the wrong Description. I'll review all of >>>>> these fields. >>>>>> >>>>>> @Category("Java Application") >>>>>> >>>>>> I'm a bit worried that we will pollute the "Java Application" >>>>>> namespace if we add lots of JDK events in that category. We may >>>>>> want to add a new top level category "Java Development Kit", >>>>>> analogous to the "Java Virtual Machine" category, and put all >>>>>> security related events in subcategory, perhaps called "Security". >>>>> Yes - Open to suggestions. "Security" sounds like a good suggestion. >>>>>> >>>>>> @Label("X509Cert") >>>>>> >>>>>> The label should be human readable name, with spaces, title cased >>>>>> etc. I would recommend "X.509 Certificate". In general, avoid >>>>>> abbreviations like "certs" and instead use labels such as >>>>>> "Certificate Chain". The label should be short and not a full >>>>>> sentence. >>>>>> >>>>>> For details see, >>>>>> https://docs.oracle.com/javase/10/docs/api/jdk/jfr/Label.html >>>>>> >>>>>> I think it would be good to separate testing of JFR and logging >>>>>> into different files / tests. I would prefer that the test name >>>>>> is the same as the event prefixed with "Test", i.e >>>>>> TestX509CertificateEvent, as this is the pattern used by other >>>>>> JFR tests. >>>>>> >>>>> I'll take a look at that pattern again. I've separated out the >>>>> current tests into an (a) outer test to analyze the logger output >>>>> and (b) the inner test which checks for JFR correctness. I did >>>>> include extra logic to make sure that the EventHelper >>>>> configuration was working correctly. "Events.assertField" looks >>>>> very helpful. Thanks for the pointer. >>>>> >>>>> Let me take on board the suggestions below and get a new webrev >>>>> out on Tuesday. >>>>> >>>>> regards, >>>>> Sean. >>>>> >>>>>> I reworked one of the tests to how I like to see it: >>>>>> >>>>>> /* >>>>>> ?* @test >>>>>> ?* @key jfr >>>>>> ?* @library /test/lib >>>>>> ?* @run main/othervm jdk.jfr.event.security.TestX509CertificateEvent >>>>>> ?*/ >>>>>> public class TestX509CertificateEvent { >>>>>> >>>>>> ??? private static final String CERTIFICATE_1 = "..."; >>>>>> ??? private static final String CERTIFICATE_2 = "..."; >>>>>> >>>>>> ??? public static void main(String... args) throws >>>>>> CertificateException { >>>>>> >>>>>> ???????? Recording r = new Recording(); >>>>>> r.enable(EventNames.X509Certificate).withoutStackTrace(); >>>>>> ???????? r.start(); >>>>>> >>>>>> ???????? CertificateFactory cf = >>>>>> CertificateFactory.getInstance("X.509"); >>>>>> ???????? cf.generateCertificate(new >>>>>> ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>>>>> ???????? cf.generateCertificate(new >>>>>> ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>>>>> >>>>>> ???????? // Make sure only one event per certificate >>>>>> ???????? cf.generateCertificate(new >>>>>> ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>>>>> ???????? cf.generateCertificate(new >>>>>> ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>>>>> >>>>>> ???????? r.stop(); >>>>>> >>>>>> ???????? List events = Events.fromRecording(r); >>>>>> ???????? Asserts.assertEquals(events.size(), 2, "Expected two >>>>>> X.509 Certificate events"); >>>>>> >>>>>> ???????? assertEvent(events, "1000", "SHA256withRSA", >>>>>> ??????????????????? "CN=SSLCertificate, O=SomeCompany", >>>>>> ??????????????????? "CN=Intermediate CA Cert, O=SomeCompany", >>>>>> ???????????????????? "RSA", 2048); >>>>>> ???????? assertEvent(events, "1000", "SHA256withRSA", >>>>>> ??????????????????? "CN=SSLCertificate, O=SomeCompany", >>>>>> ??????????????????? "CN=Intermediate CA Cert, O=SomeCompany", >>>>>> ???????????????????? "RSA", 2048); >>>>>> ??? } >>>>>> >>>>>> ??? private static void assertEvent(List events, >>>>>> String certID, String algId, String subject, >>>>>> ??????????? String issuer, String keyType, int length) throws >>>>>> Exception { >>>>>> >>>>>> ??????? for (RecordedEvent e : events) { >>>>>> ??????????? if (e.getString("serialNumber").equals(certID)) { >>>>>> ??????????????? Events.assertField(e, "algId").equal(algId); >>>>>> ??????????????? ... >>>>>> ??????????????? return; >>>>>> ??????????? } >>>>>> ??????? } >>>>>> ??????? System.out.println(events); >>>>>> ??????? throw new Exception("Could not find event with Cert ID: " >>>>>> + certID); >>>>>> ??? } >>>>>> } >>>>>> >>>>>> The reworked example uses the Events.assertField method, which >>>>>> will give context if the assertion fails. Keeping the test >>>>>> simple, means it can be analyzed quickly if it fails in testing. >>>>>> There is no new test framework to learn, or methods to search >>>>>> for, and it is usually not hard to determine if the failure is >>>>>> product, test or infrastructure related, and what component >>>>>> (team) should be assigned the issue. The use of >>>>>> EventNames.X509Certificate means all occurrences of the event can >>>>>> be tracked done in an IDE using find by reference. >>>>>> >>>>>> Thanks >>>>>> Erik >>>>>> >>>>>>> Following on from the recent JDK-8203629 code review, I'd like >>>>>>> to propose enhancements on how we can record events in security >>>>>>> libs. The introduction of the JFR libraries can give us much >>>>>>> better ways of examining JDK actions. For the initial phase, I'm >>>>>>> looking to enhance some key security library events in JDK 11 so >>>>>>> that they can be either recorded to JFR, logged to a traditional >>>>>>> logger, or both. >>>>>>> >>>>>>> Examples of how useful JFR recordings could be can be seen here : >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/X509Event_1.png >>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_1.png >>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_2.png >>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/TLSEvent_1.png >>>>>>> >>>>>>> securityProp_2.png gives an example of how the JFR recording can >>>>>>> be queried to quickly locate events of interest (in this case, >>>>>>> code setting the jdk.tls.* Security properties). I still need to >>>>>>> clean up the TLSEvents testcase to improve test coverage and >>>>>>> hope to do that in coming days. >>>>>>> >>>>>>> JBS record : >>>>>>> ?* https://bugs.openjdk.java.net/browse/JDK-8148188 >>>>>>> >>>>>>> webrev : >>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v1/webrev/ >>>>>>> >>>>>> >>>>> >>>> >> > From xuelei.fan at oracle.com Thu Jun 28 12:42:21 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 28 Jun 2018 05:42:21 -0700 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: <25b3ae82-5c97-ff18-d0f9-4bfea00c29cb@oracle.com> References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> <25b3ae82-5c97-ff18-d0f9-4bfea00c29cb@oracle.com> Message-ID: <1d8326f3-2a2f-2a0b-f6a5-8773a46e259b@oracle.com> Looks fine to me. Thanks! Xuelei On 6/28/2018 5:28 AM, Se?n Coffey wrote: > Thanks for reviewing Xuelei, > > I do acknowledge that the new TLS v1.3 code has greatly improved the > logging output for related operations. I think the main drive with this > enhancement is to use the new JFR API to capture interesting events. We > can revisit the Logger requirements if there's a strong opinion from > users. By default, both the new Logger and JFR output will be switched > off. I've just made an edit to the JFR jfc files to disable these events. > > "I may suggest remove this method and use Key.getAlgorithm() directly." > - Yes, great idea. Done. > > Thanks for feedback on Finished.java edits. I did question to myself > whether fewer edits were sufficient given the client/server nature of > the handshake. > > I've refreshed the webrev : > > http://cr.openjdk.java.net/~coffeys/webrev.8148188.v3/webrev/ > > some jfr side edits also : > > * Change label from "X.509 Certificate" to "X509 Certificate" - JFR test > fails with "." usage > * Move the instance field variable name in CertChainEvent to "certChain" > - JFR tests discourage use of? "ID" in "certIDs" > > regards, > Sean. > > > On 27/06/2018 21:11, Xuelei Fan wrote: >> Finished.java >> ------------- >> In each handshake, Finished messages are delivered twice.? One from >> client, and the other one from the server side.? Catch Finished >> message and use the final one of them should be sufficient. >> >> In the Finished.java implementation, the signal of the final Finished >> message is the handshakeFinished field is set to true. >> >> Please move line 582: >> ?582???????????? recordEvent(chc.conContext.conSession); >> to line 558: >> ?556???????????????? // handshake context cleanup. >> ?557???????????????? chc.handshakeFinished = true; >> ?558 >> >> Please move line 632: >> ?632???????????? recordEvent(shc.conContext.conSession); >> to line 608: >> ?606???????????????? // handshake context cleanup. >> ?607???????????????? shc.handshakeFinished = true; >> ?608 >> >> Please remove line 838: >> ?838???????????? recordEvent(shc.conContext.conSession); >> >> Please remove line 984: >> ?984???????????? recordEvent(chc.conContext.conSession); >> >> No more comment. >> >> Thanks, >> Xuelei >> >> On 6/27/2018 11:57 AM, Xuelei Fan wrote: >>> Hi Sean, >>> >>> I may reply in several replies. >>> >>> PKIXMasterCertPathValidator.java >>> -------------------------------- >>> +? CertChainEvent cce = new CertChainEvent(); >>> +? if(cce.isEnabled() || EventHelper.loggingSecurity()) { >>> +????? String c = reversedCertList.stream() >>> +????????????????? .map(x -> x.getSerialNumber().toString(16)) >>> +??????????????????????? .collect(Collectors.joining(", ")); >>> +???? EventHelper.commitCertChainEvent(cce, c); >>> +?? } >>> >>> No matter the event or the JFR mechanism is enabled or not, the above >>> code will create a new instance.? Is the return value of >>> cce.isEnabled() dynamically changed or static? >>> >>> Is there a need to support both logging and JFR?? I'm new to record >>> events.? I did not get the point to use both. >>> >>> Thanks, >>> Xuelei >>> >>> On 6/26/2018 3:18 PM, Se?n Coffey wrote: >>>> Erik, >>>> >>>> I rebased the patch with TLS v1.3 integration today. I hadn't >>>> realized how much the handshaker code had changed. Hopefully, I'll >>>> get a review from security dev team on that front. >>>> >>>> Regards the JFR semantics, I believe the edits should match majority >>>> of requests . I still have a preference for the test infra design >>>> for these new logger/JFR tests used in version 1 of webrev. I think >>>> it makes sense to keep the test functionality together - no sense in >>>> separating them out into different components IMO. Also, some of the >>>> edits to the JFR testing were made to test for the new dual >>>> log/record functionality. I might catch up with you tomorrow to see >>>> what the best arrangement would be. >>>> >>>> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v2/webrev/ >>>> >>>> regards, >>>> Sean. >>>> >>>> >>>> On 25/06/2018 21:22, Se?n Coffey wrote: >>>>> Many thanks for the review comments Erik. Replies inline. >>>>> >>>>> >>>>> On 24/06/2018 14:21, Erik Gahlin wrote: >>>>>> Hi Sean, >>>>>> >>>>>> Some of the changes in the webrev belongs to JDK-8203629 and >>>>>> should be removed for clarity. >>>>>> >>>>>> Some initial comments: >>>>>> >>>>>> default.jfc, profile.jfr: >>>>>> The events should not have control="enable-exceptions". The >>>>>> purpose of the control attribute is so to provide parameterized >>>>>> configuration of events for JMC.? As it is now, the security >>>>>> events will be enabled when a user turns on the exception events. >>>>> Makes sense. I'll remove that parameter. >>>>>> >>>>>> X509CertEvent: >>>>>> You should use milliseconds since epoch to represent a date >>>>>> instead of a string value, i.e. >>>>>> >>>>>> ??? @Label("Valid From") >>>>>> ??? @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>>>>> ??? public long validFrom; >>>>>> >>>>>> ??? @Label("Valid Until") >>>>>> ??? @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>>>>> ??? public long validUntil; >>>>>> >>>>> The CertificateValidity class operates on Date Object values. I'll >>>>> work with the Date.getTime() method then (and update the Logger >>>>> formatting) >>>>>> This following annotation adds little value >>>>>> >>>>>> @Description("Details of Security Property") >>>>>> >>>>>> I would either remove the annotation, or provide information that >>>>>> helps a user understand the event. For instance, what is X509, and >>>>>> what kind of certificates are we talking about? >>>>> Yes - that looks like the wrong Description. I'll review all of >>>>> these fields. >>>>>> >>>>>> @Category("Java Application") >>>>>> >>>>>> I'm a bit worried that we will pollute the "Java Application" >>>>>> namespace if we add lots of JDK events in that category. We may >>>>>> want to add a new top level category "Java Development Kit", >>>>>> analogous to the "Java Virtual Machine" category, and put all >>>>>> security related events in subcategory, perhaps called "Security". >>>>> Yes - Open to suggestions. "Security" sounds like a good suggestion. >>>>>> >>>>>> @Label("X509Cert") >>>>>> >>>>>> The label should be human readable name, with spaces, title cased >>>>>> etc. I would recommend "X.509 Certificate". In general, avoid >>>>>> abbreviations like "certs" and instead use labels such as >>>>>> "Certificate Chain". The label should be short and not a full >>>>>> sentence. >>>>>> >>>>>> For details see, >>>>>> https://docs.oracle.com/javase/10/docs/api/jdk/jfr/Label.html >>>>>> >>>>>> I think it would be good to separate testing of JFR and logging >>>>>> into different files / tests. I would prefer that the test name is >>>>>> the same as the event prefixed with "Test", i.e >>>>>> TestX509CertificateEvent, as this is the pattern used by other JFR >>>>>> tests. >>>>>> >>>>> I'll take a look at that pattern again. I've separated out the >>>>> current tests into an (a) outer test to analyze the logger output >>>>> and (b) the inner test which checks for JFR correctness. I did >>>>> include extra logic to make sure that the EventHelper configuration >>>>> was working correctly. "Events.assertField" looks very helpful. >>>>> Thanks for the pointer. >>>>> >>>>> Let me take on board the suggestions below and get a new webrev out >>>>> on Tuesday. >>>>> >>>>> regards, >>>>> Sean. >>>>> >>>>>> I reworked one of the tests to how I like to see it: >>>>>> >>>>>> /* >>>>>> ?* @test >>>>>> ?* @key jfr >>>>>> ?* @library /test/lib >>>>>> ?* @run main/othervm jdk.jfr.event.security.TestX509CertificateEvent >>>>>> ?*/ >>>>>> public class TestX509CertificateEvent { >>>>>> >>>>>> ??? private static final String CERTIFICATE_1 = "..."; >>>>>> ??? private static final String CERTIFICATE_2 = "..."; >>>>>> >>>>>> ??? public static void main(String... args) throws >>>>>> CertificateException { >>>>>> >>>>>> ???????? Recording r = new Recording(); >>>>>> r.enable(EventNames.X509Certificate).withoutStackTrace(); >>>>>> ???????? r.start(); >>>>>> >>>>>> ???????? CertificateFactory cf = >>>>>> CertificateFactory.getInstance("X.509"); >>>>>> ???????? cf.generateCertificate(new >>>>>> ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>>>>> ???????? cf.generateCertificate(new >>>>>> ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>>>>> >>>>>> ???????? // Make sure only one event per certificate >>>>>> ???????? cf.generateCertificate(new >>>>>> ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>>>>> ???????? cf.generateCertificate(new >>>>>> ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>>>>> >>>>>> ???????? r.stop(); >>>>>> >>>>>> ???????? List events = Events.fromRecording(r); >>>>>> ???????? Asserts.assertEquals(events.size(), 2, "Expected two >>>>>> X.509 Certificate events"); >>>>>> >>>>>> ???????? assertEvent(events, "1000", "SHA256withRSA", >>>>>> ??????????????????? "CN=SSLCertificate, O=SomeCompany", >>>>>> ??????????????????? "CN=Intermediate CA Cert, O=SomeCompany", >>>>>> ???????????????????? "RSA", 2048); >>>>>> ???????? assertEvent(events, "1000", "SHA256withRSA", >>>>>> ??????????????????? "CN=SSLCertificate, O=SomeCompany", >>>>>> ??????????????????? "CN=Intermediate CA Cert, O=SomeCompany", >>>>>> ???????????????????? "RSA", 2048); >>>>>> ??? } >>>>>> >>>>>> ??? private static void assertEvent(List events, >>>>>> String certID, String algId, String subject, >>>>>> ??????????? String issuer, String keyType, int length) throws >>>>>> Exception { >>>>>> >>>>>> ??????? for (RecordedEvent e : events) { >>>>>> ??????????? if (e.getString("serialNumber").equals(certID)) { >>>>>> ??????????????? Events.assertField(e, "algId").equal(algId); >>>>>> ??????????????? ... >>>>>> ??????????????? return; >>>>>> ??????????? } >>>>>> ??????? } >>>>>> ??????? System.out.println(events); >>>>>> ??????? throw new Exception("Could not find event with Cert ID: " >>>>>> + certID); >>>>>> ??? } >>>>>> } >>>>>> >>>>>> The reworked example uses the Events.assertField method, which >>>>>> will give context if the assertion fails. Keeping the test simple, >>>>>> means it can be analyzed quickly if it fails in testing. There is >>>>>> no new test framework to learn, or methods to search for, and it >>>>>> is usually not hard to determine if the failure is product, test >>>>>> or infrastructure related, and what component (team) should be >>>>>> assigned the issue. The use of EventNames.X509Certificate means >>>>>> all occurrences of the event can be tracked done in an IDE using >>>>>> find by reference. >>>>>> >>>>>> Thanks >>>>>> Erik >>>>>> >>>>>>> Following on from the recent JDK-8203629 code review, I'd like to >>>>>>> propose enhancements on how we can record events in security >>>>>>> libs. The introduction of the JFR libraries can give us much >>>>>>> better ways of examining JDK actions. For the initial phase, I'm >>>>>>> looking to enhance some key security library events in JDK 11 so >>>>>>> that they can be either recorded to JFR, logged to a traditional >>>>>>> logger, or both. >>>>>>> >>>>>>> Examples of how useful JFR recordings could be can be seen here : >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/X509Event_1.png >>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_1.png >>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_2.png >>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/TLSEvent_1.png >>>>>>> >>>>>>> securityProp_2.png gives an example of how the JFR recording can >>>>>>> be queried to quickly locate events of interest (in this case, >>>>>>> code setting the jdk.tls.* Security properties). I still need to >>>>>>> clean up the TLSEvents testcase to improve test coverage and hope >>>>>>> to do that in coming days. >>>>>>> >>>>>>> JBS record : >>>>>>> ?* https://bugs.openjdk.java.net/browse/JDK-8148188 >>>>>>> >>>>>>> webrev : >>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v1/webrev/ >>>>>>> >>>>>> >>>>> >>>> > From sibabrata.sahoo at oracle.com Thu Jun 28 15:10:10 2018 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Thu, 28 Jun 2018 08:10:10 -0700 (PDT) Subject: [11] RFR: 8205653: test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java and RmiSslBootstrapTest.sh fail with handshake_failure Message-ID: <3e4af336-6863-4145-9dce-60b08ea64a79@default> Hi, Please review the patch for, JBS: https://bugs.openjdk.java.net/browse/JDK-8205653 Webrev: http://cr.openjdk.java.net/~ssahoo/8205653/webrev.00/ Change: The Test has been upgraded to address the following 2 cases, Add protocol support for TLSv1.3. The change is done in the config file named "management_ssltest11_ok.properties.in". Add support for legacy TLS. Now a new config file "management_ssltest15_ok.properties.in" hold TLS protocol "TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA" instead of "SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_RC4_128_MD5". Previously the Test was using DSA keys which is not compatible with TLSv1.3. So the keys has been upgraded to use RSA(2048 bit). Hence the instruction in "Readme.txt" changed which generates RSA(2048 bit) keys. NOTE: Few Test was problem listed which are removed from the list now. Mach 5 result PASS with multiple try for all 14 Test belongs to "open/test/jdk/sun/management/jmxremote" folder. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From sibabrata.sahoo at oracle.com Thu Jun 28 15:15:44 2018 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Thu, 28 Jun 2018 08:15:44 -0700 (PDT) Subject: [11] RFR: 8205653: test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java and RmiSslBootstrapTest.sh fail with handshake_failure In-Reply-To: <3e4af336-6863-4145-9dce-60b08ea64a79@default> References: <3e4af336-6863-4145-9dce-60b08ea64a79@default> Message-ID: <8e9e4472-cdc3-48a2-afd5-af310f4987a2@default> Hi Daniel, I am not a member of HYPERLINK "mailto:jmx-dev at openjdk.java.net"jmx-dev at openjdk.java.net. So the review posted is waiting for moderator's approval. Thanks, Siba From: Sibabrata Sahoo Sent: Thursday, June 28, 2018 8:40 PM To: jmx-dev at openjdk.java.net; security-dev at openjdk.java.net Subject: [11] RFR: 8205653: test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java and RmiSslBootstrapTest.sh fail with handshake_failure Hi, Please review the patch for, JBS: https://bugs.openjdk.java.net/browse/JDK-8205653 Webrev: http://cr.openjdk.java.net/~ssahoo/8205653/webrev.00/ Change: The Test has been upgraded to address the following 2 cases, Add protocol support for TLSv1.3. The change is done in the config file named "management_ssltest11_ok.properties.in". Add support for legacy TLS. Now a new config file "management_ssltest15_ok.properties.in" hold TLS protocol "TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA" instead of "SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_RC4_128_MD5". Previously the Test was using DSA keys which is not compatible with TLSv1.3. So the keys has been upgraded to use RSA(2048 bit). Hence the instruction in "Readme.txt" changed which generates RSA(2048 bit) keys. NOTE: Few Test was problem listed which are removed from the list now. Mach 5 result PASS with multiple try for all 14 Test belongs to "open/test/jdk/sun/management/jmxremote" folder. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From sibabrata.sahoo at oracle.com Thu Jun 28 15:23:20 2018 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Thu, 28 Jun 2018 08:23:20 -0700 (PDT) Subject: [11] RFR: 8205653: test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java and RmiSslBootstrapTest.sh fail with handshake_failure References: <3e4af336-6863-4145-9dce-60b08ea64a79@default> Message-ID: Resending the email after subscribing to HYPERLINK "mailto:jmx-dev at openjdk.java.net"jmx-dev at openjdk.java.net Thanks, Siba From: Sibabrata Sahoo Sent: Thursday, June 28, 2018 8:40 PM To: HYPERLINK "mailto:jmx-dev at openjdk.java.net"jmx-dev at openjdk.java.net; HYPERLINK "mailto:security-dev at openjdk.java.net"security-dev at openjdk.java.net Subject: [11] RFR: 8205653: test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java and RmiSslBootstrapTest.sh fail with handshake_failure Hi, Please review the patch for, JBS: https://bugs.openjdk.java.net/browse/JDK-8205653 Webrev: http://cr.openjdk.java.net/~ssahoo/8205653/webrev.00/ Change: The Test has been upgraded to address the following 2 cases, Add protocol support for TLSv1.3. The change is done in the config file named "management_ssltest11_ok.properties.in". Add support for legacy TLS. Now a new config file "management_ssltest15_ok.properties.in" hold TLS protocol "TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA" instead of "SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_RC4_128_MD5". Previously the Test was using DSA keys which is not compatible with TLSv1.3. So the keys has been upgraded to use RSA(2048 bit). Hence the instruction in "Readme.txt" changed which generates RSA(2048 bit) keys. NOTE: Few Test was problem listed which are removed from the list now. Mach 5 result PASS with multiple try for all 14 Test belongs to "open/test/jdk/sun/management/jmxremote" folder. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Jun 28 15:27:54 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 28 Jun 2018 11:27:54 -0400 Subject: RFR 8205927: Update src/java.base/share/legal/public_suffix.md to match the actual file version In-Reply-To: <2F5DE4AB-EF54-45B1-9A9F-48F996275C33@oracle.com> References: <2F5DE4AB-EF54-45B1-9A9F-48F996275C33@oracle.com> Message-ID: <888b5478-e26d-631d-a74c-cc254294dccb@oracle.com> Looks fine. --Sean On 6/27/18 10:20 AM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8205927/webrev.00/ > > I missed a date and a link when pushing the change for JDK-8201815. Also, the latest MPL 2.0 uses https now. > > Thanks > Max > From daniel.fuchs at oracle.com Thu Jun 28 15:46:16 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 28 Jun 2018 17:46:16 +0200 Subject: [11] RFR: 8205653: test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java and RmiSslBootstrapTest.sh fail with handshake_failure In-Reply-To: <3e4af336-6863-4145-9dce-60b08ea64a79@default> References: <3e4af336-6863-4145-9dce-60b08ea64a79@default> Message-ID: <74fabdff-3523-49cc-5ac2-4b766c8bbb30@oracle.com> [ccing serviceability-dev at openjdk.java.net] Hi Siba, This looks good to me - but I'm not a SSL expert. It would be good to get someone from the security team eyeball those changes (Xuelei? Brad?) I added serviceability-dev at openjdk.java.net in cc as this is where reviews for JMX/Monitoring changes happen these days... best regards, -- daniel On 28/06/2018 17:10, Sibabrata Sahoo wrote: > Hi, > > Please review the patch for, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8205653 > > Webrev: http://cr.openjdk.java.net/~ssahoo/8205653/webrev.00/ > > Change: > > The Test has been upgraded to address the following 2 cases, > > 1. Add protocol support for TLSv1.3. The change is done in the config > file named ?management_ssltest11_ok.properties.in?. > 2. Add support for legacy TLS. Now a new config file > ?management_ssltest15_ok.properties.in? hold TLS protocol > ?TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA? instead > of ?SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_RC4_128_MD5?. > > Previously the Test was using DSA keys which is not compatible with > TLSv1.3. So the keys has been upgraded to use RSA(2048 bit). Hence the > instruction in ?Readme.txt? changed which generates RSA(2048 bit) keys. > > NOTE: Few Test was problem listed which are removed from the list now. > Mach 5 result PASS with multiple try for all 14 Test belongs to > ?open/test/jdk/sun/management/jmxremote? folder. > > Thanks, > > Siba > From weijun.wang at oracle.com Thu Jun 28 15:48:21 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 28 Jun 2018 23:48:21 +0800 Subject: RFR 8205927: Update src/java.base/share/legal/public_suffix.md to match the actual file version In-Reply-To: <888b5478-e26d-631d-a74c-cc254294dccb@oracle.com> References: <2F5DE4AB-EF54-45B1-9A9F-48F996275C33@oracle.com> <888b5478-e26d-631d-a74c-cc254294dccb@oracle.com> Message-ID: <731A1952-BCEF-4CF5-9302-B1E3C3E76B6F@oracle.com> RDP1 started on 15:00 UTC. I'll push to jdk/jdk11 when it's ready. --Max > On Jun 28, 2018, at 11:27 PM, Sean Mullan wrote: > > Looks fine. > > --Sean > > On 6/27/18 10:20 AM, Weijun Wang wrote: >> Please take a review at >> http://cr.openjdk.java.net/~weijun/8205927/webrev.00/ >> I missed a date and a link when pushing the change for JDK-8201815. Also, the latest MPL 2.0 uses https now. >> Thanks >> Max From xuelei.fan at oracle.com Thu Jun 28 15:57:05 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 28 Jun 2018 08:57:05 -0700 Subject: [11] RFR: 8205653: test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java and RmiSslBootstrapTest.sh fail with handshake_failure In-Reply-To: <74fabdff-3523-49cc-5ac2-4b766c8bbb30@oracle.com> References: <3e4af336-6863-4145-9dce-60b08ea64a79@default> <74fabdff-3523-49cc-5ac2-4b766c8bbb30@oracle.com> Message-ID: <5764f7f2-f0a7-4bf1-44dc-977953cc6cab@oracle.com> Hi Siba, The change looks fine to me. I would like Serviceability review this change as well. Thanks, Xuelei On 6/28/2018 8:46 AM, Daniel Fuchs wrote: > [ccing serviceability-dev at openjdk.java.net] > > Hi Siba, > > This looks good to me - but I'm not a SSL expert. > It would be good to get someone from the security team eyeball those > changes (Xuelei? Brad?) > > I added serviceability-dev at openjdk.java.net in cc as this is where > reviews for JMX/Monitoring changes happen these days... > > best regards, > > -- daniel > > On 28/06/2018 17:10, Sibabrata Sahoo wrote: >> Hi, >> >> Please review the patch for, >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8205653 >> >> Webrev: http://cr.openjdk.java.net/~ssahoo/8205653/webrev.00/ >> >> Change: >> >> The Test has been upgraded to address the following 2 cases, >> >> ?1. Add protocol support for TLSv1.3. The change is done in the config >> ??? file named ?management_ssltest11_ok.properties.in?. >> ?2. Add support for legacy TLS. Now a new config file >> ??? ?management_ssltest15_ok.properties.in? hold TLS protocol >> ??? ?TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA? instead >> ??? of ?SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_RC4_128_MD5?. >> >> Previously the Test was using DSA keys which is not compatible with >> TLSv1.3. So the keys has been upgraded to use RSA(2048 bit). Hence the >> instruction in ?Readme.txt? changed which generates RSA(2048 bit) keys. >> >> NOTE: Few Test was problem listed which are removed from the list now. >> Mach 5 result PASS with multiple try for all 14 Test belongs to >> ?open/test/jdk/sun/management/jmxremote? folder. >> >> Thanks, >> >> Siba >> > From xuelei.fan at oracle.com Thu Jun 28 16:14:22 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 28 Jun 2018 09:14:22 -0700 Subject: Code review request: JDK-8046295 - Support Trusted CA Indication extension In-Reply-To: References: <619b0a8b-5be7-1d29-6d8b-acf3cdc34a8c@oracle.com> <66aaaaad-175b-89f9-ba18-254b7881b0d1@oracle.com> <4d15dae7-e1a1-93ab-6b15-e95044c8f2f2@oracle.com> Message-ID: Hi Martin, The TLS 1.3 implementation was integrated into the mainline. I know you have multiple contributions were pending because of the re-org of the JSSE implementation. Would you mind to check if your design and implementation need some adjustment? I may not reply for your contributions in other email threads. Please trigger the code review again if the code is ready for the new JSSE implementation. Thanks & Regards, Xuelei On 8/11/2017 8:24 AM, Xuelei Fan wrote: > Hi Martin, > > Sorry for the delay. > > I'd like to wait for finalization of TLS 1.3 specification, so that we > can get a stable specification of the Certificate Authorities extension. > > For the current design, I did not see much benefit to add a new > CertificateAuthority API.? The CertificateAuthority.implies() may not > yet reach the threshold to be a public API.? A trust/key manager can > easily matching the distinguished name with the target certificate.? And > I did not see the cert matching behavior differences between different > providers and trust/key managers. > > For the specification documentation part, I may suggest reword them a > little bit so that those developers who are not TLS specification > experts can easily catch the purpose or benefits of the API. > > Xuelei > > On 7/21/2017 7:20 AM, Martin Balao wrote: >> Webrev has been uploaded to cr.openjdk.java.net >> : >> >> ? * >> http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-8046295/webrev.03/ >> >> ? * >> http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-8046295/webrev.03/8046295.webrev.03.zip >> >> >> Kind regards, >> Martin.- >> >> On Tue, Jul 18, 2017 at 2:12 PM, Martin Balao > > wrote: >> >> ??? Hi, >> >> ??? Given that 1) Trusted CA Indication TLS Extension does not appear to >> ??? be widely implemented today and 2) it will be replaced by >> ??? Certificate Authorities TLS extension in TLS 1.3, it looks more >> ??? beneficial to me supporting only the latter -and avoid paying the >> ??? cost for a larger code-base-. >> >> ??? Here it is my proposal for Certificate Authorities TLS extension: >> >> ????? * >> >> http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_trusted_ca/2017_07_18/8046295.webrev.03/ >> >> >> >> >> ??? (browse online) >> ????? * >> >> http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_trusted_ca/2017_07_18/8046295.webrev.03.zip >> >> >> >> >> ??? (download) >> >> ??? Implementation based on TLS 1.3 - draft 20 [1]. Patch based on >> ??? JDK-10 (rev 76ff72bb6a4a). >> >> ??? Pending / blocked (in descending priority order): >> >> ??? High >> >> ????? * The extension applies only to TLSv1.3+ >> ?????? * Blocked because TLSv1.3 is still not supported in JSSE. >> ?????? * Impact: the extension cannot be used in TLS 1.2 (high impact on >> ??? the client-side). >> ?????? * Action: replace "useTLS12PlusSpec" with "useTLS13PlusSpec" in >> ??? the patch when available. >> >> ??? Medium >> >> ????? * Server can send the CertificateAuthorities extension to the >> ??? client in a CertificateRequest message (feature) >> ?????? * Blocked by: Server is still not able to send >> ??? EncryptedExtensions message in CertificateRequest >> ?????? * Impact: feature not supported on the server side. The extension >> ??? can still work in production environments. (medium). >> ?????? * Action: implement EncryptedExtensions message in >> ??? CertificateRequest and then implement this feature. >> >> ??? Low >> >> ????? * Update documentation to refer the final TLS 1.3 RFC (draft 20 is >> ??? currently referred) >> ?????? * Blocked by: publication of the final TLS 1.3 RFC >> ?????? * Impact: documentation is not accurate. (low) >> ?????? * Action: replace >> ??? "https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.2.4 >> ??? " >> ??? with the final link in the patch. >> >> ????? * Update bug id in "CertificateAuthoritiesClientTest.java" and >> ??? "CertificateAuthoritiesServerTest.java" >> ?????? * Blocked by: there is no bug id for Certificate Authorities TLS >> ??? extension >> ?????? * Impact: internal tests (very low). >> ?????? * Action: replace "@bug 8046295" with the new bug id in the >> ??? patch. Open a new bug id for Certificate Authorities TLS extension. >> ??? Look forward to your comments. >> >> ??? Kind regards, >> ??? Martin.- >> >> ??? -- >> ??? [1] - >> ??? https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.2.4 >> ??? >> >> ??? On Tue, Jun 20, 2017 at 9:33 PM, Xuelei Fan > ??? > wrote: >> >> ??????? Hi Martin, >> >> ??????? The TLS 1.3 spec is replacing the Trusted CA Indication >> ??????? (trusted_ca_keys) extension with a new Certificate Authorities >> ??????? (certificate_authorities) extension.? See more details about the >> ??????? specification in the TLS 1.3 draft: >> >> https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.2.4 >> >> >> ??????? Both serves a similar purpose, but the trusted_ca_keys extension >> ??????? will not be used in TLS 1.3 any more.? The "trusted_ca_keys" >> ??????? extension will only be used for legacy protocol versions (TLS >> ??????? 1.2/1.1/1.0). >> >> ??????? There are two options to me: >> ??????? 1. Supports the certificate_authorities, but not trusted_ca_keys >> ??????? extension. >> ??????? It is acceptable to me as trusted_ca_keys is for legacy use only >> ??????? and the certificate_authorities extension is the future.? Plus, >> ??????? the certificate_authorities extension can also be used for TLS >> ??????? 1.2 and previous versions. >> >> ??????? 2. Supports both the certificate_authorities and trusted_ca_keys >> ??????? extensions. >> ??????? As far as I know, I did not see much benefit of this option >> ??????? unless the trusted_ca_keys extension is widely used in practice. >> >> ??????? If I did not miss something, the APIs you designed can still be >> ??????? used for the certificate_authorities extension, with a little >> ??????? bit update. >> >> ??????? What do you think? >> >> ??????? Thanks & Regards, >> ??????? Xuelei >> >> >> ??????? On 6/15/2017 12:05 PM, Martin Balao wrote: >> >> ??????????? Hi Xuelei, >> >> ??????????? The new webrev.02 is ready: >> >> ?????????????? * >> >> http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_trusted_ca/2017_06_15/8046295.webrev.02/ >> >> >> >> >> ??????????? (browse online) >> ?????????????? * >> >> http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_trusted_ca/2017_06_15/8046295.webrev.02.zip >> >> >> >> >> ??????????? (zip, download) >> >> ??????????? The following changes have been implemented since the >> ??????????? previous webrev.01: >> >> ?????????????? * s/getUseTrustedCAIndication() methods in >> ??????????? SSLEngine/SSLSocket and in SSLEngineImpl/SSLSocketImpl >> ??????????? removed. s/getSSLParameters is now the only way to set or >> ??????????? get the use of the Trusted CA Indication extension. An >> ??????????? exception is no longer thrown if trying to disable the >> ??????????? extension for a server, but the change takes no effect as >> ??????????? the extension is mandatory for servers. X509KeyManagerImpl >> ??????????? modified to use SSLParameters to get information regarding >> ??????????? if Trusted CA Indication is enabled and should guide the >> ??????????? certificate choice. >> >> ?????????????? * TrustedAuthorityIndicator.IdentifierType has been moved >> ??????????? from enum to String, to follow JSSE conventions. I >> ??????????? understand how important is to be consistent. However, I >> ??????????? still believe that an enum is a better fit for this value >> ??????????? and does not prevent from future extension. We are choosing >> ??????????? from a closed set (strictly defined by the RFC) and that's >> ??????????? what enum allows to express. From the client point of >> ??????????? view/API, it's very handy that the type gives you >> ??????????? information regarding the allowed choices for the parameter. >> ??????????? You don't necessarily have to look for implementation >> ??????????? details or documentation but you can just leverage on the >> ??????????? strongly typed language. It's also likely that enums are >> ??????????? faster for comparisons than strings, but that's not the main >> ??????????? point here. >> >> ?????????????? * Removed X509Certificate from TrustedAuthorityIndicator >> ??????????? class (method and property). It was there for informational >> ??????????? purposes (when TrustedAuthorityIndicator was built from a >> ??????????? certificate by a client and the whole extension indicators >> ??????????? converted to String). >> >> ?????????????? * "equals" and "hashCode" methods moved from >> ??????????? TrustedAuthorityIndicator to TrustedAuthorityIndicatorImpl >> ??????????? class. >> >> ?????????????? * "getLength" method removed from >> ??????????? TrustedAuthorityIndicator class. It's possible to get the >> ??????????? encoded buffer and the length from there. >> >> ?????????????? * "getData" method renamed to "getEncoded" in >> ??????????? TrustedAuthorityIndicator class. >> >> ?????????????? * "trustedAuthorityEncodedData" renamed to "encodedData" >> ??????????? in TrustedAuthorityIndicator and >> ??????????? TrustedAuthorityIndicatorImpl classes >> >> ?????????????? * "identifier" and "encodedData" instance variables moved >> ??????????? from TrustedAuthorityIndicator to >> ??????????? TrustedAuthorityIndicatorImpl class. >> >> ?????????????? * "getEncoded" and "getIdentifier" are now abstract >> ??????????? methods in TrustedAuthorityIndicator, and their >> ??????????? implementation is in TrustedAuthorityIndicatorImpl class. >> >> ?????????????? * "getIdentifier" method renamed to "getType" in >> ??????????? TrustedAuthorityIndicator and TrustedAuthorityIndicatorImpl >> ??????????? classes ("identifier" instance variable and parameter in >> ??????????? TrustedAuthorityIndicatorImpl class renamed to "type"). >> >> ?????????????? * Test cases (server and client) updated to reflect the >> ??????????? new interface (enabling the use of the extension through >> ??????????? SSLParameters) >> >> ??????????? However, some changes are still not implemented and I have >> ??????????? some concerns: >> >> ??????????? 1) I still believe that identifier type information has to >> ??????????? be on TrustedAuthorityIndicator class somehow, and >> ??????????? implementations restricted on what they can return as part >> ??????????? of "getType" method. This is strictly specified by the RFC >> ??????????? TrustedAuthorityIndicator class represents, and I find >> ??????????? desirable that any implementation is enforced to be >> ??????????? compliant to that. If we remove all of that (including the >> ??????????? enum), TrustedAuthorityIndicator looks too generic and does >> ??????????? not reflect (in my opinion) what it really is. It'd also be >> ??????????? chaotic if different implementations call pre-agreed type as >> ??????????? "preagreed", "pre-agreed", "PRE_AGREED", etc. I prefer >> ??????????? stricter and more explicit interfaces. >> >> ??????????? 2) I agree that type mappings can be seen as part of an >> ??????????? implementation, but they were in TrustedAuthorityIndicator >> ??????????? (as protected) because every implementation is highly likely >> ??????????? to need them and we can avoid the necessity for repeated >> ??????????? code/mappings. The same for "type" and "encodedData" >> ??????????? variables or even "hashCode" and "equals" methods. That's >> ??????????? why I was thinking more of an abstract class and not an >> ??????????? interface, as it happens (in example) with SNIServerName. >> >> ??????????? 3) I think that "implies" method on >> ??????????? TrustedAuthorityIndicator should be also part of the >> ??????????? class/interface, because that's the whole point of a Trusted >> ??????????? Authority Information: to allow queries for a given >> ??????????? certificate. This is, in fact, the only thing a server wants >> ??????????? from one of these objects. My concern is that if we remove >> ??????????? this requirement for an implementation, the interface looks >> ??????????? more like a byte buffer holder. >> >> ??????????? I'd appreciate if you can re-consider these items. >> >> ??????????? Thanks, >> ??????????? Martin.- >> >> ??????????? On Wed, Jun 14, 2017 at 7:17 PM, Xuelei Fan >> ??????????? >> ??????????? > ??????????? >> wrote: >> >> ???????????????? Hi Martin, >> >> ???????????????? The big picture of the design looks pretty good to me, >> ??????????? except a few >> ???????????????? comment about the JSSE conventions.? I appreciate it >> ??????????? very much.? By >> ???????????????? the way, I need more time to look into the details of >> the >> ???????????????? specification and implementation. >> >> >> ???????????????? In order to keep the APIs simple and small, >> ??????????? SSLParameters is >> ???????????????? preferred as the only configuration port for common >> ??????????? cases.?? I may >> ???????????????? suggest to remove the s/getUseTrustedCAIndication() >> ??????????? methods in >> ???????????????? SSLEngine/SSLSocket. >> >> ???????????????? The identify type is defined as an enum >> ???????????????? TrustedAuthorityIndicator.IdentifierType.? In the >> ??????????? future, if more >> ???????????????? type is added, we need to update the specification by >> ??????????? adding a new >> ???????????????? enum item.? Enum is preferred in JDK, but for good >> ??????????? extensibility, in >> ???????????????? general JSSE does not use enum in public APIs for >> ??????????? extensible >> ???????????????? properties.? I may suggest to use String (or >> ??????????? integer/byte, I prefer >> ???????????????? to use String) as the type.? The standard trusted >> authority >> ???????????????? indicator algorithm (identifier) can be documented in >> ??????????? the "Java >> ???????????????? Cryptography Architecture Standard Algorithm Name >> ??????????? Documentation"[1]. >> >> ???????????????? In TrustedAuthorityIndicator class, some methods, like >> ???????????????? getIdentifierTypeFromCode(), >> ??????????? getCodeFromIdentifierType(), implies(), >> ???????????????? getLength(), equals() and hashCode() look more like >> ??????????? implementation >> ???????????????? logic.? I may suggest remove them from public APIs. >> >> ???????????????? I did not see the benefit to have X509Certificate in the >> ???????????????? TrustedAuthorityIndicator class.? The class is mainly >> ??????????? used for >> ???????????????? server side certificate selection.? X509Certificate >> ??????????? could be unknown >> ???????????????? for a indicator.? I may suggestion remove the related >> ??????????? methods and >> ???????????????? properties. >> >> ???????????????? After that, as there is no requirement to instantiate >> ???????????????? TrustedAuthorityIndicator class in application code, >> ??????????? looks like it >> ???????????????? may be enough to use an interface to represent a >> ??????????? trusted authorities: >> ???????????????????? public interface TrustedAuthorityIndicator { >> ????????????????????????? // identifier type, standard algorithm name >> ????????????????????????? String/int/Byte getType(); >> >> ????????????????????????? // identifier >> ????????????????????????? byte[] getEncoded(); >> ???????????????????? } >> >> ???????????????? What do you think? >> >> >> ???????????????? Thanks & Regards, >> ???????????????? Xuelei >> >> ???????????????? [1] >> >> https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html >> >> >> >> >> >> > >> >> > >> >> >> >> ???????????????? On 6/13/2017 3:41 PM, Martin Balao wrote: >> >> ???????????????????? Hi Xuelei, >> >> ???????????????????? The new webrev.01 is ready: >> >> ??????????????????????? * >> >> http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_trusted_ca/2017_06_13/8046295.webrev.01/ >> >> >> >> >> >> > >> >> > >> >> ???????????????????? (browse online) >> ??????????????????????? * >> >> http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_trusted_ca/2017_06_13/8046295.webrev.01.zip >> >> >> >> >> >> > >> >> > >> >> ???????????????????? (zip, download) >> >> ???????????????????? The following changes have been implemented since >> ??????????? the previous >> ???????????????????? webrev.00: >> >> ??????????????????????? * Pre-agreed support removed from server-side >> ???????????????????????? * Unnecessary overhead and minium benefits for >> ??????????? JSSE. >> >> ??????????????????????? * Enabling the use of Trusted CA Indication >> ??????????? extension for >> ???????????????????? clients through TrustManager objects was reverted. >> ??????????? Trusted CA >> ???????????????????? Indication extension can now be enabled through: 1) >> ??????????? SSLEngine, >> ???????????????????? 2) SSLSocket, or 3) SSLParameters (which can be >> ??????????? applied to both >> ???????????????????? SSLEngine and SSLSocket objects). Trusted CA >> Indication >> ???????????????????? extension is mandatory for servers. >> >> ??????????????????????? * SunX509KeyManagerImpl old key manager >> ??????????? ("SunX509" algorithm) >> ???????????????????? is now out of scope. This key manager does not >> ??????????? support other TLS >> ???????????????????? extensions as Server Name Indication (SNI), which >> ??????????? is far more >> ???????????????????? relevant than Trusted CA Indication. The new >> ??????????? X509KeyManagerImpl >> ???????????????????? key manager ("PKIX" algorithm) is now in scope. >> >> ??????????????????????? * Client requested indications are now an >> ??????????? ExtendedSSLSession >> ???????????????????? attribute. ServerHandshaker gets the information >> ??????????? from the Client >> ???????????????????? Hello message (now parsed by >> ??????????? TrustedCAIndicationExtension class >> ???????????????????? instead of TrustedAuthorityIndicator) and sets it >> ??????????? in the >> ???????????????????? ExtendedSSLSession (SSLSessionImpl object). The key >> ??????????? manager >> ???????????????????? (i.e.: X509KeyManagerImpl), when choosing a server >> ??????????? alias, may >> ???????????????????? now get the information from the ExtendedSSLSession >> ??????????? object and >> ???????????????????? guide the certificate selection based on it. >> ???????????????????????? * In order to allow multiple key managers to >> ??????????? use Trusted >> ???????????????????? Authority Indicators information and to allow >> ??????????? multiple Trusted >> ???????????????????? Authority Indicators implementations, >> ??????????? TrustedAuthorityIndicator >> ???????????????????? has now been split in an abstract class >> ???????????????????? (TrustedAuthorityIndicator, located in >> ??????????? javax.net.ssl) and an >> ???????????????????? implementation class >> ??????????? (TrustedAuthorityIndicatorImpl, located in >> ???????????????????? sun.security.ssl). No coupling was added between >> ??????????? javax.net.ssl >> ???????????????????? and sun.security.ssl packages. >> >> ??????????????????????? * Documentation extended and improved. >> ??????????????????????? * Test cases (server and client) updated to >> ??????????? reflect the new >> ???????????????????? interface and supported key manager. >> >> ???????????????????? Look forward to your new review! >> >> ???????????????????? Kind regards, >> ???????????????????? Martin.- >> >> >> >> ???????????????????? On Fri, Jun 9, 2017 at 6:15 PM, Xuelei Fan >> ???????????????????? > ??????????? > ??????????? > >> ???????????????????? > ??????????? > ??????????? >>> >> ???????????????????? wrote: >> >> ????????????????????????? I'm OK to use SSLParameters.? Thank you very >> ??????????? much for >> ???????????????????? considering a >> ????????????????????????? new design. >> >> ????????????????????????? Xuelei >> >> ????????????????????????? On 6/9/2017 1:10 PM, Martin Balao wrote: >> >> ????????????????????????????? Hi Xuelei, >> >> ????????????????????????????? I didn't notice that some of the SSLSocket >> ??????????? contructors >> ???????????????????? did not >> ????????????????????????????? establish the connection, so SSLParameters >> ??????????? can be >> ???????????????????? effective for >> ????????????????????????????? Trusted CA Indication. This was an invalid >> ??????????? argument on >> ???????????????????? my side, >> ????????????????????????????? sorry. >> >> ????????????????????????????? As for the configuration to enable the >> ??????????? extension, it's >> ???????????????????? probably >> ????????????????????????????? not necessary on the Server side because >> ??????????? -as you >> ???????????????????? mentioned- it >> ????????????????????????????? is mandatory and there is no harm in >> ??????????? supporting it. >> ???????????????????? However, it >> ????????????????????????????? has to be configurable on the Client side >> ??????????? because -as we >> ????????????????????????????? previously discussed- the client may cause >> ??????????? a handshake >> ???????????????????? failure >> ????????????????????????????? if the server does not support the >> ??????????? extension. I'd >> ???????????????????? prefer the >> ????????????????????????????? Client configuring the SSLSocket through >> ??????????? SSLParameters >> ???????????????????? instead >> ????????????????????????????? of a system-wide property -which has even >> ??????????? more impact >> ???????????????????? than the >> ????????????????????????????? TrustManager approach-. Would this work >> ??????????? for you? >> >> ??????????????????????????????? > In JSSE, the benefits pre_agreed >> ??????????? option can get by >> ????????????????????????????? customizing the key/trust manager, so I >> ??????????? did not see too >> ???????????????????? much >> ????????????????????????????? benefits to support this option in JDK >> >> ????????????????????????????? I understand your point and will remove >> ??????????? support for >> ???????????????????? "pre_agreed". >> >> >> ????????????????????????????? On Fri, Jun 9, 2017 at 1:37 AM, Xuelei Fan >> ????????????????????????????? > ??????????? > ??????????? > >> ???????????????????? > ??????????? > ??????????? >> >> ????????????????????????????? > ??????????? >> ???????????????????? > ??????????? > >> ??????????? >> ???????????????????? > ??????????? >>>> >> ????????????????????????????? wrote: >> >> >> >> ?????????????????????????????????? On 6/8/2017 8:36 PM, Xuelei Fan wrote: >> >> ?????????????????????????????????????? The trusted authorities can be >> ??????????? get from client >> ???????????????????? trust >> ????????????????????????????? manager.???????? Server can choose the >> ??????????? best matching of >> ???????????????????? server >> ????????????????????????????? certificate of the >> ?????????????????????????????????????? client requested trusted >> authorities. >> >> ?????????????????????????????????? > >> ?????????????????????????????????? I missed the point that the key >> ??????????? manager need to >> ???????????????????? know the client >> ?????????????????????????????????? requested trusted authorities for the >> ??????????? choosing.???????? So may >> ????????????????????????????? need a new >> ?????????????????????????????????? SSLSession attribute (See similar >> ??????????? method in >> ????????????????????????????? ExtendedSSLSession). >> >> ?????????????????????????????????? Xuelei >> >> >> >> ????????????????????????????? Yes, an attribute on SSLSession may do the >> ??????????? job (both >> ???????????????????? when Key >> ????????????????????????????? Manager receives a SSLSocket and a >> SSLEngine). >> >> ????????????????????????????? Kind regards, >> ????????????????????????????? Martin.- >> >> >> >> >> From erik.gahlin at oracle.com Thu Jun 28 16:20:53 2018 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 28 Jun 2018 18:20:53 +0200 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> <5B33EC28.6090604@oracle.com> Message-ID: <5B350AE5.3080401@oracle.com> It's sufficient if an event object escapes to another method (regardless if JFR is enabled or not). Some more feedback: Rename event jdk.CertChain to jdk.CertificateChain Rename event jdk.X509Cert to jdk.X509Certificate Rename field certChain to certificateChain. Rename field serialNum to serialNumber Rename field algId to AlgorithmicId or AlgorithmicID Rename @Label("Ciphersuite") to @Label("Cipher Suite") Rename @Label("Cert Chain") to @Label("Certificate Chain") Rename @Label("Property Name") to "Name" or "Key" if that makes sense in the context? Rename @Label("Property Value") to "Value". Put events in a subcategory, i.e @Category({"Java Development Kit", "Security"}) Make classes final. What is the unit of the key in X509Certificate event? Bits? If that is the case, use @DataAmount(DataAmount.BITS) @Label("Serial numbers forming chain of trust") should not be a sentence. How about "Serial Numbers"? I think the tests are hard to read when two things are tested at the same time. It is also likely that if a test fail due to logging issues, it will be assigned to JFR because of the test name, even thought the issues is not JFR related. If you want to reuse code between tests, I would put it in testlibrary. Erik > Thanks for the update Erik. By default I'm proposing that the new JFR > Events and Logger be disabled. As a result the event class shouldn't > escape. If performance metrics highlight an issue, we should revisit. > > regards, > Sean. > > > On 27/06/2018 20:57, Erik Gahlin wrote: >> On 2018-06-27 21:14, Se?n Coffey wrote: >>> >>> >>> On 27/06/2018 19:57, Xuelei Fan wrote: >>>> Hi Sean, >>>> >>>> I may reply in several replies. >>>> >>>> PKIXMasterCertPathValidator.java >>>> -------------------------------- >>>> + CertChainEvent cce = new CertChainEvent(); >>>> + if(cce.isEnabled() || EventHelper.loggingSecurity()) { >>>> + String c = reversedCertList.stream() >>>> + .map(x -> x.getSerialNumber().toString(16)) >>>> + .collect(Collectors.joining(", ")); >>>> + EventHelper.commitCertChainEvent(cce, c); >>>> + } >>>> >>>> No matter the event or the JFR mechanism is enabled or not, the >>>> above code will create a new instance. Is the return value of >>>> cce.isEnabled() dynamically changed or static? >>> This is a requirement from the JFR framework. All their >>> event.isEnabled calls are instance methods and follow a similar >>> pattern. The JFR team assure me that the JIT can optimize away such >>> calls. >> >> The JIT will most likely not be able to optimize if the event class >> escapes. >> >> From a JFR perspective, this would be the preferred layout: >> >> EventA eventA= new EventA(); >> eventA.value = this.value; >> eventA.commit(); >> >> and then do logging separately: >> >> System.Logger.log(DEBUG, this.value) >> >> With this layout, the JIT will remove the allocation and dead store. >> >> If it is expensive to gather the data for the event, like the >> CertChainEvent above, the following pattern should be used. >> >> EventB eventB= new EventB (); >> if (eventB.shouldCommit()) { >> eventB.value = calculateValue(); >> eventB .commit(); >> } >> >> If JFR is not enabled, shouldCommit returns false and the JIT should >> be able to remove the allocation. This will be best from a >> performance point of view, and also in my opinion from a maintenance >> and readability perspective. Others may disagree. >> >> Erik >> >>>> >>>> Is there a need to support both logging and JFR? I'm new to record >>>> events. I did not get the point to use both. >>> I was initially hoping to concentrate on just JFR events but I got >>> strong feedback to also consider use of Logger (esp. in cases where >>> the jdk.jfr module is not available) >>> >>> regards, >>> Sean. >>> >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 6/26/2018 3:18 PM, Se?n Coffey wrote: >>>>> Erik, >>>>> >>>>> I rebased the patch with TLS v1.3 integration today. I hadn't >>>>> realized how much the handshaker code had changed. Hopefully, I'll >>>>> get a review from security dev team on that front. >>>>> >>>>> Regards the JFR semantics, I believe the edits should match >>>>> majority of requests . I still have a preference for the test >>>>> infra design for these new logger/JFR tests used in version 1 of >>>>> webrev. I think it makes sense to keep the test functionality >>>>> together - no sense in separating them out into different >>>>> components IMO. Also, some of the edits to the JFR testing were >>>>> made to test for the new dual log/record functionality. I might >>>>> catch up with you tomorrow to see what the best arrangement would be. >>>>> >>>>> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v2/webrev/ >>>>> >>>>> regards, >>>>> Sean. >>>>> >>>>> >>>>> On 25/06/2018 21:22, Se?n Coffey wrote: >>>>>> Many thanks for the review comments Erik. Replies inline. >>>>>> >>>>>> >>>>>> On 24/06/2018 14:21, Erik Gahlin wrote: >>>>>>> Hi Sean, >>>>>>> >>>>>>> Some of the changes in the webrev belongs to JDK-8203629 and >>>>>>> should be removed for clarity. >>>>>>> >>>>>>> Some initial comments: >>>>>>> >>>>>>> default.jfc, profile.jfr: >>>>>>> The events should not have control="enable-exceptions". The >>>>>>> purpose of the control attribute is so to provide parameterized >>>>>>> configuration of events for JMC. As it is now, the security >>>>>>> events will be enabled when a user turns on the exception events. >>>>>> Makes sense. I'll remove that parameter. >>>>>>> >>>>>>> X509CertEvent: >>>>>>> You should use milliseconds since epoch to represent a date >>>>>>> instead of a string value, i.e. >>>>>>> >>>>>>> @Label("Valid From") >>>>>>> @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>>>>>> public long validFrom; >>>>>>> >>>>>>> @Label("Valid Until") >>>>>>> @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>>>>>> public long validUntil; >>>>>>> >>>>>> The CertificateValidity class operates on Date Object values. >>>>>> I'll work with the Date.getTime() method then (and update the >>>>>> Logger formatting) >>>>>>> This following annotation adds little value >>>>>>> >>>>>>> @Description("Details of Security Property") >>>>>>> >>>>>>> I would either remove the annotation, or provide information >>>>>>> that helps a user understand the event. For instance, what is >>>>>>> X509, and what kind of certificates are we talking about? >>>>>> Yes - that looks like the wrong Description. I'll review all of >>>>>> these fields. >>>>>>> >>>>>>> @Category("Java Application") >>>>>>> >>>>>>> I'm a bit worried that we will pollute the "Java Application" >>>>>>> namespace if we add lots of JDK events in that category. We may >>>>>>> want to add a new top level category "Java Development Kit", >>>>>>> analogous to the "Java Virtual Machine" category, and put all >>>>>>> security related events in subcategory, perhaps called "Security". >>>>>> Yes - Open to suggestions. "Security" sounds like a good suggestion. >>>>>>> >>>>>>> @Label("X509Cert") >>>>>>> >>>>>>> The label should be human readable name, with spaces, title >>>>>>> cased etc. I would recommend "X.509 Certificate". In general, >>>>>>> avoid abbreviations like "certs" and instead use labels such as >>>>>>> "Certificate Chain". The label should be short and not a full >>>>>>> sentence. >>>>>>> >>>>>>> For details see, >>>>>>> https://docs.oracle.com/javase/10/docs/api/jdk/jfr/Label.html >>>>>>> >>>>>>> I think it would be good to separate testing of JFR and logging >>>>>>> into different files / tests. I would prefer that the test name >>>>>>> is the same as the event prefixed with "Test", i.e >>>>>>> TestX509CertificateEvent, as this is the pattern used by other >>>>>>> JFR tests. >>>>>>> >>>>>> I'll take a look at that pattern again. I've separated out the >>>>>> current tests into an (a) outer test to analyze the logger output >>>>>> and (b) the inner test which checks for JFR correctness. I did >>>>>> include extra logic to make sure that the EventHelper >>>>>> configuration was working correctly. "Events.assertField" looks >>>>>> very helpful. Thanks for the pointer. >>>>>> >>>>>> Let me take on board the suggestions below and get a new webrev >>>>>> out on Tuesday. >>>>>> >>>>>> regards, >>>>>> Sean. >>>>>> >>>>>>> I reworked one of the tests to how I like to see it: >>>>>>> >>>>>>> /* >>>>>>> * @test >>>>>>> * @key jfr >>>>>>> * @library /test/lib >>>>>>> * @run main/othervm >>>>>>> jdk.jfr.event.security.TestX509CertificateEvent >>>>>>> */ >>>>>>> public class TestX509CertificateEvent { >>>>>>> >>>>>>> private static final String CERTIFICATE_1 = "..."; >>>>>>> private static final String CERTIFICATE_2 = "..."; >>>>>>> >>>>>>> public static void main(String... args) throws >>>>>>> CertificateException { >>>>>>> >>>>>>> Recording r = new Recording(); >>>>>>> r.enable(EventNames.X509Certificate).withoutStackTrace(); >>>>>>> r.start(); >>>>>>> >>>>>>> CertificateFactory cf = >>>>>>> CertificateFactory.getInstance("X.509"); >>>>>>> cf.generateCertificate(new >>>>>>> ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>>>>>> cf.generateCertificate(new >>>>>>> ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>>>>>> >>>>>>> // Make sure only one event per certificate >>>>>>> cf.generateCertificate(new >>>>>>> ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>>>>>> cf.generateCertificate(new >>>>>>> ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>>>>>> >>>>>>> r.stop(); >>>>>>> >>>>>>> List events = Events.fromRecording(r); >>>>>>> Asserts.assertEquals(events.size(), 2, "Expected two >>>>>>> X.509 Certificate events"); >>>>>>> >>>>>>> assertEvent(events, "1000", "SHA256withRSA", >>>>>>> "CN=SSLCertificate, O=SomeCompany", >>>>>>> "CN=Intermediate CA Cert, O=SomeCompany", >>>>>>> "RSA", 2048); >>>>>>> assertEvent(events, "1000", "SHA256withRSA", >>>>>>> "CN=SSLCertificate, O=SomeCompany", >>>>>>> "CN=Intermediate CA Cert, O=SomeCompany", >>>>>>> "RSA", 2048); >>>>>>> } >>>>>>> >>>>>>> private static void assertEvent(List events, >>>>>>> String certID, String algId, String subject, >>>>>>> String issuer, String keyType, int length) throws >>>>>>> Exception { >>>>>>> >>>>>>> for (RecordedEvent e : events) { >>>>>>> if (e.getString("serialNumber").equals(certID)) { >>>>>>> Events.assertField(e, "algId").equal(algId); >>>>>>> ... >>>>>>> return; >>>>>>> } >>>>>>> } >>>>>>> System.out.println(events); >>>>>>> throw new Exception("Could not find event with Cert ID: >>>>>>> " + certID); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> The reworked example uses the Events.assertField method, which >>>>>>> will give context if the assertion fails. Keeping the test >>>>>>> simple, means it can be analyzed quickly if it fails in testing. >>>>>>> There is no new test framework to learn, or methods to search >>>>>>> for, and it is usually not hard to determine if the failure is >>>>>>> product, test or infrastructure related, and what component >>>>>>> (team) should be assigned the issue. The use of >>>>>>> EventNames.X509Certificate means all occurrences of the event >>>>>>> can be tracked done in an IDE using find by reference. >>>>>>> >>>>>>> Thanks >>>>>>> Erik >>>>>>> >>>>>>>> Following on from the recent JDK-8203629 code review, I'd like >>>>>>>> to propose enhancements on how we can record events in security >>>>>>>> libs. The introduction of the JFR libraries can give us much >>>>>>>> better ways of examining JDK actions. For the initial phase, >>>>>>>> I'm looking to enhance some key security library events in JDK >>>>>>>> 11 so that they can be either recorded to JFR, logged to a >>>>>>>> traditional logger, or both. >>>>>>>> >>>>>>>> Examples of how useful JFR recordings could be can be seen here : >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/X509Event_1.png >>>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_1.png >>>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_2.png >>>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/TLSEvent_1.png >>>>>>>> >>>>>>>> securityProp_2.png gives an example of how the JFR recording >>>>>>>> can be queried to quickly locate events of interest (in this >>>>>>>> case, code setting the jdk.tls.* Security properties). I still >>>>>>>> need to clean up the TLSEvents testcase to improve test >>>>>>>> coverage and hope to do that in coming days. >>>>>>>> >>>>>>>> JBS record : >>>>>>>> * https://bugs.openjdk.java.net/browse/JDK-8148188 >>>>>>>> >>>>>>>> webrev : >>>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v1/webrev/ >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >> > From sean.coffey at oracle.com Thu Jun 28 16:59:02 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 28 Jun 2018 17:59:02 +0100 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: <5B350AE5.3080401@oracle.com> References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> <5B33EC28.6090604@oracle.com> <5B350AE5.3080401@oracle.com> Message-ID: Comments inline. On 28/06/2018 17:20, Erik Gahlin wrote: > It's sufficient if an event object escapes to another method > (regardless if JFR is enabled or not). > > Some more feedback: > > Rename event jdk.CertChain to jdk.CertificateChain > Rename event jdk.X509Cert to jdk.X509Certificate > Rename field certChain to certificateChain. > Rename field serialNum to serialNumber all above done. > Rename field algId to AlgorithmicId or AlgorithmicID maybe "algorithm" works here also ? > Rename @Label("Ciphersuite") to @Label("Cipher Suite") > Rename @Label("Cert Chain") to @Label("Certificate Chain") > Rename @Label("Property Name") to "Name" or "Key" if that makes sense > in the context? > Rename @Label("Property Value") to "Value". > Put events in a subcategory, i.e? @Category({"Java Development Kit", > "Security"}) done. > Make classes final. done. I had thought that the JFR mechanism required non-final classes. > What is the unit of the key in X509Certificate event? Bits? If that is > the case, use @DataAmount(DataAmount.BITS) Yes - it's essentially the bit length of the keys used. Let me look into that annotation usage. > @Label("Serial numbers forming chain of trust") should not be a > sentence. How about "Serial Numbers"? > > I think the tests are hard to read when two things are tested at the > same time. It is also likely that if a test fail due to logging > issues, it will be assigned to JFR because of the test name, even > thought the issues is not JFR related. I think we're always going to have some ownership issues when tests serve a dual purpose. I still think it makes sense to keep the test logic in one place. Any failures in these tests will most likely be owned by security team. (moving the tests to security directory is also an option) > > If you want to reuse code between tests, I would put it in testlibrary. Let me check if there's any common patterns that could be added to the testlibary. Thanks, Sean. > > Erik > >> Thanks for the update Erik. By default I'm proposing that the new JFR >> Events and Logger be disabled. As a result the event class shouldn't >> escape. If performance metrics highlight an issue, we should revisit. >> >> regards, >> Sean. >> >> >> On 27/06/2018 20:57, Erik Gahlin wrote: >>> On 2018-06-27 21:14, Se?n Coffey wrote: >>>> >>>> >>>> On 27/06/2018 19:57, Xuelei Fan wrote: >>>>> Hi Sean, >>>>> >>>>> I may reply in several replies. >>>>> >>>>> PKIXMasterCertPathValidator.java >>>>> -------------------------------- >>>>> +? CertChainEvent cce = new CertChainEvent(); >>>>> +? if(cce.isEnabled() || EventHelper.loggingSecurity()) { >>>>> +????? String c = reversedCertList.stream() >>>>> +????????????????? .map(x -> x.getSerialNumber().toString(16)) >>>>> +??????????????????????? .collect(Collectors.joining(", ")); >>>>> +???? EventHelper.commitCertChainEvent(cce, c); >>>>> +?? } >>>>> >>>>> No matter the event or the JFR mechanism is enabled or not, the >>>>> above code will create a new instance.? Is the return value of >>>>> cce.isEnabled() dynamically changed or static? >>>> This is a requirement from the JFR framework. All their >>>> event.isEnabled calls are instance methods and follow a similar >>>> pattern. The JFR team assure me that the JIT can optimize away such >>>> calls. >>> >>> The JIT will most likely not be able to optimize if the event class >>> escapes. >>> >>> From a JFR perspective, this would be the preferred layout: >>> >>> EventA eventA= new EventA(); >>> eventA.value = this.value; >>> eventA.commit(); >>> >>> and then do logging separately: >>> >>> System.Logger.log(DEBUG, this.value) >>> >>> With this layout, the JIT will remove the allocation and dead store. >>> >>> If it is expensive to gather the data for the event, like the >>> CertChainEvent above, the following pattern should be used. >>> >>> EventB eventB= new EventB (); >>> if (eventB.shouldCommit()) { >>> ?? eventB.value = calculateValue(); >>> ?? eventB .commit(); >>> } >>> >>> If JFR is not enabled, shouldCommit returns false and the JIT should >>> be able to remove the allocation.? This will be best from a >>> performance point of view, and also in my opinion from a maintenance >>> and readability perspective. Others may disagree. >>> >>> Erik >>> >>>>> >>>>> Is there a need to support both logging and JFR?? I'm new to >>>>> record events.? I did not get the point to use both. >>>> I was initially hoping to concentrate on just JFR events but I got >>>> strong feedback to also consider use of Logger (esp. in cases where >>>> the jdk.jfr module is not available) >>>> >>>> regards, >>>> Sean. >>>> >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 6/26/2018 3:18 PM, Se?n Coffey wrote: >>>>>> Erik, >>>>>> >>>>>> I rebased the patch with TLS v1.3 integration today. I hadn't >>>>>> realized how much the handshaker code had changed. Hopefully, >>>>>> I'll get a review from security dev team on that front. >>>>>> >>>>>> Regards the JFR semantics, I believe the edits should match >>>>>> majority of requests . I still have a preference for the test >>>>>> infra design for these new logger/JFR tests used in version 1 of >>>>>> webrev. I think it makes sense to keep the test functionality >>>>>> together - no sense in separating them out into different >>>>>> components IMO. Also, some of the edits to the JFR testing were >>>>>> made to test for the new dual log/record functionality. I might >>>>>> catch up with you tomorrow to see what the best arrangement would >>>>>> be. >>>>>> >>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v2/webrev/ >>>>>> >>>>>> regards, >>>>>> Sean. >>>>>> >>>>>> >>>>>> On 25/06/2018 21:22, Se?n Coffey wrote: >>>>>>> Many thanks for the review comments Erik. Replies inline. >>>>>>> >>>>>>> >>>>>>> On 24/06/2018 14:21, Erik Gahlin wrote: >>>>>>>> Hi Sean, >>>>>>>> >>>>>>>> Some of the changes in the webrev belongs to JDK-8203629 and >>>>>>>> should be removed for clarity. >>>>>>>> >>>>>>>> Some initial comments: >>>>>>>> >>>>>>>> default.jfc, profile.jfr: >>>>>>>> The events should not have control="enable-exceptions". The >>>>>>>> purpose of the control attribute is so to provide parameterized >>>>>>>> configuration of events for JMC.? As it is now, the security >>>>>>>> events will be enabled when a user turns on the exception events. >>>>>>> Makes sense. I'll remove that parameter. >>>>>>>> >>>>>>>> X509CertEvent: >>>>>>>> You should use milliseconds since epoch to represent a date >>>>>>>> instead of a string value, i.e. >>>>>>>> >>>>>>>> ??? @Label("Valid From") >>>>>>>> ??? @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>>>>>>> ??? public long validFrom; >>>>>>>> >>>>>>>> ??? @Label("Valid Until") >>>>>>>> ??? @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>>>>>>> ??? public long validUntil; >>>>>>>> >>>>>>> The CertificateValidity class operates on Date Object values. >>>>>>> I'll work with the Date.getTime() method then (and update the >>>>>>> Logger formatting) >>>>>>>> This following annotation adds little value >>>>>>>> >>>>>>>> @Description("Details of Security Property") >>>>>>>> >>>>>>>> I would either remove the annotation, or provide information >>>>>>>> that helps a user understand the event. For instance, what is >>>>>>>> X509, and what kind of certificates are we talking about? >>>>>>> Yes - that looks like the wrong Description. I'll review all of >>>>>>> these fields. >>>>>>>> >>>>>>>> @Category("Java Application") >>>>>>>> >>>>>>>> I'm a bit worried that we will pollute the "Java Application" >>>>>>>> namespace if we add lots of JDK events in that category. We may >>>>>>>> want to add a new top level category "Java Development Kit", >>>>>>>> analogous to the "Java Virtual Machine" category, and put all >>>>>>>> security related events in subcategory, perhaps called "Security". >>>>>>> Yes - Open to suggestions. "Security" sounds like a good >>>>>>> suggestion. >>>>>>>> >>>>>>>> @Label("X509Cert") >>>>>>>> >>>>>>>> The label should be human readable name, with spaces, title >>>>>>>> cased etc. I would recommend "X.509 Certificate". In general, >>>>>>>> avoid abbreviations like "certs" and instead use labels such as >>>>>>>> "Certificate Chain". The label should be short and not a full >>>>>>>> sentence. >>>>>>>> >>>>>>>> For details see, >>>>>>>> https://docs.oracle.com/javase/10/docs/api/jdk/jfr/Label.html >>>>>>>> >>>>>>>> I think it would be good to separate testing of JFR and logging >>>>>>>> into different files / tests. I would prefer that the test name >>>>>>>> is the same as the event prefixed with "Test", i.e >>>>>>>> TestX509CertificateEvent, as this is the pattern used by other >>>>>>>> JFR tests. >>>>>>>> >>>>>>> I'll take a look at that pattern again. I've separated out the >>>>>>> current tests into an (a) outer test to analyze the logger >>>>>>> output and (b) the inner test which checks for JFR correctness. >>>>>>> I did include extra logic to make sure that the EventHelper >>>>>>> configuration was working correctly. "Events.assertField" looks >>>>>>> very helpful. Thanks for the pointer. >>>>>>> >>>>>>> Let me take on board the suggestions below and get a new webrev >>>>>>> out on Tuesday. >>>>>>> >>>>>>> regards, >>>>>>> Sean. >>>>>>> >>>>>>>> I reworked one of the tests to how I like to see it: >>>>>>>> >>>>>>>> /* >>>>>>>> ?* @test >>>>>>>> ?* @key jfr >>>>>>>> ?* @library /test/lib >>>>>>>> ?* @run main/othervm >>>>>>>> jdk.jfr.event.security.TestX509CertificateEvent >>>>>>>> ?*/ >>>>>>>> public class TestX509CertificateEvent { >>>>>>>> >>>>>>>> ??? private static final String CERTIFICATE_1 = "..."; >>>>>>>> ??? private static final String CERTIFICATE_2 = "..."; >>>>>>>> >>>>>>>> ??? public static void main(String... args) throws >>>>>>>> CertificateException { >>>>>>>> >>>>>>>> ???????? Recording r = new Recording(); >>>>>>>> r.enable(EventNames.X509Certificate).withoutStackTrace(); >>>>>>>> ???????? r.start(); >>>>>>>> >>>>>>>> ???????? CertificateFactory cf = >>>>>>>> CertificateFactory.getInstance("X.509"); >>>>>>>> ???????? cf.generateCertificate(new >>>>>>>> ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>>>>>>> ???????? cf.generateCertificate(new >>>>>>>> ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>>>>>>> >>>>>>>> ???????? // Make sure only one event per certificate >>>>>>>> ???????? cf.generateCertificate(new >>>>>>>> ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>>>>>>> ???????? cf.generateCertificate(new >>>>>>>> ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>>>>>>> >>>>>>>> ???????? r.stop(); >>>>>>>> >>>>>>>> ???????? List events = Events.fromRecording(r); >>>>>>>> ???????? Asserts.assertEquals(events.size(), 2, "Expected two >>>>>>>> X.509 Certificate events"); >>>>>>>> >>>>>>>> ???????? assertEvent(events, "1000", "SHA256withRSA", >>>>>>>> ??????????????????? "CN=SSLCertificate, O=SomeCompany", >>>>>>>> ??????????????????? "CN=Intermediate CA Cert, O=SomeCompany", >>>>>>>> ???????????????????? "RSA", 2048); >>>>>>>> ???????? assertEvent(events, "1000", "SHA256withRSA", >>>>>>>> ??????????????????? "CN=SSLCertificate, O=SomeCompany", >>>>>>>> ??????????????????? "CN=Intermediate CA Cert, O=SomeCompany", >>>>>>>> ???????????????????? "RSA", 2048); >>>>>>>> ??? } >>>>>>>> >>>>>>>> ??? private static void assertEvent(List events, >>>>>>>> String certID, String algId, String subject, >>>>>>>> ??????????? String issuer, String keyType, int length) throws >>>>>>>> Exception { >>>>>>>> >>>>>>>> ??????? for (RecordedEvent e : events) { >>>>>>>> ??????????? if (e.getString("serialNumber").equals(certID)) { >>>>>>>> ??????????????? Events.assertField(e, "algId").equal(algId); >>>>>>>> ??????????????? ... >>>>>>>> ??????????????? return; >>>>>>>> ??????????? } >>>>>>>> ??????? } >>>>>>>> ??????? System.out.println(events); >>>>>>>> ??????? throw new Exception("Could not find event with Cert ID: >>>>>>>> " + certID); >>>>>>>> ??? } >>>>>>>> } >>>>>>>> >>>>>>>> The reworked example uses the Events.assertField method, which >>>>>>>> will give context if the assertion fails. Keeping the test >>>>>>>> simple, means it can be analyzed quickly if it fails in >>>>>>>> testing. There is no new test framework to learn, or methods to >>>>>>>> search for, and it is usually not hard to determine if the >>>>>>>> failure is product, test or infrastructure related, and what >>>>>>>> component (team) should be assigned the issue. The use of >>>>>>>> EventNames.X509Certificate means all occurrences of the event >>>>>>>> can be tracked done in an IDE using find by reference. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Erik >>>>>>>> >>>>>>>>> Following on from the recent JDK-8203629 code review, I'd like >>>>>>>>> to propose enhancements on how we can record events in >>>>>>>>> security libs. The introduction of the JFR libraries can give >>>>>>>>> us much better ways of examining JDK actions. For the initial >>>>>>>>> phase, I'm looking to enhance some key security library events >>>>>>>>> in JDK 11 so that they can be either recorded to JFR, logged >>>>>>>>> to a traditional logger, or both. >>>>>>>>> >>>>>>>>> Examples of how useful JFR recordings could be can be seen here : >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/X509Event_1.png >>>>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_1.png >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_2.png >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/TLSEvent_1.png >>>>>>>>> >>>>>>>>> securityProp_2.png gives an example of how the JFR recording >>>>>>>>> can be queried to quickly locate events of interest (in this >>>>>>>>> case, code setting the jdk.tls.* Security properties). I still >>>>>>>>> need to clean up the TLSEvents testcase to improve test >>>>>>>>> coverage and hope to do that in coming days. >>>>>>>>> >>>>>>>>> JBS record : >>>>>>>>> ?* https://bugs.openjdk.java.net/browse/JDK-8148188 >>>>>>>>> >>>>>>>>> webrev : >>>>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v1/webrev/ >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>> >> > From prasadarao.koppula at oracle.com Fri Jun 29 08:06:21 2018 From: prasadarao.koppula at oracle.com (Prasadrao Koppula) Date: Fri, 29 Jun 2018 01:06:21 -0700 (PDT) Subject: [8u] RFR: 8074462: Handshake messages can be strictly ordered Message-ID: <64436cfe-714a-494a-ba0b-352ccbf72853@default> Could you please review the changes Webrev: http://cr.openjdk.java.net/~pkoppula/8074462/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8074462 To fix handshake message out-of-order issues, we extracted required classes/ code from JEP 219 implementation. Contributed by: Sean Coffey and Prasadrao Koppula Thanks, Prasad.K -------------- next part -------------- An HTML attachment was scrubbed... URL: From sibabrata.sahoo at oracle.com Fri Jun 29 08:22:20 2018 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Fri, 29 Jun 2018 01:22:20 -0700 (PDT) Subject: [11] RFR: 8205653: test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java and RmiSslBootstrapTest.sh fail with handshake_failure In-Reply-To: <5764f7f2-f0a7-4bf1-44dc-977953cc6cab@oracle.com> References: <3e4af336-6863-4145-9dce-60b08ea64a79@default> <74fabdff-3523-49cc-5ac2-4b766c8bbb30@oracle.com> <5764f7f2-f0a7-4bf1-44dc-977953cc6cab@oracle.com> Message-ID: <06b1c50c-401c-4c50-9ddf-7876c0638e63@default> May I get the approval from serviceability-dev at openjdk.java.net. Thanks, Siba -----Original Message----- From: Xuelei Fan Sent: Thursday, June 28, 2018 9:27 PM To: Daniel Fuchs ; Sibabrata Sahoo ; jmx-dev at openjdk.java.net; security-dev at openjdk.java.net; serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net Subject: Re: [11] RFR: 8205653: test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java and RmiSslBootstrapTest.sh fail with handshake_failure Hi Siba, The change looks fine to me. I would like Serviceability review this change as well. Thanks, Xuelei On 6/28/2018 8:46 AM, Daniel Fuchs wrote: > [ccing serviceability-dev at openjdk.java.net] > > Hi Siba, > > This looks good to me - but I'm not a SSL expert. > It would be good to get someone from the security team eyeball those > changes (Xuelei? Brad?) > > I added serviceability-dev at openjdk.java.net in cc as this is where > reviews for JMX/Monitoring changes happen these days... > > best regards, > > -- daniel > > On 28/06/2018 17:10, Sibabrata Sahoo wrote: >> Hi, >> >> Please review the patch for, >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8205653 >> >> Webrev: http://cr.openjdk.java.net/~ssahoo/8205653/webrev.00/ >> >> Change: >> >> The Test has been upgraded to address the following 2 cases, >> >> ?1. Add protocol support for TLSv1.3. The change is done in the >> config >> ??? file named "management_ssltest11_ok.properties.in". >> ?2. Add support for legacy TLS. Now a new config file >> ??? "management_ssltest15_ok.properties.in" hold TLS protocol >> ??? "TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA" >> instead >> ??? of "SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_RC4_128_MD5". >> >> Previously the Test was using DSA keys which is not compatible with >> TLSv1.3. So the keys has been upgraded to use RSA(2048 bit). Hence >> the instruction in "Readme.txt" changed which generates RSA(2048 bit) keys. >> >> NOTE: Few Test was problem listed which are removed from the list now. >> Mach 5 result PASS with multiple try for all 14 Test belongs to >> "open/test/jdk/sun/management/jmxremote" folder. >> >> Thanks, >> >> Siba >> > From Alan.Bateman at oracle.com Fri Jun 29 08:32:38 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 29 Jun 2018 09:32:38 +0100 Subject: [11] RFR: 8205653: test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java and RmiSslBootstrapTest.sh fail with handshake_failure In-Reply-To: <06b1c50c-401c-4c50-9ddf-7876c0638e63@default> References: <3e4af336-6863-4145-9dce-60b08ea64a79@default> <74fabdff-3523-49cc-5ac2-4b766c8bbb30@oracle.com> <5764f7f2-f0a7-4bf1-44dc-977953cc6cab@oracle.com> <06b1c50c-401c-4c50-9ddf-7876c0638e63@default> Message-ID: <687b7dd7-5be5-cfdb-c411-2cf4a7008b12@oracle.com> On 29/06/2018 09:22, Sibabrata Sahoo wrote: > May I get the approval from serviceability-dev at openjdk.java.net. > This a test only change to update the keystores and the list of ciphers/protocols that the test uses. There's nothing serviceability specific here so having a Reviewer from the security area should be okay in the event that don't get a quick review on serviceability-dev list. -Alan From xuelei.fan at oracle.com Fri Jun 29 14:47:23 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 29 Jun 2018 07:47:23 -0700 Subject: [8u] RFR: 8074462: Handshake messages can be strictly ordered In-Reply-To: <64436cfe-714a-494a-ba0b-352ccbf72853@default> References: <64436cfe-714a-494a-ba0b-352ccbf72853@default> Message-ID: <7f033b31-9b30-1cd6-84cc-138e76d50deb@oracle.com> Hi Prasad, Thanks for take care of this issue. SSLEngineImpl.java ------------------ 1422 private HandshakeStatus finishHandshake() { 1423 handshaker = null; 1424 connectionState = cs_DATA; 1425 return HandshakeStatus.FINISHED; 1426 } This method are used in two places, for different purposes. It is a little bit confusing, especially the code in line 1019. I may just remove this method, and update the calling line accordingly. @@ -1024,12 +1014,11 @@: ----------------------- - handshaker = null; - receivedCCS = false; + finishHandshake(); May be sufficient to remove the "receivedCCS = false" only: handshaker = null; - receivedCCS = false; @@ -1040,15 +1029,14 @@ ----------------------- if (!writer.hasOutboundData()) { - hsStatus = HandshakeStatus.FINISHED; + hsStatus = finishHandshake(); } - handshaker = null; connectionState = cs_DATA; - receivedCCS = false; + handshaker = null; May be sufficient to remove the "receivedCCS = false" only: if (!writer.hasOutboundData()) { hsStatus = HandshakeStatus.FINISHED; } handshaker = null; connectionState = cs_DATA; - receivedCCS = false; Otherwise, looks fine to me. Xuelei On 6/29/2018 1:06 AM, Prasadrao Koppula wrote: > Could you please review the changes > > Webrev: http://cr.openjdk.java.net/~pkoppula/8074462/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8074462 > > To fix handshake message out-of-order issues, we extracted required > classes/ code from JEP 219 implementation. > > Contributed by: Sean Coffey and Prasadrao Koppula > > Thanks, > Prasad.K > From sean.coffey at oracle.com Fri Jun 29 15:34:25 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 29 Jun 2018 16:34:25 +0100 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> <5B33EC28.6090604@oracle.com> <5B350AE5.3080401@oracle.com> Message-ID: I've introduced a new test helper class in the jdk/test/lib/jfr directory to help with the dual test nature of the new tests. It's helped alot with test code duplication. Looked at use of @DataAmount(DataAmount.BITS) also. Not sure if it's fits. The output is displayed in units like "KiB" - not the normal when examining key lengths used in X509Certificates. i.e a 2048 bit key gets displayed as "2 KiB" - I'd prefer to keep the 2048 display version. new webrev at: http://cr.openjdk.java.net/~coffeys/webrev.8148188.v4/webrev/ Regards, Sean. On 28/06/18 17:59, Se?n Coffey wrote: > Comments inline. > > > On 28/06/2018 17:20, Erik Gahlin wrote: >> It's sufficient if an event object escapes to another method >> (regardless if JFR is enabled or not). >> >> Some more feedback: >> >> Rename event jdk.CertChain to jdk.CertificateChain >> Rename event jdk.X509Cert to jdk.X509Certificate >> Rename field certChain to certificateChain. >> Rename field serialNum to serialNumber > all above done. >> Rename field algId to AlgorithmicId or AlgorithmicID > maybe "algorithm" works here also ? >> Rename @Label("Ciphersuite") to @Label("Cipher Suite") >> Rename @Label("Cert Chain") to @Label("Certificate Chain") >> Rename @Label("Property Name") to "Name" or "Key" if that makes sense >> in the context? >> Rename @Label("Property Value") to "Value". >> Put events in a subcategory, i.e @Category({"Java Development Kit", >> "Security"}) > done. >> Make classes final. > done. I had thought that the JFR mechanism required non-final classes. >> What is the unit of the key in X509Certificate event? Bits? If that >> is the case, use @DataAmount(DataAmount.BITS) > Yes - it's essentially the bit length of the keys used. Let me look > into that annotation usage. >> @Label("Serial numbers forming chain of trust") should not be a >> sentence. How about "Serial Numbers"? >> >> I think the tests are hard to read when two things are tested at the >> same time. It is also likely that if a test fail due to logging >> issues, it will be assigned to JFR because of the test name, even >> thought the issues is not JFR related. > I think we're always going to have some ownership issues when tests > serve a dual purpose. I still think it makes sense to keep the test > logic in one place. Any failures in these tests will most likely be > owned by security team. (moving the tests to security directory is > also an option) >> >> If you want to reuse code between tests, I would put it in testlibrary. > Let me check if there's any common patterns that could be added to the > testlibary. > > Thanks, > Sean. >> >> Erik >> >>> Thanks for the update Erik. By default I'm proposing that the new >>> JFR Events and Logger be disabled. As a result the event class >>> shouldn't escape. If performance metrics highlight an issue, we >>> should revisit. >>> >>> regards, >>> Sean. >>> >>> >>> On 27/06/2018 20:57, Erik Gahlin wrote: >>>> On 2018-06-27 21:14, Se?n Coffey wrote: >>>>> >>>>> >>>>> On 27/06/2018 19:57, Xuelei Fan wrote: >>>>>> Hi Sean, >>>>>> >>>>>> I may reply in several replies. >>>>>> >>>>>> PKIXMasterCertPathValidator.java >>>>>> -------------------------------- >>>>>> + CertChainEvent cce = new CertChainEvent(); >>>>>> + if(cce.isEnabled() || EventHelper.loggingSecurity()) { >>>>>> + String c = reversedCertList.stream() >>>>>> + .map(x -> x.getSerialNumber().toString(16)) >>>>>> + .collect(Collectors.joining(", ")); >>>>>> + EventHelper.commitCertChainEvent(cce, c); >>>>>> + } >>>>>> >>>>>> No matter the event or the JFR mechanism is enabled or not, the >>>>>> above code will create a new instance. Is the return value of >>>>>> cce.isEnabled() dynamically changed or static? >>>>> This is a requirement from the JFR framework. All their >>>>> event.isEnabled calls are instance methods and follow a similar >>>>> pattern. The JFR team assure me that the JIT can optimize away >>>>> such calls. >>>> >>>> The JIT will most likely not be able to optimize if the event class >>>> escapes. >>>> >>>> From a JFR perspective, this would be the preferred layout: >>>> >>>> EventA eventA= new EventA(); >>>> eventA.value = this.value; >>>> eventA.commit(); >>>> >>>> and then do logging separately: >>>> >>>> System.Logger.log(DEBUG, this.value) >>>> >>>> With this layout, the JIT will remove the allocation and dead store. >>>> >>>> If it is expensive to gather the data for the event, like the >>>> CertChainEvent above, the following pattern should be used. >>>> >>>> EventB eventB= new EventB (); >>>> if (eventB.shouldCommit()) { >>>> eventB.value = calculateValue(); >>>> eventB .commit(); >>>> } >>>> >>>> If JFR is not enabled, shouldCommit returns false and the JIT >>>> should be able to remove the allocation. This will be best from a >>>> performance point of view, and also in my opinion from a >>>> maintenance and readability perspective. Others may disagree. >>>> >>>> Erik >>>> >>>>>> >>>>>> Is there a need to support both logging and JFR? I'm new to >>>>>> record events. I did not get the point to use both. >>>>> I was initially hoping to concentrate on just JFR events but I got >>>>> strong feedback to also consider use of Logger (esp. in cases >>>>> where the jdk.jfr module is not available) >>>>> >>>>> regards, >>>>> Sean. >>>>> >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> On 6/26/2018 3:18 PM, Se?n Coffey wrote: >>>>>>> Erik, >>>>>>> >>>>>>> I rebased the patch with TLS v1.3 integration today. I hadn't >>>>>>> realized how much the handshaker code had changed. Hopefully, >>>>>>> I'll get a review from security dev team on that front. >>>>>>> >>>>>>> Regards the JFR semantics, I believe the edits should match >>>>>>> majority of requests . I still have a preference for the test >>>>>>> infra design for these new logger/JFR tests used in version 1 of >>>>>>> webrev. I think it makes sense to keep the test functionality >>>>>>> together - no sense in separating them out into different >>>>>>> components IMO. Also, some of the edits to the JFR testing were >>>>>>> made to test for the new dual log/record functionality. I might >>>>>>> catch up with you tomorrow to see what the best arrangement >>>>>>> would be. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v2/webrev/ >>>>>>> >>>>>>> regards, >>>>>>> Sean. >>>>>>> >>>>>>> >>>>>>> On 25/06/2018 21:22, Se?n Coffey wrote: >>>>>>>> Many thanks for the review comments Erik. Replies inline. >>>>>>>> >>>>>>>> >>>>>>>> On 24/06/2018 14:21, Erik Gahlin wrote: >>>>>>>>> Hi Sean, >>>>>>>>> >>>>>>>>> Some of the changes in the webrev belongs to JDK-8203629 and >>>>>>>>> should be removed for clarity. >>>>>>>>> >>>>>>>>> Some initial comments: >>>>>>>>> >>>>>>>>> default.jfc, profile.jfr: >>>>>>>>> The events should not have control="enable-exceptions". The >>>>>>>>> purpose of the control attribute is so to provide >>>>>>>>> parameterized configuration of events for JMC. As it is now, >>>>>>>>> the security events will be enabled when a user turns on the >>>>>>>>> exception events. >>>>>>>> Makes sense. I'll remove that parameter. >>>>>>>>> >>>>>>>>> X509CertEvent: >>>>>>>>> You should use milliseconds since epoch to represent a date >>>>>>>>> instead of a string value, i.e. >>>>>>>>> >>>>>>>>> @Label("Valid From") >>>>>>>>> @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>>>>>>>> public long validFrom; >>>>>>>>> >>>>>>>>> @Label("Valid Until") >>>>>>>>> @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>>>>>>>> public long validUntil; >>>>>>>>> >>>>>>>> The CertificateValidity class operates on Date Object values. >>>>>>>> I'll work with the Date.getTime() method then (and update the >>>>>>>> Logger formatting) >>>>>>>>> This following annotation adds little value >>>>>>>>> >>>>>>>>> @Description("Details of Security Property") >>>>>>>>> >>>>>>>>> I would either remove the annotation, or provide information >>>>>>>>> that helps a user understand the event. For instance, what is >>>>>>>>> X509, and what kind of certificates are we talking about? >>>>>>>> Yes - that looks like the wrong Description. I'll review all of >>>>>>>> these fields. >>>>>>>>> >>>>>>>>> @Category("Java Application") >>>>>>>>> >>>>>>>>> I'm a bit worried that we will pollute the "Java Application" >>>>>>>>> namespace if we add lots of JDK events in that category. We >>>>>>>>> may want to add a new top level category "Java Development >>>>>>>>> Kit", analogous to the "Java Virtual Machine" category, and >>>>>>>>> put all security related events in subcategory, perhaps called >>>>>>>>> "Security". >>>>>>>> Yes - Open to suggestions. "Security" sounds like a good >>>>>>>> suggestion. >>>>>>>>> >>>>>>>>> @Label("X509Cert") >>>>>>>>> >>>>>>>>> The label should be human readable name, with spaces, title >>>>>>>>> cased etc. I would recommend "X.509 Certificate". In general, >>>>>>>>> avoid abbreviations like "certs" and instead use labels such >>>>>>>>> as "Certificate Chain". The label should be short and not a >>>>>>>>> full sentence. >>>>>>>>> >>>>>>>>> For details see, >>>>>>>>> https://docs.oracle.com/javase/10/docs/api/jdk/jfr/Label.html >>>>>>>>> >>>>>>>>> I think it would be good to separate testing of JFR and >>>>>>>>> logging into different files / tests. I would prefer that the >>>>>>>>> test name is the same as the event prefixed with "Test", i.e >>>>>>>>> TestX509CertificateEvent, as this is the pattern used by other >>>>>>>>> JFR tests. >>>>>>>>> >>>>>>>> I'll take a look at that pattern again. I've separated out the >>>>>>>> current tests into an (a) outer test to analyze the logger >>>>>>>> output and (b) the inner test which checks for JFR correctness. >>>>>>>> I did include extra logic to make sure that the EventHelper >>>>>>>> configuration was working correctly. "Events.assertField" looks >>>>>>>> very helpful. Thanks for the pointer. >>>>>>>> >>>>>>>> Let me take on board the suggestions below and get a new webrev >>>>>>>> out on Tuesday. >>>>>>>> >>>>>>>> regards, >>>>>>>> Sean. >>>>>>>> >>>>>>>>> I reworked one of the tests to how I like to see it: >>>>>>>>> >>>>>>>>> /* >>>>>>>>> * @test >>>>>>>>> * @key jfr >>>>>>>>> * @library /test/lib >>>>>>>>> * @run main/othervm >>>>>>>>> jdk.jfr.event.security.TestX509CertificateEvent >>>>>>>>> */ >>>>>>>>> public class TestX509CertificateEvent { >>>>>>>>> >>>>>>>>> private static final String CERTIFICATE_1 = "..."; >>>>>>>>> private static final String CERTIFICATE_2 = "..."; >>>>>>>>> >>>>>>>>> public static void main(String... args) throws >>>>>>>>> CertificateException { >>>>>>>>> >>>>>>>>> Recording r = new Recording(); >>>>>>>>> r.enable(EventNames.X509Certificate).withoutStackTrace(); >>>>>>>>> r.start(); >>>>>>>>> >>>>>>>>> CertificateFactory cf = >>>>>>>>> CertificateFactory.getInstance("X.509"); >>>>>>>>> cf.generateCertificate(new >>>>>>>>> ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>>>>>>>> cf.generateCertificate(new >>>>>>>>> ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>>>>>>>> >>>>>>>>> // Make sure only one event per certificate >>>>>>>>> cf.generateCertificate(new >>>>>>>>> ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>>>>>>>> cf.generateCertificate(new >>>>>>>>> ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>>>>>>>> >>>>>>>>> r.stop(); >>>>>>>>> >>>>>>>>> List events = Events.fromRecording(r); >>>>>>>>> Asserts.assertEquals(events.size(), 2, "Expected two >>>>>>>>> X.509 Certificate events"); >>>>>>>>> >>>>>>>>> assertEvent(events, "1000", "SHA256withRSA", >>>>>>>>> "CN=SSLCertificate, O=SomeCompany", >>>>>>>>> "CN=Intermediate CA Cert, O=SomeCompany", >>>>>>>>> "RSA", 2048); >>>>>>>>> assertEvent(events, "1000", "SHA256withRSA", >>>>>>>>> "CN=SSLCertificate, O=SomeCompany", >>>>>>>>> "CN=Intermediate CA Cert, O=SomeCompany", >>>>>>>>> "RSA", 2048); >>>>>>>>> } >>>>>>>>> >>>>>>>>> private static void assertEvent(List >>>>>>>>> events, String certID, String algId, String subject, >>>>>>>>> String issuer, String keyType, int length) throws >>>>>>>>> Exception { >>>>>>>>> >>>>>>>>> for (RecordedEvent e : events) { >>>>>>>>> if (e.getString("serialNumber").equals(certID)) { >>>>>>>>> Events.assertField(e, "algId").equal(algId); >>>>>>>>> ... >>>>>>>>> return; >>>>>>>>> } >>>>>>>>> } >>>>>>>>> System.out.println(events); >>>>>>>>> throw new Exception("Could not find event with Cert >>>>>>>>> ID: " + certID); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> The reworked example uses the Events.assertField method, which >>>>>>>>> will give context if the assertion fails. Keeping the test >>>>>>>>> simple, means it can be analyzed quickly if it fails in >>>>>>>>> testing. There is no new test framework to learn, or methods >>>>>>>>> to search for, and it is usually not hard to determine if the >>>>>>>>> failure is product, test or infrastructure related, and what >>>>>>>>> component (team) should be assigned the issue. The use of >>>>>>>>> EventNames.X509Certificate means all occurrences of the event >>>>>>>>> can be tracked done in an IDE using find by reference. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Erik >>>>>>>>> >>>>>>>>>> Following on from the recent JDK-8203629 code review, I'd >>>>>>>>>> like to propose enhancements on how we can record events in >>>>>>>>>> security libs. The introduction of the JFR libraries can give >>>>>>>>>> us much better ways of examining JDK actions. For the initial >>>>>>>>>> phase, I'm looking to enhance some key security library >>>>>>>>>> events in JDK 11 so that they can be either recorded to JFR, >>>>>>>>>> logged to a traditional logger, or both. >>>>>>>>>> >>>>>>>>>> Examples of how useful JFR recordings could be can be seen >>>>>>>>>> here : >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/X509Event_1.png >>>>>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_1.png >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_2.png >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/TLSEvent_1.png >>>>>>>>>> >>>>>>>>>> securityProp_2.png gives an example of how the JFR recording >>>>>>>>>> can be queried to quickly locate events of interest (in this >>>>>>>>>> case, code setting the jdk.tls.* Security properties). I >>>>>>>>>> still need to clean up the TLSEvents testcase to improve test >>>>>>>>>> coverage and hope to do that in coming days. >>>>>>>>>> >>>>>>>>>> JBS record : >>>>>>>>>> * https://bugs.openjdk.java.net/browse/JDK-8148188 >>>>>>>>>> >>>>>>>>>> webrev : >>>>>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v1/webrev/ >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> >> > From mbalao at redhat.com Fri Jun 29 17:03:48 2018 From: mbalao at redhat.com (Martin Balao) Date: Fri, 29 Jun 2018 14:03:48 -0300 Subject: Code review request: JDK-8046295 - Support Trusted CA Indication extension In-Reply-To: References: <619b0a8b-5be7-1d29-6d8b-acf3cdc34a8c@oracle.com> <66aaaaad-175b-89f9-ba18-254b7881b0d1@oracle.com> <4d15dae7-e1a1-93ab-6b15-e95044c8f2f2@oracle.com> Message-ID: Hi Xuelei, Thanks for your notification. This is on my backlog again but don't have an ETA yet. Kind regards, Martin.- On Thu, Jun 28, 2018 at 1:14 PM, Xuelei Fan wrote: > Hi Martin, > > The TLS 1.3 implementation was integrated into the mainline. > > I know you have multiple contributions were pending because of the re-org > of the JSSE implementation. Would you mind to check if your design and > implementation need some adjustment? > > I may not reply for your contributions in other email threads. Please > trigger the code review again if the code is ready for the new JSSE > implementation. > > Thanks & Regards, > Xuelei > > > On 8/11/2017 8:24 AM, Xuelei Fan wrote: > >> Hi Martin, >> >> Sorry for the delay. >> >> I'd like to wait for finalization of TLS 1.3 specification, so that we >> can get a stable specification of the Certificate Authorities extension. >> >> For the current design, I did not see much benefit to add a new >> CertificateAuthority API. The CertificateAuthority.implies() may not yet >> reach the threshold to be a public API. A trust/key manager can easily >> matching the distinguished name with the target certificate. And I did not >> see the cert matching behavior differences between different providers and >> trust/key managers. >> >> For the specification documentation part, I may suggest reword them a >> little bit so that those developers who are not TLS specification experts >> can easily catch the purpose or benefits of the API. >> >> Xuelei >> >> On 7/21/2017 7:20 AM, Martin Balao wrote: >> >>> Webrev has been uploaded to cr.openjdk.java.net < >>> http://cr.openjdk.java.net>: >>> >>> * http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-80 >>> 46295/webrev.03/ >>> * http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-80 >>> 46295/webrev.03/8046295.webrev.03.zip >>> >>> Kind regards, >>> Martin.- >>> >>> On Tue, Jul 18, 2017 at 2:12 PM, Martin Balao >> > wrote: >>> >>> Hi, >>> >>> Given that 1) Trusted CA Indication TLS Extension does not appear to >>> be widely implemented today and 2) it will be replaced by >>> Certificate Authorities TLS extension in TLS 1.3, it looks more >>> beneficial to me supporting only the latter -and avoid paying the >>> cost for a larger code-base-. >>> >>> Here it is my proposal for Certificate Authorities TLS extension: >>> >>> * >>> http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_truste >>> d_ca/2017_07_18/8046295.webrev.03/ >>> >> ed_ca/2017_07_18/8046295.webrev.03/> >>> (browse online) >>> * >>> http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_truste >>> d_ca/2017_07_18/8046295.webrev.03.zip >>> >> ed_ca/2017_07_18/8046295.webrev.03.zip> >>> (download) >>> >>> Implementation based on TLS 1.3 - draft 20 [1]. Patch based on >>> JDK-10 (rev 76ff72bb6a4a). >>> >>> Pending / blocked (in descending priority order): >>> >>> High >>> >>> * The extension applies only to TLSv1.3+ >>> * Blocked because TLSv1.3 is still not supported in JSSE. >>> * Impact: the extension cannot be used in TLS 1.2 (high impact on >>> the client-side). >>> * Action: replace "useTLS12PlusSpec" with "useTLS13PlusSpec" in >>> the patch when available. >>> >>> Medium >>> >>> * Server can send the CertificateAuthorities extension to the >>> client in a CertificateRequest message (feature) >>> * Blocked by: Server is still not able to send >>> EncryptedExtensions message in CertificateRequest >>> * Impact: feature not supported on the server side. The extension >>> can still work in production environments. (medium). >>> * Action: implement EncryptedExtensions message in >>> CertificateRequest and then implement this feature. >>> >>> Low >>> >>> * Update documentation to refer the final TLS 1.3 RFC (draft 20 is >>> currently referred) >>> * Blocked by: publication of the final TLS 1.3 RFC >>> * Impact: documentation is not accurate. (low) >>> * Action: replace >>> "https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.2.4 >>> " >>> with the final link in the patch. >>> >>> * Update bug id in "CertificateAuthoritiesClientTest.java" and >>> "CertificateAuthoritiesServerTest.java" >>> * Blocked by: there is no bug id for Certificate Authorities TLS >>> extension >>> * Impact: internal tests (very low). >>> * Action: replace "@bug 8046295" with the new bug id in the >>> patch. Open a new bug id for Certificate Authorities TLS extension. >>> Look forward to your comments. >>> >>> Kind regards, >>> Martin.- >>> >>> -- >>> [1] - >>> https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.2.4 >>> >>> >>> On Tue, Jun 20, 2017 at 9:33 PM, Xuelei Fan >> > wrote: >>> >>> Hi Martin, >>> >>> The TLS 1.3 spec is replacing the Trusted CA Indication >>> (trusted_ca_keys) extension with a new Certificate Authorities >>> (certificate_authorities) extension. See more details about the >>> specification in the TLS 1.3 draft: >>> https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section- >>> 4.2.4 >> > >>> >>> Both serves a similar purpose, but the trusted_ca_keys extension >>> will not be used in TLS 1.3 any more. The "trusted_ca_keys" >>> extension will only be used for legacy protocol versions (TLS >>> 1.2/1.1/1.0). >>> >>> There are two options to me: >>> 1. Supports the certificate_authorities, but not trusted_ca_keys >>> extension. >>> It is acceptable to me as trusted_ca_keys is for legacy use only >>> and the certificate_authorities extension is the future. Plus, >>> the certificate_authorities extension can also be used for TLS >>> 1.2 and previous versions. >>> >>> 2. Supports both the certificate_authorities and trusted_ca_keys >>> extensions. >>> As far as I know, I did not see much benefit of this option >>> unless the trusted_ca_keys extension is widely used in practice. >>> >>> If I did not miss something, the APIs you designed can still be >>> used for the certificate_authorities extension, with a little >>> bit update. >>> >>> What do you think? >>> >>> Thanks & Regards, >>> Xuelei >>> >>> >>> On 6/15/2017 12:05 PM, Martin Balao wrote: >>> >>> Hi Xuelei, >>> >>> The new webrev.02 is ready: >>> >>> * >>> http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_truste >>> d_ca/2017_06_15/8046295.webrev.02/ >>> >> ed_ca/2017_06_15/8046295.webrev.02/> >>> (browse online) >>> * >>> http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_truste >>> d_ca/2017_06_15/8046295.webrev.02.zip >>> >> ed_ca/2017_06_15/8046295.webrev.02.zip> >>> (zip, download) >>> >>> The following changes have been implemented since the >>> previous webrev.01: >>> >>> * s/getUseTrustedCAIndication() methods in >>> SSLEngine/SSLSocket and in SSLEngineImpl/SSLSocketImpl >>> removed. s/getSSLParameters is now the only way to set or >>> get the use of the Trusted CA Indication extension. An >>> exception is no longer thrown if trying to disable the >>> extension for a server, but the change takes no effect as >>> the extension is mandatory for servers. X509KeyManagerImpl >>> modified to use SSLParameters to get information regarding >>> if Trusted CA Indication is enabled and should guide the >>> certificate choice. >>> >>> * TrustedAuthorityIndicator.IdentifierType has been moved >>> from enum to String, to follow JSSE conventions. I >>> understand how important is to be consistent. However, I >>> still believe that an enum is a better fit for this value >>> and does not prevent from future extension. We are choosing >>> from a closed set (strictly defined by the RFC) and that's >>> what enum allows to express. From the client point of >>> view/API, it's very handy that the type gives you >>> information regarding the allowed choices for the parameter. >>> You don't necessarily have to look for implementation >>> details or documentation but you can just leverage on the >>> strongly typed language. It's also likely that enums are >>> faster for comparisons than strings, but that's not the main >>> point here. >>> >>> * Removed X509Certificate from TrustedAuthorityIndicator >>> class (method and property). It was there for informational >>> purposes (when TrustedAuthorityIndicator was built from a >>> certificate by a client and the whole extension indicators >>> converted to String). >>> >>> * "equals" and "hashCode" methods moved from >>> TrustedAuthorityIndicator to TrustedAuthorityIndicatorImpl >>> class. >>> >>> * "getLength" method removed from >>> TrustedAuthorityIndicator class. It's possible to get the >>> encoded buffer and the length from there. >>> >>> * "getData" method renamed to "getEncoded" in >>> TrustedAuthorityIndicator class. >>> >>> * "trustedAuthorityEncodedData" renamed to "encodedData" >>> in TrustedAuthorityIndicator and >>> TrustedAuthorityIndicatorImpl classes >>> >>> * "identifier" and "encodedData" instance variables moved >>> from TrustedAuthorityIndicator to >>> TrustedAuthorityIndicatorImpl class. >>> >>> * "getEncoded" and "getIdentifier" are now abstract >>> methods in TrustedAuthorityIndicator, and their >>> implementation is in TrustedAuthorityIndicatorImpl class. >>> >>> * "getIdentifier" method renamed to "getType" in >>> TrustedAuthorityIndicator and TrustedAuthorityIndicatorImpl >>> classes ("identifier" instance variable and parameter in >>> TrustedAuthorityIndicatorImpl class renamed to "type"). >>> >>> * Test cases (server and client) updated to reflect the >>> new interface (enabling the use of the extension through >>> SSLParameters) >>> >>> However, some changes are still not implemented and I have >>> some concerns: >>> >>> 1) I still believe that identifier type information has to >>> be on TrustedAuthorityIndicator class somehow, and >>> implementations restricted on what they can return as part >>> of "getType" method. This is strictly specified by the RFC >>> TrustedAuthorityIndicator class represents, and I find >>> desirable that any implementation is enforced to be >>> compliant to that. If we remove all of that (including the >>> enum), TrustedAuthorityIndicator looks too generic and does >>> not reflect (in my opinion) what it really is. It'd also be >>> chaotic if different implementations call pre-agreed type as >>> "preagreed", "pre-agreed", "PRE_AGREED", etc. I prefer >>> stricter and more explicit interfaces. >>> >>> 2) I agree that type mappings can be seen as part of an >>> implementation, but they were in TrustedAuthorityIndicator >>> (as protected) because every implementation is highly likely >>> to need them and we can avoid the necessity for repeated >>> code/mappings. The same for "type" and "encodedData" >>> variables or even "hashCode" and "equals" methods. That's >>> why I was thinking more of an abstract class and not an >>> interface, as it happens (in example) with SNIServerName. >>> >>> 3) I think that "implies" method on >>> TrustedAuthorityIndicator should be also part of the >>> class/interface, because that's the whole point of a Trusted >>> Authority Information: to allow queries for a given >>> certificate. This is, in fact, the only thing a server wants >>> from one of these objects. My concern is that if we remove >>> this requirement for an implementation, the interface looks >>> more like a byte buffer holder. >>> >>> I'd appreciate if you can re-consider these items. >>> >>> Thanks, >>> Martin.- >>> >>> On Wed, Jun 14, 2017 at 7:17 PM, Xuelei Fan >>> >>> >> >> wrote: >>> >>> Hi Martin, >>> >>> The big picture of the design looks pretty good to me, >>> except a few >>> comment about the JSSE conventions. I appreciate it >>> very much. By >>> the way, I need more time to look into the details of >>> the >>> specification and implementation. >>> >>> >>> In order to keep the APIs simple and small, >>> SSLParameters is >>> preferred as the only configuration port for common >>> cases. I may >>> suggest to remove the s/getUseTrustedCAIndication() >>> methods in >>> SSLEngine/SSLSocket. >>> >>> The identify type is defined as an enum >>> TrustedAuthorityIndicator.IdentifierType. In the >>> future, if more >>> type is added, we need to update the specification by >>> adding a new >>> enum item. Enum is preferred in JDK, but for good >>> extensibility, in >>> general JSSE does not use enum in public APIs for >>> extensible >>> properties. I may suggest to use String (or >>> integer/byte, I prefer >>> to use String) as the type. The standard trusted >>> authority >>> indicator algorithm (identifier) can be documented in >>> the "Java >>> Cryptography Architecture Standard Algorithm Name >>> Documentation"[1]. >>> >>> In TrustedAuthorityIndicator class, some methods, like >>> getIdentifierTypeFromCode(), >>> getCodeFromIdentifierType(), implies(), >>> getLength(), equals() and hashCode() look more like >>> implementation >>> logic. I may suggest remove them from public APIs. >>> >>> I did not see the benefit to have X509Certificate in the >>> TrustedAuthorityIndicator class. The class is mainly >>> used for >>> server side certificate selection. X509Certificate >>> could be unknown >>> for a indicator. I may suggestion remove the related >>> methods and >>> properties. >>> >>> After that, as there is no requirement to instantiate >>> TrustedAuthorityIndicator class in application code, >>> looks like it >>> may be enough to use an interface to represent a >>> trusted authorities: >>> public interface TrustedAuthorityIndicator { >>> // identifier type, standard algorithm name >>> String/int/Byte getType(); >>> >>> // identifier >>> byte[] getEncoded(); >>> } >>> >>> What do you think? >>> >>> >>> Thanks & Regards, >>> Xuelei >>> >>> [1] >>> https://docs.oracle.com/javase/8/docs/technotes/guides/ >>> security/StandardNames.html >>> >> security/StandardNames.html> >>> >> security/StandardNames.html >>> >> security/StandardNames.html>> >>> >>> >>> On 6/13/2017 3:41 PM, Martin Balao wrote: >>> >>> Hi Xuelei, >>> >>> The new webrev.01 is ready: >>> >>> * >>> http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_truste >>> d_ca/2017_06_13/8046295.webrev.01/ >>> >> ed_ca/2017_06_13/8046295.webrev.01/> >>> >> ed_ca/2017_06_13/8046295.webrev.01/ >>> >> ed_ca/2017_06_13/8046295.webrev.01/>> >>> (browse online) >>> * >>> http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_truste >>> d_ca/2017_06_13/8046295.webrev.01.zip >>> >> ed_ca/2017_06_13/8046295.webrev.01.zip> >>> >> ed_ca/2017_06_13/8046295.webrev.01.zip >>> >> ed_ca/2017_06_13/8046295.webrev.01.zip>> >>> (zip, download) >>> >>> The following changes have been implemented since >>> the previous >>> webrev.00: >>> >>> * Pre-agreed support removed from server-side >>> * Unnecessary overhead and minium benefits for >>> JSSE. >>> >>> * Enabling the use of Trusted CA Indication >>> extension for >>> clients through TrustManager objects was reverted. >>> Trusted CA >>> Indication extension can now be enabled through: 1) >>> SSLEngine, >>> 2) SSLSocket, or 3) SSLParameters (which can be >>> applied to both >>> SSLEngine and SSLSocket objects). Trusted CA >>> Indication >>> extension is mandatory for servers. >>> >>> * SunX509KeyManagerImpl old key manager >>> ("SunX509" algorithm) >>> is now out of scope. This key manager does not >>> support other TLS >>> extensions as Server Name Indication (SNI), which >>> is far more >>> relevant than Trusted CA Indication. The new >>> X509KeyManagerImpl >>> key manager ("PKIX" algorithm) is now in scope. >>> >>> * Client requested indications are now an >>> ExtendedSSLSession >>> attribute. ServerHandshaker gets the information >>> from the Client >>> Hello message (now parsed by >>> TrustedCAIndicationExtension class >>> instead of TrustedAuthorityIndicator) and sets it >>> in the >>> ExtendedSSLSession (SSLSessionImpl object). The key >>> manager >>> (i.e.: X509KeyManagerImpl), when choosing a server >>> alias, may >>> now get the information from the ExtendedSSLSession >>> object and >>> guide the certificate selection based on it. >>> * In order to allow multiple key managers to >>> use Trusted >>> Authority Indicators information and to allow >>> multiple Trusted >>> Authority Indicators implementations, >>> TrustedAuthorityIndicator >>> has now been split in an abstract class >>> (TrustedAuthorityIndicator, located in >>> javax.net.ssl) and an >>> implementation class >>> (TrustedAuthorityIndicatorImpl, located in >>> sun.security.ssl). No coupling was added between >>> javax.net.ssl >>> and sun.security.ssl packages. >>> >>> * Documentation extended and improved. >>> * Test cases (server and client) updated to >>> reflect the new >>> interface and supported key manager. >>> >>> Look forward to your new review! >>> >>> Kind regards, >>> Martin.- >>> >>> >>> >>> On Fri, Jun 9, 2017 at 6:15 PM, Xuelei Fan >>> >> >> > >>> >> >> >>> >>> wrote: >>> >>> I'm OK to use SSLParameters. Thank you very >>> much for >>> considering a >>> new design. >>> >>> Xuelei >>> >>> On 6/9/2017 1:10 PM, Martin Balao wrote: >>> >>> Hi Xuelei, >>> >>> I didn't notice that some of the SSLSocket >>> contructors >>> did not >>> establish the connection, so SSLParameters >>> can be >>> effective for >>> Trusted CA Indication. This was an invalid >>> argument on >>> my side, >>> sorry. >>> >>> As for the configuration to enable the >>> extension, it's >>> probably >>> not necessary on the Server side because >>> -as you >>> mentioned- it >>> is mandatory and there is no harm in >>> supporting it. >>> However, it >>> has to be configurable on the Client side >>> because -as we >>> previously discussed- the client may cause >>> a handshake >>> failure >>> if the server does not support the >>> extension. I'd >>> prefer the >>> Client configuring the SSLSocket through >>> SSLParameters >>> instead >>> of a system-wide property -which has even >>> more impact >>> than the >>> TrustManager approach-. Would this work >>> for you? >>> >>> > In JSSE, the benefits pre_agreed >>> option can get by >>> customizing the key/trust manager, so I >>> did not see too >>> much >>> benefits to support this option in JDK >>> >>> I understand your point and will remove >>> support for >>> "pre_agreed". >>> >>> >>> On Fri, Jun 9, 2017 at 1:37 AM, Xuelei Fan >>> >> >> > >>> >> >> >> >>> >> >>> >> > >>> >>> >> >>>> >>> wrote: >>> >>> >>> >>> On 6/8/2017 8:36 PM, Xuelei Fan >>> wrote: >>> >>> The trusted authorities can be >>> get from client >>> trust >>> manager. Server can choose the >>> best matching of >>> server >>> certificate of the >>> client requested trusted >>> authorities. >>> >>> > >>> I missed the point that the key >>> manager need to >>> know the client >>> requested trusted authorities for the >>> choosing. So may >>> need a new >>> SSLSession attribute (See similar >>> method in >>> ExtendedSSLSession). >>> >>> Xuelei >>> >>> >>> >>> Yes, an attribute on SSLSession may do the >>> job (both >>> when Key >>> Manager receives a SSLSocket and a >>> SSLEngine). >>> >>> Kind regards, >>> Martin.- >>> >>> >>> >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Fri Jun 29 18:30:44 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 29 Jun 2018 11:30:44 -0700 Subject: RFR[11] JDK-8205720 "KeyFactory#getKeySpec and translateKey thorws NullPointerException with Invalid key" Message-ID: <6b7e5bdf-911b-c0a6-b8bd-0dfe841a0a27@oracle.com> Xuelei, Can you please help reviewing this fix for JCK test failures? Essentially, the JCK tests use key created with null algorithm, encoding, and format for triggering InvalidKeyException. However, the SunRsaSign provider code throw NPE so test failures are observed. Null checks are added to various places to detect and check InvalidKeyException instead. Fixes have been verified against the failed JCK tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8205720 Webrev: http://cr.openjdk.java.net/~valeriep/8205720/webrev.00/ Thanks, Valerie -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Fri Jun 29 18:35:36 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 29 Jun 2018 11:35:36 -0700 Subject: RFR[11] JDK-8205720 "KeyFactory#getKeySpec and translateKey thorws NullPointerException with Invalid key" In-Reply-To: <6b7e5bdf-911b-c0a6-b8bd-0dfe841a0a27@oracle.com> References: <6b7e5bdf-911b-c0a6-b8bd-0dfe841a0a27@oracle.com> Message-ID: Looks fine to me. Thanks, Xuelei On 6/29/2018 11:30 AM, Valerie Peng wrote: > Xuelei, > > Can you please help reviewing this fix for JCK test failures? > Essentially, the JCK tests use key created with null algorithm, > encoding, and format for triggering InvalidKeyException. However, the > SunRsaSign provider code throw NPE so test failures are observed. Null > checks are added to various places to detect and check > InvalidKeyException instead. Fixes have been verified against the failed > JCK tests. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205720 > Webrev: http://cr.openjdk.java.net/~valeriep/8205720/webrev.00/ > > Thanks, > Valerie > From gromero at linux.vnet.ibm.com Wed Jun 20 00:59:58 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 20 Jun 2018 00:59:58 -0000 Subject: RFC: Add new JCA provider to support hardware RNGs Message-ID: <993c258a-57ae-d29d-2368-faac5b4d3cb1@linux.vnet.ibm.com> Hi, Please, could I get comments on the following change? Since it's related to security, I would be glad if security experts could also comment on that. webrev: http://cr.openjdk.java.net/~gromero/POWER9/darn/v6_rebased/ It introduces a way to get benefits from hardware instructions in userspace that can delivery a random number and so be used to speed up and avoid blocking in some SecureRandom methods, notably generateSeed() and nextBytes(), without loosing the random number quality. Particularly on Power, the new POWER9 CPUs introduced a hardware instruction called 'darn' that can be used for that purpose. The main idea is to add a new JCA provider called "HWTRNG" (if no better name is suggested), adding new helper methods that can then be intrinsified and that will be used by generateSeed() and nextBytes(). In that sense, this change also adds the proper mechanisms in the Interpreter, C1 Compiler, and C2 compiler (for PPC64, but also paving the way for other platforms) to intrinsify these helper methods that will be used in the end by generateSeed() and nextBytes() methods. The added helpers are: byte[] getRandomSequence0(int) byte[] getRandomSequence1(byte[]) long validRandomLong(void) long randomLong(void) The helpers also take care of checking if the returned random number is valid and attempt 10 times (as recommended by ISA) get a valid random number before falling back to a software alternative (HWTRNG is based mostly on JCA provider NativePRNG and so the fall back mechanism will use the exactly same methods found in NativePRNG and hence behave similarly. Nonetheless, in my experience such a hardware failures (which are the main cause of a returned invalid random number) are quite rare: in my tests I was never able to exhaust the HW RNG and force it to generate an invalid random number). The user, besides having to specify explicitly the use of a non-default provider (HWTRNG), will have to unlock the VM experimental options to effectively use the hardware RNG as an unique random source by passing options "-XX:+UnlockExperimentalVMOptions -XX:+UseRANDOMIntrinsics". On Power, for the Interpreter and C1 Compiler, besides avoiding the blocking effect of a low entropy on /dev/random, I was able to get about 126 Mbps (3x higher than the version without 'darn') on generaSeed() and nextBytes(). The maximum theoretical value on a POWER9 machine is usually 128 Mbps. I'll address the details about the file headers (Copyright, dates, authors, versions, etc) after I get some feedback about this change. Thanks in advance. Best regards, Gustavo