From xuelei.fan at oracle.com Wed Jul 1 00:44:21 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 01 Jul 2015 08:44:21 +0800 Subject: [9] review request for 8130151: Exclude sun/security/provider/SecureRandom/StrongSecureRandom.java from testruns on MacOSX 10.10 In-Reply-To: <1199E054-CD38-4A7C-AAD0-75F62E0FC2B8@oracle.com> References: <1199E054-CD38-4A7C-AAD0-75F62E0FC2B8@oracle.com> Message-ID: <559337E5.2000900@oracle.com> Looks fine to me. Xuelei On 7/1/2015 1:34 AM, Vincent Ryan wrote: > Please approve this temporary addition to the ProblemList to exclude a > single test on Mac OS X 10.10 only. > It is related to the issue being tracked > by https://bugs.openjdk.java.net/browse/JDK-8051770 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8130151 > Webrev: http://cr.openjdk.java.net/~vinnie/8130151/webrev.00/ > > Thanks. From xuelei.fan at oracle.com Wed Jul 1 01:04:07 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 01 Jul 2015 09:04:07 +0800 Subject: [Update]: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <55931A9A.9080003@oracle.com> References: <558361E0.2060409@oracle.com> <558EBBF7.3010805@oracle.com> <5592658D.5090004@oracle.com> <55931A9A.9080003@oracle.com> Message-ID: <55933C87.9040000@oracle.com> On 7/1/2015 6:39 AM, Jamil Nimeh wrote: >> src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java >> ================================================================== >> line 713/714, 730/731 throws SSLHandshakeException for extension >> constructor in server side. That's unlikely to happen, I think. I was >> wondering, if CertificateStatus cannot be constructed, the server may >> not want to send the message, rather than terminate the connection >> immediately. > I think you're right. While the exception is unlikely, I'd like to have > the HandshakeMessage throw the exception if something bad happens. I do > however, agree that we shouldn't make it a fatal error. I'll catch the > exception in ServerHandshaker, log it, and just not send the message as > you suggested since that is legal. OK? I have not read the server side implementation. I would like firstly check whether the message should be delivered, and than new the instance. Exception catching is not performance friendly, and looks a little bit not-straightforward. I think you may want a static method for the validity checking in CertificateStatus class, instead. It's OK to throw exception if something bad happens. For easy reading, please have a comment that it is unlikely to happen if you keep the throw exception blocks. Thanks, Xuelei From xuelei.fan at oracle.com Wed Jul 1 01:53:07 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 01 Jul 2015 09:53:07 +0800 Subject: [Update]: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <55932882.50805@oracle.com> References: <558361E0.2060409@oracle.com> <558EBBF7.3010805@oracle.com> <55922925.5000806@oracle.com> <55932882.50805@oracle.com> Message-ID: <55934803.5010707@oracle.com> On 7/1/2015 7:38 AM, Jamil Nimeh wrote: >> src/java.base/share/classes/sun/security/validator/PKIXValidator.java >> ===================================================================== >> minor comment: >> >> Is it more instinctive if changing the parameter name from responseList >> to ocspResponses, and the method name from addResponses() to >> addOcspResponses()? >> >> Same for SimpleValidator.java and Validator.java. > I've tried to not use "ocsp" in the names, only because OCSP is just one > type of stapled response for certificate revocation status. Granted, it > is the only one used today. I didn't want to use a term that denoted > that the only kind of data coming through CertificateStatus is OCSP > data, since in the future it may be something different. I know there > are places where I didn't adhere to my own rule, but I really tried to > where I could. Good point. I had the same concern for the spec of ExtendedSSLSession.getStatusResponses(). If the response other than OCSP, may need to specify the type of the response. I'm OK with the current API as OCSP is the only cert status we know so far: public List getStatusResponses() Alternatively, if you want the flexibility to support types other than OCSP, the API may look like: public Map> getStatusResponses() Xuelei From jamil.j.nimeh at oracle.com Wed Jul 1 02:02:15 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 30 Jun 2015 19:02:15 -0700 Subject: [Update]: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <55933C87.9040000@oracle.com> References: <558361E0.2060409@oracle.com> <558EBBF7.3010805@oracle.com> <5592658D.5090004@oracle.com> <55931A9A.9080003@oracle.com> <55933C87.9040000@oracle.com> Message-ID: <55934A27.2010709@oracle.com> On 06/30/2015 06:04 PM, Xuelei Fan wrote: > On 7/1/2015 6:39 AM, Jamil Nimeh wrote: >>> src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java >>> ================================================================== >>> line 713/714, 730/731 throws SSLHandshakeException for extension >>> constructor in server side. That's unlikely to happen, I think. I was >>> wondering, if CertificateStatus cannot be constructed, the server may >>> not want to send the message, rather than terminate the connection >>> immediately. >> I think you're right. While the exception is unlikely, I'd like to have >> the HandshakeMessage throw the exception if something bad happens. I do >> however, agree that we shouldn't make it a fatal error. I'll catch the >> exception in ServerHandshaker, log it, and just not send the message as >> you suggested since that is legal. OK? > I have not read the server side implementation. I would like firstly > check whether the message should be delivered, and than new the > instance. Exception catching is not performance friendly, and looks a > little bit not-straightforward. I think you may want a static method > for the validity checking in CertificateStatus class, instead. As it is written today, the ServerHandshaker will only create a new CertificateStatus instance if the following is true: * Stapling has already been activated in the server (meaning that the client requested it and the server has the feature enabled) * A "get" operation was done from the StatusResponseManager and at least one OCSP response was returned. In other words, if no responses can be brought back from the SRM, then there's no point in even asserting status_request[_v2] in the ServerHello. I don't see the advantage of making a static method that does what is already accomplished in two lines of code in ServerHandshaker (873-4). > > It's OK to throw exception if something bad happens. For easy reading, > please have a comment that it is unlikely to happen if you keep the > throw exception blocks. Okay, I can definitely do that. There are some cases where I think we need to throw an exception, particularly on the constructor from a HandshakeInStream. That's a case where we want the client to Alert if the server asserts some weird/unsupported/illegal type or does something like type = ocsp and a zero length response (also illegal according to the spec). Zero length responses are OK for ocsp_multi, though. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Wed Jul 1 02:10:28 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 30 Jun 2015 19:10:28 -0700 Subject: [Update]: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <55934803.5010707@oracle.com> References: <558361E0.2060409@oracle.com> <558EBBF7.3010805@oracle.com> <55922925.5000806@oracle.com> <55932882.50805@oracle.com> <55934803.5010707@oracle.com> Message-ID: <55934C13.4080302@oracle.com> On 06/30/2015 06:53 PM, Xuelei Fan wrote: > On 7/1/2015 7:38 AM, Jamil Nimeh wrote: >>> src/java.base/share/classes/sun/security/validator/PKIXValidator.java >>> ===================================================================== >>> minor comment: >>> >>> Is it more instinctive if changing the parameter name from responseList >>> to ocspResponses, and the method name from addResponses() to >>> addOcspResponses()? >>> >>> Same for SimpleValidator.java and Validator.java. >> I've tried to not use "ocsp" in the names, only because OCSP is just one >> type of stapled response for certificate revocation status. Granted, it >> is the only one used today. I didn't want to use a term that denoted >> that the only kind of data coming through CertificateStatus is OCSP >> data, since in the future it may be something different. I know there >> are places where I didn't adhere to my own rule, but I really tried to >> where I could. > Good point. > > I had the same concern for the spec of > ExtendedSSLSession.getStatusResponses(). If the response other than > OCSP, may need to specify the type of the response. I'm OK with the > current API as OCSP is the only cert status we know so far: > public List getStatusResponses() > > Alternatively, if you want the flexibility to support types other than > OCSP, the API may look like: > public Map> getStatusResponses() That's a good idea, Xuelei. Let me take a closer look at that approach. I think it would pretty easy to make this change, and it would involve a minor change to either X509TrustManagerImpl or PKIXValidator (probably the latter since that's where we really do things with the response bytes). If the responses are of a type we don't currently support, then I think we just treat it as if no responses were provided. If I can get that reworked tonight I'll send out another webrev with this last round of comments from you and Sean. --Jamil From xuelei.fan at oracle.com Wed Jul 1 02:42:29 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 01 Jul 2015 10:42:29 +0800 Subject: [Update]: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <55934A27.2010709@oracle.com> References: <558361E0.2060409@oracle.com> <558EBBF7.3010805@oracle.com> <5592658D.5090004@oracle.com> <55931A9A.9080003@oracle.com> <55933C87.9040000@oracle.com> <55934A27.2010709@oracle.com> Message-ID: <55935395.7060907@oracle.com> On 7/1/2015 10:02 AM, Jamil Nimeh wrote: > > > On 06/30/2015 06:04 PM, Xuelei Fan wrote: >> On 7/1/2015 6:39 AM, Jamil Nimeh wrote: >>>> src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java >>>> ================================================================== >>>> line 713/714, 730/731 throws SSLHandshakeException for extension >>>> constructor in server side. That's unlikely to happen, I think. I was >>>> wondering, if CertificateStatus cannot be constructed, the server may >>>> not want to send the message, rather than terminate the connection >>>> immediately. >>> I think you're right. While the exception is unlikely, I'd like to have >>> the HandshakeMessage throw the exception if something bad happens. I do >>> however, agree that we shouldn't make it a fatal error. I'll catch the >>> exception in ServerHandshaker, log it, and just not send the message as >>> you suggested since that is legal. OK? >> I have not read the server side implementation. I would like firstly >> check whether the message should be delivered, and than new the >> instance. Exception catching is not performance friendly, and looks a >> little bit not-straightforward. I think you may want a static method >> for the validity checking in CertificateStatus class, instead. > As it is written today, the ServerHandshaker will only create a new > CertificateStatus instance if the following is true: > > * Stapling has already been activated in the server (meaning that the > client requested it and the server has the feature enabled) > * A "get" operation was done from the StatusResponseManager and at > least one OCSP response was returned. In other words, if no > responses can be brought back from the SRM, then there's no point in > even asserting status_request[_v2] in the ServerHello. > > I don't see the advantage of making a static method that does what is > already accomplished in two lines of code in ServerHandshaker (873-4). > Good you can accomplish it in ServerHandshaker. >> >> It's OK to throw exception if something bad happens. For easy reading, >> please have a comment that it is unlikely to happen if you keep the >> throw exception blocks. > Okay, I can definitely do that. There are some cases where I think we > need to throw an exception, particularly on the constructor from a > HandshakeInStream. It's the expected behavior to throw exception for reading issues. What we are talking about previously is for write side constructor. Thanks, Xuelei > That's a case where we want the client to Alert if > the server asserts some weird/unsupported/illegal type or does something > like type = ocsp and a zero length response (also illegal according to > the spec). Zero length responses are OK for ocsp_multi, though. > From xuelei.fan at oracle.com Wed Jul 1 03:52:13 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 01 Jul 2015 11:52:13 +0800 Subject: [Update]: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <558EBBF7.3010805@oracle.com> References: <558361E0.2060409@oracle.com> <558EBBF7.3010805@oracle.com> Message-ID: <559363ED.50501@oracle.com> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java ================================================================ Minor comment: Not necessary, but in order to indicate the initialization, better to set statusResponses variable to null explicitly in the constructor. ----------- line 564-569 The comment does not apply here now. You may forgot to remove this comment. ----------- 570 if ((cipherSuite.keyExchange == K_KRB5) || 571 (cipherSuite.keyExchange == K_KRB5_EXPORT) || 572 statusResponses == null || statusResponses.isEmpty()) { There are situations other than KRB5 that do not use certificate-base authentication. The call should take care of the situations when setting the statusResponses value. The statusResponses should not be set if it does not apply. It's enough to check statusResponses only: if (statusResponses == null || statusResponses.isEmpty()) { src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java ================================================================== Minor comment: 59 // The default amount of time the handshaker will wait ... 60 private static final long DEFAULT_STATUS_RESP_DELAY = 5000; I think the unit is millisecond. Nice to indicate the time unit. ------------- Need to update handshake states. 964 csMsg.write(output); + handshakeState.update(csMsg, resumingSession); 965 responseMap = null; Xuelei On 6/27/2015 11:06 PM, Jamil Nimeh wrote: > Hello all, I've posted an updated webrev based on comments I've received > so far: > > http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.1 > > Thanks, > --Jamil > > On 06/18/2015 05:27 PM, Jamil Nimeh wrote: >> Hello all, >> >> I have a first cut at the OCSP stapling webrev posted for your review: >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8046321 >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/ >> >> A couple items to note: >> >> * I'm in the process of updating the JEP with some more details. I >> should be done with these changes by tonight (PDT). >> * Missing are some of the TLS end-to-end tests. These tests have >> been coded and run outside the jtreg framework, but for some >> reason things hang in jtreg. I've included some of the supporting >> classes that these tests will use (CertificateBuilder.java and >> SimpleOCSPResponder.java) so folks could review those if they're >> interested. I will update the webrev and notify the list as soon >> as I've got the tests working in jtreg. >> >> Thanks to everyone who has helped along the way. >> >> --Jamil >> >> > From zoltan.majo at oracle.com Wed Jul 1 08:54:26 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 01 Jul 2015 10:54:26 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> <559120C8.5070208@oracle.com> <559141C3.7000909@redhat.com> <9CDED78E-AC52-444C-95E0-6453D6E8D86C@oracle.com> Message-ID: <5593AAC2.5070202@oracle.com> Hi, thank you, everyone, for the comments/suggestions/feedback! If no other issues come up, I intend to push the latest webrev (webrev.07) on Thursday (July 2). Best regards, Zoltan From aph at redhat.com Wed Jul 1 11:57:49 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 01 Jul 2015 12:57:49 +0100 Subject: RFR: 8130150: RSA Acceleration In-Reply-To: <5592D6AA.8020509@redhat.com> References: <557ABD2E.7050608@redhat.com> <557EFF94.5000006@oracle.com> <557F042D.4060707@redhat.com> <558033C4.8040104@redhat.com> <5582F936.5020008@oracle.com> <5582FACA.4060103@redhat.com> <5582FDCA.8010507@oracle.com> <55831BC8.9060001@oracle.com> <5583D414.5050502@redhat.com> <558D7D02.6070303@redhat.com> <559103D8.1010302@oracle.com> <559110BF.4090804@redhat.com> <5592D6AA.8020509@redhat.com> Message-ID: <5593D5BD.8000809@redhat.com> On 06/30/2015 06:49 PM, Andrew Haley wrote: > New webrevs: > > http://cr.openjdk.java.net/~aph/8130150-jdk > http://cr.openjdk.java.net/~aph/8130150-hs/ I made an error when preparing these webrevs. Please ignore. Andrew. From bhanu.prakash.gopularam at oracle.com Wed Jul 1 12:48:13 2015 From: bhanu.prakash.gopularam at oracle.com (Bhanu Prakash Gopularam) Date: Wed, 1 Jul 2015 05:48:13 -0700 (PDT) Subject: RFR: 8048830 - Implement tests for new functionality provided in JEP 166 In-Reply-To: <1b1a0975-c522-4b92-8339-76a6d2a274c5@default> References: <1b1a0975-c522-4b92-8339-76a6d2a274c5@default> Message-ID: <995b679f-4873-44da-87c3-790e44785865@default> Hello, Please review changes for JEP 166: Test for storing and validating the secret key entries in keystore is merged into test/sun/security/pkcs12/StoreSecretKeyTest.java and the test certificate files are regenerated with valid identity information. HYPERLINK "http://cr.openjdk.java.net/%7Easmotrak/bhanu/8048830/webrev.04/"http://cr.openjdk.java.net/~asmotrak/bhanu/8048830/webrev.04/ Thanks, Bhanu From: Bhanu Prakash Gopularam Sent: Monday, May 25, 2015 8:43 PM To: security-dev at openjdk.java.net Subject: RFR: 8048830 - Implement tests for new functionality provided in JEP 166 Hello, Please review tests for JEP 166: Tests check for default key store format i.e., PKCS 12, import a trusted cert into PKCS 12 key store and export cert and print it. Tests validate whether exception is thrown when key entry with invalid cert chain is imported, Read and write key entry data to key store. Tests also validate metadata store and load functionality. Bug: https://bugs.openjdk.java.net/browse/JDK-8048830 Webrev: http://cr.openjdk.java.net/~asmotrak/bhanu/8048830/webrev.00/ Thanks, Bhanu -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Wed Jul 1 14:56:40 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 01 Jul 2015 15:56:40 +0100 Subject: RFR: 8130150: RSA Acceleration In-Reply-To: <5593D5BD.8000809@redhat.com> References: <557ABD2E.7050608@redhat.com> <557EFF94.5000006@oracle.com> <557F042D.4060707@redhat.com> <558033C4.8040104@redhat.com> <5582F936.5020008@oracle.com> <5582FACA.4060103@redhat.com> <5582FDCA.8010507@oracle.com> <55831BC8.9060001@oracle.com> <5583D414.5050502@redhat.com> <558D7D02.6070303@redhat.com> <559103D8.1010302@oracle.com> <559110BF.4090804@redhat.com> <5592D6AA.8020509@redhat.com> <5593D5BD.8000809@redhat.com> Message-ID: <5593FFA8.8090506@redhat.com> Sorry for the mistake. New webrevs: http://cr.openjdk.java.net/~aph/8130150-hs-1/ http://cr.openjdk.java.net/~aph/8130150-jdk-1/ Andrew. From david.lloyd at redhat.com Wed Jul 1 16:45:52 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 01 Jul 2015 11:45:52 -0500 Subject: New status code in SSLEngineResult.HandshakeStatus Message-ID: <55941940.30100@redhat.com> It has caused some consternation among certain of our engineers that there is a new possible status code in SSLEngineResult.HandshakeStatus. If a new status were generally added, it would cause subtle or not so subtle breakage amount current SSLEngine consumers. I request that it be made more clear in the documentation that the new status code applies only to DTLS; something like this: diff --git a/src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java b/src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java index e2865e6..5473188 100644 --- a/src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java +++ b/src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java @@ -156,6 +156,9 @@ public class SSLEngineResult { * This value is used to indicate that not-yet-interpreted data * has been previously received from the remote side, and does * not need to be received again. + *

+ * This result code is only used by DTLS and is not a possible + * result for stream-oriented TLS. * * @since 1.9 */ Thanks. -- - DML From ivan.gerasimov at oracle.com Wed Jul 1 17:04:17 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 01 Jul 2015 20:04:17 +0300 Subject: RFR 8098854: Do cleanup in a proper order in mscapi In-Reply-To: <55846AE6.30004@oracle.com> References: <55846AE6.30004@oracle.com> Message-ID: <55941D91.6070001@oracle.com> Hello! Would someone please help review this small cleanup fix? I'll go on vacation in a week, and I would like to push it before then. Sincerely yours, Ivan On 19.06.2015 22:17, Ivan Gerasimov wrote: > Hello everyone! > > The changeset consists of two parts: > - checking systematically for NULL result of FindClass() and > GetMethodID(), > - calling CryptReleaseContext() after CryptDestroyHash(), as it is > suggested in MSDN [1]. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8098854 > WEBREV: http://cr.openjdk.java.net/~igerasim/8098854/00/webrev/ > > [1] > https://msdn.microsoft.com/en-us/library/windows/desktop/aa380268(v=vs.85).aspx > > Sincerely yours, > Ivan > > > From vincent.x.ryan at oracle.com Wed Jul 1 17:08:43 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 1 Jul 2015 18:08:43 +0100 Subject: RFR 8098854: Do cleanup in a proper order in mscapi In-Reply-To: <55941D91.6070001@oracle.com> References: <55846AE6.30004@oracle.com> <55941D91.6070001@oracle.com> Message-ID: <29DA0004-1C83-4ECB-88FC-195BBC22B68E@oracle.com> Your fix looks fine to me. Thanks. > On 1 Jul 2015, at 18:04, Ivan Gerasimov wrote: > > Hello! > > Would someone please help review this small cleanup fix? > I'll go on vacation in a week, and I would like to push it before then. > > Sincerely yours, > Ivan > > On 19.06.2015 22:17, Ivan Gerasimov wrote: >> Hello everyone! >> >> The changeset consists of two parts: >> - checking systematically for NULL result of FindClass() and GetMethodID(), >> - calling CryptReleaseContext() after CryptDestroyHash(), as it is suggested in MSDN [1]. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8098854 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8098854/00/webrev/ >> >> [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa380268(v=vs.85).aspx >> >> Sincerely yours, >> Ivan >> >> >> > From vladimir.kozlov at oracle.com Wed Jul 1 18:56:10 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 01 Jul 2015 11:56:10 -0700 Subject: RFR: 8130150: RSA Acceleration In-Reply-To: <5593FFA8.8090506@redhat.com> References: <557ABD2E.7050608@redhat.com> <557EFF94.5000006@oracle.com> <557F042D.4060707@redhat.com> <558033C4.8040104@redhat.com> <5582F936.5020008@oracle.com> <5582FACA.4060103@redhat.com> <5582FDCA.8010507@oracle.com> <55831BC8.9060001@oracle.com> <5583D414.5050502@redhat.com> <558D7D02.6070303@redhat.com> <559103D8.1010302@oracle.com> <559110BF.4090804@redhat.com> <5592D6AA.8020509@redhat.com> <5593D5BD.8000809@redhat.com> <5593FFA8.8090506@redhat.com> Message-ID: <559437CA.2070303@oracle.com> Looks good to me. Thanks, Vladimir On 7/1/15 7:56 AM, Andrew Haley wrote: > Sorry for the mistake. New webrevs: > > http://cr.openjdk.java.net/~aph/8130150-hs-1/ > http://cr.openjdk.java.net/~aph/8130150-jdk-1/ > > Andrew. > From ivan.gerasimov at oracle.com Wed Jul 1 19:01:46 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 01 Jul 2015 22:01:46 +0300 Subject: RFR 8098854: Do cleanup in a proper order in mscapi In-Reply-To: <29DA0004-1C83-4ECB-88FC-195BBC22B68E@oracle.com> References: <55846AE6.30004@oracle.com> <55941D91.6070001@oracle.com> <29DA0004-1C83-4ECB-88FC-195BBC22B68E@oracle.com> Message-ID: <5594391A.4040604@oracle.com> On 01.07.2015 20:08, Vincent Ryan wrote: > Your fix looks fine to me. > Thanks. > Thank you Vincent! >> On 1 Jul 2015, at 18:04, Ivan Gerasimov wrote: >> >> Hello! >> >> Would someone please help review this small cleanup fix? >> I'll go on vacation in a week, and I would like to push it before then. >> >> Sincerely yours, >> Ivan >> >> On 19.06.2015 22:17, Ivan Gerasimov wrote: >>> Hello everyone! >>> >>> The changeset consists of two parts: >>> - checking systematically for NULL result of FindClass() and GetMethodID(), >>> - calling CryptReleaseContext() after CryptDestroyHash(), as it is suggested in MSDN [1]. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8098854 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8098854/00/webrev/ >>> >>> [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa380268(v=vs.85).aspx >>> >>> Sincerely yours, >>> Ivan >>> >>> >>> > > From weijun.wang at oracle.com Thu Jul 2 07:46:35 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 02 Jul 2015 15:46:35 +0800 Subject: RFR 8130112: Create a common TEST.properties for @modules in test/sun/security/krb5/auto Message-ID: <5594EC5B.2050302@oracle.com> Hi All Please take a look at http://cr.openjdk.java.net/~weijun/8130112/webrev.00/ You only need to read the jdk.patch file. Basically I just remove the @modules tags in each test and combine them into a single TEST.properties. Two other small changes: 1. HttpNegotiateServer no longer uses PlatformLogger, there is no useful output. 2. tools/KtabZero.java (not in auto) has a platform-dependent @modules value (sun.security.krb5.internal.tools only available on Windows) and @requires tag is used. A JPRT job is running now. Thanks Max From Alan.Bateman at oracle.com Thu Jul 2 07:53:56 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 02 Jul 2015 08:53:56 +0100 Subject: RFR 8130112: Create a common TEST.properties for @modules in test/sun/security/krb5/auto In-Reply-To: <5594EC5B.2050302@oracle.com> References: <5594EC5B.2050302@oracle.com> Message-ID: <5594EE14.8060002@oracle.com> On 02/07/2015 08:46, Weijun Wang wrote: > Hi All > > Please take a look at > > http://cr.openjdk.java.net/~weijun/8130112/webrev.00/ > > You only need to read the jdk.patch file. Basically I just remove the > @modules tags in each test and combine them into a single > TEST.properties. > > Two other small changes: > > 1. HttpNegotiateServer no longer uses PlatformLogger, there is no > useful output. > > 2. tools/KtabZero.java (not in auto) has a platform-dependent @modules > value (sun.security.krb5.internal.tools only available on Windows) and > @requires tag is used. > This looks good to me. -Alan. From vincent.x.ryan at oracle.com Thu Jul 2 10:52:58 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 2 Jul 2015 11:52:58 +0100 Subject: [9] review request for 8130151: Exclude sun/security/provider/SecureRandom/StrongSecureRandom.java from testruns on MacOSX 10.10 In-Reply-To: <559337E5.2000900@oracle.com> References: <1199E054-CD38-4A7C-AAD0-75F62E0FC2B8@oracle.com> <559337E5.2000900@oracle.com> Message-ID: Thanks Xuelei. > On 1 Jul 2015, at 01:44, Xuelei Fan wrote: > > Looks fine to me. > > Xuelei > > On 7/1/2015 1:34 AM, Vincent Ryan wrote: >> Please approve this temporary addition to the ProblemList to exclude a >> single test on Mac OS X 10.10 only. >> It is related to the issue being tracked >> by https://bugs.openjdk.java.net/browse/JDK-8051770 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8130151 >> Webrev: http://cr.openjdk.java.net/~vinnie/8130151/webrev.00/ >> >> Thanks. > From xuelei.fan at oracle.com Thu Jul 2 12:05:43 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 02 Jul 2015 20:05:43 +0800 Subject: [Update]: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <558EBBF7.3010805@oracle.com> References: <558361E0.2060409@oracle.com> <558EBBF7.3010805@oracle.com> Message-ID: <55952917.2070502@oracle.com> sun/security/ssl/ServerHandshaker.java ====================================== OCSP stapling only used for certificate-based server authentication at present. I was wondering, may be better to make a check before wrap the ServerHello OCSP extension and CertificateStatus message that Certificate message would be actually used. ------------------- 860 for (CertStatusReqItemV2 csriv2 : 861 statReqExtV2.getRequestItems()) { 862 // Favor OCSP_MULTI over OCSP 863 statReqType = csriv2.getType(); 864 statReqData = csriv2.getRequest(); 865 if (statReqType == StatusRequestType.OCSP_MULTI) { 866 break; 867 } 868 } Client's preference (favorite choice first) should be respected. For type OCSP, line 863-864 prefer the last item rather than the client preference. And line 863-864 does not consider whether the OCSPStatusRequest is suitable for this server or not, just select the last one. As may result in ocsp stapling failure if the selected item is not for the right responder. Line 865-867 does not consider whether the OCSPStatusRequest is suitable for this server or not, either. In general, client knows nothing about server certificates. So client would offer responders it trusted. The responders is not necessary suitable for the target server. The server side should select a suitable one. It is not necessary the first one or the last one. See also section 2.2, RFC 6961: "Servers that support a client's selection of responders using the ResponderID field could implement this selection by matching the responder ID values from the client's list with the ResponderIDs of known OCSP responders, either by using a binary compare of the values or a hash calculation and compare method." If the update of your implementation is pretty significant or it is unclean how we should move forward at present, I'm OK if you want to remove the support of client specified responders. sun/security/ssl/StatusResponseManager.java =========================================== line 207-213: // It is assumed that the caller has ordered the certs in the chain // from end-entity to trust anchor. In order to create the CertId // necessary for OCSP requests the subject and issuer certs must // be present. - if (chain.length < 2) { + if (chain.length == 0) { return Collections.emptyMap(); } This assumption is not actually correct in general. The trust anchor is not necessarily be included in the Certificate message. See page 48, section 7.4.2, RFC 5246. ---------------------------- 436 List responderIds; You don't actually use the client specified responders, do you? It's OK to me if we don't support none-empty OCSPStatusRequest. If we do not want to do that, I would suggest to remove the related implementation code for that. As would simplify the job, I think. ----------------------------- 252 // Set a bunch of threads to go do the fetching 253 List> resultList = 254 threadMgr.invokeAll(requestList, delay, unit); The current implementation of OCSP response getter, looks like for every cert in the chain, a fetch thread would be created to get the corresponding OCSP response. In the fetch thread, if the response is cached, use it; otherwise, connect to OCSP server and fetch it. Performance would be a very big concern. A connection may kick start many threads. Fetch threads may be a bottleneck of the server. In general, a server may be expected to serve 10K+ connections, but may only be able to hit around 10K- threads. It's likely to face DoS challenges if every ClientHello trigger 1+ fetch threads. Another performance concern is that when there is no cache, the client would have to wait for the server to fetch the response from OCSP servers. It's easy to run into client timeout issue. I may suggest to use a single thread to get responses from OCSP servers. And any TLS connection would only get responses from cache. The scenarios may looks like: 1. Per every SSLContext instance, create a scheduled single thread to fetch the response from OCSP servers, and cache them for each server certificate chains. The server certificates can be got from key manager. 2. For every client request, look for the response from the cache. 3. if responder is not cached and if we want to support none-empty OCSPStatusRequest, fetch the response from OCSP servers in the same thread, and cache the result. We may also want to add the task to the scheduled thread in #1. Not create new thread for every connection is important for SSLEngine in some circumstances. #3 is also not performance friendly. I think none-empty OCSPStatusRequest is not common in practice. I will stop here for the first round code review. Looking forward for the next round webrev. Thanks, Xuelei On 6/27/2015 11:06 PM, Jamil Nimeh wrote: > Hello all, I've posted an updated webrev based on comments I've received > so far: > > http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.1 > > Thanks, > --Jamil > > On 06/18/2015 05:27 PM, Jamil Nimeh wrote: >> Hello all, >> >> I have a first cut at the OCSP stapling webrev posted for your review: >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8046321 >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/ >> >> A couple items to note: >> >> * I'm in the process of updating the JEP with some more details. I >> should be done with these changes by tonight (PDT). >> * Missing are some of the TLS end-to-end tests. These tests have >> been coded and run outside the jtreg framework, but for some >> reason things hang in jtreg. I've included some of the supporting >> classes that these tests will use (CertificateBuilder.java and >> SimpleOCSPResponder.java) so folks could review those if they're >> interested. I will update the webrev and notify the list as soon >> as I've got the tests working in jtreg. >> >> Thanks to everyone who has helped along the way. >> >> --Jamil >> >> > From vincent.x.ryan at oracle.com Thu Jul 2 12:59:39 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 2 Jul 2015 13:59:39 +0100 Subject: RFR: 8048830 - Implement tests for new functionality provided in JEP 166 In-Reply-To: <995b679f-4873-44da-87c3-790e44785865@default> References: <1b1a0975-c522-4b92-8339-76a6d2a274c5@default> <995b679f-4873-44da-87c3-790e44785865@default> Message-ID: <3CE6810D-75E6-4185-A16B-91DBC3049944@oracle.com> These new tests look fine. Thanks. > On 1 Jul 2015, at 13:48, Bhanu Prakash Gopularam wrote: > > Hello, > > Please review changes for JEP 166: > Test for storing and validating the secret key entries in keystore is merged into test/sun/security/pkcs12/StoreSecretKeyTest.java and the test certificate files are regenerated with valid identity information. > > http://cr.openjdk.java.net/~asmotrak/bhanu/8048830/webrev.04/ > > Thanks, > Bhanu > > From: Bhanu Prakash Gopularam > Sent: Monday, May 25, 2015 8:43 PM > To: security-dev at openjdk.java.net > Subject: RFR: 8048830 - Implement tests for new functionality provided in JEP 166 > > Hello, > > Please review tests for JEP 166: > > Tests check for default key store format i.e., PKCS 12, import a trusted cert into PKCS 12 key store and export cert and print it. Tests validate whether exception is thrown when key entry with invalid cert chain is imported, Read and write key entry data to key store. Tests also validate metadata store and load functionality. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8048830 > Webrev: http://cr.openjdk.java.net/~asmotrak/bhanu/8048830/webrev.00/ > > Thanks, > Bhanu -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Jul 2 14:05:21 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 02 Jul 2015 10:05:21 -0400 Subject: RFR 8058290: JAAS Krb5LoginModule has suspect ticket-renewal logic, relies on clockskew grace In-Reply-To: <558BBA10.8090301@oracle.com> References: <558BBA10.8090301@oracle.com> Message-ID: <55954521.6030904@oracle.com> This looks fine. The isOld method should probably be static. Also, can you document this renewal behavior in the class summary in the "renewTGT" section? --Sean On 06/25/2015 04:21 AM, Weijun Wang wrote: > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8058290/webrev.00/ > > After this fix, a "renewTGT=true" in JAAS config for Krb5LoginModule > means "renew if old enough", as suggested by the bug reporter [1]. > > Thanks > Max > > [1] https://bugs.openjdk.java.net/browse/JDK-8058290 From jamil.j.nimeh at oracle.com Thu Jul 2 14:26:18 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 02 Jul 2015 07:26:18 -0700 Subject: [Update]: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <55952917.2070502@oracle.com> References: <558361E0.2060409@oracle.com> <558EBBF7.3010805@oracle.com> <55952917.2070502@oracle.com> Message-ID: <55954A0A.4050708@oracle.com> On 07/02/2015 05:05 AM, Xuelei Fan wrote: > sun/security/ssl/ServerHandshaker.java > ====================================== > OCSP stapling only used for certificate-based server authentication at > present. I was wondering, may be better to make a check before wrap > the ServerHello OCSP extension and CertificateStatus message that > Certificate message would be actually used. > > ------------------- > 860 for (CertStatusReqItemV2 csriv2 : > 861 statReqExtV2.getRequestItems()) { > 862 // Favor OCSP_MULTI over OCSP > 863 statReqType = csriv2.getType(); > 864 statReqData = csriv2.getRequest(); > 865 if (statReqType == StatusRequestType.OCSP_MULTI) { > 866 break; > 867 } > 868 } > > Client's preference (favorite choice first) should be respected. For > type OCSP, line 863-864 prefer the last item rather than the client > preference. And line 863-864 does not consider whether the > OCSPStatusRequest is suitable for this server or not, just select the > last one. As may result in ocsp stapling failure if the selected item > is not for the right responder. We talked about this back when the original design was done. Back then I had gone with client-ordering as the selection criteria and the feedback I got was to favor ocsp_multi for those clients that can do it, since it gives a more complete set of revocation information. While the client is ordering it's preference, I don't see in the spec any area that says the server has to strictly adhere to the client preference. If we want to favor ocsp_multi as a server we should be able to do that legally. As for the discussion where we talked about this, I don't recall if it was a conversation or in email. I'll have to check. If folks feel strongly about strictly honoring client ordering I can make the change. The current code snippet doesn't strictly prefer the last item. If the first item is OCSP_MULTI, then it will stop right there, but your point is still true that we're not going on client ordering (as explained above). > > Line 865-867 does not consider whether the OCSPStatusRequest is suitable > for this server or not, either. > > In general, client knows nothing about server certificates. So client > would offer responders it trusted. The responders is not necessary > suitable for the target server. The server side should select a > suitable one. It is not necessary the first one or the last one. See > also section 2.2, RFC 6961: > > "Servers that support a client's selection of responders using the > ResponderID field could implement this selection by matching the > responder ID values from the client's list with the ResponderIDs of > known OCSP responders, either by using a binary compare of the values > or a hash calculation and compare method." > > If the update of your implementation is pretty significant or it is > unclean how we should move forward at present, I'm OK if you want to > remove the support of client specified responders. As implied from the above paragraph servers aren't required to support client ResponderId selection. I don't have support for this feature yet, neither from the client or the server. The OCSPStatusRequest has the hooks in it to populate ResponderIds because it was fairly easy to do. I would like to leave that code in, since providing that capability to the client is something I want to do in the future, as well as handle the server selection based on Responder Id. > > sun/security/ssl/StatusResponseManager.java > =========================================== > line 207-213: > > // It is assumed that the caller has ordered the certs in the chain > // from end-entity to trust anchor. In order to create the CertId > // necessary for OCSP requests the subject and issuer certs must > // be present. > - if (chain.length < 2) { > + if (chain.length == 0) { > return Collections.emptyMap(); > } > > This assumption is not actually correct in general. The trust anchor is > not necessarily be included in the Certificate message. See page 48, > section 7.4.2, RFC 5246. I believe this chain comes in from the KeyManager via ServerHandshaker.setupPrivateKeyAndChain(), so it should be a complete cert chain in the correct order (or as complete as the server can do, I suppose). The Certificate message is not a factor here. > > ---------------------------- > 436 List responderIds; > > You don't actually use the client specified responders, do you? It's OK > to me if we don't support none-empty OCSPStatusRequest. If we do not > want to do that, I would suggest to remove the related implementation > code for that. As would simplify the job, I think. No, not today. In the future we will. I don't believe Apache does ResponderId selection either. Not sure about other implementations. I know Apache will handle extension forwarding, which we also do (and can opt not to do with a property). I don't want to remove the code though. Those are the hooks for the feature in the future. Same for the OCSPStatusRequest...it has a constructor that allows population of extensions and ResponderIds. I'd like to leave this in, even if we're not populating those fields from the client today. > > ----------------------------- > 252 // Set a bunch of threads to go do the fetching > 253 List> resultList = > 254 threadMgr.invokeAll(requestList, delay, unit); > > The current implementation of OCSP response getter, looks like for every > cert in the chain, a fetch thread would be created to get the > corresponding OCSP response. In the fetch thread, if the response is > cached, use it; otherwise, connect to OCSP server and fetch it. > > Performance would be a very big concern. A connection may kick start > many threads. Fetch threads may be a bottleneck of the server. In > general, a server may be expected to serve 10K+ connections, but may > only be able to hit around 10K- threads. It's likely to face DoS > challenges if every ClientHello trigger 1+ fetch threads. If a Server has to hit that many connections simultaneously, it's probably already doing multi-threading to accomplish that goal, wouldn't you think? If it cannot hit 10K threads to begin with, it seems to me like some system-level tuning needs to be done . Second, a new thread isn't created for each client connection. This is a thread pool, so a core number of threads are created when the SRM is created, new ones are made as needed, and old ones are reused whenever their task is finished and goes into an idle state. So we not always making a new thread. Further, time to bring the response back to the caller from the cache is very fast, between 2-5 msec. So there would most likely be some thread reuse on a very busy server. That very busy server is not going to be a single-core/single-thread machine; it will be capable of servicing multiple threads at the same time, so that should help aggregate throughput. It of course takes significantly longer to bring the response back from the network. I didn't get exact numbers, but in an environment where the responders are on the same machine as the server I could get them back in about 150msec. So in extremely rough terms it's network IO time + 150msec for each fetch. > > Another performance concern is that when there is no cache, the client > would have to wait for the server to fetch the response from OCSP > servers. It's easy to run into client timeout issue. As clients do with other implementations. If the server doesn't have the response, it has to get it and the client has to wait for it. I see no problem here. The connection delay isn't technically the time taken to retrieve all responses, it is the time taken to retrieve all responses or the server fetch timeout, whichever is smaller. A server can opt to wait 500 msec, 1000msec, or whatever the admin thinks is appropriate given the distance of the responders and the client load. If the timer is exceeded, the server will include any responses it has and will not include the ones it is still retrieving. If it cannot get any, then it doesn't even assert status_requst[_v2]. What's more, even if the server has to get 3 responses, but only has one by the timeout threshold the remaining two fetches will continue in the background and complete, even if the connection has gone on. This way a future connection coming in has a greater chance of getting a cache hit. > > I may suggest to use a single thread to get responses from OCSP servers. > And any TLS connection would only get responses from cache. The > scenarios may looks like: > 1. Per every SSLContext instance, create a scheduled single thread to > fetch the response from OCSP servers, and cache them for each server > certificate chains. The server certificates can be got from key manager. > 2. For every client request, look for the response from the cache. > 3. if responder is not cached and if we want to support none-empty > OCSPStatusRequest, fetch the response from OCSP servers in the same > thread, and cache the result. We may also want to add the task to the > scheduled thread in #1. Not create new thread for every connection is > important for SSLEngine in some circumstances. > > #3 is also not performance friendly. I think none-empty > OCSPStatusRequest is not common in practice. I'll have to think about your proposal a bit. It's a significant change from what I'm doing, but it is an interesting alternative. As stated above, we don't create new threads for each connection. Threads are reused when they are idle/available. You are correct, non-empty OCSPStatusRequests are rare. I've never seen a client do one. I've only looked at browsers, but none of them populate the request. > > > I will stop here for the first round code review. Looking forward for > the next round webrev. > > Thanks, > Xuelei > > > On 6/27/2015 11:06 PM, Jamil Nimeh wrote: >> Hello all, I've posted an updated webrev based on comments I've received >> so far: >> >> http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.1 >> >> Thanks, >> --Jamil >> >> On 06/18/2015 05:27 PM, Jamil Nimeh wrote: >>> Hello all, >>> >>> I have a first cut at the OCSP stapling webrev posted for your review: >>> >>> JEP: https://bugs.openjdk.java.net/browse/JDK-8046321 >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/ >>> >>> A couple items to note: >>> >>> * I'm in the process of updating the JEP with some more details. I >>> should be done with these changes by tonight (PDT). >>> * Missing are some of the TLS end-to-end tests. These tests have >>> been coded and run outside the jtreg framework, but for some >>> reason things hang in jtreg. I've included some of the supporting >>> classes that these tests will use (CertificateBuilder.java and >>> SimpleOCSPResponder.java) so folks could review those if they're >>> interested. I will update the webrev and notify the list as soon >>> as I've got the tests working in jtreg. >>> >>> Thanks to everyone who has helped along the way. >>> >>> --Jamil >>> >>> From zoltan.majo at oracle.com Thu Jul 2 15:39:52 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 02 Jul 2015 17:39:52 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <5593AAC2.5070202@oracle.com> References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> <559120C8.5070208@oracle.com> <559141C3.7000909@redhat.com> <9CDED78E-AC52-444C-95E0-6453D6E8D86C@oracle.com> <5593AAC2.5070202@oracle.com> Message-ID: <55955B48.2070108@oracle.com> Hi, I updated the code to also consider intrinsics that were recently added for the following methods: - java.math.BigInteger.implMontgomeryMultiply - java.math.BigInteger.implMontgomerySquare - java.util.zip.CRC32C.updateBytes - java.util.zip.CRC32C.updateDirectByteBuffer In the latest webrev (webrev.08) three files have changed relative to the previous webrev (webrev.07): - hotspot: src/share/vm/classfile/vmSymbols.hpp (merge conflict) - jdk: src/java.base/share/classes/java/util/zip/CRC32.java and src/java.base/share/classes/java/math/BigInteger.java (annotations were added to intrinsified methods) Here is the updated webrev: - hotspot: http://cr.openjdk.java.net/~zmajo/8076112/hotspot/webrev.08/ - jdk: http://cr.openjdk.java.net/~zmajo/8076112/jdk/webrev.08/ All JPRT tests pass. I plan to push the newest webrev (webrev.08) on Friday (July 3) if no other issues come up by then. Thank you and best regards, Zoltan On 07/01/2015 10:54 AM, Zolt?n Maj? wrote: > Hi, > > > thank you, everyone, for the comments/suggestions/feedback! If no > other issues come up, I intend to push the latest webrev (webrev.07) > on Thursday (July 2). > > Best regards, > > > Zoltan > From xuelei.fan at oracle.com Thu Jul 2 16:43:01 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 03 Jul 2015 00:43:01 +0800 Subject: [Update]: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <55954A0A.4050708@oracle.com> References: <558361E0.2060409@oracle.com> <558EBBF7.3010805@oracle.com> <55952917.2070502@oracle.com> <55954A0A.4050708@oracle.com> Message-ID: <55956A15.7030105@oracle.com> On 7/2/2015 10:26 PM, Jamil Nimeh wrote: > > > On 07/02/2015 05:05 AM, Xuelei Fan wrote: >> sun/security/ssl/ServerHandshaker.java >> ====================================== >> OCSP stapling only used for certificate-based server authentication at >> present. I was wondering, may be better to make a check before wrap >> the ServerHello OCSP extension and CertificateStatus message that >> Certificate message would be actually used. >> >> ------------------- >> 860 for (CertStatusReqItemV2 csriv2 : >> 861 statReqExtV2.getRequestItems()) { >> 862 // Favor OCSP_MULTI over OCSP >> 863 statReqType = csriv2.getType(); >> 864 statReqData = csriv2.getRequest(); >> 865 if (statReqType == StatusRequestType.OCSP_MULTI) { >> 866 break; >> 867 } >> 868 } >> >> Client's preference (favorite choice first) should be respected. For >> type OCSP, line 863-864 prefer the last item rather than the client >> preference. And line 863-864 does not consider whether the >> OCSPStatusRequest is suitable for this server or not, just select the >> last one. As may result in ocsp stapling failure if the selected item >> is not for the right responder. > We talked about this back when the original design was done. Back then > I had gone with client-ordering as the selection criteria and the > feedback I got was to favor ocsp_multi for those clients that can do it, > since it gives a more complete set of revocation information. While the > client is ordering it's preference, I don't see in the spec any area > that says the server has to strictly adhere to the client preference. > If we want to favor ocsp_multi as a server we should be able to do that > legally. As for the discussion where we talked about this, I don't > recall if it was a conversation or in email. I'll have to check. If > folks feel strongly about strictly honoring client ordering I can make > the change. > I think we are not talking about the same thing. Per RFC 6961: The items in the list of CertificateStatusRequestItemV2 entries are ordered according to the client's preference (favorite choice first). Considering the request list: ocsp-1, ocsp-2, ocsp_multi-1, ocsp_multi-2 I think we would want to select ocsp_multi-1, it's the expected behavior. We prefer ocsp_multi. It's OK. Considering one more request list: ocsp-1, ocsp-2 I think the current implementation would select ocsp-2, rather than ocsp-1. That's one of my concerns. This update should be simple. Let's consider one more example, the server cert is issued by Verisign Class 3. The request list looks like: ocsp_multi-1 (for Entrust OCSP responder), ocsp_multi-2 (for Verisign), ocsp_multi-3 (for Verisign Class 3), ocsp_multi-4 (for GeoTrust) We are expected to use ocsp_multi-3 for the server cert. I think your implementation would use ocsp_multi-1 (for Entrust) as the OCSP responder for Verisign Class 3 server cert. That's another one of my concerns. > The current code snippet doesn't strictly prefer the last item. If the > first item is OCSP_MULTI, then it will stop right there, but your point > is still true that we're not going on client ordering (as explained above). >> >> Line 865-867 does not consider whether the OCSPStatusRequest is suitable >> for this server or not, either. >> >> In general, client knows nothing about server certificates. So client >> would offer responders it trusted. The responders is not necessary >> suitable for the target server. The server side should select a >> suitable one. It is not necessary the first one or the last one. See >> also section 2.2, RFC 6961: >> >> "Servers that support a client's selection of responders using the >> ResponderID field could implement this selection by matching the >> responder ID values from the client's list with the ResponderIDs of >> known OCSP responders, either by using a binary compare of the values >> or a hash calculation and compare method." >> >> If the update of your implementation is pretty significant or it is >> unclean how we should move forward at present, I'm OK if you want to >> remove the support of client specified responders. > As implied from the above paragraph servers aren't required to support > client ResponderId selection. I don't have support for this feature > yet, neither from the client or the server. The OCSPStatusRequest has > the hooks in it to populate ResponderIds because it was fairly easy to > do. I would like to leave that code in, since providing that capability > to the client is something I want to do in the future, as well as handle > the server selection based on Responder Id. See above. >> >> sun/security/ssl/StatusResponseManager.java >> =========================================== >> line 207-213: >> >> // It is assumed that the caller has ordered the certs in the chain >> // from end-entity to trust anchor. In order to create the CertId >> // necessary for OCSP requests the subject and issuer certs must >> // be present. >> - if (chain.length < 2) { >> + if (chain.length == 0) { >> return Collections.emptyMap(); >> } >> >> This assumption is not actually correct in general. The trust anchor is >> not necessarily be included in the Certificate message. See page 48, >> section 7.4.2, RFC 5246. > I believe this chain comes in from the KeyManager via > ServerHandshaker.setupPrivateKeyAndChain(), so it should be a complete > cert chain in the correct order (or as complete as the server can do, I > suppose). The Certificate message is not a factor here. It may be a complete cert chain. And a complete cert chain may not contain the trust anchor. It depends on the key manager implementation. Our implementation may provider the trust anchor, but others may not. >> >> ---------------------------- >> 436 List responderIds; >> >> You don't actually use the client specified responders, do you? It's OK >> to me if we don't support none-empty OCSPStatusRequest. If we do not >> want to do that, I would suggest to remove the related implementation >> code for that. As would simplify the job, I think. > No, not today. It's OK to me. > In the future we will. IMHO, I don't find the necessary to support this feature in the near future. Maybe we can do it when we have some free cycles. > I don't believe Apache does > ResponderId selection either. Not sure about other implementations. I > know Apache will handle extension forwarding, which we also do (and can > opt not to do with a property). I don't want to remove the code > though. Those are the hooks for the feature in the future. Same for > the OCSPStatusRequest...it has a constructor that allows population of > extensions and ResponderIds. I'd like to leave this in, even if we're > not populating those fields from the client today. I would suggest remove the source code. You can have the history in a webrev. In an official product, we'd better not having unused code. >> >> ----------------------------- >> 252 // Set a bunch of threads to go do the fetching >> 253 List> resultList = >> 254 threadMgr.invokeAll(requestList, delay, unit); >> >> The current implementation of OCSP response getter, looks like for every >> cert in the chain, a fetch thread would be created to get the >> corresponding OCSP response. In the fetch thread, if the response is >> cached, use it; otherwise, connect to OCSP server and fetch it. >> >> Performance would be a very big concern. A connection may kick start >> many threads. Fetch threads may be a bottleneck of the server. In >> general, a server may be expected to serve 10K+ connections, but may >> only be able to hit around 10K- threads. It's likely to face DoS >> challenges if every ClientHello trigger 1+ fetch threads. > If a Server has to hit that many connections simultaneously, it's > probably already doing multi-threading to accomplish that goal, wouldn't > you think? If it cannot hit 10K threads to begin with, it seems to me > like some system-level tuning needs to be done. We may be not on the same page again. I was talking a threshold benchmark: how much clients a server can serve at the same time. Let's see an example, suppose the cert chain contains 3 certs, each connection takes one thread. The system is able to hit 10K thread. Before your implementation, the system can accept 10K clients at the same time. With the implementation, because each cert may open a thread, the system can only accept 2.5K clients. Very bad performance impact. > Second, a new thread > isn't created for each client connection. This is a thread pool, so a > core number of threads are created when the SRM is created, new ones are > made as needed, and old ones are reused whenever their task is finished > and goes into an idle state. So we not always making a new thread. > I understand, but the threshold are get impacted. Not much impact on spare system, but bad performance impact on busy system. > Further, time to bring the response back to the caller from the cache is > very fast, between 2-5 msec. So there would most likely be some thread > reuse on a very busy server. That very busy server is not going to be a > single-core/single-thread machine; it will be capable of servicing > multiple threads at the same time, so that should help aggregate > throughput. > Not enough. 10K client may request the connection at the same time, and the management of a large butch of threads (10K) is a big load for every system. That's why AIO programming popular today. We support AIO programming via SSLEngine, need to consider the requirements. > It of course takes significantly longer to bring the response back from > the network. I didn't get exact numbers, but in an environment where > the responders are on the same machine as the server I could get them > back in about 150msec. So in extremely rough terms it's network IO time > + 150msec for each fetch. >> >> Another performance concern is that when there is no cache, the client >> would have to wait for the server to fetch the response from OCSP >> servers. It's easy to run into client timeout issue. > As clients do with other implementations. If the server doesn't have > the response, it has to get it and the client has to wait for it. I see > no problem here. No problem here. The problem is we may want to improve the performance if we could. > The connection delay isn't technically the time taken > to retrieve all responses, it is the time taken to retrieve all > responses or the server fetch timeout, whichever is smaller. A server > can opt to wait 500 msec, 1000msec, or whatever the admin thinks is > appropriate given the distance of the responders and the client load. > If the timer is exceeded, the server will include any responses it has > and will not include the ones it is still retrieving. If it cannot get > any, then it doesn't even assert status_requst[_v2]. > 10 seconds is the OCSP service availability per Baseline Requirements of CA/Browser Forum. If 200 msec is used, it means the OCSP stapling of the server may be not reliable as the OCSP server may not response yet when timeout. > What's more, even if the server has to get 3 responses, but only has one > by the timeout threshold the remaining two fetches will continue in the > background and complete, even if the connection has gone on. This way a > future connection coming in has a greater chance of getting a cache hit. It's a kind of unreliable for the present client. We may want to make a improvement if possible. Thanks, Xuelei >> >> I may suggest to use a single thread to get responses from OCSP servers. >> And any TLS connection would only get responses from cache. The >> scenarios may looks like: >> 1. Per every SSLContext instance, create a scheduled single thread to >> fetch the response from OCSP servers, and cache them for each server >> certificate chains. The server certificates can be got from key manager. >> 2. For every client request, look for the response from the cache. >> 3. if responder is not cached and if we want to support none-empty >> OCSPStatusRequest, fetch the response from OCSP servers in the same >> thread, and cache the result. We may also want to add the task to the >> scheduled thread in #1. Not create new thread for every connection is >> important for SSLEngine in some circumstances. >> >> #3 is also not performance friendly. I think none-empty >> OCSPStatusRequest is not common in practice. > I'll have to think about your proposal a bit. It's a significant change > from what I'm doing, but it is an interesting alternative. > > As stated above, we don't create new threads for each connection. > Threads are reused when they are idle/available. > > You are correct, non-empty OCSPStatusRequests are rare. I've never seen > a client do one. I've only looked at browsers, but none of them > populate the request. >> >> >> I will stop here for the first round code review. Looking forward for >> the next round webrev. >> >> Thanks, >> Xuelei >> >> >> On 6/27/2015 11:06 PM, Jamil Nimeh wrote: >>> Hello all, I've posted an updated webrev based on comments I've received >>> so far: >>> >>> http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.1 >>> >>> Thanks, >>> --Jamil >>> >>> On 06/18/2015 05:27 PM, Jamil Nimeh wrote: >>>> Hello all, >>>> >>>> I have a first cut at the OCSP stapling webrev posted for your review: >>>> >>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8046321 >>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/ >>>> >>>> A couple items to note: >>>> >>>> * I'm in the process of updating the JEP with some more details. I >>>> should be done with these changes by tonight (PDT). >>>> * Missing are some of the TLS end-to-end tests. These tests have >>>> been coded and run outside the jtreg framework, but for some >>>> reason things hang in jtreg. I've included some of the supporting >>>> classes that these tests will use (CertificateBuilder.java and >>>> SimpleOCSPResponder.java) so folks could review those if they're >>>> interested. I will update the webrev and notify the list as soon >>>> as I've got the tests working in jtreg. >>>> >>>> Thanks to everyone who has helped along the way. >>>> >>>> --Jamil >>>> >>>> > From jamil.j.nimeh at oracle.com Thu Jul 2 17:25:30 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 02 Jul 2015 10:25:30 -0700 Subject: [Update]: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <55956A15.7030105@oracle.com> References: <558361E0.2060409@oracle.com> <558EBBF7.3010805@oracle.com> <55952917.2070502@oracle.com> <55954A0A.4050708@oracle.com> <55956A15.7030105@oracle.com> Message-ID: <5595740A.4020707@oracle.com> On 7/2/2015 9:43 AM, Xuelei Fan wrote: > On 7/2/2015 10:26 PM, Jamil Nimeh wrote: >> On 07/02/2015 05:05 AM, Xuelei Fan wrote: >>> sun/security/ssl/ServerHandshaker.java >>> ====================================== >>> OCSP stapling only used for certificate-based server authentication at >>> present. I was wondering, may be better to make a check before wrap >>> the ServerHello OCSP extension and CertificateStatus message that >>> Certificate message would be actually used. >>> >>> ------------------- >>> 860 for (CertStatusReqItemV2 csriv2 : >>> 861 statReqExtV2.getRequestItems()) { >>> 862 // Favor OCSP_MULTI over OCSP >>> 863 statReqType = csriv2.getType(); >>> 864 statReqData = csriv2.getRequest(); >>> 865 if (statReqType == StatusRequestType.OCSP_MULTI) { >>> 866 break; >>> 867 } >>> 868 } >>> >>> Client's preference (favorite choice first) should be respected. For >>> type OCSP, line 863-864 prefer the last item rather than the client >>> preference. And line 863-864 does not consider whether the >>> OCSPStatusRequest is suitable for this server or not, just select the >>> last one. As may result in ocsp stapling failure if the selected item >>> is not for the right responder. >> We talked about this back when the original design was done. Back then >> I had gone with client-ordering as the selection criteria and the >> feedback I got was to favor ocsp_multi for those clients that can do it, >> since it gives a more complete set of revocation information. While the >> client is ordering it's preference, I don't see in the spec any area >> that says the server has to strictly adhere to the client preference. >> If we want to favor ocsp_multi as a server we should be able to do that >> legally. As for the discussion where we talked about this, I don't >> recall if it was a conversation or in email. I'll have to check. If >> folks feel strongly about strictly honoring client ordering I can make >> the change. >> > I think we are not talking about the same thing. > > Per RFC 6961: > > The items in the list of CertificateStatusRequestItemV2 entries are > ordered according to the client's preference (favorite choice first). > > Considering the request list: > ocsp-1, ocsp-2, ocsp_multi-1, ocsp_multi-2 > > I think we would want to select ocsp_multi-1, it's the expected > behavior. We prefer ocsp_multi. It's OK. Oh! I see what you mean about not honoring the preference now. The current implementation in this particular case would select ocsp_multi-1, since we break from the loop on first detection of ocsp_multi. > Considering one more request list: > ocsp-1, ocsp-2 > > I think the current implementation would select ocsp-2, rather than > ocsp-1. That's one of my concerns. This update should be simple. In this case you are correct, we would select ocsp-2. So that's definitely inconsistent behavior given your previous example. I will fix this to select the first instance of each type, but allow ocsp_multi to take precedence over ocsp. > > Let's consider one more example, the server cert is issued by Verisign > Class 3. The request list looks like: > > ocsp_multi-1 (for Entrust OCSP responder), > ocsp_multi-2 (for Verisign), > ocsp_multi-3 (for Verisign Class 3), > ocsp_multi-4 (for GeoTrust) > > We are expected to use ocsp_multi-3 for the server cert. I think your > implementation would use ocsp_multi-1 (for Entrust) as the OCSP > responder for Verisign Class 3 server cert. That's another one of my > concerns. In a case like this, I think the distinguishing factor between those ocsp_multi ItemV2s is one or more ResponderIds. Since we're not supporting server-side ResponderId selection in this first release I don't think we can distinguish between these. I don't know how much of a real-world case this is, though when we do support ResponderId selection we would definitely need to handle this properly. > > >> The current code snippet doesn't strictly prefer the last item. If the >> first item is OCSP_MULTI, then it will stop right there, but your point >> is still true that we're not going on client ordering (as explained above). >>> Line 865-867 does not consider whether the OCSPStatusRequest is suitable >>> for this server or not, either. >>> >>> In general, client knows nothing about server certificates. So client >>> would offer responders it trusted. The responders is not necessary >>> suitable for the target server. The server side should select a >>> suitable one. It is not necessary the first one or the last one. See >>> also section 2.2, RFC 6961: >>> >>> "Servers that support a client's selection of responders using the >>> ResponderID field could implement this selection by matching the >>> responder ID values from the client's list with the ResponderIDs of >>> known OCSP responders, either by using a binary compare of the values >>> or a hash calculation and compare method." >>> >>> If the update of your implementation is pretty significant or it is >>> unclean how we should move forward at present, I'm OK if you want to >>> remove the support of client specified responders. >> As implied from the above paragraph servers aren't required to support >> client ResponderId selection. I don't have support for this feature >> yet, neither from the client or the server. The OCSPStatusRequest has >> the hooks in it to populate ResponderIds because it was fairly easy to >> do. I would like to leave that code in, since providing that capability >> to the client is something I want to do in the future, as well as handle >> the server selection based on Responder Id. > See above. > >>> sun/security/ssl/StatusResponseManager.java >>> =========================================== >>> line 207-213: >>> >>> // It is assumed that the caller has ordered the certs in the chain >>> // from end-entity to trust anchor. In order to create the CertId >>> // necessary for OCSP requests the subject and issuer certs must >>> // be present. >>> - if (chain.length < 2) { >>> + if (chain.length == 0) { >>> return Collections.emptyMap(); >>> } >>> >>> This assumption is not actually correct in general. The trust anchor is >>> not necessarily be included in the Certificate message. See page 48, >>> section 7.4.2, RFC 5246. >> I believe this chain comes in from the KeyManager via >> ServerHandshaker.setupPrivateKeyAndChain(), so it should be a complete >> cert chain in the correct order (or as complete as the server can do, I >> suppose). The Certificate message is not a factor here. > It may be a complete cert chain. And a complete cert chain may not > contain the trust anchor. It depends on the key manager implementation. > Our implementation may provider the trust anchor, but others may not. Fair enough. In order to be able to craft an OCSP request for a cert you need the issuer key (otherwise you cannot make a CertId). So are you suggesting we try to build a certpath based on the last cert found in the "certs" field (set as part of setupPrivateKeyAndChain?) Assuming it is not a trust anchor, I would think some kind of certpath would be returned and we could hopefully get the issuer cert from that. > >>> ---------------------------- >>> 436 List responderIds; >>> >>> You don't actually use the client specified responders, do you? It's OK >>> to me if we don't support none-empty OCSPStatusRequest. If we do not >>> want to do that, I would suggest to remove the related implementation >>> code for that. As would simplify the job, I think. >> No, not today. > It's OK to me. > >> In the future we will. > IMHO, I don't find the necessary to support this feature in the near > future. Maybe we can do it when we have some free cycles. > >> I don't believe Apache does >> ResponderId selection either. Not sure about other implementations. I >> know Apache will handle extension forwarding, which we also do (and can >> opt not to do with a property). I don't want to remove the code >> though. Those are the hooks for the feature in the future. Same for >> the OCSPStatusRequest...it has a constructor that allows population of >> extensions and ResponderIds. I'd like to leave this in, even if we're >> not populating those fields from the client today. > I would suggest remove the source code. You can have the history in a > webrev. In an official product, we'd better not having unused code. > >>> ----------------------------- >>> 252 // Set a bunch of threads to go do the fetching >>> 253 List> resultList = >>> 254 threadMgr.invokeAll(requestList, delay, unit); >>> >>> The current implementation of OCSP response getter, looks like for every >>> cert in the chain, a fetch thread would be created to get the >>> corresponding OCSP response. In the fetch thread, if the response is >>> cached, use it; otherwise, connect to OCSP server and fetch it. >>> >>> Performance would be a very big concern. A connection may kick start >>> many threads. Fetch threads may be a bottleneck of the server. In >>> general, a server may be expected to serve 10K+ connections, but may >>> only be able to hit around 10K- threads. It's likely to face DoS >>> challenges if every ClientHello trigger 1+ fetch threads. >> If a Server has to hit that many connections simultaneously, it's >> probably already doing multi-threading to accomplish that goal, wouldn't >> you think? If it cannot hit 10K threads to begin with, it seems to me >> like some system-level tuning needs to be done. > We may be not on the same page again. I was talking a threshold > benchmark: how much clients a server can serve at the same time. No, I understood you. > > Let's see an example, suppose the cert chain contains 3 certs, each > connection takes one thread. The system is able to hit 10K thread. > Before your implementation, the system can accept 10K clients at the > same time. With the implementation, because each cert may open a > thread, the system can only accept 2.5K clients. Very bad performance > impact. > >> Second, a new thread >> isn't created for each client connection. This is a thread pool, so a >> core number of threads are created when the SRM is created, new ones are >> made as needed, and old ones are reused whenever their task is finished >> and goes into an idle state. So we not always making a new thread. >> > I understand, but the threshold are get impacted. Not much impact on > spare system, but bad performance impact on busy system. > >> Further, time to bring the response back to the caller from the cache is >> very fast, between 2-5 msec. So there would most likely be some thread >> reuse on a very busy server. That very busy server is not going to be a >> single-core/single-thread machine; it will be capable of servicing >> multiple threads at the same time, so that should help aggregate >> throughput. >> > Not enough. 10K client may request the connection at the same time, and > the management of a large butch of threads (10K) is a big load for every > system. That's why AIO programming popular today. We support AIO > programming via SSLEngine, need to consider the requirements. Hmmm...I see what you're saying. I'm going to have to think on this one a bit and see what can be done in the SRM. > >> It of course takes significantly longer to bring the response back from >> the network. I didn't get exact numbers, but in an environment where >> the responders are on the same machine as the server I could get them >> back in about 150msec. So in extremely rough terms it's network IO time >> + 150msec for each fetch. >>> Another performance concern is that when there is no cache, the client >>> would have to wait for the server to fetch the response from OCSP >>> servers. It's easy to run into client timeout issue. >> As clients do with other implementations. If the server doesn't have >> the response, it has to get it and the client has to wait for it. I see >> no problem here. > No problem here. The problem is we may want to improve the performance > if we could. > >> The connection delay isn't technically the time taken >> to retrieve all responses, it is the time taken to retrieve all >> responses or the server fetch timeout, whichever is smaller. A server >> can opt to wait 500 msec, 1000msec, or whatever the admin thinks is >> appropriate given the distance of the responders and the client load. >> If the timer is exceeded, the server will include any responses it has >> and will not include the ones it is still retrieving. If it cannot get >> any, then it doesn't even assert status_requst[_v2]. >> > 10 seconds is the OCSP service availability per Baseline Requirements of > CA/Browser Forum. If 200 msec is used, it means the OCSP stapling of > the server may be not reliable as the OCSP server may not response yet > when timeout. 200msec was just an example. It's the admin's call what they want to set for their environment. If there's a cache hit, even 200msec is plenty of time for the responses to be returned. If it's a cache miss then the fetches will be initiated and eventually those responses will be received and cached, but for that connection at least no responses will be available by the time the server has to move on with the handshaking process. If admins want to hold up a connection longer they can alter that property. I don't know that there's a fool-proof way to get around that. Even at start of day, there would be a window of time where the server is waiting for initial responses and clients could be connecting and no responses would be available. Just out of curiosity, the CA/Browser foum's recommendation of 10 seconds is between a client and OCSP responder... > >> What's more, even if the server has to get 3 responses, but only has one >> by the timeout threshold the remaining two fetches will continue in the >> background and complete, even if the connection has gone on. This way a >> future connection coming in has a greater chance of getting a cache hit. > It's a kind of unreliable for the present client. We may want to make a > improvement if possible. > > Thanks, > Xuelei > >>> I may suggest to use a single thread to get responses from OCSP servers. >>> And any TLS connection would only get responses from cache. The >>> scenarios may looks like: >>> 1. Per every SSLContext instance, create a scheduled single thread to >>> fetch the response from OCSP servers, and cache them for each server >>> certificate chains. The server certificates can be got from key manager. >>> 2. For every client request, look for the response from the cache. >>> 3. if responder is not cached and if we want to support none-empty >>> OCSPStatusRequest, fetch the response from OCSP servers in the same >>> thread, and cache the result. We may also want to add the task to the >>> scheduled thread in #1. Not create new thread for every connection is >>> important for SSLEngine in some circumstances. >>> >>> #3 is also not performance friendly. I think none-empty >>> OCSPStatusRequest is not common in practice. >> I'll have to think about your proposal a bit. It's a significant change >> from what I'm doing, but it is an interesting alternative. >> >> As stated above, we don't create new threads for each connection. >> Threads are reused when they are idle/available. >> >> You are correct, non-empty OCSPStatusRequests are rare. I've never seen >> a client do one. I've only looked at browsers, but none of them >> populate the request. >>> I will stop here for the first round code review. Looking forward for >>> the next round webrev. >>> >>> Thanks, >>> Xuelei >>> >>> >>> On 6/27/2015 11:06 PM, Jamil Nimeh wrote: >>>> Hello all, I've posted an updated webrev based on comments I've received >>>> so far: >>>> >>>> http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.1 >>>> >>>> Thanks, >>>> --Jamil >>>> >>>> On 06/18/2015 05:27 PM, Jamil Nimeh wrote: >>>>> Hello all, >>>>> >>>>> I have a first cut at the OCSP stapling webrev posted for your review: >>>>> >>>>> JEP:https://bugs.openjdk.java.net/browse/JDK-8046321 >>>>> Webrev:http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/ >>>>> >>>>> A couple items to note: >>>>> >>>>> * I'm in the process of updating the JEP with some more details. I >>>>> should be done with these changes by tonight (PDT). >>>>> * Missing are some of the TLS end-to-end tests. These tests have >>>>> been coded and run outside the jtreg framework, but for some >>>>> reason things hang in jtreg. I've included some of the supporting >>>>> classes that these tests will use (CertificateBuilder.java and >>>>> SimpleOCSPResponder.java) so folks could review those if they're >>>>> interested. I will update the webrev and notify the list as soon >>>>> as I've got the tests working in jtreg. >>>>> >>>>> Thanks to everyone who has helped along the way. >>>>> >>>>> --Jamil >>>>> >>>>> From xuelei.fan at oracle.com Fri Jul 3 00:15:10 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 03 Jul 2015 08:15:10 +0800 Subject: [Update]: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <5595740A.4020707@oracle.com> References: <558361E0.2060409@oracle.com> <558EBBF7.3010805@oracle.com> <55952917.2070502@oracle.com> <55954A0A.4050708@oracle.com> <55956A15.7030105@oracle.com> <5595740A.4020707@oracle.com> Message-ID: <5595D40E.2050204@oracle.com> On 7/3/2015 1:25 AM, Jamil Nimeh wrote: >> Let's consider one more example, the server cert is issued by Verisign >> Class 3. The request list looks like: >> >> ocsp_multi-1 (for Entrust OCSP responder), >> ocsp_multi-2 (for Verisign), >> ocsp_multi-3 (for Verisign Class 3), >> ocsp_multi-4 (for GeoTrust) >> >> We are expected to use ocsp_multi-3 for the server cert. I think your >> implementation would use ocsp_multi-1 (for Entrust) as the OCSP >> responder for Verisign Class 3 server cert. That's another one of my >> concerns. > In a case like this, I think the distinguishing factor between those > ocsp_multi ItemV2s is one or more ResponderIds. Since we're not > supporting server-side ResponderId selection in this first release I > don't think we can distinguish between these. I don't know how much of > a real-world case this is, though when we do support ResponderId > selection we would definitely need to handle this properly. In realy-world, if client want to support ResponderIds, the above case should be common. The client does not know what kind of cert the server would be used in general. Therefore, the client would include all trusted OCSP responders in the request so that the server can selected from. By "we're not supporting server-side ResponderId selection", I have two understands: 1. we don't support none-empty OCSPStatusRequest, ServerHello would not include the extension for such cases. 2. we would make an effort to match the requested ResponderID. If the ResponderID is the same as what we used to fetch the OCSP response, use it. If none of the IDs are available, ServerHello would not include the extension for such cases. We cannot send the CertificateStatus if no matching ResponderID, as would result in handshaking failure. I would prefer #2 at present. >>>> See also section 2.2, RFC 6961: >>>> >>>> "Servers that support a client's selection of responders using the >>>> ResponderID field could implement this selection by matching the >>>> responder ID values from the client's list with the >>>> ResponderIDs of >>>> known OCSP responders, either by using a binary compare of the >>>> values >>>> or a hash calculation and compare method." >>>> In case we need to handle it in the future, the section above is the proposal of RFC 6961 about how to handle ResponderId selection. Xuelei From xuelei.fan at oracle.com Mon Jul 6 01:11:34 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 06 Jul 2015 09:11:34 +0800 Subject: Code Review Request: JDK-8130460 Increase the stability of DTLS test CipherSuite.java Message-ID: <5599D5C6.6080008@oracle.com> Hi, Please review this simple fix. http://cr.openjdk.java.net/~xuelei/8130460/webrev.00/ The DTLS test, javax/net/ssl/DTLS/CipherSuite.java, failed in nightly regression intermittent. In the test, it only allows 10 times app packet loss and 60 times handshake packet loss. This value is reasonable in general, but may be not big enough if the system networking is heavy loaded. With this update, I plan to increase the packet loss limitation in order to increase the stability of the related tests. Thanks, Xuelei From openjdk at suche.org Mon Jul 6 22:13:13 2015 From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Tue, 7 Jul 2015 00:13:13 +0200 Subject: Possible DOS in KeepAliveCache Message-ID: <559AFD79.2020904@suche.org> Hi, i found after an high number of CLOSE_WAIT's in an high load production environment that there is and problem with sun.net.www.http.KeepAliveCache. There are two conditions when an sun.net.www.http.HttpClient will be closed: 1) If the connection is detected to be closed by usage. 2) If the idleTimeout is expired. We had an server that send an incorrect Header "Keep-Alive: timeout=1200000, max=1000" and close the connection much before the timeout. This can cause an problem because there seems to be no limit for timeout and the "run()" method in KeepAliveCache does not detect if the client connection is in state CLOSE_WAIT. I solved this by an "dirty" trick with " socket.sendUrgentData(0);". Sadly that there is not option to use getsockopt - SO_ERROR to check if the socket is closed. Is there any clean way to find out if an socket is in state close_wait? - Maybe check if we can read one byte (nonBlocking) because we are not expecting data on idle connection. Gru? Thomas Lu?nig p.s. My workaround public void run() { do { try { Thread.sleep(LIFETIME); } catch (final InterruptedException e) {} synchronized (this) { /* Remove all unused HttpClients. Starting from the bottom of the stack (the least-recently used first). * REMIND: It'd be nice to not remove *all* connections that aren't presently in use. * One could have been added a second ago that's still perfectly valid, and we're needlessly axing it. * But it's not clear how to do this cleanly, and doing it right may be more trouble than it's worth. */ final long currentTime = System.currentTimeMillis(); final ArrayList keysToRemove = new ArrayList<>(); for (final KeepAliveKey key : keySet()) { final ClientVector v = get(key); synchronized (v) { for (int i = 0; i < v.size(); i++) { final KeepAliveEntry e = v.elementAt(i); if ((currentTime - e.idleStartTime) > v.nap) { e.hc.closeServer(); } else { if(i>0) v.subList(0, i).clear(); break; } } if(serverSocket != null) { final ArrayList clientsToRemove = new ArrayList<>(); for (final KeepAliveEntry e : v) { try { @SuppressWarnings("resource") final Socket socket = (Socket)serverSocket.get(e.hc); try { socket.sendUrgentData(0); } catch(final Throwable t) { e.hc.closeServer(); clientsToRemove.add(e); System.out.println("ClosedHttp: "+socket.getLocalPort()+">"+socket.getRemoteSocketAddress()+" Timeout:"+v.nap+"/" + (currentTime-e.idleStartTime)+" => "+t.getMessage()); } } catch(final Throwable t) { t.printStackTrace(System.out); } } for(final KeepAliveEntry e : clientsToRemove) { v.remove(e); } } // FOR if (v.size() == 0) { keysToRemove.add(key); } } } for(final KeepAliveKey key : keysToRemove) { removeVector(key); } } } while (size() > 0); return; } From iris.clark at oracle.com Tue Jul 7 17:48:42 2015 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 7 Jul 2015 10:48:42 -0700 (PDT) Subject: RFR: (s) 8130696: Security Providers need to have their version numbers updated for JDK 9 Message-ID: Hi. Please review changes to resolve the following bug: 8130696: Security Providers need to have their version numbers updated for JDK 9 (Verona) Bug: https://bugs.openjdk.java.net/browse/JDK-8130696 Changeset: http://cr.openjdk.java.net/~iris/verona/8130696/webrev The constructor invocation for every Provider implementation contains a hard-coded value for the version, "1.9d", which it compares to java.specification.version. Verona [0,1] changes the system property from "1.9" to "9". The provider's version should be changed to "9.0d". Many regression tests in the jdk repository fail due to this bug. Test groups with failing tests detecting this problem include jdk_security, jdk_management, jdk_jmx, and jdk_net. These tests now pass. I have verified that all providers modified by 8030823 [2] have been updated. After review, the changeset will be pushed to verona/stage [3]. The changeset will go to jdk9/dev when Verona is complete later this summer. Thanks, Iris [0] http://openjdk.java.net/projects/verona [1] http://openjdk.java.net/jeps/223 [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f1066af06fa0 [3] http://hg.openjdk.java.net/verona/stage -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue Jul 7 23:57:43 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 08 Jul 2015 07:57:43 +0800 Subject: New status code in SSLEngineResult.HandshakeStatus In-Reply-To: <55941940.30100@redhat.com> References: <55941940.30100@redhat.com> Message-ID: <559C6777.80902@oracle.com> Hi David, Thanks for the suggestion. Here is the JBS bug for the track of the improvement: https://bugs.openjdk.java.net/browse/JDK-8130461 Thanks, Xuelei On 7/2/2015 12:45 AM, David M. Lloyd wrote: > It has caused some consternation among certain of our engineers that > there is a new possible status code in SSLEngineResult.HandshakeStatus. > If a new status were generally added, it would cause subtle or not so > subtle breakage amount current SSLEngine consumers. > > I request that it be made more clear in the documentation that the new > status code applies only to DTLS; something like this: > > diff --git > a/src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java > b/src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java > index e2865e6..5473188 100644 > --- a/src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java > +++ b/src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java > @@ -156,6 +156,9 @@ public class SSLEngineResult { > * This value is used to indicate that not-yet-interpreted data > * has been previously received from the remote side, and does > * not need to be received again. > + *

> + * This result code is only used by DTLS and is not a possible > + * result for stream-oriented TLS. > * > * @since 1.9 > */ > > Thanks. > From weijun.wang at oracle.com Wed Jul 8 02:25:31 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 08 Jul 2015 10:25:31 +0800 Subject: RFR 8130720: BadKDC1 failed again Message-ID: <559C8A1B.9090006@oracle.com> Hi All Please review the fix at http://cr.openjdk.java.net/~weijun/8130720/webrev.00/ As the bug description [1] says, at this stage, when k1 and k2 are on, although the most likely output is 1212 (try #1 without preauth, succeeds; try #1 with preauth, succeed), the actual output we spotted in a test run 122212 (try #1 without preauth, timeout; try #2 without preauth, succeed; try #1 with preauth, succeed) is still possible. It will be a mess to list all possible outputs because of possible timeout at each request and its different consequences. In the case, the list is "(12(12){1,2}|122232-)". The main reason I want to add a new output is that compare to 122232- (timeout at #1, timeout at #2, timeout at #3, fail at last), 122212 is much more likely to happen. Thanks Max [1] https://bugs.openjdk.java.net/browse/JDK-8130720 From xuelei.fan at oracle.com Wed Jul 8 02:34:23 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 08 Jul 2015 10:34:23 +0800 Subject: RFR 8130720: BadKDC1 failed again In-Reply-To: <559C8A1B.9090006@oracle.com> References: <559C8A1B.9090006@oracle.com> Message-ID: <559C8C2F.9090008@oracle.com> Looks fine to me. Xuelei On 7/8/2015 10:25 AM, Weijun Wang wrote: > Hi All > > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8130720/webrev.00/ > > As the bug description [1] says, at this stage, when k1 and k2 are on, > although the most likely output is 1212 (try #1 without preauth, > succeeds; try #1 with preauth, succeed), the actual output we spotted in > a test run 122212 (try #1 without preauth, timeout; try #2 without > preauth, succeed; try #1 with preauth, succeed) is still possible. > > It will be a mess to list all possible outputs because of possible > timeout at each request and its different consequences. In the case, the > list is "(12(12){1,2}|122232-)". The main reason I want to add a new > output is that compare to 122232- (timeout at #1, timeout at #2, timeout > at #3, fail at last), 122212 is much more likely to happen. > > Thanks > Max > > [1] https://bugs.openjdk.java.net/browse/JDK-8130720 From ivan.gerasimov at oracle.com Wed Jul 8 15:35:46 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 08 Jul 2015 18:35:46 +0300 Subject: RFR 8130022: Use Java-style array declarations consistently Message-ID: <559D4352.8080504@oracle.com> Hello! We've got a request to fix javadoc for SecureRandom, so that the example code will read byte[] bytes = new byte[20]; instead of byte bytes[] = new byte[20]; I took opportunity to make all array declarations throughout security-lib source code more of Java-style. Would you please help review this cleanup? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8130022 WEBREV: http://cr.openjdk.java.net/~igerasim/8130022/00/webrev/ Sincerely yours, Ivan From sean.coffey at oracle.com Wed Jul 8 15:57:31 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Wed, 08 Jul 2015 16:57:31 +0100 Subject: RFR 8130022: Use Java-style array declarations consistently In-Reply-To: <559D4352.8080504@oracle.com> References: <559D4352.8080504@oracle.com> Message-ID: <559D486B.3040207@oracle.com> Looks good to me.. and is much easier to read now! Regards, Sean. On 08/07/2015 16:35, Ivan Gerasimov wrote: > Hello! > > We've got a request to fix javadoc for SecureRandom, so that the > example code will read > byte[] bytes = new byte[20]; > instead of > byte bytes[] = new byte[20]; > > I took opportunity to make all array declarations throughout > security-lib source code more of Java-style. > > Would you please help review this cleanup? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8130022 > WEBREV: http://cr.openjdk.java.net/~igerasim/8130022/00/webrev/ > > Sincerely yours, > Ivan From ivan.gerasimov at oracle.com Wed Jul 8 17:14:46 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 08 Jul 2015 20:14:46 +0300 Subject: RFR 8130022: Use Java-style array declarations consistently In-Reply-To: <559D486B.3040207@oracle.com> References: <559D4352.8080504@oracle.com> <559D486B.3040207@oracle.com> Message-ID: <559D5A86.4080606@oracle.com> On 08.07.2015 18:57, Se?n Coffey wrote: > Looks good to me.. and is much easier to read now! > Thanks Se?n for review! I've missed some portion of update int the previous webrev. Now, sending the whole changeset: http://cr.openjdk.java.net/~igerasim/8130022/01/webrev/ Would you please take another look at your convenience? I'll fire a jprt job before pushing to make sure nothing is broken. Sincerely yours, Ivan > Regards, > Sean. > > On 08/07/2015 16:35, Ivan Gerasimov wrote: >> Hello! >> >> We've got a request to fix javadoc for SecureRandom, so that the >> example code will read >> byte[] bytes = new byte[20]; >> instead of >> byte bytes[] = new byte[20]; >> >> I took opportunity to make all array declarations throughout >> security-lib source code more of Java-style. >> >> Would you please help review this cleanup? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8130022 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8130022/00/webrev/ >> >> Sincerely yours, >> Ivan > > > From ivan.gerasimov at oracle.com Wed Jul 8 17:14:58 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 08 Jul 2015 20:14:58 +0300 Subject: RFR 8130022: Use Java-style array declarations consistently In-Reply-To: <559D486B.3040207@oracle.com> References: <559D4352.8080504@oracle.com> <559D486B.3040207@oracle.com> Message-ID: <559D5A92.6050700@oracle.com> On 08.07.2015 18:57, Se?n Coffey wrote: > Looks good to me.. and is much easier to read now! > Thanks Se?n for review! I've missed some portion of update int the previous webrev. Now, sending the whole changeset: http://cr.openjdk.java.net/~igerasim/8130022/01/webrev/ Would you please take another look at your convenience? I'll fire a jprt job before pushing to make sure nothing is broken. Sincerely yours, Ivan > Regards, > Sean. > > On 08/07/2015 16:35, Ivan Gerasimov wrote: >> Hello! >> >> We've got a request to fix javadoc for SecureRandom, so that the >> example code will read >> byte[] bytes = new byte[20]; >> instead of >> byte bytes[] = new byte[20]; >> >> I took opportunity to make all array declarations throughout >> security-lib source code more of Java-style. >> >> Would you please help review this cleanup? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8130022 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8130022/00/webrev/ >> >> Sincerely yours, >> Ivan > > > From sean.coffey at oracle.com Wed Jul 8 18:03:42 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Wed, 08 Jul 2015 19:03:42 +0100 Subject: RFR 8130022: Use Java-style array declarations consistently In-Reply-To: <559D5A86.4080606@oracle.com> References: <559D4352.8080504@oracle.com> <559D486B.3040207@oracle.com> <559D5A86.4080606@oracle.com> Message-ID: <559D65FE.6000503@oracle.com> On 08/07/2015 18:14, Ivan Gerasimov wrote: > > > On 08.07.2015 18:57, Se?n Coffey wrote: >> Looks good to me.. and is much easier to read now! >> > Thanks Se?n for review! > > I've missed some portion of update int the previous webrev. > Now, sending the whole changeset: > http://cr.openjdk.java.net/~igerasim/8130022/01/webrev/ > > Would you please take another look at your convenience? Still looks good. regards, Sean. > I'll fire a jprt job before pushing to make sure nothing is broken. > > Sincerely yours, > Ivan > >> Regards, >> Sean. >> >> On 08/07/2015 16:35, Ivan Gerasimov wrote: >>> Hello! >>> >>> We've got a request to fix javadoc for SecureRandom, so that the >>> example code will read >>> byte[] bytes = new byte[20]; >>> instead of >>> byte bytes[] = new byte[20]; >>> >>> I took opportunity to make all array declarations throughout >>> security-lib source code more of Java-style. >>> >>> Would you please help review this cleanup? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8130022 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8130022/00/webrev/ >>> >>> Sincerely yours, >>> Ivan >> >> >> > From xuelei.fan at oracle.com Wed Jul 8 23:24:44 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 09 Jul 2015 07:24:44 +0800 Subject: Code Review Request: JDK-8130460 Increase the stability of DTLS test CipherSuite.java In-Reply-To: <5599D5C6.6080008@oracle.com> References: <5599D5C6.6080008@oracle.com> Message-ID: <559DB13C.8010804@oracle.com> ping ... Xuelei On 7/6/2015 9:11 AM, Xuelei Fan wrote: > Hi, > > Please review this simple fix. > > http://cr.openjdk.java.net/~xuelei/8130460/webrev.00/ > > The DTLS test, javax/net/ssl/DTLS/CipherSuite.java, failed in nightly > regression intermittent. In the test, it only allows 10 times app > packet loss and 60 times handshake packet loss. This value is > reasonable in general, but may be not big enough if the system > networking is heavy loaded. With this update, I plan to increase the > packet loss limitation in order to increase the stability of the related > tests. > > Thanks, > Xuelei > From bradford.wetmore at oracle.com Wed Jul 8 23:42:59 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 8 Jul 2015 16:42:59 -0700 Subject: TLS ALPN Proposal v3 In-Reply-To: <5571C016.7080909@oracle.com> References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> <556E9D5C.5040106@oracle.com> <55707475.8060401@oracle.com> <557081BB.5080508@oracle.com> <5571217A.1070501@oracle.com> <557197C9.5010407@oracle.com> <5571B645.7050305@oracle.com> <5571C016.7080909@oracle.com> Message-ID: <559DB583.8060609@oracle.com> Greetings, Xuelei wrote: > I think Brad would consider our information for his design. I did, and thanks for the all of the detailed discussion, Simone/Michael/Xuelei. I've taken into account the feedback from the previous discussion back in June. Here is v3 of the public ALPN API. http://cr.openjdk.java.net/~wetmore/8051498/webrev.04/ Main points: 1. SSLBase/SSLFunction gone 2. New ApplicationProtocolSelector class with two select methods: select(SSLSocket), select(SSLEngine) throws SSLHandshakeException instead of SSLProtocolException (oops/sorry!) 3. "@since 1.9" changes to "@since 9" (changes for JDK 9) 4. SSLSession.getCipherSuite() a getHandshakeSession.getCipherSuite() no longer dynamic value ALPN Selector will be called after suite has been set. 5. Psuedo code in the SunJSSEimplementation for ALPN selection. 6. Working HTTP 2 & 1.1 client/server configuration example (test). Various responses, I'll try to attribute the original author correctly. :) If I missed a point you feel is important, please restate. Simone wrote: >> ExtendedSSLSession >> public List getReceivedApplicationProtocols() { > > This is a constant once the application protocols are received, so it > can be surely retrieved from SSLParameters. > I don't understand why it is replicated here ? SSLParameters is a configuration class which is used to configure SSLSockets/SSLEngines. SSLSession/ExtendedSSLSession is a class which holds negotiated Session values. getReceivedApplicationProtocols() represents the Application Protocol values received from the peer, thus belongs in the SSLSession. One other point that is not always obvious to folks is that a single SSLParameters object can be used to initialize multiple SSLEngine/SSLSocket objects. You can configure sockets as part of a customer SSLSocketFactory, or by using SSLParameters. Regarding the old SSLFunction/SSLBase: > I'm not sure about this one being a marker interface. > I could understand if it extracted the common functionality of > SSLEngine and SSLSocket, but a marker interface does not really add > much, and perhaps I would prefer it entirely gone. Previously it was suggested that the ALPN selector could be a @FunctionalInterface (Simone?) and generic (Sean?), so I was trying to accommodate that. Both are gone now. We could still introduce a SSLBase with these methods: ---begin--- public abstract String[] getEnabledCipherSuites() public abstract void setEnabledCipherSuites(String[] suites) public abstract String[] getEnabledProtocols() public abstract void setEnabledProtocols(String[] protocols) public abstract boolean getEnableSessionCreation() public abstract void setEnableSessionCreation(boolean flag) public SSLSession getHandshakeSession() minor tweak for SSLSocket about getSession() public abstract void setNeedClientAuth(boolean need) public abstract boolean getNeedClientAuth() public abstract SSLSession getSession() minor tweak needed in SSLSocket public abstract String[] getSupportedCipherSuites() public abstract String[] getSupportedProtocols() public abstract boolean getUseClientMode() public abstract void setUseClientMode(boolean mode) public abstract boolean getWantClientAuth() public abstract void setWantClientAuth(boolean want) public SSLParameters getSSLParameters() public void setSSLParameters(SSLParameters params) ---end--- which would eliminate the SSLEngine/SSLSocket-specific methods in ApplicationProtocolSelector.java, but I'm not sure it's worth the effort to isolate all these methods just to lose one method in the ALPN selector. To do this as a @FunctionInterface, I wanted to use java.util.function.Function, but needed it to return a checked Exception. Anyway, it's gone for now. > On the same note, why is SSLFunction generic at all ? This was an internal idea that in the future there might be additional SSL functions we could do as lambdas. Xuelei/Simone wrote: >> Per my understanding, application protocol should be negotiated before >> cipher suite and protocol version negotiated. > > This is not possible for HTTP/2. > Application protocol negotiation MUST happen *after* the TLS protocol > and the TLS cipher are negotiated. Yes, that's my understanding as well. Simone wrote: > Currently, IIUC, the cipher selection is an iterative process where a > cipher is attempted until one is negotiated. Yes. Simone wrote: > Yesterday a browser could open a page and browse the site over > http/1.1. From my readings of the RFC, I agree with Simone and think the intent of the RFC writers was that if a sufficient connection state does not exist for HTTP/2, then it should be possible to fallback to something else instead of killing the connection. If the implementation wants to insist on HTTP/2 only, the ALPN selector can certainly enforce that, but it needs to try the H2 ciphersuites first. With this API, we can do either style. Simone wrote: > If the server chooses a blacklisted cipher, and then "h2" as protocol, > it's a non compliant server. IIUC, the HTTP/2 blacklist is just strongly recommended ("...SHOULD NOT use any of the cipher suites...black list"), but not required. Such potential peers must also support such a configuration, but in general, it will not. See section 9.2.2. I think it's still considered compliant to the spec tho. Simone wrote two different ways to do selection: > 1) ... so that TLS protocol, cipher (possibly the alias too) and > application protocol are chosen together, or > 2) we separate the TLS protocol and > cipher negotiation (and alias) in one step, and we perform application > protocol selection afterwards. Rather than completely redo the JSSE selection mechanism with the (version/ciphersuite/ALPN)-tuple idea (which would be a much more involved API and behavior change), I think the more straightforward solution (2) is better. Simon wrote: > Alternatively, the ciphers on the server are sorted so that those > valid for h2 have higher priority (they are attempted before all the > others), so that there is a high chance that a h2 valid cipher is > chosen (but no guarantee) before choosing the application protocol. This is the best approach to date. Applications can simply order the enabled ciphersuites based on the server's ALPN preference. For example, say three ALPN values are known/supported by a server: "h2" > "spdy/3" > "http/1.1". If the ALPN-enabled app provides the ordered list of ciphersuites {h2[] spdy/3[], http/1.1[]}, then calls sslParameters.setUseCipherSuitesOrder(true), during handshaking, the server will intersect the received client ciphersuites with the server's enabled ciphersuites, which will then be tried for h2 first, then spdy/3, then http/1.1. Once the server has selected the protocol version and ciphersuite, the ALPN selector is called to select an appropriate ALPN value. For a concrete example, please see my test case in the webrev, and below. Micheal wrote: > If (internally) the server > chooses that cipher first, > without knowing the application protocol is going to be HTTP/2 > then you end up with a non-compliant connection that will probably > have to be closed for reason of insufficient security. That assumes the peer won't accept a down-version, see above. I also had another API approach that I played with where the ALPN selector was also tasked with the job of "pre-approving" ciphersuites before they were tried. That is, if a ciphersuite would never work for a preferred ALPN value, we would remove it from consideration. However, things got really complicated because if we got to the end of the ciphersuite list because we were insisting on finding an h2-compatible suites, we couldn't jump back and try the http/1.1 suites as a fallback. The server-ordered ciphersuite approach took care of that problem. > Also, it is critical to detail how the mechanism work. > > Example implementations for SSLFunction would be great to have: the > typical HTTP/2 case is to select the application protocol based on the > TLS protocol and the already negotiated cipher. I have a "working" test example which shows how the ALPN APIs can be used for HTTP/2 clients and servers. It is a minor configuration tweak to the jdk/test/javax/net/ssl/templates/SSLEngineTemplate.java test that we use as the basis for JSSE SSLEngine testing. http://cr.openjdk.java.net/~wetmore/8051498/webrev.04/test/javax/net/ssl/ALPN/SSLEngineAlpnHttp2.java.html See the configuration in createSSLEngines() around line 265 and 280. http://cr.openjdk.java.net/~wetmore/8051498/webrev.04/test/javax/net/ssl/ALPN/Http2ApplicationSelector.java.html Note the HTTP/2 blacklist and reordering code. The code is not actually "working" yet (haven't merged API/impl repos yet), but shows how to configure/use this API. Michael wrote: > Okay. I've been looking at it from the client point of view, and > as far as I understand it, all of the information is available to the > client at the right time. For ALPN, for clients the protocol version/ciphersuite/ALPN do come back in the ServerHello in one chunk. As you've realized by now, the discussion is about the server side selection. Brad BTW, in our current default configuration, for HTTP/2 only these ciphersuites are available (not blacklisted). TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 From bradford.wetmore at oracle.com Wed Jul 8 23:44:05 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 8 Jul 2015 16:44:05 -0700 Subject: Code Review Request: JDK-8130460 Increase the stability of DTLS test CipherSuite.java In-Reply-To: <559DB13C.8010804@oracle.com> References: <5599D5C6.6080008@oracle.com> <559DB13C.8010804@oracle.com> Message-ID: <559DB5C5.1000605@oracle.com> Looks good. Brad On 7/8/2015 4:24 PM, Xuelei Fan wrote: > ping ... > > Xuelei > > On 7/6/2015 9:11 AM, Xuelei Fan wrote: >> Hi, >> >> Please review this simple fix. >> >> http://cr.openjdk.java.net/~xuelei/8130460/webrev.00/ >> >> The DTLS test, javax/net/ssl/DTLS/CipherSuite.java, failed in nightly >> regression intermittent. In the test, it only allows 10 times app >> packet loss and 60 times handshake packet loss. This value is >> reasonable in general, but may be not big enough if the system >> networking is heavy loaded. With this update, I plan to increase the >> packet loss limitation in order to increase the stability of the related >> tests. >> >> Thanks, >> Xuelei >> > From artem.smotrakov at oracle.com Thu Jul 9 00:30:20 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 08 Jul 2015 17:30:20 -0700 Subject: [9] RFR: 8049814: Additional SASL client-server tests Message-ID: <559DC09C.5020304@oracle.com> Hello, Please review a client/server test for SASL which uses different mechanisms and QOPs. Bug: https://bugs.openjdk.java.net/browse/JDK-8049814 Webrev: http://cr.openjdk.java.net/~asmotrak/8049814/webrev.00/ Artem From xuelei.fan at oracle.com Thu Jul 9 00:44:40 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 09 Jul 2015 08:44:40 +0800 Subject: TLS ALPN Proposal v3 In-Reply-To: <559DB583.8060609@oracle.com> References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> <556E9D5C.5040106@oracle.com> <55707475.8060401@oracle.com> <557081BB.5080508@oracle.com> <5571217A.1070501@oracle.com> <557197C9.5010407@oracle.com> <5571B645.7050305@oracle.com> <5571C016.7080909@oracle.com> <559DB583.8060609@oracle.com> Message-ID: <559DC3F8.7090207@oracle.com> On 7/9/2015 7:42 AM, Bradford Wetmore wrote: > Xuelei/Simone wrote: >>> Per my understanding, application protocol should be negotiated before >>> cipher suite and protocol version negotiated. >> >> This is not possible for HTTP/2. >> Application protocol negotiation MUST happen *after* the TLS protocol >> and the TLS cipher are negotiated. > > Yes, that's my understanding as well. What are the behaviors of other vendors? Can we ask for a clarification from both HTTP/2 and TLS WG? Thanks, Xuelei From valerie.peng at oracle.com Thu Jul 9 02:23:56 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 08 Jul 2015 19:23:56 -0700 Subject: RFR: (s) 8130696: Security Providers need to have their version numbers updated for JDK 9 In-Reply-To: References: Message-ID: <559DDB3C.9090204@oracle.com> Is the Verona repo sync'ed to the latest OpenJDK? The webrev seems to be missing the provider JdkSASL inside the following file src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/JdkSASL.java The rest looks good. Valerie On 7/7/2015 10:48 AM, Iris Clark wrote: > > Hi. > > Please review changes to resolve the following bug: > > 8130696: Security Providers need to have their version numbers updated > for JDK 9 (Verona) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8130696 > > Changeset: http://cr.openjdk.java.net/~iris/verona/8130696/webrev > > The constructor invocation for every Provider implementation contains > a hard-coded value for the version, "1.9d", which it compares to > java.specification.version. Verona [0,1] changes the system property > from "1.9" to "9". The provider's version should be changed to "9.0d". > > Many regression tests in the jdk repository fail due to this bug. > Test groups with failing tests detecting this problem include > jdk_security, jdk_management, jdk_jmx, and jdk_net. These tests now > pass. I have verified that all providers modified by 8030823 [2] have > been updated. > > After review, the changeset will be pushed to verona/stage [3]. The > changeset will go to jdk9/dev when Verona is complete later this summer. > > Thanks, > > Iris > > [0] http://openjdk.java.net/projects/verona > > [1] http://openjdk.java.net/jeps/223 > > [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f1066af06fa0 > > [3] http://hg.openjdk.java.net/verona/stage > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Jul 9 03:57:27 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 09 Jul 2015 11:57:27 +0800 Subject: RFR: (s) 8130696: Security Providers need to have their version numbers updated for JDK 9 In-Reply-To: References: Message-ID: <559DF127.8080709@oracle.com> Hi Iris The change to S11N.java looks fine. Thanks Max On 07/08/2015 01:48 AM, Iris Clark wrote: > Hi. > > Please review changes to resolve the following bug: > > 8130696: Security Providers need to have their version numbers updated > for JDK 9 (Verona) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8130696 > > Changeset: http://cr.openjdk.java.net/~iris/verona/8130696/webrev > > The constructor invocation for every Provider implementation contains a > hard-coded value for the version, "1.9d", which it compares to > java.specification.version. Verona [0,1] changes the system property > from "1.9" to "9". The provider?s version should be changed to ?9.0d?. > > Many regression tests in the jdk repository fail due to this bug. Test > groups with failing tests detecting this problem include jdk_security, > jdk_management, jdk_jmx, and jdk_net. These tests now pass. I have > verified that all providers modified by 8030823 [2] have been updated. > > After review, the changeset will be pushed to verona/stage [3]. The > changeset will go to jdk9/dev when Verona is complete later this summer. > > Thanks, > > Iris > > [0] http://openjdk.java.net/projects/verona > > [1] http://openjdk.java.net/jeps/223 > > [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f1066af06fa0 > > [3] http://hg.openjdk.java.net/verona/stage > From vincent.x.ryan at oracle.com Thu Jul 9 13:30:52 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 9 Jul 2015 14:30:52 +0100 Subject: [9] code review request for 8130850: Support loading a keystore with a custom KeyStore.LoadStoreParameter class Message-ID: Please review this change to the implementation of the KeyStoreSpi.engineLoad method to accept custom KeyStore.LoadStoreParameter classes. Thanks. Bug: https://bugs.openjdk.java.net/browse/JDK-8130850 Webrev: http://cr.openjdk.java.net/~vinnie/8130850/webrev.00/ From simone.bordet at gmail.com Thu Jul 9 15:29:45 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Thu, 9 Jul 2015 17:29:45 +0200 Subject: TLS ALPN Proposal v3 In-Reply-To: <559DB583.8060609@oracle.com> References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> <556E9D5C.5040106@oracle.com> <55707475.8060401@oracle.com> <557081BB.5080508@oracle.com> <5571217A.1070501@oracle.com> <557197C9.5010407@oracle.com> <5571B645.7050305@oracle.com> <5571C016.7080909@oracle.com> <559DB583.8060609@oracle.com> Message-ID: Hi, On Thu, Jul 9, 2015 at 1:42 AM, Bradford Wetmore wrote: > SSLParameters is a configuration class which is used to configure > SSLSockets/SSLEngines. SSLSession/ExtendedSSLSession is a class which holds > negotiated Session values. getReceivedApplicationProtocols() represents the > Application Protocol values received from the peer, thus belongs in the > SSLSession. I suggest to rename ExtendedSSLSession.getRequestedApplicationProtocols() to ExtendedSSLSession.getPeerApplicationProtocols() The protocols are not really "requested", they are more "offered", but IIUC the reason to add "Requested" to this method is to distinguish it from SSLParameters.getApplicationProtocols() which returns the local protocols, and in that spirit I think "Peer" is better for ExtendedSSLSession. > Xuelei/Simone wrote: >>> Per my understanding, application protocol should be negotiated before >>> cipher suite and protocol version negotiated. >> >> This is not possible for HTTP/2. >> Application protocol negotiation MUST happen *after* the TLS protocol >> and the TLS cipher are negotiated. > > Yes, that's my understanding as well. Well, to be precise, either the application protocol is negotiated after the cipher (and you need cipher sorting to influence the cipher selection towards the application protocol you would like to choose), or it must happen at the same time - that is, cipher and application protocol must be chosen at the same time - but this implies that the action of choosing that tuple may be invoked multiple times with the current OpenJDK implementation. Note that I don't know if the fact that cipher selection is an iterative process is an OpenJDK implementation detail. If other implementations are not iterative, then perhaps they have a single moment where the tuple is chosen. I support Xuelei in that you should ask confirmation to the HTTP/2 editor. Also, remember that Firefox, Chrome, OpenSSL, nghttp2, etc. are all open source and their code is available to verify the behavior. > IIUC, the HTTP/2 blacklist is just strongly recommended ("...SHOULD NOT use > any of the cipher suites...black list"), but not required. Such potential > peers must also support such a configuration, but in general, it will not. > See section 9.2.2. I think it's still considered compliant to the spec tho. >From experience, if a server breaks this SHOULD NOT, it won't work with any browser. We had our share of pain trying to figure out interoperability with browsers for Jetty :) Sure, it's a SHOULD NOT, but it's like a MUST NOT if you want a browser to talk to a Java server (or a Java client to talk to a current HTTP/2 server). > Simone wrote two different ways to do selection: > >> 1) ... so that TLS protocol, cipher (possibly the alias too) and >> application protocol are chosen together, or >> 2) we separate the TLS protocol and >> cipher negotiation (and alias) in one step, and we perform application >> protocol selection afterwards. > > Rather than completely redo the JSSE selection mechanism with the > (version/ciphersuite/ALPN)-tuple idea (which would be a much more involved > API and behavior change), I think the more straightforward solution (2) is > better. That's what we do in Jetty's ALPN implementation too. Be aware that it rules out some possibility such as those mentioned by Michael from RFC 7301. >> Also, it is critical to detail how the mechanism work. >> >> Example implementations for SSLFunction would be great to have: the >> typical HTTP/2 case is to select the application protocol based on the >> TLS protocol and the already negotiated cipher. > > I have a "working" test example which shows how the ALPN APIs can be used > for HTTP/2 clients and servers. It is a minor configuration tweak to the > jdk/test/javax/net/ssl/templates/SSLEngineTemplate.java test that we use as > the basis for JSSE SSLEngine testing. Do you have a Java 9 server that can negotiate h2 with current browsers ? > http://cr.openjdk.java.net/~wetmore/8051498/webrev.04/test/javax/net/ssl/ALPN/SSLEngineAlpnHttp2.java.html > > See the configuration in createSSLEngines() around line 265 and 280. > > > http://cr.openjdk.java.net/~wetmore/8051498/webrev.04/test/javax/net/ssl/ALPN/Http2ApplicationSelector.java.html > > Note the HTTP/2 blacklist and reordering code. > > The code is not actually "working" yet (haven't merged API/impl repos yet), > but shows how to configure/use this API. Just a reminder that the cipher blacklist is only valid for TLS 1.2. For example, if the negotiated TLS protocol is 1.3, there is no need to look at the ciphers (nor to sort them). Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From sean.mullan at oracle.com Thu Jul 9 16:23:08 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 09 Jul 2015 12:23:08 -0400 Subject: RFR: (s) 8130696: Security Providers need to have their version numbers updated for JDK 9 In-Reply-To: <559DF127.8080709@oracle.com> References: <559DF127.8080709@oracle.com> Message-ID: <559E9FEC.3090002@oracle.com> The Version variable on line 73 of S11N.java should be all lowercase: int version = Integer.valueOf(v); otherwise it should not compile. --Sean On 07/08/2015 11:57 PM, Weijun Wang wrote: > Hi Iris > > The change to S11N.java looks fine. > > Thanks > Max > > On 07/08/2015 01:48 AM, Iris Clark wrote: >> Hi. >> >> Please review changes to resolve the following bug: >> >> 8130696: Security Providers need to have their version numbers updated >> for JDK 9 (Verona) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8130696 >> >> Changeset: http://cr.openjdk.java.net/~iris/verona/8130696/webrev >> >> The constructor invocation for every Provider implementation contains a >> hard-coded value for the version, "1.9d", which it compares to >> java.specification.version. Verona [0,1] changes the system property >> from "1.9" to "9". The provider?s version should be changed to ?9.0d?. >> >> Many regression tests in the jdk repository fail due to this bug. Test >> groups with failing tests detecting this problem include jdk_security, >> jdk_management, jdk_jmx, and jdk_net. These tests now pass. I have >> verified that all providers modified by 8030823 [2] have been updated. >> >> After review, the changeset will be pushed to verona/stage [3]. The >> changeset will go to jdk9/dev when Verona is complete later this summer. >> >> Thanks, >> >> Iris >> >> [0] http://openjdk.java.net/projects/verona >> >> [1] http://openjdk.java.net/jeps/223 >> >> [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f1066af06fa0 >> >> [3] http://hg.openjdk.java.net/verona/stage >> From bradford.wetmore at oracle.com Thu Jul 9 17:02:29 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 09 Jul 2015 10:02:29 -0700 Subject: TLS ALPN Proposal v3 In-Reply-To: References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> <556E9D5C.5040106@oracle.com> <55707475.8060401@oracle.com> <557081BB.5080508@oracle.com> <5571217A.1070501@oracle.com> <557197C9.5010407@oracle.com> <5571B645.7050305@oracle.com> <5571C016.7080909@oracle.com> <559DB583.8060609@oracle.com> Message-ID: <559EA925.5010701@oracle.com> Ok, I'll check with the HTTP/2 group tomorrow. It appears the proper list is: ietf-http-wg at w3.org Is that correct? Brad On 7/9/2015 8:29 AM, Simone Bordet wrote: > Hi, > > On Thu, Jul 9, 2015 at 1:42 AM, Bradford Wetmore > wrote: >> SSLParameters is a configuration class which is used to configure >> SSLSockets/SSLEngines. SSLSession/ExtendedSSLSession is a class which holds >> negotiated Session values. getReceivedApplicationProtocols() represents the >> Application Protocol values received from the peer, thus belongs in the >> SSLSession. > > I suggest to rename > > ExtendedSSLSession.getRequestedApplicationProtocols() > > to > > ExtendedSSLSession.getPeerApplicationProtocols() > > The protocols are not really "requested", they are more "offered", but > IIUC the reason to add "Requested" to this method is to distinguish it > from SSLParameters.getApplicationProtocols() which returns the local > protocols, and in that spirit I think "Peer" is better for > ExtendedSSLSession. > >> Xuelei/Simone wrote: >>>> Per my understanding, application protocol should be negotiated before >>>> cipher suite and protocol version negotiated. >>> >>> This is not possible for HTTP/2. >>> Application protocol negotiation MUST happen *after* the TLS protocol >>> and the TLS cipher are negotiated. >> >> Yes, that's my understanding as well. > > Well, to be precise, either the application protocol is negotiated > after the cipher (and you need cipher sorting to influence the cipher > selection towards the application protocol you would like to choose), > or it must happen at the same time - that is, cipher and application > protocol must be chosen at the same time - but this implies that the > action of choosing that tuple may be invoked multiple times with the > current OpenJDK implementation. > > Note that I don't know if the fact that cipher selection is an > iterative process is an OpenJDK implementation detail. > If other implementations are not iterative, then perhaps they have a > single moment where the tuple is chosen. > > I support Xuelei in that you should ask confirmation to the HTTP/2 editor. > Also, remember that Firefox, Chrome, OpenSSL, nghttp2, etc. are all > open source and their code is available to verify the behavior. > >> IIUC, the HTTP/2 blacklist is just strongly recommended ("...SHOULD NOT use >> any of the cipher suites...black list"), but not required. Such potential >> peers must also support such a configuration, but in general, it will not. >> See section 9.2.2. I think it's still considered compliant to the spec tho. > > From experience, if a server breaks this SHOULD NOT, it won't work > with any browser. > We had our share of pain trying to figure out interoperability with > browsers for Jetty :) > Sure, it's a SHOULD NOT, but it's like a MUST NOT if you want a > browser to talk to a Java server (or a Java client to talk to a > current HTTP/2 server). > >> Simone wrote two different ways to do selection: >> >>> 1) ... so that TLS protocol, cipher (possibly the alias too) and >>> application protocol are chosen together, or >>> 2) we separate the TLS protocol and >>> cipher negotiation (and alias) in one step, and we perform application >>> protocol selection afterwards. >> >> Rather than completely redo the JSSE selection mechanism with the >> (version/ciphersuite/ALPN)-tuple idea (which would be a much more involved >> API and behavior change), I think the more straightforward solution (2) is >> better. > > That's what we do in Jetty's ALPN implementation too. > Be aware that it rules out some possibility such as those mentioned by > Michael from RFC 7301. > >>> Also, it is critical to detail how the mechanism work. >>> >>> Example implementations for SSLFunction would be great to have: the >>> typical HTTP/2 case is to select the application protocol based on the >>> TLS protocol and the already negotiated cipher. >> >> I have a "working" test example which shows how the ALPN APIs can be used >> for HTTP/2 clients and servers. It is a minor configuration tweak to the >> jdk/test/javax/net/ssl/templates/SSLEngineTemplate.java test that we use as >> the basis for JSSE SSLEngine testing. > > Do you have a Java 9 server that can negotiate h2 with current browsers ? > >> http://cr.openjdk.java.net/~wetmore/8051498/webrev.04/test/javax/net/ssl/ALPN/SSLEngineAlpnHttp2.java.html >> >> See the configuration in createSSLEngines() around line 265 and 280. >> >> >> http://cr.openjdk.java.net/~wetmore/8051498/webrev.04/test/javax/net/ssl/ALPN/Http2ApplicationSelector.java.html >> >> Note the HTTP/2 blacklist and reordering code. >> >> The code is not actually "working" yet (haven't merged API/impl repos yet), >> but shows how to configure/use this API. > > Just a reminder that the cipher blacklist is only valid for TLS 1.2. > For example, if the negotiated TLS protocol is 1.3, there is no need > to look at the ciphers (nor to sort them). > > Thanks ! > From artem.smotrakov at oracle.com Thu Jul 9 17:16:07 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 09 Jul 2015 10:16:07 -0700 Subject: [9] RFR: 8049814: Additional SASL client-server tests In-Reply-To: <559DC09C.5020304@oracle.com> References: <559DC09C.5020304@oracle.com> Message-ID: <559EAC57.1010104@oracle.com> Removed one duplicate test case at line 100 in webrev.00, please see updated webrev: http://cr.openjdk.java.net/~asmotrak/8049814/webrev.01/ Artem On 07/08/2015 05:30 PM, Artem Smotrakov wrote: > Hello, > > Please review a client/server test for SASL which uses different > mechanisms and QOPs. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8049814 > Webrev: http://cr.openjdk.java.net/~asmotrak/8049814/webrev.00/ > > Artem From sean.mullan at oracle.com Thu Jul 9 20:45:58 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 09 Jul 2015 16:45:58 -0400 Subject: [9] code review request for 8130850: Support loading a keystore with a custom KeyStore.LoadStoreParameter class In-Reply-To: References: Message-ID: <559EDD86.6080000@oracle.com> The specification for KeyStoreSpi.engineLoad is completely silent on what the default implementation does. We really should add something here, so providers know if they need to override it or if the default impl. is sufficient. Could you add an @implSpec section describing what it does? (you will need a CCC). Otherwise, looks fine. --Sean On 07/09/2015 09:30 AM, Vincent Ryan wrote: > Please review this change to the implementation of the KeyStoreSpi.engineLoad method to accept custom KeyStore.LoadStoreParameter classes. > Thanks. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8130850 > Webrev: http://cr.openjdk.java.net/~vinnie/8130850/webrev.00/ > From tristan.yan at oracle.com Thu Jul 9 22:46:53 2015 From: tristan.yan at oracle.com (Tristan Yan) Date: Thu, 9 Jul 2015 15:46:53 -0700 Subject: RFR 8044199: tests for RSA keys and key specifications Message-ID: Hi Please review new tests for RSA keys and key specifications Bug: https://bugs.openjdk.java.net/browse/JDK-8044199 Webrev: http://cr.openjdk.java.net/~tyan/8044199/webrev.01/ Thanks Tristan -------------- next part -------------- An HTML attachment was scrubbed... URL: From artem.smotrakov at oracle.com Fri Jul 10 20:02:00 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 10 Jul 2015 13:02:00 -0700 Subject: [9] RFR: 8048596: Tests for AEAD ciphers Message-ID: <55A024B8.2030602@oracle.com> Hello, Please review a couple of new tests for AEAD ciphers. Webrev: http://cr.openjdk.java.net/~asmotrak/8048596/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8048596 Artem From bradford.wetmore at oracle.com Fri Jul 10 20:27:46 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 10 Jul 2015 13:27:46 -0700 Subject: RFR: (s) 8130696: Security Providers need to have their version numbers updated for JDK 9 In-Reply-To: References: Message-ID: <55A02AC2.700@oracle.com> I had done a preliminary review earlier, and the current changes look good. Brad On 7/7/2015 10:48 AM, Iris Clark wrote: > Hi. > > Please review changes to resolve the following bug: > > 8130696: Security Providers need to have their version numbers updated > for JDK 9 (Verona) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8130696 > > Changeset: http://cr.openjdk.java.net/~iris/verona/8130696/webrev > > The constructor invocation for every Provider implementation contains a > hard-coded value for the version, "1.9d", which it compares to > java.specification.version. Verona [0,1] changes the system property > from "1.9" to "9". The provider?s version should be changed to ?9.0d?. > > Many regression tests in the jdk repository fail due to this bug. Test > groups with failing tests detecting this problem include jdk_security, > jdk_management, jdk_jmx, and jdk_net. These tests now pass. I have > verified that all providers modified by 8030823 [2] have been updated. > > After review, the changeset will be pushed to verona/stage [3]. The > changeset will go to jdk9/dev when Verona is complete later this summer. > > Thanks, > > Iris > > [0] http://openjdk.java.net/projects/verona > > [1] http://openjdk.java.net/jeps/223 > > [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f1066af06fa0 > > [3] http://hg.openjdk.java.net/verona/stage > From artem.smotrakov at oracle.com Sat Jul 11 16:36:29 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Sat, 11 Jul 2015 09:36:29 -0700 Subject: [9] RFR: 8130041: TsacertOptionTest.java intermittently fails on Mac Message-ID: <55A1460C.1000604@oracle.com> Hello, Please review this fix for TsacertOptionTest.java test. The test fails intermittently on some Macs. It starts a local TSA service which is actually an HTTP server. Then, it runs jarsigner which uses this local TSA service. The failure happens on some Macs due to system network settings. It seems that on such machines jarsigner tries to connect to local TSA via proxy that can't redirect a request to TSA. The fix updates the test to reset a couple of system properties for proxy settings. The test passes with this patch. There are some other tests which use a local TSA in sun/security/tools/jarsigner, but they don't seem to be affected by the problem. Webrev: http://cr.openjdk.java.net/~asmotrak/8130041/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8130041 Artem From vincent.x.ryan at oracle.com Sat Jul 11 17:01:45 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Sat, 11 Jul 2015 18:01:45 +0100 Subject: [9] RFR: 8130041: TsacertOptionTest.java intermittently fails on Mac In-Reply-To: <55A1460C.1000604@oracle.com> References: <55A1460C.1000604@oracle.com> Message-ID: <44D2AF76-CB77-43E8-ACBD-8F3B6134228B@oracle.com> Your fix looks fine. Thanks. > On 11 Jul 2015, at 17:36, Artem Smotrakov wrote: > > Hello, > > Please review this fix for TsacertOptionTest.java test. > > The test fails intermittently on some Macs. It starts a local TSA service which is actually an HTTP server. Then, it runs jarsigner which uses this local TSA service. The failure happens on some Macs due to system network settings. It seems that on such machines jarsigner tries to connect to local TSA via proxy that can't redirect a request to TSA. The fix updates the test to reset a couple of system properties for proxy settings. > > The test passes with this patch. There are some other tests which use a local TSA in sun/security/tools/jarsigner, but they don't seem to be affected by the problem. > > Webrev: http://cr.openjdk.java.net/~asmotrak/8130041/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8130041 > > Artem From jamil.j.nimeh at oracle.com Sat Jul 11 18:16:24 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Sat, 11 Jul 2015 11:16:24 -0700 Subject: Update: JEP 249 (OCSP Stapling for TLS) Message-ID: <55A15D78.6040701@oracle.com> Hello all, I have an updated webrev for OCSP stapling which incorporates comments thus far and a few bug fixes and tests. webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.2 JEP: https://bugs.openjdk.java.net/browse/JDK-8046321 Thanks, --Jamil From weijun.wang at oracle.com Mon Jul 13 01:47:19 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 13 Jul 2015 09:47:19 +0800 Subject: [9] RFR: 8049814: Additional SASL client-server tests In-Reply-To: <559EAC57.1010104@oracle.com> References: <559DC09C.5020304@oracle.com> <559EAC57.1010104@oracle.com> Message-ID: <55A318A7.7040007@oracle.com> One major question: Is it necessary for one side to send both the status and the data to its peer? Your server side does not read the status but the client uses it. And some style things: 81-86: "new String[] { QOP_AUTH }" is defined as authQop on line 90. Why not move lines 88-93 to the beginning? 92: s/authQopConf/authConfQop/; Thanks Max On 07/10/2015 01:16 AM, Artem Smotrakov wrote: > Removed one duplicate test case at line 100 in webrev.00, please see > updated webrev: > > http://cr.openjdk.java.net/~asmotrak/8049814/webrev.01/ > > Artem > > On 07/08/2015 05:30 PM, Artem Smotrakov wrote: >> Hello, >> >> Please review a client/server test for SASL which uses different >> mechanisms and QOPs. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8049814 >> Webrev: http://cr.openjdk.java.net/~asmotrak/8049814/webrev.00/ >> >> Artem > From weijun.wang at oracle.com Mon Jul 13 09:12:05 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 13 Jul 2015 17:12:05 +0800 Subject: RFR 8131051: KDC might issue a renewable ticket even if not requested Message-ID: <55A380E5.3080309@oracle.com> Hi All Please take a look at the fix at http://cr.openjdk.java.net/~weijun/8131051/webrev.00/ When a ticket request has a ticket_lifetime that the KDC considers too long it will issue a renewable ticket with a shorter lifetime. Unfortunately, JDK does not accept this. Thanks Max From peter.brunet at oracle.com Mon Jul 13 22:34:48 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Mon, 13 Jul 2015 17:34:48 -0500 Subject: RfR JDK-8051626 Rework security restrictions of Java Access Bridge and related Utilities Message-ID: <55A43D08.7030106@oracle.com> Please review the webrev for https://bugs.openjdk.java.net/browse/JDK-8051626 http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.00/ This is so the the Java Accessibility Utilities package, com.sun.java.accessibility.util, can be run with the security manager active but the non-public accessibility packages won't, i.e. com.sun.java.accessibility.internal and com.sun.java.accessibility.util.internal. Running the regression test proves that there will be a security exception when using a method of com.sun.java.accessibility.util before the fix but not after. Pete From sean.mullan at oracle.com Tue Jul 14 15:57:48 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 14 Jul 2015 11:57:48 -0400 Subject: RfR JDK-8051626 Rework security restrictions of Java Access Bridge and related Utilities In-Reply-To: <55A43D08.7030106@oracle.com> References: <55A43D08.7030106@oracle.com> Message-ID: <55A5317C.5040809@oracle.com> You don't need to add the /secure option to jtreg. That's overriding jtreg's SecurityManager and causing you to have to grant jtreg permissions to read files in the jtreg.security.policy file. Just add the /java.security.policy option -- this will use jtreg's SecurityManager which is sufficient for testing this bug, and then you won't need the jtreg.security.policy file. Looks good otherwise. --Sean On 07/13/2015 06:34 PM, Pete Brunet wrote: > Please review the webrev for > https://bugs.openjdk.java.net/browse/JDK-8051626 > > http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.00/ > > This is so the the Java Accessibility Utilities package, > com.sun.java.accessibility.util, can be run with the security manager > active but the non-public accessibility packages won't, i.e. > com.sun.java.accessibility.internal and > com.sun.java.accessibility.util.internal. > > Running the regression test proves that there will be a security > exception when using a method of com.sun.java.accessibility.util before > the fix but not after. > > Pete > From vincent.x.ryan at oracle.com Tue Jul 14 18:43:00 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 14 Jul 2015 19:43:00 +0100 Subject: [9] request for review 8131184: Add test sun/security/pkcs11/rsa/TestKeyPairGenerator.java to the problem list Message-ID: Adding the intermittently failing test sun/security/pkcs11/rsa/TestKeyPairGenerator.java to the problem list. Webrev: http://cr.openjdk.java.net/~vinnie/8131184/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8131184 From sean.mullan at oracle.com Tue Jul 14 19:09:08 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 14 Jul 2015 15:09:08 -0400 Subject: [9] request for review 8131184: Add test sun/security/pkcs11/rsa/TestKeyPairGenerator.java to the problem list In-Reply-To: References: Message-ID: <55A55E54.80504@oracle.com> Looks fine to me. --Sean On 07/14/2015 02:43 PM, Vincent Ryan wrote: > Adding the intermittently failing test sun/security/pkcs11/rsa/TestKeyPairGenerator.java to the problem list. > > > Webrev: http://cr.openjdk.java.net/~vinnie/8131184/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8131184 > From vincent.x.ryan at oracle.com Tue Jul 14 19:06:09 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 14 Jul 2015 20:06:09 +0100 Subject: [9] request for review 8131184: Add test sun/security/pkcs11/rsa/TestKeyPairGenerator.java to the problem list In-Reply-To: <55A55E54.80504@oracle.com> References: <55A55E54.80504@oracle.com> Message-ID: <79093CD7-614A-4E2C-A1F8-38C8D217C455@oracle.com> Thanks Sean. > On 14 Jul 2015, at 20:09, Sean Mullan wrote: > > Looks fine to me. > > --Sean > > On 07/14/2015 02:43 PM, Vincent Ryan wrote: >> Adding the intermittently failing test sun/security/pkcs11/rsa/TestKeyPairGenerator.java to the problem list. >> >> >> Webrev: http://cr.openjdk.java.net/~vinnie/8131184/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8131184 >> From amanda.jiang at oracle.com Tue Jul 14 19:15:38 2015 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Tue, 14 Jul 2015 12:15:38 -0700 Subject: RFR 8050402: Tests to check for use of policy files Message-ID: <55A55FDA.3030606@oracle.com> Hi, Please review a new test which checks Policy is extensible with user defined permissions. Bug: https://bugs.openjdk.java.net/browse/JDK-8050402 Webrev: http://cr.openjdk.java.net/~amjiang/8050402/webrev.01/ Thanks, Amanda -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajan.halade at oracle.com Tue Jul 14 20:27:02 2015 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 14 Jul 2015 13:27:02 -0700 Subject: [9] RFR: 8048601: Tests for JCE crypto ciphers Message-ID: <55A57096.10700@oracle.com> May I request you to review new tests added to check Cipher operations with different algorithms and modes. Webrev: http://cr.openjdk.java.net/~rhalade/8048601/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8048601 Thanks, Rajan From Sergey.Bylokhov at oracle.com Tue Jul 14 10:00:41 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 14 Jul 2015 13:00:41 +0300 Subject: RfR JDK-8051626 Rework security restrictions of Java Access Bridge and related Utilities In-Reply-To: <55A43D08.7030106@oracle.com> References: <55A43D08.7030106@oracle.com> Message-ID: <55A4DDC9.7070704@oracle.com> Hi, Pete. The fix looks fine, but you should tweak the test a little bit. - You access the swing components on non-EDT thread. - You should not use System.exit in the test. - The JFrame should be disposed before the end of the test. On 14.07.15 1:34, Pete Brunet wrote: > Please review the webrev for > https://bugs.openjdk.java.net/browse/JDK-8051626 > > http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.00/ > > This is so the the Java Accessibility Utilities package, > com.sun.java.accessibility.util, can be run with the security manager > active but the non-public accessibility packages won't, i.e. > com.sun.java.accessibility.internal and > com.sun.java.accessibility.util.internal. > > Running the regression test proves that there will be a security > exception when using a method of com.sun.java.accessibility.util before > the fix but not after. > > Pete -- Best regards, Sergey. From ecki at zusammenkunft.net Wed Jul 15 00:48:06 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 15 Jul 2015 02:48:06 +0200 Subject: TLS hostname verifier: reverse resolves peer addresses? In-Reply-To: <20141103001528.00004786.ecki@zusammenkunft.net> References: <20141103001528.00004786.ecki@zusammenkunft.net> Message-ID: <20150715024806.000062b2.ecki@zusammenkunft.net> Am Mon, 3 Nov 2014 00:15:28 +0100 schrieb Bernd Eckenfels : > JSSE... I noticed, that > the Java 8 hostname verifier (algorithm https configured) will reverse > resolve hostnames and use them. Is this JDK-8067695 (not public) and fixed in 8u51? Does this have an CVE entry in the 8u51 CPU list, I cannot find one (but then again the descriptions aren't very verbose anyway) http://www.oracle.com/technetwork/topics/security/cpujul2015verbose-2367947.html#JAVA In case you are curious, according to the release notes, it can be controled with jdk.tls.trustNameService. Gruss Bernd From rajan.halade at oracle.com Wed Jul 15 01:37:12 2015 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 14 Jul 2015 18:37:12 -0700 Subject: [9] RFR: 8049237: Need new tests for X509V3 certificates Message-ID: <55A5B948.5030400@oracle.com> May I request you to review two new tests added. V1toV3Cert tries to covert a existing V1 certificate to V3 and V3Certificate test tries to generate V3 certificate with different extensions. Webrev: http://cr.openjdk.java.net/~rhalade/8049237/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8049237 Thanks, Rajan From artem.smotrakov at oracle.com Wed Jul 15 02:29:13 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 14 Jul 2015 19:29:13 -0700 Subject: [9] RFR: 8049814: Additional SASL client-server tests In-Reply-To: <55A318A7.7040007@oracle.com> References: <559DC09C.5020304@oracle.com> <559EAC57.1010104@oracle.com> <55A318A7.7040007@oracle.com> Message-ID: <55A5C579.4090800@oracle.com> Hi Max, Status is currently used to indicate an error on server side, or that server is complete. A client sends only CONTINUE status. I can update it to send null if CONTINUE is confusing. Addressed other comments: http://cr.openjdk.java.net/~asmotrak/8049814/webrev.02/ Artem On 07/12/2015 06:47 PM, Weijun Wang wrote: > One major question: > > Is it necessary for one side to send both the status and the data to > its peer? Your server side does not read the status but the client > uses it. > > And some style things: > > 81-86: "new String[] { QOP_AUTH }" is defined as authQop on line 90. > Why not move lines 88-93 to the beginning? > > 92: s/authQopConf/authConfQop/; > > Thanks > Max > > On 07/10/2015 01:16 AM, Artem Smotrakov wrote: >> Removed one duplicate test case at line 100 in webrev.00, please see >> updated webrev: >> >> http://cr.openjdk.java.net/~asmotrak/8049814/webrev.01/ >> >> Artem >> >> On 07/08/2015 05:30 PM, Artem Smotrakov wrote: >>> Hello, >>> >>> Please review a client/server test for SASL which uses different >>> mechanisms and QOPs. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8049814 >>> Webrev: http://cr.openjdk.java.net/~asmotrak/8049814/webrev.00/ >>> >>> Artem >> From mandy.chung at oracle.com Wed Jul 15 03:48:10 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 15 Jul 2015 11:48:10 +0800 Subject: RfR JDK-8051626 Rework security restrictions of Java Access Bridge and related Utilities In-Reply-To: <55A5317C.5040809@oracle.com> References: <55A43D08.7030106@oracle.com> <55A5317C.5040809@oracle.com> Message-ID: <1CF42E03-D436-48C5-8F66-B9C447778BB6@oracle.com> Moving the internal classes to com.sun.java.accessibility.internal is right as com.sun.java.accessibility is a supported API. Sean is right that no need to specify /secure=java.lang.SecurityManager. Mandy > On Jul 14, 2015, at 11:57 PM, Sean Mullan wrote: > > You don't need to add the /secure option to jtreg. That's overriding jtreg's SecurityManager and causing you to have to grant jtreg permissions to read files in the jtreg.security.policy file. Just add the /java.security.policy option -- this will use jtreg's SecurityManager which is sufficient for testing this bug, and then you won't need the jtreg.security.policy file. > > Looks good otherwise. > > --Sean > > On 07/13/2015 06:34 PM, Pete Brunet wrote: >> Please review the webrev for >> https://bugs.openjdk.java.net/browse/JDK-8051626 >> >> http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.00/ >> >> This is so the the Java Accessibility Utilities package, >> com.sun.java.accessibility.util, can be run with the security manager >> active but the non-public accessibility packages won't, i.e. >> com.sun.java.accessibility.internal and >> com.sun.java.accessibility.util.internal. >> >> Running the regression test proves that there will be a security >> exception when using a method of com.sun.java.accessibility.util before >> the fix but not after. >> >> Pete >> From weijun.wang at oracle.com Wed Jul 15 12:11:12 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 15 Jul 2015 20:11:12 +0800 Subject: [9] RFR: 8049814: Additional SASL client-server tests In-Reply-To: <55A5C579.4090800@oracle.com> References: <559DC09C.5020304@oracle.com> <559EAC57.1010104@oracle.com> <55A318A7.7040007@oracle.com> <55A5C579.4090800@oracle.com> Message-ID: <55A64DE0.4010301@oracle.com> On 07/15/2015 10:29 AM, Artem Smotrakov wrote: > Hi Max, > > Status is currently used to indicate an error on server side, or that > server is complete. A client sends only CONTINUE status. I can update it > to send null if CONTINUE is confusing. I read again and you don't need to make this change. One minor issue: on line 331, I guess you meant to say "data should be null". Everything else is fine. BTW, congratulations for becoming a committer now. Not sure if you can commit this changeset right now. I'll be glad to help if not. Thanks Max > > Addressed other comments: > > http://cr.openjdk.java.net/~asmotrak/8049814/webrev.02/ > > Artem > > On 07/12/2015 06:47 PM, Weijun Wang wrote: >> One major question: >> >> Is it necessary for one side to send both the status and the data to >> its peer? Your server side does not read the status but the client >> uses it. >> >> And some style things: >> >> 81-86: "new String[] { QOP_AUTH }" is defined as authQop on line 90. >> Why not move lines 88-93 to the beginning? >> >> 92: s/authQopConf/authConfQop/; >> >> Thanks >> Max >> >> On 07/10/2015 01:16 AM, Artem Smotrakov wrote: >>> Removed one duplicate test case at line 100 in webrev.00, please see >>> updated webrev: >>> >>> http://cr.openjdk.java.net/~asmotrak/8049814/webrev.01/ >>> >>> Artem >>> >>> On 07/08/2015 05:30 PM, Artem Smotrakov wrote: >>>> Hello, >>>> >>>> Please review a client/server test for SASL which uses different >>>> mechanisms and QOPs. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8049814 >>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8049814/webrev.00/ >>>> >>>> Artem >>> > From artem.smotrakov at oracle.com Wed Jul 15 15:57:59 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 15 Jul 2015 08:57:59 -0700 Subject: [9] RFR: 8049814: Additional SASL client-server tests In-Reply-To: <55A64DE0.4010301@oracle.com> References: <559DC09C.5020304@oracle.com> <559EAC57.1010104@oracle.com> <55A318A7.7040007@oracle.com> <55A5C579.4090800@oracle.com> <55A64DE0.4010301@oracle.com> Message-ID: <55A68307.60303@oracle.com> Thanks Max! Yes, I still can't commit the changes, please push them http://cr.openjdk.java.net/~asmotrak/8049814/webrev.03/ Artem On 07/15/2015 05:11 AM, Weijun Wang wrote: > > On 07/15/2015 10:29 AM, Artem Smotrakov wrote: >> Hi Max, >> >> Status is currently used to indicate an error on server side, or that >> server is complete. A client sends only CONTINUE status. I can update it >> to send null if CONTINUE is confusing. > > I read again and you don't need to make this change. One minor issue: > on line 331, I guess you meant to say "data should be null". > > Everything else is fine. > > BTW, congratulations for becoming a committer now. Not sure if you can > commit this changeset right now. I'll be glad to help if not. > > Thanks > Max > >> >> Addressed other comments: >> >> http://cr.openjdk.java.net/~asmotrak/8049814/webrev.02/ >> >> Artem >> >> On 07/12/2015 06:47 PM, Weijun Wang wrote: >>> One major question: >>> >>> Is it necessary for one side to send both the status and the data to >>> its peer? Your server side does not read the status but the client >>> uses it. >>> >>> And some style things: >>> >>> 81-86: "new String[] { QOP_AUTH }" is defined as authQop on line 90. >>> Why not move lines 88-93 to the beginning? >>> >>> 92: s/authQopConf/authConfQop/; >>> >>> Thanks >>> Max >>> >>> On 07/10/2015 01:16 AM, Artem Smotrakov wrote: >>>> Removed one duplicate test case at line 100 in webrev.00, please see >>>> updated webrev: >>>> >>>> http://cr.openjdk.java.net/~asmotrak/8049814/webrev.01/ >>>> >>>> Artem >>>> >>>> On 07/08/2015 05:30 PM, Artem Smotrakov wrote: >>>>> Hello, >>>>> >>>>> Please review a client/server test for SASL which uses different >>>>> mechanisms and QOPs. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8049814 >>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8049814/webrev.00/ >>>>> >>>>> Artem >>>> >> From vincent.x.ryan at oracle.com Wed Jul 15 16:27:28 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 15 Jul 2015 17:27:28 +0100 Subject: [9] request for review 8131359 Correct the JTREG tags in java/security/KeyStore/PKCS12/MetadataStoreLoadTest.java test Message-ID: Please approve this correction to the java/security/KeyStore/PKCS12/MetadataStoreLoadTest.java test was failing to compile. Thanks. Bug: https://bugs.openjdk.java.net/browse/JDK-8131359 Webrev: http://cr.openjdk.java.net/~vinnie/8131359/webrev.00/ From sean.mullan at oracle.com Wed Jul 15 17:07:57 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 15 Jul 2015 13:07:57 -0400 Subject: [9] request for review 8131359 Correct the JTREG tags in java/security/KeyStore/PKCS12/MetadataStoreLoadTest.java test In-Reply-To: References: Message-ID: <55A6936D.3030103@oracle.com> Looks good. --Sean On 07/15/2015 12:27 PM, Vincent Ryan wrote: > Please approve this correction to the java/security/KeyStore/PKCS12/MetadataStoreLoadTest.java test was failing to compile. > Thanks. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8131359 > Webrev: http://cr.openjdk.java.net/~vinnie/8131359/webrev.00/ > From peter.brunet at oracle.com Wed Jul 15 21:42:25 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 15 Jul 2015 16:42:25 -0500 Subject: RfR JDK-8051626 Rework security restrictions of Java Access Bridge and related Utilities In-Reply-To: <55A4DDC9.7070704@oracle.com> References: <55A43D08.7030106@oracle.com> <55A4DDC9.7070704@oracle.com> Message-ID: <55A6D3C1.4080601@oracle.com> An update is available and mostly changes only the test case, Bug8151626.java. The other change is to remove jtreg.security.policy. http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.01/ Changes: >From Sean - The jtreg @run statement was removed; don't specify security manager or security policy. - Remove jtreg.security.policy - Add System.setSecurityManager(new SecurityManager()); to the beginning of the code. >From Sergey - Wrap test in invokeAndWait - Add frame.dispose in finally - Remove System.exit I also removed the Thread.sleep. It doesn't appear to be needed. Pete On 7/14/15 5:00 AM, Sergey Bylokhov wrote: > Hi, Pete. > The fix looks fine, but you should tweak the test a little bit. > - You access the swing components on non-EDT thread. > - You should not use System.exit in the test. > - The JFrame should be disposed before the end of the test. > > On 14.07.15 1:34, Pete Brunet wrote: >> Please review the webrev for >> https://bugs.openjdk.java.net/browse/JDK-8051626 >> >> http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.00/ >> >> This is so the the Java Accessibility Utilities package, >> com.sun.java.accessibility.util, can be run with the security manager >> active but the non-public accessibility packages won't, i.e. >> com.sun.java.accessibility.internal and >> com.sun.java.accessibility.util.internal. >> >> Running the regression test proves that there will be a security >> exception when using a method of com.sun.java.accessibility.util before >> the fix but not after. >> >> Pete > > From artem.smotrakov at oracle.com Thu Jul 16 05:38:07 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 15 Jul 2015 22:38:07 -0700 Subject: [9] RFR: 8075297: Tests for RFEs 4515853 and 4745056 Message-ID: <55A7433F.7060306@oracle.com> Hello, Please review a couple of new tests that check that: - Kerberos client tries slave KDC if master KDC is not responding - if refreshKrb5Config is set to true for Krb5LoginModule, then configuration will be refreshed before login() method is called KDC.java registers a name service which returns 127.0.0.1 for all hosts. The name service was updated to throw UnknownHostException for "not.existing.host". Webrev: http://cr.openjdk.java.net/~asmotrak/8075297/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8075297 Artem From weijun.wang at oracle.com Thu Jul 16 07:57:09 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 16 Jul 2015 15:57:09 +0800 Subject: [9] RFR: 8075297: Tests for RFEs 4515853 and 4745056 In-Reply-To: <55A7433F.7060306@oracle.com> References: <55A7433F.7060306@oracle.com> Message-ID: <55A763D5.3010809@oracle.com> The logic in RefreshKrb5Config.java is very good. Why not also try NotRefreshable again after writing the correct krb5.conf in BogusKDC.java? Thanks Max On 07/16/2015 01:38 PM, Artem Smotrakov wrote: > Hello, > > Please review a couple of new tests that check that: > - Kerberos client tries slave KDC if master KDC is not responding > - if refreshKrb5Config is set to true for Krb5LoginModule, then > configuration will be refreshed before login() method is called > > KDC.java registers a name service which returns 127.0.0.1 for all hosts. > The name service was updated to throw UnknownHostException for > "not.existing.host". > > Webrev: http://cr.openjdk.java.net/~asmotrak/8075297/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8075297 > > Artem From weijun.wang at oracle.com Thu Jul 16 13:43:14 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 16 Jul 2015 21:43:14 +0800 Subject: RFR 8131350: policytool can directly reference permission classes Message-ID: <55A7B4F2.5020306@oracle.com> Hi All Please take a look at http://cr.openjdk.java.net/~weijun/8131350/webrev.00/ Policytool contains a lot of hard coded strings for permission class names, which can be changed to actual Class types. That allows checking at compile-time rather than failing at run-time if any name had a typo. Noreg-cleanup. Thanks Max From sean.mullan at oracle.com Thu Jul 16 16:58:11 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 16 Jul 2015 12:58:11 -0400 Subject: [9] RFR: 8074784: Additional tests for XML DSig API In-Reply-To: <558D927F.9060302@oracle.com> References: <55521D03.5000800@oracle.com> <555CE5EF.5030409@oracle.com> <555CEBA5.30403@oracle.com> <55804D6A.9070004@oracle.com> <558D927F.9060302@oracle.com> Message-ID: <55A7E2A3.6060206@oracle.com> Hi Artem, The updated test looks good. Thanks, Sean On 06/26/2015 01:57 PM, Artem Smotrakov wrote: > Hi Sean, > > I added new test cases to GenerationTests, please take a look: > > http://cr.openjdk.java.net/~asmotrak/8074784/webrev.01/ > > Artem > > On 06/16/2015 07:23 PM, Sean Mullan wrote: >> On 05/20/2015 04:16 PM, Artem Smotrakov wrote: >>> Hi Sean, >>> >>> Yes, at first, I thought about updating the existing tests in >>> test/javax/xml/crypto/dsig directory. But then I noticed that both >>> GenerationTests and ValidationTests has ~30 test cases. And new >>> Detached.java test contains >30 test cases. If one of test cases fails, >>> JTREG will show that full test failed. As a result, it may hide failures >>> of other test cases (an engineer should look at logs carefully). >> >> You could always change that to continue on error and run all tests >> before reporting a failure. That was just originally the way the test >> was created, it isn't set in stone. >> >>> Also it >>> may be better to split tests if possible when some tools for automated >>> failures analysis is used (for example, Java SQE uses such a tool). >>> >>> That was the main reason why I added a separate test. Not sure if >>> performance may be an issue, I have not done any measurement. >> >> Yes, but there is still a lot of common infrastructure in this test >> and ValidationTests that could be combined. You have made use of >> lambdas and streams to create a nice way to structure and run the >> different variants of tests. But a detached signature is really just >> another variant, and I think your test could be easily adapted to also >> test enveloped and enveloping signatures, as well as the other cases >> in ValidationTests. So, it would be nice to combine these tests. I >> would be ok with filing a follow-on issue to do that, though. >> >> I noticed a few typos: >> >> 151: s/fot/for >> 332: s/transfrom/transform/ >> 418: s/validaition/validation/ >> >> I also would recommend reordering the imports in alphabetical order. >> >> Looks fine otherwise. >> >> Thanks, >> Sean >> >>> >>> Artem >>> >>> On 05/20/2015 10:52 PM, Sean Mullan wrote: >>>> Hi Artem, >>>> >>>> Is there a reason this needs to be a separate test? It seems like it >>>> would be better to fold it into the existing GenerationTests and >>>> ValidationTests in the test/javax/xml/crypto/dsig directory, so you >>>> could reuse common code. >>>> >>>> Thanks, >>>> Sean >>>> >>>> On 05/12/2015 11:32 AM, Artem Smotrakov wrote: >>>>> Hello, >>>>> >>>>> Please review a new test for generating and validation of detached XML >>>>> digital signatures. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074784 >>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8074784/webrev.00/ >>>>> >>>>> Artem >>> > From sean.coffey at oracle.com Thu Jul 16 17:02:56 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Thu, 16 Jul 2015 18:02:56 +0100 Subject: RFR: (XS) : 8131665: Bad exception message in HandshakeHash.getFinishedHash Message-ID: <55A7E3C0.2030703@oracle.com> Bug report : https://bugs.openjdk.java.net/browse/JDK-8131665 Simple fix to improve the Error message for this scenario. diff --git a/src/java.base/share/classes/sun/security/ssl/HandshakeHash.java b/src/java.base/share/classes/sun/security/ssl/HandshakeHash.java --- a/src/java.base/share/classes/sun/security/ssl/HandshakeHash.java +++ b/src/java.base/share/classes/sun/security/ssl/HandshakeHash.java @@ -355,7 +355,7 @@ try { return cloneDigest(finMD).digest(); } catch (Exception e) { - throw new Error("BAD"); + throw new Error("Error during hash calculation", e); } } } -- Regards, Sean. From konstantin.shefov at oracle.com Thu Jul 16 18:08:55 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Thu, 16 Jul 2015 21:08:55 +0300 Subject: [9] RFR: 8129306: Some new tests developed for JDK-8085979 fail in jdk9/cpu Message-ID: <55A7F337.6010008@oracle.com> Hello, Please review a test bug fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8129306 Webrev: http://cr.openjdk.java.net/~kshefov/8129306/webrev.00/ -Konstantin From vincent.x.ryan at oracle.com Thu Jul 16 18:06:53 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 16 Jul 2015 19:06:53 +0100 Subject: [9] RFR: 8129306: Some new tests developed for JDK-8085979 fail in jdk9/cpu In-Reply-To: <55A7F337.6010008@oracle.com> References: <55A7F337.6010008@oracle.com> Message-ID: <3B34539D-A56B-40D3-A614-EEE3C2510CBA@oracle.com> Looks fine to me. > On 16 Jul 2015, at 19:08, Konstantin Shefov wrote: > > Hello, > > Please review a test bug fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8129306 > Webrev: http://cr.openjdk.java.net/~kshefov/8129306/webrev.00/ > > -Konstantin From artem.smotrakov at oracle.com Thu Jul 16 21:05:31 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 16 Jul 2015 14:05:31 -0700 Subject: [9] RFR: 8075297: Tests for RFEs 4515853 and 4745056 In-Reply-To: <55A763D5.3010809@oracle.com> References: <55A7433F.7060306@oracle.com> <55A763D5.3010809@oracle.com> Message-ID: <55A81C9B.3040904@oracle.com> Hi Max, Good point, please see an updated webrev: http://cr.openjdk.java.net/~asmotrak/8075297/webrev.01/ Artem On 07/16/2015 12:57 AM, Weijun Wang wrote: > The logic in RefreshKrb5Config.java is very good. Why not also try > NotRefreshable again after writing the correct krb5.conf in > BogusKDC.java? > > Thanks > Max > > On 07/16/2015 01:38 PM, Artem Smotrakov wrote: >> Hello, >> >> Please review a couple of new tests that check that: >> - Kerberos client tries slave KDC if master KDC is not responding >> - if refreshKrb5Config is set to true for Krb5LoginModule, then >> configuration will be refreshed before login() method is called >> >> KDC.java registers a name service which returns 127.0.0.1 for all hosts. >> The name service was updated to throw UnknownHostException for >> "not.existing.host". >> >> Webrev: http://cr.openjdk.java.net/~asmotrak/8075297/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8075297 >> >> Artem From xuelei.fan at oracle.com Thu Jul 16 21:46:38 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 17 Jul 2015 05:46:38 +0800 Subject: RFR: (XS) : 8131665: Bad exception message in HandshakeHash.getFinishedHash In-Reply-To: <55A7E3C0.2030703@oracle.com> References: <55A7E3C0.2030703@oracle.com> Message-ID: <55A8263E.2080203@oracle.com> Looks fine to me. Thanks, Xuelei On 7/17/2015 1:02 AM, Se?n Coffey wrote: > Bug report : https://bugs.openjdk.java.net/browse/JDK-8131665 > > Simple fix to improve the Error message for this scenario. > > diff --git > a/src/java.base/share/classes/sun/security/ssl/HandshakeHash.java > b/src/java.base/share/classes/sun/security/ssl/HandshakeHash.java > --- a/src/java.base/share/classes/sun/security/ssl/HandshakeHash.java > +++ b/src/java.base/share/classes/sun/security/ssl/HandshakeHash.java > @@ -355,7 +355,7 @@ > try { > return cloneDigest(finMD).digest(); > } catch (Exception e) { > - throw new Error("BAD"); > + throw new Error("Error during hash calculation", e); > } > } > } > From weijun.wang at oracle.com Fri Jul 17 01:19:33 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 17 Jul 2015 09:19:33 +0800 Subject: [9] RFR: 8075297: Tests for RFEs 4515853 and 4745056 In-Reply-To: <55A81C9B.3040904@oracle.com> References: <55A7433F.7060306@oracle.com> <55A763D5.3010809@oracle.com> <55A81C9B.3040904@oracle.com> Message-ID: <55A85825.5000302@oracle.com> One final point. You have the timeout set to 5 minutes in + * @run main/othervm/timeout=300 BogusKDC Did you observe the test spending a lot of time? A kerberos client is designed to timeout after 30 seconds if there is no reply from a KDC but sometimes it could be very fast if the KDC does not exist (i.e. not listening on the port at all). Sometimes it could be even slower if the client believes the KDC is there and it will retry for 3 times. This can also be platform dependent, for example, on Mac there is no PortUnreachableException. I suggest you add a "max_retries = 1" to [libdefaults] of krb5.conf in case the worst thing happens. You can also add "kdc_timeout = 10s". Don't make it too short, some embedded Linux are very slow. I am trying to drag the review process longer so you can push it yourself. :-) Thanks Max On 07/17/2015 05:05 AM, Artem Smotrakov wrote: > Hi Max, > > Good point, please see an updated webrev: > > http://cr.openjdk.java.net/~asmotrak/8075297/webrev.01/ > > Artem > > From Sergey.Bylokhov at oracle.com Thu Jul 16 10:19:06 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 16 Jul 2015 13:19:06 +0300 Subject: RfR JDK-8051626 Rework security restrictions of Java Access Bridge and related Utilities In-Reply-To: <55A6D3C1.4080601@oracle.com> References: <55A43D08.7030106@oracle.com> <55A4DDC9.7070704@oracle.com> <55A6D3C1.4080601@oracle.com> Message-ID: <55A7851A.7050400@oracle.com> The fix looks fine. On 16.07.15 0:42, Pete Brunet wrote: > An update is available and mostly changes only the test case, > Bug8151626.java. The other change is to remove jtreg.security.policy. > > http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.01/ > > Changes: > > From Sean > - The jtreg @run statement was removed; don't specify security manager > or security policy. > - Remove jtreg.security.policy > - Add System.setSecurityManager(new SecurityManager()); to the beginning > of the code. > > From Sergey > - Wrap test in invokeAndWait > - Add frame.dispose in finally > - Remove System.exit > > I also removed the Thread.sleep. It doesn't appear to be needed. > > Pete > > On 7/14/15 5:00 AM, Sergey Bylokhov wrote: >> Hi, Pete. >> The fix looks fine, but you should tweak the test a little bit. >> - You access the swing components on non-EDT thread. >> - You should not use System.exit in the test. >> - The JFrame should be disposed before the end of the test. >> >> On 14.07.15 1:34, Pete Brunet wrote: >>> Please review the webrev for >>> https://bugs.openjdk.java.net/browse/JDK-8051626 >>> >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.00/ >>> >>> This is so the the Java Accessibility Utilities package, >>> com.sun.java.accessibility.util, can be run with the security manager >>> active but the non-public accessibility packages won't, i.e. >>> com.sun.java.accessibility.internal and >>> com.sun.java.accessibility.util.internal. >>> >>> Running the regression test proves that there will be a security >>> exception when using a method of com.sun.java.accessibility.util before >>> the fix but not after. >>> >>> Pete >> -- Best regards, Sergey. From peter.brunet at oracle.com Fri Jul 17 01:48:22 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 16 Jul 2015 20:48:22 -0500 Subject: RfR JDK-8051626 Rework security restrictions of Java Access Bridge and related Utilities In-Reply-To: <55A6D3C1.4080601@oracle.com> References: <55A43D08.7030106@oracle.com> <55A4DDC9.7070704@oracle.com> <55A6D3C1.4080601@oracle.com> Message-ID: <55A85EE6.5010705@oracle.com> >From Mandy: - remove unused imports - add @run main/othervm http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.02/ On 7/15/15 4:42 PM, Pete Brunet wrote: > An update is available and mostly changes only the test case, > Bug8151626.java. The other change is to remove jtreg.security.policy. > > http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.01/ > > Changes: > > From Sean > - The jtreg @run statement was removed; don't specify security manager > or security policy. > - Remove jtreg.security.policy > - Add System.setSecurityManager(new SecurityManager()); to the beginning > of the code. > > From Sergey > - Wrap test in invokeAndWait > - Add frame.dispose in finally > - Remove System.exit > > I also removed the Thread.sleep. It doesn't appear to be needed. > > Pete > > On 7/14/15 5:00 AM, Sergey Bylokhov wrote: >> Hi, Pete. >> The fix looks fine, but you should tweak the test a little bit. >> - You access the swing components on non-EDT thread. >> - You should not use System.exit in the test. >> - The JFrame should be disposed before the end of the test. >> >> On 14.07.15 1:34, Pete Brunet wrote: >>> Please review the webrev for >>> https://bugs.openjdk.java.net/browse/JDK-8051626 >>> >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.00/ >>> >>> This is so the the Java Accessibility Utilities package, >>> com.sun.java.accessibility.util, can be run with the security manager >>> active but the non-public accessibility packages won't, i.e. >>> com.sun.java.accessibility.internal and >>> com.sun.java.accessibility.util.internal. >>> >>> Running the regression test proves that there will be a security >>> exception when using a method of com.sun.java.accessibility.util before >>> the fix but not after. >>> >>> Pete >> From artem.smotrakov at oracle.com Fri Jul 17 04:47:25 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 16 Jul 2015 21:47:25 -0700 Subject: [9] RFR: 8075297: Tests for RFEs 4515853 and 4745056 In-Reply-To: <55A85825.5000302@oracle.com> References: <55A7433F.7060306@oracle.com> <55A763D5.3010809@oracle.com> <55A81C9B.3040904@oracle.com> <55A85825.5000302@oracle.com> Message-ID: <55A888DD.9020209@oracle.com> Hi Max, On 07/16/2015 06:19 PM, Weijun Wang wrote: > One final point. > > You have the timeout set to 5 minutes in > > + * @run main/othervm/timeout=300 BogusKDC > > Did you observe the test spending a lot of time? A kerberos client is > designed to timeout after 30 seconds if there is no reply from a KDC > but sometimes it could be very fast if the KDC does not exist (i.e. > not listening on the port at all). Sometimes it could be even slower > if the client believes the KDC is there and it will retry for 3 times. > This can also be platform dependent, for example, on Mac there is no > PortUnreachableException. Yes, I noticed that sometimes a client may do 3 attempts, and default timeout is 30 seconds. That's why I increased timeout for this test. > > I suggest you add a "max_retries = 1" to [libdefaults] of krb5.conf in > case the worst thing happens. You can also add "kdc_timeout = 10s". > Don't make it too short, some embedded Linux are very slow. I think it it enough to add a "max_retries = 1" to [libdefaults] of krb5.conf, and left default timeout value for the test. Please take a look at updated webrev: http://cr.openjdk.java.net/~asmotrak/8075297/webrev.02/ > > I am trying to drag the review process longer so you can push it > yourself. :-) It looks like my account has been updated, so probably I can push it by myself now :-) http://openjdk.java.net/census#asmotrak Artem > > Thanks > Max > > On 07/17/2015 05:05 AM, Artem Smotrakov wrote: >> Hi Max, >> >> Good point, please see an updated webrev: >> >> http://cr.openjdk.java.net/~asmotrak/8075297/webrev.01/ >> >> Artem >> >> From weijun.wang at oracle.com Fri Jul 17 06:31:37 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 17 Jul 2015 14:31:37 +0800 Subject: [9] RFR: 8075297: Tests for RFEs 4515853 and 4745056 In-Reply-To: <55A888DD.9020209@oracle.com> References: <55A7433F.7060306@oracle.com> <55A763D5.3010809@oracle.com> <55A81C9B.3040904@oracle.com> <55A85825.5000302@oracle.com> <55A888DD.9020209@oracle.com> Message-ID: >> > I think it it enough to add a "max_retries = 1" to [libdefaults] of krb5.conf, and left default timeout value for the test. Please take a look at updated webrev: > > http://cr.openjdk.java.net/~asmotrak/8075297/webrev.02/ Can you also add the same line to the krb5.conf for the other test? Thanks Max From artem.smotrakov at oracle.com Fri Jul 17 17:51:08 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 17 Jul 2015 10:51:08 -0700 Subject: [9] RFR: 8075297: Tests for RFEs 4515853 and 4745056 In-Reply-To: References: <55A7433F.7060306@oracle.com> <55A763D5.3010809@oracle.com> <55A81C9B.3040904@oracle.com> <55A85825.5000302@oracle.com> <55A888DD.9020209@oracle.com> Message-ID: <55A9408C.1040502@oracle.com> Hi Max, Please see an updated webrev: http://cr.openjdk.java.net/~asmotrak/8075297/webrev.03/ Artem On 07/16/2015 11:31 PM, Wang Weijun wrote: >> I think it it enough to add a "max_retries = 1" to [libdefaults] of krb5.conf, and left default timeout value for the test. Please take a look at updated webrev: >> >> http://cr.openjdk.java.net/~asmotrak/8075297/webrev.02/ > Can you also add the same line to the krb5.conf for the other test? > > Thanks > Max From jamil.j.nimeh at oracle.com Fri Jul 17 19:19:21 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 17 Jul 2015 12:19:21 -0700 Subject: Fwd: Re: Update: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <55A82814.5060400@oracle.com> References: <55A82814.5060400@oracle.com> Message-ID: <55A95539.6090804@oracle.com> Sorry for not being explicit about the changes that went into webrev.2, but I've listed them below: * The StatusResponseManager to do cache checking from the main thread rather than a worker thread * A fix in ServerHandshaker's selection of the CertStatusReqItemV2 where I wasn't properly picking the first instance of an item type of "ocsp" (as opposed to ocsp_multi, which always get the first instance). Type ocsp_multi will still supersede ocsp types, however. * A spec change to ExtendedSSLSession.getStatusResponses() to clarify the meaning of zero-length byte arrays in the returned list. http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.2 Thanks, --Jamil > > On 07/11/2015 02:16 PM, Jamil Nimeh wrote: >> Hello all, >> >> I have an updated webrev for OCSP stapling which incorporates comments >> thus far and a few bug fixes and tests. >> >> webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.2 >> JEP: https://bugs.openjdk.java.net/browse/JDK-8046321 >> >> Thanks, >> --Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From iris.clark at oracle.com Fri Jul 17 21:18:55 2015 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 17 Jul 2015 14:18:55 -0700 (PDT) Subject: RFR: (s) 8130696: Security Providers need to have their version numbers updated for JDK 9 In-Reply-To: <559E9FEC.3090002@oracle.com> References: <559DF127.8080709@oracle.com> <559E9FEC.3090002@oracle.com> Message-ID: <6e7576c7-8b35-43c7-ac89-31d2e7304d0d@default> Hi, Sean. Sorry for the delayed response. Thanks for your review. Great catch! I thought I'd checked the output for all of the failing security tests, but it looks like I missed that. I've created and tested a new changeset which addresses that problem. The changeset is off of verona/stage which was recently sync'd with jdk9-b72. In addition to the test fix, there are some minor changes from the first webrev (some files no longer need copyright updates, com.sun.security.sasl.gsskerb.JdkSASL changes added). http://cr.openjdk.java.net/~iris/verona/8130696/webrev.1 Let me know if you have any additional concerns. Thanks, iris -----Original Message----- From: Sean Mullan Sent: Thursday, July 09, 2015 9:23 AM To: Weijun Wang; Iris Clark; security-dev at openjdk.java.net Subject: Re: RFR: (s) 8130696: Security Providers need to have their version numbers updated for JDK 9 The Version variable on line 73 of S11N.java should be all lowercase: int version = Integer.valueOf(v); otherwise it should not compile. --Sean On 07/08/2015 11:57 PM, Weijun Wang wrote: > Hi Iris > > The change to S11N.java looks fine. > > Thanks > Max > > On 07/08/2015 01:48 AM, Iris Clark wrote: >> Hi. >> >> Please review changes to resolve the following bug: >> >> 8130696: Security Providers need to have their version numbers >> updated for JDK 9 (Verona) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8130696 >> >> Changeset: http://cr.openjdk.java.net/~iris/verona/8130696/webrev >> >> The constructor invocation for every Provider implementation contains >> a hard-coded value for the version, "1.9d", which it compares to >> java.specification.version. Verona [0,1] changes the system property >> from "1.9" to "9". The provider's version should be changed to "9.0d". >> >> Many regression tests in the jdk repository fail due to this bug. >> Test groups with failing tests detecting this problem include >> jdk_security, jdk_management, jdk_jmx, and jdk_net. These tests now >> pass. I have verified that all providers modified by 8030823 [2] have been updated. >> >> After review, the changeset will be pushed to verona/stage [3]. The >> changeset will go to jdk9/dev when Verona is complete later this summer. >> >> Thanks, >> >> Iris >> >> [0] http://openjdk.java.net/projects/verona >> >> [1] http://openjdk.java.net/jeps/223 >> >> [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f1066af06fa0 >> >> [3] http://hg.openjdk.java.net/verona/stage >> From iris.clark at oracle.com Fri Jul 17 21:18:58 2015 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 17 Jul 2015 14:18:58 -0700 (PDT) Subject: RFR: (s) 8130696: Security Providers need to have their version numbers updated for JDK 9 In-Reply-To: <559DDB3C.9090204@oracle.com> References: <559DDB3C.9090204@oracle.com> Message-ID: Hi, Valerie. Sorry for the delayed response. Thanks for reviewing. The original webrev was based off of verona/stage which was synch'd to jdk9-b70. The file you reference wasn't in the repository yet. Since that time, verona/stage has been sync'd with jdk9-b72 . Here's the new changeset: http://cr.openjdk.java.net/~iris/verona/8130696/webrev.1 In addition to modifying com.sun.security.sasl.gsskerb.JdkSASL, I also updated the S11N.java test to address Sean's concern. Other security updates pulled in by the sync made some of my copyright updates unnecessary, so those have been removed as well. Let me know if you have any additional concerns. Regards. iris From: Valerie Peng Sent: Wednesday, July 08, 2015 7:24 PM To: HYPERLINK "mailto:security-dev at openjdk.java.net"security-dev at openjdk.java.net Subject: Re: RFR: (s) 8130696: Security Providers need to have their version numbers updated for JDK 9 Is the Verona repo sync'ed to the latest OpenJDK? The webrev seems to be missing the provider JdkSASL inside the following file src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/JdkSASL.java The rest looks good. Valerie On 7/7/2015 10:48 AM, Iris Clark wrote: Hi. Please review changes to resolve the following bug: 8130696: Security Providers need to have their version numbers updated for JDK 9 (Verona) Bug: https://bugs.openjdk.java.net/browse/JDK-8130696 Changeset: http://cr.openjdk.java.net/~iris/verona/8130696/webrev The constructor invocation for every Provider implementation contains a hard-coded value for the version, "1.9d", which it compares to java.specification.version. Verona [0,1] changes the system property from "1.9" to "9". The provider's version should be changed to "9.0d". Many regression tests in the jdk repository fail due to this bug. Test groups with failing tests detecting this problem include jdk_security, jdk_management, jdk_jmx, and jdk_net. These tests now pass. I have verified that all providers modified by 8030823 [2] have been updated. After review, the changeset will be pushed to verona/stage [3]. The changeset will go to jdk9/dev when Verona is complete later this summer. Thanks, Iris [0] http://openjdk.java.net/projects/verona [1] http://openjdk.java.net/jeps/223 [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f1066af06fa0 [3] http://hg.openjdk.java.net/verona/stage -------------- next part -------------- An HTML attachment was scrubbed... URL: From iris.clark at oracle.com Fri Jul 17 21:20:04 2015 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 17 Jul 2015 14:20:04 -0700 (PDT) Subject: RFR: (s) 8130696: Security Providers need to have their version numbers updated for JDK 9 In-Reply-To: <559DF127.8080709@oracle.com> References: <559DF127.8080709@oracle.com> Message-ID: <1166fefb-efe9-4aa6-bd28-a12d7e097fe8@default> Hi, Max. Thanks for taking the time to review. Regards, iris -----Original Message----- From: Weijun Wang Sent: Wednesday, July 08, 2015 8:57 PM To: Iris Clark; security-dev at openjdk.java.net Subject: Re: RFR: (s) 8130696: Security Providers need to have their version numbers updated for JDK 9 Hi Iris The change to S11N.java looks fine. Thanks Max On 07/08/2015 01:48 AM, Iris Clark wrote: > Hi. > > Please review changes to resolve the following bug: > > 8130696: Security Providers need to have their version numbers updated > for JDK 9 (Verona) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8130696 > > Changeset: http://cr.openjdk.java.net/~iris/verona/8130696/webrev > > The constructor invocation for every Provider implementation contains > a hard-coded value for the version, "1.9d", which it compares to > java.specification.version. Verona [0,1] changes the system property > from "1.9" to "9". The provider's version should be changed to "9.0d". > > Many regression tests in the jdk repository fail due to this bug. > Test groups with failing tests detecting this problem include > jdk_security, jdk_management, jdk_jmx, and jdk_net. These tests now > pass. I have verified that all providers modified by 8030823 [2] have been updated. > > After review, the changeset will be pushed to verona/stage [3]. The > changeset will go to jdk9/dev when Verona is complete later this summer. > > Thanks, > > Iris > > [0] http://openjdk.java.net/projects/verona > > [1] http://openjdk.java.net/jeps/223 > > [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f1066af06fa0 > > [3] http://hg.openjdk.java.net/verona/stage > From sean.mullan at oracle.com Fri Jul 17 21:32:06 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 17 Jul 2015 17:32:06 -0400 Subject: RFR: JDK-8131486 : SecureClassLoader key for ProtectionDomain cache also needs to take into account certificates Message-ID: <55A97456.2070708@oracle.com> One of the changesets for JEP 232 (Improve Secure Application Performance) introduced a regression in the ProtectionDomain cache used by SecureClassLoader. The HashMap key needs to also check the Certificates of the CodeSource (as well as the location); otherwise 2 CodeSources from the same location but with different signers can resolve to the same ProtectionDomain. The existing regression test has also been updated to test this case. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8131486/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8131486 Thanks, Sean From weijun.wang at oracle.com Fri Jul 17 23:19:57 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 18 Jul 2015 07:19:57 +0800 Subject: [9] RFR: 8075297: Tests for RFEs 4515853 and 4745056 In-Reply-To: <55A9408C.1040502@oracle.com> References: <55A7433F.7060306@oracle.com> <55A763D5.3010809@oracle.com> <55A81C9B.3040904@oracle.com> <55A85825.5000302@oracle.com> <55A888DD.9020209@oracle.com> <55A9408C.1040502@oracle.com> Message-ID: <55A98D9D.5080001@oracle.com> Although the java.security.krb5.kdc/realm system properties are able to override the values inside krb5.conf, it is better to write one without realm/kdc info at all. So, instead of 60 KDC.saveConfig(KRB5_CONF_FILENAME, kdc, "max_retries = 1"); How about just manually write Files.write(Paths.get(KRB5_CONF_FILENAME), Arrays.asList( "[libdefaults]", "max_retries = 1")); --Max On 07/18/2015 01:51 AM, Artem Smotrakov wrote: > Hi Max, > > Please see an updated webrev: > > http://cr.openjdk.java.net/~asmotrak/8075297/webrev.03/ > > Artem > > On 07/16/2015 11:31 PM, Wang Weijun wrote: >>> I think it it enough to add a "max_retries = 1" to [libdefaults] of >>> krb5.conf, and left default timeout value for the test. Please take a >>> look at updated webrev: >>> >>> http://cr.openjdk.java.net/~asmotrak/8075297/webrev.02/ >> Can you also add the same line to the krb5.conf for the other test? >> >> Thanks >> Max > From rajan.halade at oracle.com Fri Jul 17 23:21:51 2015 From: rajan.halade at oracle.com (Rajan Halade) Date: Fri, 17 Jul 2015 16:21:51 -0700 Subject: [9] RFR: 8048624: Tests for SealedObject Message-ID: <55A98E0F.7040409@oracle.com> May I request you to review two new tests added to check SealedObject with different ciphers. Bug: https://bugs.openjdk.java.net/browse/JDK-8048624 Webrev: http://cr.openjdk.java.net/~rhalade/8048624/webrev/ Thanks, Rajan From artem.smotrakov at oracle.com Fri Jul 17 23:30:09 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 17 Jul 2015 16:30:09 -0700 Subject: [9] RFR: 8075297: Tests for RFEs 4515853 and 4745056 In-Reply-To: <55A98D9D.5080001@oracle.com> References: <55A7433F.7060306@oracle.com> <55A763D5.3010809@oracle.com> <55A81C9B.3040904@oracle.com> <55A85825.5000302@oracle.com> <55A888DD.9020209@oracle.com> <55A9408C.1040502@oracle.com> <55A98D9D.5080001@oracle.com> Message-ID: <55A99001.6060406@oracle.com> Hi Max, Yes, it is possible to write it manually, but content of krb5 file should be like the following: [libdefaults] default_realm = TEST.REALM max_retries = 1 [realms] TEST.REALM = { kdc = localhost: 12345 } Then, the test overrides kdc/realm with system properties. But finally at line 103 it re-load krb5 config file and reads kdc/realm from there. I would prefer to re-use existing KDC.saveConfig(). It is just shorter. Artem On 07/17/2015 04:19 PM, Weijun Wang wrote: > Although the java.security.krb5.kdc/realm system properties are able > to override the values inside krb5.conf, it is better to write one > without realm/kdc info at all. So, instead of > > 60 KDC.saveConfig(KRB5_CONF_FILENAME, kdc, "max_retries = 1"); > > How about just manually write > > Files.write(Paths.get(KRB5_CONF_FILENAME), Arrays.asList( > "[libdefaults]", > "max_retries = 1")); > > --Max > > > On 07/18/2015 01:51 AM, Artem Smotrakov wrote: >> Hi Max, >> >> Please see an updated webrev: >> >> http://cr.openjdk.java.net/~asmotrak/8075297/webrev.03/ >> >> Artem >> >> On 07/16/2015 11:31 PM, Wang Weijun wrote: >>>> I think it it enough to add a "max_retries = 1" to [libdefaults] of >>>> krb5.conf, and left default timeout value for the test. Please take a >>>> look at updated webrev: >>>> >>>> http://cr.openjdk.java.net/~asmotrak/8075297/webrev.02/ >>> Can you also add the same line to the krb5.conf for the other test? >>> >>> Thanks >>> Max >> From weijun.wang at oracle.com Fri Jul 17 23:49:34 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 18 Jul 2015 07:49:34 +0800 Subject: [9] RFR: 8075297: Tests for RFEs 4515853 and 4745056 In-Reply-To: <55A99001.6060406@oracle.com> References: <55A7433F.7060306@oracle.com> <55A763D5.3010809@oracle.com> <55A81C9B.3040904@oracle.com> <55A85825.5000302@oracle.com> <55A888DD.9020209@oracle.com> <55A9408C.1040502@oracle.com> <55A98D9D.5080001@oracle.com> <55A99001.6060406@oracle.com> Message-ID: <55A9948E.3030604@oracle.com> Oh, I didn't see you clear the properties. I thought you reassign correct ones still using system properties. Sorry. Then there is nothing wrong. Thanks Max On 07/18/2015 07:30 AM, Artem Smotrakov wrote: > Hi Max, > > Yes, it is possible to write it manually, but content of krb5 file > should be like the following: > > [libdefaults] > default_realm = TEST.REALM > max_retries = 1 > > [realms] > TEST.REALM = { > kdc = localhost: 12345 > } > > Then, the test overrides kdc/realm with system properties. But finally > at line 103 it re-load krb5 config file and reads kdc/realm from there. > > I would prefer to re-use existing KDC.saveConfig(). It is just shorter. > > Artem > > On 07/17/2015 04:19 PM, Weijun Wang wrote: >> Although the java.security.krb5.kdc/realm system properties are able >> to override the values inside krb5.conf, it is better to write one >> without realm/kdc info at all. So, instead of >> >> 60 KDC.saveConfig(KRB5_CONF_FILENAME, kdc, "max_retries = 1"); >> >> How about just manually write >> >> Files.write(Paths.get(KRB5_CONF_FILENAME), Arrays.asList( >> "[libdefaults]", >> "max_retries = 1")); >> >> --Max >> >> >> On 07/18/2015 01:51 AM, Artem Smotrakov wrote: >>> Hi Max, >>> >>> Please see an updated webrev: >>> >>> http://cr.openjdk.java.net/~asmotrak/8075297/webrev.03/ >>> >>> Artem >>> >>> On 07/16/2015 11:31 PM, Wang Weijun wrote: >>>>> I think it it enough to add a "max_retries = 1" to [libdefaults] of >>>>> krb5.conf, and left default timeout value for the test. Please take a >>>>> look at updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~asmotrak/8075297/webrev.02/ >>>> Can you also add the same line to the krb5.conf for the other test? >>>> >>>> Thanks >>>> Max >>> > From weijun.wang at oracle.com Sat Jul 18 00:00:46 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 18 Jul 2015 08:00:46 +0800 Subject: RFR: JDK-8131486 : SecureClassLoader key for ProtectionDomain cache also needs to take into account certificates In-Reply-To: <55A97456.2070708@oracle.com> References: <55A97456.2070708@oracle.com> Message-ID: <55A9972E.4000309@oracle.com> The change looks fine. That said, is CodeSource's hashCode/equals used somewhere else? I mean, can we directly update them? Thanks Max On 07/18/2015 05:32 AM, Sean Mullan wrote: > One of the changesets for JEP 232 (Improve Secure Application > Performance) introduced a regression in the ProtectionDomain cache used > by SecureClassLoader. The HashMap key needs to also check the > Certificates of the CodeSource (as well as the location); otherwise 2 > CodeSources from the same location but with different signers can > resolve to the same ProtectionDomain. > > The existing regression test has also been updated to test this case. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8131486/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8131486 > > Thanks, > Sean From weijun.wang at oracle.com Sat Jul 18 00:26:21 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 18 Jul 2015 08:26:21 +0800 Subject: RFR 8131350: policytool can directly reference permission classes In-Reply-To: <55A7B4F2.5020306@oracle.com> References: <55A7B4F2.5020306@oracle.com> Message-ID: <55A99D2D.7030607@oracle.com> A new version at http://cr.openjdk.java.net/~weijun/8131350/webrev.01/ "public" modifiers of methods/fields inside Prin/Perm and child classes removed. Thanks Max On 07/16/2015 09:43 PM, Weijun Wang wrote: > Hi All > > Please take a look at > > http://cr.openjdk.java.net/~weijun/8131350/webrev.00/ > > Policytool contains a lot of hard coded strings for permission class > names, which can be changed to actual Class types. That allows checking > at compile-time rather than failing at run-time if any name had a typo. > > Noreg-cleanup. > > Thanks > Max From xuelei.fan at oracle.com Sat Jul 18 23:56:21 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 19 Jul 2015 07:56:21 +0800 Subject: [Update]: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <55935395.7060907@oracle.com> References: <558361E0.2060409@oracle.com> <558EBBF7.3010805@oracle.com> <5592658D.5090004@oracle.com> <55931A9A.9080003@oracle.com> <55933C87.9040000@oracle.com> <55934A27.2010709@oracle.com> <55935395.7060907@oracle.com> Message-ID: <55AAE7A5.3090803@oracle.com> In the new webrev, you try the approach to throw exceptions CertificateStatus constructor and catch it in ServerHandshaker. It is a kind a abuse of SSLHandshakeException. I would like to make the checking before construct CertificateStatus in ServerHandshaker. It's really hard to understand the code. When I find a SSLHandshakeException, firstly, I think the connection would be terminated. But actually the handshaking can continue. It's not easy to understand the code. You can file a new bug and make the update later. Xuelei On 7/1/2015 10:42 AM, Xuelei Fan wrote: > On 7/1/2015 10:02 AM, Jamil Nimeh wrote: >> >> >> On 06/30/2015 06:04 PM, Xuelei Fan wrote: >>> On 7/1/2015 6:39 AM, Jamil Nimeh wrote: >>>>> src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java >>>>> ================================================================== >>>>> line 713/714, 730/731 throws SSLHandshakeException for extension >>>>> constructor in server side. That's unlikely to happen, I think. I was >>>>> wondering, if CertificateStatus cannot be constructed, the server may >>>>> not want to send the message, rather than terminate the connection >>>>> immediately. >>>> I think you're right. While the exception is unlikely, I'd like to have >>>> the HandshakeMessage throw the exception if something bad happens. I do >>>> however, agree that we shouldn't make it a fatal error. I'll catch the >>>> exception in ServerHandshaker, log it, and just not send the message as >>>> you suggested since that is legal. OK? >>> I have not read the server side implementation. I would like firstly >>> check whether the message should be delivered, and than new the >>> instance. Exception catching is not performance friendly, and looks a >>> little bit not-straightforward. I think you may want a static method >>> for the validity checking in CertificateStatus class, instead. >> As it is written today, the ServerHandshaker will only create a new >> CertificateStatus instance if the following is true: >> >> * Stapling has already been activated in the server (meaning that the >> client requested it and the server has the feature enabled) >> * A "get" operation was done from the StatusResponseManager and at >> least one OCSP response was returned. In other words, if no >> responses can be brought back from the SRM, then there's no point in >> even asserting status_request[_v2] in the ServerHello. >> >> I don't see the advantage of making a static method that does what is >> already accomplished in two lines of code in ServerHandshaker (873-4). >> > Good you can accomplish it in ServerHandshaker. > >>> >>> It's OK to throw exception if something bad happens. For easy reading, >>> please have a comment that it is unlikely to happen if you keep the >>> throw exception blocks. >> Okay, I can definitely do that. There are some cases where I think we >> need to throw an exception, particularly on the constructor from a >> HandshakeInStream. > It's the expected behavior to throw exception for reading issues. What > we are talking about previously is for write side constructor. > > Thanks, > Xuelei > >> That's a case where we want the client to Alert if >> the server asserts some weird/unsupported/illegal type or does something >> like type = ocsp and a zero length response (also illegal according to >> the spec). Zero length responses are OK for ocsp_multi, though. >> > From xuelei.fan at oracle.com Sun Jul 19 00:41:40 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 19 Jul 2015 08:41:40 +0800 Subject: Fwd: Re: Update: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <55A95539.6090804@oracle.com> References: <55A82814.5060400@oracle.com> <55A95539.6090804@oracle.com> Message-ID: <55AAF244.3030606@oracle.com> Hi Jamil, Looks fine to me. Maybe, a few implementation issues still need to be addressed, it's OK to me if they get addressed in JDK 9 later in new bugs. Thank you! Thanks, Xuelei On 7/18/2015 3:19 AM, Jamil Nimeh wrote: > Sorry for not being explicit about the changes that went into webrev.2, > but I've listed them below: > > * The StatusResponseManager to do cache checking from the main thread > rather than a worker thread > * A fix in ServerHandshaker's selection of the CertStatusReqItemV2 > where I wasn't properly picking the first instance of an item type > of "ocsp" (as opposed to ocsp_multi, which always get the first > instance). Type ocsp_multi will still supersede ocsp types, however. > * A spec change to ExtendedSSLSession.getStatusResponses() to clarify > the meaning of zero-length byte arrays in the returned list. > > http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.2 > > Thanks, > --Jamil > >> >> On 07/11/2015 02:16 PM, Jamil Nimeh wrote: >>> Hello all, >>> >>> I have an updated webrev for OCSP stapling which incorporates comments >>> thus far and a few bug fixes and tests. >>> >>> webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.2 >>> JEP: https://bugs.openjdk.java.net/browse/JDK-8046321 >>> >>> Thanks, >>> --Jamil > > > From jamil.j.nimeh at oracle.com Sun Jul 19 14:57:41 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Sun, 19 Jul 2015 07:57:41 -0700 Subject: [Update]: JEP 249 (OCSP Stapling for TLS) In-Reply-To: <55AAE7A5.3090803@oracle.com> References: <558361E0.2060409@oracle.com> <558EBBF7.3010805@oracle.com> <5592658D.5090004@oracle.com> <55931A9A.9080003@oracle.com> <55933C87.9040000@oracle.com> <55934A27.2010709@oracle.com> <55935395.7060907@oracle.com> <55AAE7A5.3090803@oracle.com> Message-ID: <55ABBAE5.5000703@oracle.com> On 07/18/2015 04:56 PM, Xuelei Fan wrote: > In the new webrev, you try the approach to throw exceptions > CertificateStatus constructor and catch it in ServerHandshaker. It is a > kind a abuse of SSLHandshakeException. I would like to make the > checking before construct CertificateStatus in ServerHandshaker. It's > really hard to understand the code. When I find a > SSLHandshakeException, firstly, I think the connection would be > terminated. But actually the handshaking can continue. It's not easy > to understand the code. What you're saying makes sense. I can make that change. If it is a quick change I'll get it out before the weekend is over, otherwise I'll file the bug as you mentioned. > You can file a new bug and make the update later. > > Xuelei > > On 7/1/2015 10:42 AM, Xuelei Fan wrote: >> On 7/1/2015 10:02 AM, Jamil Nimeh wrote: >>> >>> On 06/30/2015 06:04 PM, Xuelei Fan wrote: >>>> On 7/1/2015 6:39 AM, Jamil Nimeh wrote: >>>>>> src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java >>>>>> ================================================================== >>>>>> line 713/714, 730/731 throws SSLHandshakeException for extension >>>>>> constructor in server side. That's unlikely to happen, I think. I was >>>>>> wondering, if CertificateStatus cannot be constructed, the server may >>>>>> not want to send the message, rather than terminate the connection >>>>>> immediately. >>>>> I think you're right. While the exception is unlikely, I'd like to have >>>>> the HandshakeMessage throw the exception if something bad happens. I do >>>>> however, agree that we shouldn't make it a fatal error. I'll catch the >>>>> exception in ServerHandshaker, log it, and just not send the message as >>>>> you suggested since that is legal. OK? >>>> I have not read the server side implementation. I would like firstly >>>> check whether the message should be delivered, and than new the >>>> instance. Exception catching is not performance friendly, and looks a >>>> little bit not-straightforward. I think you may want a static method >>>> for the validity checking in CertificateStatus class, instead. >>> As it is written today, the ServerHandshaker will only create a new >>> CertificateStatus instance if the following is true: >>> >>> * Stapling has already been activated in the server (meaning that the >>> client requested it and the server has the feature enabled) >>> * A "get" operation was done from the StatusResponseManager and at >>> least one OCSP response was returned. In other words, if no >>> responses can be brought back from the SRM, then there's no point in >>> even asserting status_request[_v2] in the ServerHello. >>> >>> I don't see the advantage of making a static method that does what is >>> already accomplished in two lines of code in ServerHandshaker (873-4). >>> >> Good you can accomplish it in ServerHandshaker. >> >>>> It's OK to throw exception if something bad happens. For easy reading, >>>> please have a comment that it is unlikely to happen if you keep the >>>> throw exception blocks. >>> Okay, I can definitely do that. There are some cases where I think we >>> need to throw an exception, particularly on the constructor from a >>> HandshakeInStream. >> It's the expected behavior to throw exception for reading issues. What >> we are talking about previously is for write side constructor. >> >> Thanks, >> Xuelei >> >>> That's a case where we want the client to Alert if >>> the server asserts some weird/unsupported/illegal type or does something >>> like type = ocsp and a zero length response (also illegal according to >>> the spec). Zero length responses are OK for ocsp_multi, though. >>> From sean.mullan at oracle.com Sun Jul 19 23:37:03 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Sun, 19 Jul 2015 19:37:03 -0400 Subject: RFR: JDK-8131486 : SecureClassLoader key for ProtectionDomain cache also needs to take into account certificates In-Reply-To: <55A9972E.4000309@oracle.com> References: <55A97456.2070708@oracle.com> <55A9972E.4000309@oracle.com> Message-ID: <55AC349F.8010509@oracle.com> On 07/17/2015 08:00 PM, Weijun Wang wrote: > The change looks fine. > > That said, is CodeSource's hashCode/equals used somewhere else? I mean, > can we directly update them? It might affect third party policy providers. We would also need to update the CodeSource.equals specification. I think it is something to think about for later on though. --Sean > > Thanks > Max > > On 07/18/2015 05:32 AM, Sean Mullan wrote: >> One of the changesets for JEP 232 (Improve Secure Application >> Performance) introduced a regression in the ProtectionDomain cache used >> by SecureClassLoader. The HashMap key needs to also check the >> Certificates of the CodeSource (as well as the location); otherwise 2 >> CodeSources from the same location but with different signers can >> resolve to the same ProtectionDomain. >> >> The existing regression test has also been updated to test this case. >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8131486/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8131486 >> >> Thanks, >> Sean From weijun.wang at oracle.com Mon Jul 20 05:22:08 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 20 Jul 2015 13:22:08 +0800 Subject: RFR: JDK-8131486 : SecureClassLoader key for ProtectionDomain cache also needs to take into account certificates In-Reply-To: <55AC349F.8010509@oracle.com> References: <55A97456.2070708@oracle.com> <55A9972E.4000309@oracle.com> <55AC349F.8010509@oracle.com> Message-ID: <55AC8580.4030900@oracle.com> On 07/20/2015 07:37 AM, Sean Mullan wrote: > On 07/17/2015 08:00 PM, Weijun Wang wrote: >> The change looks fine. >> >> That said, is CodeSource's hashCode/equals used somewhere else? I mean, >> can we directly update them? > > It might affect third party policy providers. We would also need to > update the CodeSource.equals specification. I think it is something to > think about for later on though. I see. Thanks Max > > --Sean > >> >> Thanks >> Max >>>>> >>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8131486/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8131486 >>> >>> Thanks, >>> Sean From weijun.wang at oracle.com Mon Jul 20 06:03:32 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 20 Jul 2015 14:03:32 +0800 Subject: RFR 8131350: policytool can directly reference permission classes In-Reply-To: <55A99D2D.7030607@oracle.com> References: <55A7B4F2.5020306@oracle.com> <55A99D2D.7030607@oracle.com> Message-ID: <55AC8F34.9060107@oracle.com> Ping again. Also, this change is needed inside jdk9/dev: diff --git a/modules.xml b/modules.xml --- a/modules.xml +++ b/modules.xml @@ -1777,6 +1777,11 @@ jdk.policytool java.base java.desktop + java.logging + java.management + java.security.jgss + java.sql + jdk.security.jgss jdk.rmic Thanks Max On 07/18/2015 08:26 AM, Weijun Wang wrote: > A new version at > > http://cr.openjdk.java.net/~weijun/8131350/webrev.01/ > > "public" modifiers of methods/fields inside Prin/Perm and child classes > removed. > > Thanks > Max > > On 07/16/2015 09:43 PM, Weijun Wang wrote: >> Hi All >> >> Please take a look at >> >> http://cr.openjdk.java.net/~weijun/8131350/webrev.00/ >> >> Policytool contains a lot of hard coded strings for permission class >> names, which can be changed to actual Class types. That allows checking >> at compile-time rather than failing at run-time if any name had a typo. >> >> Noreg-cleanup. >> >> Thanks >> Max From xuelei.fan at oracle.com Mon Jul 20 11:48:27 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 20 Jul 2015 19:48:27 +0800 Subject: RFR 8131350: policytool can directly reference permission classes In-Reply-To: <55AC8F34.9060107@oracle.com> References: <55A7B4F2.5020306@oracle.com> <55A99D2D.7030607@oracle.com> <55AC8F34.9060107@oracle.com> Message-ID: <55ACE00B.3070702@oracle.com> Looks fine to me. Xuelei On 7/20/2015 2:03 PM, Weijun Wang wrote: > Ping again. > > Also, this change is needed inside jdk9/dev: > > diff --git a/modules.xml b/modules.xml > --- a/modules.xml > +++ b/modules.xml > @@ -1777,6 +1777,11 @@ > jdk.policytool > java.base > java.desktop > + java.logging > + java.management > + java.security.jgss > + java.sql > + jdk.security.jgss > > > jdk.rmic > > Thanks > Max > > On 07/18/2015 08:26 AM, Weijun Wang wrote: >> A new version at >> >> http://cr.openjdk.java.net/~weijun/8131350/webrev.01/ >> >> "public" modifiers of methods/fields inside Prin/Perm and child classes >> removed. >> >> Thanks >> Max >> >> On 07/16/2015 09:43 PM, Weijun Wang wrote: >>> Hi All >>> >>> Please take a look at >>> >>> http://cr.openjdk.java.net/~weijun/8131350/webrev.00/ >>> >>> Policytool contains a lot of hard coded strings for permission class >>> names, which can be changed to actual Class types. That allows checking >>> at compile-time rather than failing at run-time if any name had a typo. >>> >>> Noreg-cleanup. >>> >>> Thanks >>> Max From iris.clark at oracle.com Mon Jul 20 17:01:01 2015 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 20 Jul 2015 10:01:01 -0700 (PDT) Subject: RFR: (s) 8130696: Security Providers need to have their version numbers updated for JDK 9 In-Reply-To: <<201507201641.t6KGfBXi011482@aojmv0008.oracle.com>> References: <<201507201641.t6KGfBXi011482@aojmv0008.oracle.com>> Message-ID: <75000e81-28de-44d2-8a20-9a71e38a80f0@default> Hi, Anthony, Brad, Max, Sean, and Valerie. Just a quick thanks to all for your time in reviewing this issue. I pushed the changeset this morning to verona/stage. Expect the changeset to get to jdk9/* when we Verona is complete, later this summer. Regards, iris -----Original Message----- From: verona-dev [mailto:verona-dev-bounces at openjdk.java.net] On Behalf Of iris.clark at oracle.com Sent: Monday, July 20, 2015 9:41 AM To: verona-dev at openjdk.java.net Subject: hg: verona/stage/jdk: 8130696: Security Providers need to have their version numbers updated for JDK 9 Changeset: 165608bfa113 Author: iris Date: 2015-07-20 09:40 -0700 URL: http://hg.openjdk.java.net/verona/stage/jdk/rev/165608bfa113 8130696: Security Providers need to have their version numbers updated for JDK 9 Reviewed-by: ascarpino, mullan, valeriep, weijun, wetmore ! src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java ! src/java.base/share/classes/sun/security/provider/MD4.java ! src/java.base/share/classes/sun/security/provider/Sun.java ! src/java.base/share/classes/sun/security/provider/VerificationProvider.java ! src/java.base/share/classes/sun/security/rsa/SunRsaSign.java ! src/java.base/share/classes/sun/security/ssl/JsseJce.java ! src/java.base/share/classes/sun/security/ssl/SunJSSE.java ! src/java.naming/share/classes/sun/security/provider/certpath/ldap/JdkLDAP.java ! src/java.security.jgss/share/classes/sun/security/jgss/SunProvider.java ! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java ! src/java.security.sasl/share/classes/com/sun/security/sasl/Provider.java ! src/java.smartcardio/share/classes/sun/security/smartcardio/SunPCSC.java ! src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java ! src/jdk.crypto.ec/share/classes/sun/security/ec/SunEC.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/SunMSCAPI.java ! src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/jdk.crypto.ucrypto/solaris/classes/com/oracle/security/ucrypto/UcryptoProvider.java ! src/jdk.deploy.osx/macosx/classes/apple/security/AppleProvider.java ! src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/JdkSASL.java ! test/java/security/Provider/ProviderVersionCheck.java ! test/sun/security/util/Oid/S11N.java From valerie.peng at oracle.com Mon Jul 20 21:19:41 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 20 Jul 2015 14:19:41 -0700 Subject: [9] RFR: 8048596: Tests for AEAD ciphers In-Reply-To: <55A024B8.2030602@oracle.com> References: <55A024B8.2030602@oracle.com> Message-ID: <55AD65EC.5000104@oracle.com> Hi Artem, Just some nit (see below). In general, I find the tests don't need to use so many random bytes. If we don't need RandomFactory, then no dependence on jdk.testlibrary. Make things easier to execute the test on its own if necessary. Just something to keep in mind for future test development. - line 186: typo in "intiate". I think you mean initiate the cipher without parameters? I don't see how the parameters are saved here. - line 190: I think either "generated" or "specified" is better than "saved". - line 117: template not reporting key length? - line 219: getInstance with "SunJCE"? - line 110: this check can be done earlier, e.g. on line 108. Thanks, Valerie On 7/10/2015 1:02 PM, Artem Smotrakov wrote: > Hello, > > Please review a couple of new tests for AEAD ciphers. > > Webrev: http://cr.openjdk.java.net/~asmotrak/8048596/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8048596 > > Artem From artem.smotrakov at oracle.com Tue Jul 21 06:33:05 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 21 Jul 2015 09:33:05 +0300 Subject: [9] RFR: 8048596: Tests for AEAD ciphers In-Reply-To: <55AD65EC.5000104@oracle.com> References: <55A024B8.2030602@oracle.com> <55AD65EC.5000104@oracle.com> Message-ID: <55ADE7A1.9070804@oracle.com> Hi Valerie, The tests can easily get data in one line with RandomFacroty. But they can use static data that may be created with something like the following: public class Helper { public static byte[] generateBytes(int length) { byte[] bytes = new byte[length]; for (int i=0; i Hi Artem, > > Just some nit (see below). In general, I find the tests don't need to > use so many random bytes. If we don't need RandomFactory, then no > dependence on jdk.testlibrary. Make things easier to execute the test > on its own if necessary. Just something to keep in mind for future > test development. > > > - line 186: typo in "intiate". I think you mean initiate the cipher > without parameters? I don't see how the parameters are saved here. > - line 190: I think either "generated" or "specified" is better than > "saved". > > > - line 117: template not reporting key length? > - line 219: getInstance with "SunJCE"? > > > - line 110: this check can be done earlier, e.g. on line 108. > > Thanks, > Valerie > > On 7/10/2015 1:02 PM, Artem Smotrakov wrote: >> Hello, >> >> Please review a couple of new tests for AEAD ciphers. >> >> Webrev: http://cr.openjdk.java.net/~asmotrak/8048596/webrev.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8048596 >> >> Artem From weijun.wang at oracle.com Tue Jul 21 08:12:08 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 21 Jul 2015 16:12:08 +0800 Subject: RFR 8131051: KDC might issue a renewable ticket even if not requested In-Reply-To: <55A380E5.3080309@oracle.com> References: <55A380E5.3080309@oracle.com> Message-ID: <55ADFED8.9080100@oracle.com> Ping again. Basically, Java currently requires the renewable flag of a ticket to be identical to the renewable flag in the request, and thus rejects the following legal case: - Client requests for a non-renewable ticket with a lifetime of 2 days - KDC thinks 2 days is too long, instead, it issues a ticket with a lifetime of 10 hours, but makes it renewable with 2 days Thanks Max On 07/13/2015 05:12 PM, Weijun Wang wrote: > Hi All > > Please take a look at the fix at > > http://cr.openjdk.java.net/~weijun/8131051/webrev.00/ > > When a ticket request has a ticket_lifetime that the KDC considers too > long it will issue a renewable ticket with a shorter lifetime. > Unfortunately, JDK does not accept this. > > Thanks > Max From xuelei.fan at oracle.com Tue Jul 21 08:36:14 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 21 Jul 2015 16:36:14 +0800 Subject: RFR 8131051: KDC might issue a renewable ticket even if not requested In-Reply-To: <55ADFED8.9080100@oracle.com> References: <55A380E5.3080309@oracle.com> <55ADFED8.9080100@oracle.com> Message-ID: <55AE047E.9030407@oracle.com> Looks fine to me. Hm, it's an interesting behavior of KDC. Xuelei On 7/21/2015 4:12 PM, Weijun Wang wrote: > Ping again. > > Basically, Java currently requires the renewable flag of a ticket to be > identical to the renewable flag in the request, and thus rejects the > following legal case: > > - Client requests for a non-renewable ticket with a lifetime of 2 days > > - KDC thinks 2 days is too long, instead, it issues a ticket with a > lifetime of 10 hours, but makes it renewable with 2 days > > Thanks > Max > > > On 07/13/2015 05:12 PM, Weijun Wang wrote: >> Hi All >> >> Please take a look at the fix at >> >> http://cr.openjdk.java.net/~weijun/8131051/webrev.00/ >> >> When a ticket request has a ticket_lifetime that the KDC considers too >> long it will issue a renewable ticket with a shorter lifetime. >> Unfortunately, JDK does not accept this. >> >> Thanks >> Max From valerie.peng at oracle.com Wed Jul 22 00:03:22 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 21 Jul 2015 17:03:22 -0700 Subject: RFR 8130648: JCK test api/java_security/AuthProvider/ProviderTests_login starts failing after JDK-7191662 Message-ID: <55AEDDCA.9010202@oracle.com> Anyone can help review this? As part of 7191662, the default SunPKCS11 provider (without configuration) is created by default for non-Solaris systems. This is to help runtime configuration of custom PKCS11 providers. However, given that SunPKCS11 extends AuthProvider, JCK test would expect the default PKCS11 provider to be able to login/logout. Thus, I have to refactor the code so that the default SunPKCS11 provider does not extend AuthProvider and will be skipped by JCK test when testing AuthProvider APIs. The two regression tests are just test clean up. Since it's already covered by JCK test, I didn't add regression test. Webrev: http://cr.openjdk.java.net/~valeriep/8130648/webrev.00/ Thanks, Valerie From weijun.wang at oracle.com Wed Jul 22 03:22:46 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 22 Jul 2015 11:22:46 +0800 Subject: RFR 8132111: Do not request for addresses for forwarded TGT Message-ID: <55AF0C86.7020708@oracle.com> Hi All Please review the code change at http://cr.openjdk.java.net/~weijun/8132111/webrev.00/ Java Kerberos was designed to provide the addresses of a service when requesting for a forwarded TGT. However, the field was never filled, because of a bug that the service principal does not have the KRB_NT_SRV_HST nameType. (It has always been KRB_NT_UNKNOWN). In JDK-8031111, we "fixed" this and the addresses field is now always sent. However, it is well known in the Kerberos community that it's difficult to get the correct addresses. For example, the service and the client might be inside a NAT but the KDC is not. If the addresses observed by the client and the KDC are different, such a ticket will be rejected when the service is trying to use it. For this reason, other krb5 vendors do not use the addresses field in a forwarded TGT request. We will remove it in this fix. This is also the actual behavior of Java before JDK-8031111. Thanks Max From rajan.halade at oracle.com Wed Jul 22 06:49:20 2015 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 21 Jul 2015 23:49:20 -0700 Subject: [9] RFR: 8130031: Remove the intermittent keyword for this test Message-ID: <55AF3CF0.60206@oracle.com> Please help me with your review for this one line fix to remove intermittent keyword. The test is pretty stable now. Bug: https://bugs.openjdk.java.net/browse/JDK-8130031 Webrev: http://cr.openjdk.java.net/~rhalade/8130031/webrev.00/ Thanks, Rajan From xuelei.fan at oracle.com Wed Jul 22 07:11:02 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 22 Jul 2015 15:11:02 +0800 Subject: [9] RFR: 8130031: Remove the intermittent keyword for this test In-Reply-To: <55AF3CF0.60206@oracle.com> References: <55AF3CF0.60206@oracle.com> Message-ID: <55AF4206.3010100@oracle.com> ok. Xuelei On 7/22/2015 2:49 PM, Rajan Halade wrote: > Please help me with your review for this one line fix to remove > intermittent keyword. The test is pretty stable now. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8130031 > Webrev: http://cr.openjdk.java.net/~rhalade/8130031/webrev.00/ > > Thanks, > Rajan From alexander.v.stepanov at oracle.com Wed Jul 22 13:51:42 2015 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Wed, 22 Jul 2015 16:51:42 +0300 Subject: RFR [9] 8132130: some docs cleanup Message-ID: <55AF9FEE.40107@oracle.com> Hello, Could you please review the following fix http://cr.openjdk.java.net/~avstepan/8132130/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8132130 Just some docs cleanup (fix invalid tags, parameter names, remove obsolete

tags) Thanks, Alexander From valerie.peng at oracle.com Wed Jul 22 20:36:36 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 22 Jul 2015 13:36:36 -0700 Subject: [9] RFR: 8048596: Tests for AEAD ciphers In-Reply-To: <55ADE7A1.9070804@oracle.com> References: <55A024B8.2030602@oracle.com> <55AD65EC.5000104@oracle.com> <55ADE7A1.9070804@oracle.com> Message-ID: <55AFFED4.3090203@oracle.com> Yeah, many ways to generate bytes. It's generally ok to just re-use the same input for various test scenarios in the same test class. As far as I am concerned, the benefit of get data in one line doesn't quite justify the extra dependency. The updated webrev looks fine. Valerie On 7/20/2015 11:33 PM, Artem Smotrakov wrote: > Hi Valerie, > > The tests can easily get data in one line with RandomFacroty. But they > can use static data that may be created with something like the > following: > > public class Helper { > > public static byte[] generateBytes(int length) { > byte[] bytes = new byte[length]; > for (int i=0; i<length; i++) { > bytes[i] = (byte) (i % 256); > } > return bytes; > } > } > > Please take a look an updated webrev: > > http://cr.openjdk.java.net/~asmotrak/8048596/webrev.02/ > > Artem > > On 07/21/2015 12:19 AM, Valerie Peng wrote: >> Hi Artem, >> >> Just some nit (see below). In general, I find the tests don't need to >> use so many random bytes. If we don't need RandomFactory, then no >> dependence on jdk.testlibrary. Make things easier to execute the test >> on its own if necessary. Just something to keep in mind for future >> test development. >> >> <Encrypt.java> >> - line 186: typo in "intiate". I think you mean initiate the cipher >> without parameters? I don't see how the parameters are saved here. >> - line 190: I think either "generated" or "specified" is better than >> "saved". >> >> <GCMParameterSpecTest.java> >> - line 117: template not reporting key length? >> - line 219: getInstance with "SunJCE"? >> >> <SameBuffer.java> >> - line 110: this check can be done earlier, e.g. on line 108. >> >> Thanks, >> Valerie >> >> On 7/10/2015 1:02 PM, Artem Smotrakov wrote: >>> Hello, >>> >>> Please review a couple of new tests for AEAD ciphers. >>> >>> Webrev: http://cr.openjdk.java.net/~asmotrak/8048596/webrev.01/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048596 >>> >>> Artem > From valerie.peng at oracle.com Thu Jul 23 21:20:45 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 23 Jul 2015 14:20:45 -0700 Subject: [9] RFR: 8048624: Tests for SealedObject In-Reply-To: <55A98E0F.7040409@oracle.com> References: <55A98E0F.7040409@oracle.com> Message-ID: <55B15AAD.6040108@oracle.com> <TestSealedObject.java> - I think it's more universal to call getParameters() instead of getIV(). Otherwise, if the test is enhanced with GCM mode, it will not work. - Certain combination of mode and padding require certain input length. With SealedObject, the input to the Cipher object is the "serialized" bytes. Otherwise, IllegalBlockSizeException will be thrown. If the test coverage is about SealedObject code, we don't need these many different combinations. What is the aim for coverage here? - DES, DESede and Blowfish and no AES? Note that AES block size is 16 bytes, so the current input will need to be adjusted. Currently, the serialized form is 24 bytes. You need to bump it up to at least 32 bytes to avoid IllegalBlockSizeException. <TestSealedObjectNull.java> - This is not really testing NullCipher. If you replace NullCipher with any other cipher, this test would still pass. - Well, in reality, no one will ever use SealedObject with NullCipher, I can't think of a reason to. I wonder if anyone actually uses NullCipher. What is the purpose of this test? Thanks, Valerie On 7/17/2015 4:21 PM, Rajan Halade wrote: > May I request you to review two new tests added to check SealedObject > with different ciphers. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8048624 > Webrev: http://cr.openjdk.java.net/~rhalade/8048624/webrev/ > > Thanks, > Rajan From artem.smotrakov at oracle.com Fri Jul 24 10:15:07 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 24 Jul 2015 13:15:07 +0300 Subject: [9] RFR: 8048596: Tests for AEAD ciphers In-Reply-To: <55AFFED4.3090203@oracle.com> References: <55A024B8.2030602@oracle.com> <55AD65EC.5000104@oracle.com> <55ADE7A1.9070804@oracle.com> <55AFFED4.3090203@oracle.com> Message-ID: <55B2102B.4020308@oracle.com> Hi Valerie, I thought about random data again. I agree that it doesn't make much difference if random data is used instead of static one. And as a result, in this case 'randomness' key may be confusing (someone may want to filter out tests which use random data for some reason). I updated the tests not to use random data: - removed dependency on RandomFactory - removed 'randomness' tag Please take a look: http://cr.openjdk.java.net/~asmotrak/8048596/webrev.03/ Artem On 07/22/2015 11:36 PM, Valerie Peng wrote: > > Yeah, many ways to generate bytes. It's generally ok to just re-use > the same input for various test scenarios in the same test class. > As far as I am concerned, the benefit of get data in one line doesn't > quite justify the extra dependency. > > The updated webrev looks fine. > Valerie > > On 7/20/2015 11:33 PM, Artem Smotrakov wrote: >> Hi Valerie, >> >> The tests can easily get data in one line with RandomFacroty. But >> they can use static data that may be created with something like the >> following: >> >> public class Helper { >> >> public static byte[] generateBytes(int length) { >> byte[] bytes = new byte[length]; >> for (int i=0; i<length; i++) { >> bytes[i] = (byte) (i % 256); >> } >> return bytes; >> } >> } >> >> Please take a look an updated webrev: >> >> http://cr.openjdk.java.net/~asmotrak/8048596/webrev.02/ >> >> Artem >> >> On 07/21/2015 12:19 AM, Valerie Peng wrote: >>> Hi Artem, >>> >>> Just some nit (see below). In general, I find the tests don't need >>> to use so many random bytes. If we don't need RandomFactory, then no >>> dependence on jdk.testlibrary. Make things easier to execute the >>> test on its own if necessary. Just something to keep in mind for >>> future test development. >>> >>> <Encrypt.java> >>> - line 186: typo in "intiate". I think you mean initiate the cipher >>> without parameters? I don't see how the parameters are saved here. >>> - line 190: I think either "generated" or "specified" is better than >>> "saved". >>> >>> <GCMParameterSpecTest.java> >>> - line 117: template not reporting key length? >>> - line 219: getInstance with "SunJCE"? >>> >>> <SameBuffer.java> >>> - line 110: this check can be done earlier, e.g. on line 108. >>> >>> Thanks, >>> Valerie >>> >>> On 7/10/2015 1:02 PM, Artem Smotrakov wrote: >>>> Hello, >>>> >>>> Please review a couple of new tests for AEAD ciphers. >>>> >>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8048596/webrev.01/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048596 >>>> >>>> Artem >> From jason.greene at redhat.com Fri Jul 24 19:38:36 2015 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 24 Jul 2015 14:38:36 -0500 Subject: TLS ALPN Proposal v3 In-Reply-To: <559EA925.5010701@oracle.com> References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> <556E9D5C.5040106@oracle.com> <CAFWmRJ12W+_avfF=oBBqxsKimXP50zjPCf7am6x86p_yaGyC3A@mail.gmail.com> <55707475.8060401@oracle.com> <CAFWmRJ3PfacUKrWB=Lpic1Mizgxs+UrMy6PzZLtw5vJ4L=WCXA@mail.gmail.com> <557081BB.5080508@oracle.com> <CAFWmRJ2+P5F4nphpDGx50z1e1KWrc76WQ+vo5CRiTy7KktUJvQ@mail.gmail.com> <5571217A.1070501@oracle.com> <CAFWmRJ3pR=c61Btxg-0EZJkhkpH6ueJ6+Vj1zomACdOE1Aub2Q@mail.gmail.com> <557197C9.5010407@oracle.com> <CAFWmRJ2Js9fram5i-YQ1o3aGMk4wVji-50zcdHsyxMankRkPTw@mail.gmail.com> <5571B645.7050305@oracle.com> <CAFWmRJ0PPJTyh_6Vj+6_sOr+npt+sAL9Stc565KXUFBuSUG4XA@mail.gmail.com> <5571C016.7080909@oracle.com> <559DB583.8060609@oracle.com> <CAFWmRJ0mvGM8DDXxUvJ3ODMg_8yLaH7kq=KQKWWZu6r8TNcB2A@mail.gmail.com> <559EA925.5010701@oracle.com> Message-ID: <C9A8F00E-F143-4A77-9122-5FFD1E0F04F6@redhat.com> > On Jul 9, 2015, at 12:02 PM, Bradford Wetmore <bradford.wetmore at oracle.com> wrote: > > Ok, I'll check with the HTTP/2 group tomorrow. It appears the proper > list is: Hi Brad, Your post to the H2 group got my attention, so I thought as a user of JSSE for an H2 implementation I should reply additionally here. My responses are inline: -snip- > > On 7/9/2015 8:29 AM, Simone Bordet wrote: >> Hi, >> >> On Thu, Jul 9, 2015 at 1:42 AM, Bradford Wetmore >> <bradford.wetmore at oracle.com> wrote: >> >>> Xuelei/Simone wrote: >>>>> Per my understanding, application protocol should be negotiated before >>>>> cipher suite and protocol version negotiated. >>>> >>>> This is not possible for HTTP/2. >>>> Application protocol negotiation MUST happen *after* the TLS protocol >>>> and the TLS cipher are negotiated. >>> >>> Yes, that's my understanding as well. >> >> Well, to be precise, either the application protocol is negotiated >> after the cipher (and you need cipher sorting to influence the cipher >> selection towards the application protocol you would like to choose), >> or it must happen at the same time - that is, cipher and application >> protocol must be chosen at the same time - but this implies that the >> action of choosing that tuple may be invoked multiple times with the >> current OpenJDK implementation. >> >> Note that I don't know if the fact that cipher selection is an >> iterative process is an OpenJDK implementation detail. >> If other implementations are not iterative, then perhaps they have a >> single moment where the tuple is chosen. >> >> I support Xuelei in that you should ask confirmation to the HTTP/2 editor. >> Also, remember that Firefox, Chrome, OpenSSL, nghttp2, etc. are all >> open source and their code is available to verify the behavior. The truth is that there is a gap between the current capabilities of TLS stacks and what the specs are trying to achieve. Ultimately the desired semantic the specs are trying to achieve is that every ALPN protocol can have its own TLS requirements. In this case H2 wanted TLS 1.3 behavior before it was released. This is basically social engineering, the newer protocol is the carrot for updating your TLS stack. However there are other potential scenarios, such as protocols which desire to be encrypted but unauthenticated. To truly resolve this gap in a future proof manner, TLS stacks need to support cipher suite selection based on the combination of ALPN protocol and TLS version. Until then h2 implementations have to rely on both peers sorting, with many clients taking the additional step of post-validating the selected cipher. With NSS this is accomplished using an API that that categorizes cipher aspects (e.g. not a block cipher etc). This approach, which is arguably a hack can lead to interop errors if the administrator has tried to influence cipher suite selection for other reasons. As an example, its quite common to use an abstract indicator (e.g GNU TLS priority strings & openssl cipher strings), and these may inadvertently disable ciphers now required for h2 interop. >> >>> IIUC, the HTTP/2 blacklist is just strongly recommended ("...SHOULD NOT use >>> any of the cipher suites...black list"), but not required. Such potential >>> peers must also support such a configuration, but in general, it will not. >>> See section 9.2.2. I think it's still considered compliant to the spec tho. >> >> From experience, if a server breaks this SHOULD NOT, it won't work >> with any browser. >> We had our share of pain trying to figure out interoperability with >> browsers for Jetty :) >> Sure, it's a SHOULD NOT, but it's like a MUST NOT if you want a >> browser to talk to a Java server (or a Java client to talk to a >> current HTTP/2 server). Yes exactly. Firefox and Chrome enforce the SHOULDs, and if negotiation results in a cipher that violates the SHOULDs you not only fail to establish an h2 connection, you fail to establish any connection at all. >> >>> Simone wrote two different ways to do selection: >>> >>>> 1) ... so that TLS protocol, cipher (possibly the alias too) and >>>> application protocol are chosen together, or >>>> 2) we separate the TLS protocol and >>>> cipher negotiation (and alias) in one step, and we perform application >>>> protocol selection afterwards. >>> >>> Rather than completely redo the JSSE selection mechanism with the >>> (version/ciphersuite/ALPN)-tuple idea (which would be a much more involved >>> API and behavior change), I think the more straightforward solution (2) is >>> better. >> >> That's what we do in Jetty's ALPN implementation too. >> Be aware that it rules out some possibility such as those mentioned by >> Michael from RFC 7301. I?d highly recommend exploring 1) because its quite possible you will end up needing to go that route anyway based on the above reasoning. -snip- >> >>> http://cr.openjdk.java.net/~wetmore/8051498/webrev.04/test/javax/net/ssl/ALPN/SSLEngineAlpnHttp2.java.html >>> >>> See the configuration in createSSLEngines() around line 265 and 280. >>> >>> >>> http://cr.openjdk.java.net/~wetmore/8051498/webrev.04/test/javax/net/ssl/ALPN/Http2ApplicationSelector.java.html >>> >>> Note the HTTP/2 blacklist and reordering code. >>> >>> The code is not actually "working" yet (haven't merged API/impl repos yet), >>> but shows how to configure/use this API. >> >> Just a reminder that the cipher blacklist is only valid for TLS 1.2. >> For example, if the negotiated TLS protocol is 1.3, there is no need >> to look at the ciphers (nor to sort them). Yes, just to restate differently. The h2 requirements are simulating TLS 1.3 over TLS 1.2. The key difference being that TLS stacks are already architected for version directed suite negotiation. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From valerie.peng at oracle.com Fri Jul 24 20:33:09 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 24 Jul 2015 13:33:09 -0700 Subject: [9] RFR: 8048596: Tests for AEAD ciphers In-Reply-To: <55B2102B.4020308@oracle.com> References: <55A024B8.2030602@oracle.com> <55AD65EC.5000104@oracle.com> <55ADE7A1.9070804@oracle.com> <55AFFED4.3090203@oracle.com> <55B2102B.4020308@oracle.com> Message-ID: <55B2A105.4050006@oracle.com> Updated webrev looks good~ Valerie On 7/24/2015 3:15 AM, Artem Smotrakov wrote: > Hi Valerie, > > I thought about random data again. I agree that it doesn't make much > difference if random data is used instead of static one. And as a > result, in this case 'randomness' key may be confusing (someone may > want to filter out tests which use random data for some reason). > > I updated the tests not to use random data: > - removed dependency on RandomFactory > - removed 'randomness' tag > > Please take a look: > > http://cr.openjdk.java.net/~asmotrak/8048596/webrev.03/ > > Artem > > On 07/22/2015 11:36 PM, Valerie Peng wrote: >> >> Yeah, many ways to generate bytes. It's generally ok to just re-use >> the same input for various test scenarios in the same test class. >> As far as I am concerned, the benefit of get data in one line doesn't >> quite justify the extra dependency. >> >> The updated webrev looks fine. >> Valerie >> >> On 7/20/2015 11:33 PM, Artem Smotrakov wrote: >>> Hi Valerie, >>> >>> The tests can easily get data in one line with RandomFacroty. But >>> they can use static data that may be created with something like the >>> following: >>> >>> public class Helper { >>> >>> public static byte[] generateBytes(int length) { >>> byte[] bytes = new byte[length]; >>> for (int i=0; i<length; i++) { >>> bytes[i] = (byte) (i % 256); >>> } >>> return bytes; >>> } >>> } >>> >>> Please take a look an updated webrev: >>> >>> http://cr.openjdk.java.net/~asmotrak/8048596/webrev.02/ >>> >>> Artem >>> >>> On 07/21/2015 12:19 AM, Valerie Peng wrote: >>>> Hi Artem, >>>> >>>> Just some nit (see below). In general, I find the tests don't need >>>> to use so many random bytes. If we don't need RandomFactory, then >>>> no dependence on jdk.testlibrary. Make things easier to execute the >>>> test on its own if necessary. Just something to keep in mind for >>>> future test development. >>>> >>>> <Encrypt.java> >>>> - line 186: typo in "intiate". I think you mean initiate the cipher >>>> without parameters? I don't see how the parameters are saved here. >>>> - line 190: I think either "generated" or "specified" is better >>>> than "saved". >>>> >>>> <GCMParameterSpecTest.java> >>>> - line 117: template not reporting key length? >>>> - line 219: getInstance with "SunJCE"? >>>> >>>> <SameBuffer.java> >>>> - line 110: this check can be done earlier, e.g. on line 108. >>>> >>>> Thanks, >>>> Valerie >>>> >>>> On 7/10/2015 1:02 PM, Artem Smotrakov wrote: >>>>> Hello, >>>>> >>>>> Please review a couple of new tests for AEAD ciphers. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8048596/webrev.01/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048596 >>>>> >>>>> Artem >>> > From ecki at zusammenkunft.net Fri Jul 24 20:39:26 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 24 Jul 2015 22:39:26 +0200 Subject: TLS ALPN Proposal v3 In-Reply-To: <C9A8F00E-F143-4A77-9122-5FFD1E0F04F6@redhat.com> References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> <556E9D5C.5040106@oracle.com> <CAFWmRJ12W+_avfF=oBBqxsKimXP50zjPCf7am6x86p_yaGyC3A@mail.gmail.com> <55707475.8060401@oracle.com> <CAFWmRJ3PfacUKrWB=Lpic1Mizgxs+UrMy6PzZLtw5vJ4L=WCXA@mail.gmail.com> <557081BB.5080508@oracle.com> <CAFWmRJ2+P5F4nphpDGx50z1e1KWrc76WQ+vo5CRiTy7KktUJvQ@mail.gmail.com> <5571217A.1070501@oracle.com> <CAFWmRJ3pR=c61Btxg-0EZJkhkpH6ueJ6+Vj1zomACdOE1Aub2Q@mail.gmail.com> <557197C9.5010407@oracle.com> <CAFWmRJ2Js9fram5i-YQ1o3aGMk4wVji-50zcdHsyxMankRkPTw@mail.gmail.com> <5571B645.7050305@oracle.com> <CAFWmRJ0PPJTyh_6Vj+6_sOr+npt+sAL9Stc565KXUFBuSUG4XA@mail.gmail.com> <5571C016.7080909@oracle.com> <559DB583.8060609@oracle.com> <CAFWmRJ0mvGM8DDXxUvJ3ODMg_8yLaH7kq=KQKWWZu6r8TNcB2A@mail.gmail.com> <559EA925.5010701@oracle.com> <C9A8F00E-F143-4A77-9122-5FFD1E0F04F6@redhat.com> Message-ID: <20150724223926.00007e04.ecki@zusammenkunft.net> Am Fri, 24 Jul 2015 14:38:36 -0500 schrieb Jason Greene <jason.greene at redhat.com>: > The truth is that there is a gap between the current capabilities of > TLS stacks and what the specs are trying to achieve. Ultimately the > desired semantic the specs are trying to achieve is that every ALPN > protocol can have its own TLS requirements. Not sure if this is desireable, it was I guess the motivation, but see below: > In this case H2 wanted > TLS 1.3 behavior before it was released. This is basically social > engineering, the newer protocol is the carrot for updating your TLS > stack. However there are other potential scenarios, such as protocols > which desire to be encrypted but unauthenticated. I think it is fine to define a minimum security level together with an application protocol. If the protocol is supported the TLS stack needs to provide the desired features, and given the fact that it will negotiate the "best" protocol version you can just deny H2 if the cipher is not good enough. However: > To truly resolve this gap in a future proof manner, TLS stacks need > to support cipher suite selection based on the combination of ALPN > protocol and TLS version. If each ALPN can select different security parameters, this would be a configuration and interop nightmare. Dont go that route. I would not provide any features to enable it, nor require them. Having said that H2 should really be less demanding. (not sure whats the best place to discuss it, not part of the H2 group). Gruss Bernd From jharrop at gmail.com Sat Jul 25 13:40:11 2015 From: jharrop at gmail.com (Jason Harrop) Date: Sat, 25 Jul 2015 23:40:11 +1000 Subject: NPE in sun.security.provider.certpath.OCSPResponse.verify Message-ID: <CAM-hvXdFXCc8P0mK1aLrm+E-_jHK5EPks_7y4sWUzaLw6ptkTw@mail.gmail.com> Hi there, I'm getting an NPE, Java 8: at sun.security.provider.certpath.OCSPResponse.verify(OCSPResponse.java:452) at sun.security.provider.certpath.OCSP.check(OCSP.java:290) at sun.security.provider.certpath.RevocationChecker.checkOCSP(RevocationChecker.java:716) at sun.security.provider.certpath.RevocationChecker.check(RevocationChecker.java:357) at sun.security.provider.certpath.RevocationChecker.check(RevocationChecker.java:337) at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:119) at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:215) at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:143) at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:79) at java.security.cert.CertPathValidator.validate(CertPathValidator.java:292) and Java 9: at sun.security.provider.certpath.OCSPResponse.verify(OCSPResponse.java:451) at sun.security.provider.certpath.OCSP.check(OCSP.java:290) at sun.security.provider.certpath.RevocationChecker.checkOCSP(RevocationChecker.java:749) at sun.security.provider.certpath.RevocationChecker.check(RevocationChecker.java:363) at sun.security.provider.certpath.RevocationChecker.check(RevocationChecker.java:337) at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:125) at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:212) at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:140) at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:79) at java.security.cert.CertPathValidator.validate(CertPathValidator.java:292) It is happening because List<X509CertImpl> certs contains 10 null entries, so cert is null at: KeyIdentifier certKeyId = cert.getSubjectKeyId(); The last bit of debug before this failure is: certpath: BasicChecker.updateState issuer: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US; subject: CN=COMODO Code Signing CA 2, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB; serial#: 21852375853972585523540355797488858555 certpath: -checker6 validation succeeded certpath: -Using checker7 ... [sun.security.provider.certpath.RevocationChecker] certpath: connecting to OCSP service at: http://ocsp.usertrust.com certpath: OCSP response status: SUCCESSFUL certpath: OCSP response type: basic certpath: Responder's key ID: 2b:c3:46:ab:ba:0e:c9:65:2a:46:d1:79:47:c4:62:e2:e1:da:fc:b8 certpath: OCSP response produced at: Sat Jul 25 19:49:44 EST 2015 certpath: OCSP number of SingleResponses: 1 certpath: Status of certificate (with serial number 21852375853972585523540355797488858555) is: GOOD In OCSPResponse constructor, i think its just setting certs = new ArrayList<X509CertImpl>(); // line 386 I'm new to this certpath stuff, so I hope that's intelligible. cheers .. Jason From simone.bordet at gmail.com Sat Jul 25 17:26:41 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Sat, 25 Jul 2015 19:26:41 +0200 Subject: TLS ALPN Proposal v3 In-Reply-To: <C9A8F00E-F143-4A77-9122-5FFD1E0F04F6@redhat.com> References: <555E7E98.9050208@oracle.com> <556E50B3.3080709@oracle.com> <556E9D5C.5040106@oracle.com> <CAFWmRJ12W+_avfF=oBBqxsKimXP50zjPCf7am6x86p_yaGyC3A@mail.gmail.com> <55707475.8060401@oracle.com> <CAFWmRJ3PfacUKrWB=Lpic1Mizgxs+UrMy6PzZLtw5vJ4L=WCXA@mail.gmail.com> <557081BB.5080508@oracle.com> <CAFWmRJ2+P5F4nphpDGx50z1e1KWrc76WQ+vo5CRiTy7KktUJvQ@mail.gmail.com> <5571217A.1070501@oracle.com> <CAFWmRJ3pR=c61Btxg-0EZJkhkpH6ueJ6+Vj1zomACdOE1Aub2Q@mail.gmail.com> <557197C9.5010407@oracle.com> <CAFWmRJ2Js9fram5i-YQ1o3aGMk4wVji-50zcdHsyxMankRkPTw@mail.gmail.com> <5571B645.7050305@oracle.com> <CAFWmRJ0PPJTyh_6Vj+6_sOr+npt+sAL9Stc565KXUFBuSUG4XA@mail.gmail.com> <5571C016.7080909@oracle.com> <559DB583.8060609@oracle.com> <CAFWmRJ0mvGM8DDXxUvJ3ODMg_8yLaH7kq=KQKWWZu6r8TNcB2A@mail.gmail.com> <559EA925.5010701@oracle.com> <C9A8F00E-F143-4A77-9122-5FFD1E0F04F6@redhat.com> Message-ID: <CAFWmRJ1SPeH=yOj0=Lxgh++bJnC1ZW4hTPF7ueagmCKBFPX6Uw@mail.gmail.com> Hi, On Fri, Jul 24, 2015 at 9:38 PM, Jason Greene <jason.greene at redhat.com> wrote: > The truth is that there is a gap between the current capabilities of TLS stacks and what the specs are trying to achieve. Ultimately the desired semantic the specs are trying to achieve is that every ALPN protocol can have its own TLS requirements. In this case H2 wanted TLS 1.3 behavior before it was released. This is basically social engineering, the newer protocol is the carrot for updating your TLS stack. However there are other potential scenarios, such as protocols which desire to be encrypted but unauthenticated. > > To truly resolve this gap in a future proof manner, TLS stacks need to support cipher suite selection based on the combination of ALPN protocol and TLS version. Had TLS 1.3 been released before H2, we would not need to choose the cipher suite based on ALPN + TLS version, because any TLS 1.3 cipher would do, and the support for ALPN would be much simpler (probably akin to SNI). The current situation is a temporary glitch produced by the H2 specification, and requires clients and servers to implement hacks to support H2 (sorting ciphers, etc.). Another thing to remember is that clients and servers may implement different ways of selecting the various TLS parameters. While server have to choose among TLS protocol versions, ciphers, application protocols, etc., the client can only react to what the server chose. For a TLS implementation, it may be simpler to implement a client (like browsers do) than a server; I think the server algorithm would work for clients, but not necessarily viceversa. Tradeoff between A) change radically the OpenJDK implementation to support an iterative processing of TLS protocols, extensions (all of them), ciphers, aliases, etc. that would be future proof (if that is even possible) and B) hack in just enough of what is needed to support H2 today (for which we already have working examples) ? Would it be possible to fit the ALPN solution that would have been implemented if TLS 1.3 was out before HTTP/2 to support the current situation ? -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From sean.mullan at oracle.com Mon Jul 27 18:35:00 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 27 Jul 2015 14:35:00 -0400 Subject: RFR [9] 8132130: some docs cleanup In-Reply-To: <55AF9FEE.40107@oracle.com> References: <55AF9FEE.40107@oracle.com> Message-ID: <55B679D4.7020904@oracle.com> DHParameterGenerator.java, l95: typo s/genParamSpes/genParamSpec/ jgss/spi/GSSContextSpi.java, l368: s/msgStr/mProp/ Looks fine otherwise. --Sean On 07/22/2015 09:51 AM, alexander stepanov wrote: > Hello, > > Could you please review the following fix > http://cr.openjdk.java.net/~avstepan/8132130/webrev.00/ > for > https://bugs.openjdk.java.net/browse/JDK-8132130 > > Just some docs cleanup (fix invalid tags, parameter names, remove > obsolete <xmp> tags) > > Thanks, > Alexander From alexander.v.stepanov at oracle.com Tue Jul 28 17:41:47 2015 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Tue, 28 Jul 2015 20:41:47 +0300 Subject: RFR [9] 8132130: some docs cleanup In-Reply-To: <55B7BE89.9090808@oracle.com> References: <55AF9FEE.40107@oracle.com> <55B679D4.7020904@oracle.com> <55B7BE89.9090808@oracle.com> Message-ID: <55B7BEDB.3020400@oracle.com> Adding the forgotten mailing list... On 28.07.2015 20:40, Alexander Stepanov wrote: > Hello Sean, > > Thank you; the typos were fixed (sorry for inattention): > http://cr.openjdk.java.net/~avstepan/8132130/webrev.01/ > > Regards, > Alexander > > On 27.07.2015 21:35, Sean Mullan wrote: >> DHParameterGenerator.java, l95: typo s/genParamSpes/genParamSpec/ >> >> jgss/spi/GSSContextSpi.java, l368: s/msgStr/mProp/ >> >> Looks fine otherwise. >> >> --Sean >> >> On 07/22/2015 09:51 AM, alexander stepanov wrote: >>> Hello, >>> >>> Could you please review the following fix >>> http://cr.openjdk.java.net/~avstepan/8132130/webrev.00/ >>> for >>> https://bugs.openjdk.java.net/browse/JDK-8132130 >>> >>> Just some docs cleanup (fix invalid tags, parameter names, remove >>> obsolete <xmp> tags) >>> >>> Thanks, >>> Alexander > From sean.mullan at oracle.com Wed Jul 29 18:01:23 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 29 Jul 2015 14:01:23 -0400 Subject: RFR 8050402: Tests to check for use of policy files In-Reply-To: <55A55FDA.3030606@oracle.com> References: <55A55FDA.3030606@oracle.com> Message-ID: <55B914F3.1010403@oracle.com> Hi Amanda, Rather than exec-ing java from within the test, I think it would be better if you used jtreg @run options to do that. For example: @run main/java.security.policy=ExtensiblePolicyTest1.policy ExtensiblePolicyTest1 false @run main/java.security.policy=ExtensiblePolicyTest2.policy ExtensiblePolicyTest1 true etc.. I think this would lead to a more robust test and eliminate some overhead. Thanks, Sean On 07/14/2015 03:15 PM, Amanda Jiang wrote: > Hi, > > Please review a new test which checks Policy is extensible with user > defined permissions. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8050402 > Webrev: http://cr.openjdk.java.net/~amjiang/8050402/webrev.01/ > > Thanks, > Amanda From sean.mullan at oracle.com Thu Jul 30 13:07:57 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 30 Jul 2015 09:07:57 -0400 Subject: RFR 8132111: Do not request for addresses for forwarded TGT In-Reply-To: <55AF0C86.7020708@oracle.com> References: <55AF0C86.7020708@oracle.com> Message-ID: <55BA21AD.1080803@oracle.com> This seems ok to me. I think we should also document this behavior if it isn't already (maybe in one of the security guides), so could you file a followon docs bug? Thanks, Sean On 07/21/2015 11:22 PM, Weijun Wang wrote: > Hi All > > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8132111/webrev.00/ > > Java Kerberos was designed to provide the addresses of a service when > requesting for a forwarded TGT. However, the field was never filled, > because of a bug that the service principal does not have the > KRB_NT_SRV_HST nameType. (It has always been KRB_NT_UNKNOWN). > > In JDK-8031111, we "fixed" this and the addresses field is now always sent. > > However, it is well known in the Kerberos community that it's difficult > to get the correct addresses. For example, the service and the client > might be inside a NAT but the KDC is not. If the addresses observed by > the client and the KDC are different, such a ticket will be rejected > when the service is trying to use it. > > For this reason, other krb5 vendors do not use the addresses field in a > forwarded TGT request. We will remove it in this fix. This is also the > actual behavior of Java before JDK-8031111. > > Thanks > Max