From sean.mullan at oracle.com Fri May 1 12:48:38 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 01 May 2015 08:48:38 -0400 Subject: RFR: JDK-8075706 : Policy implementation does not allow policy.provider to be on the class path Message-ID: <55437626.7070501@oracle.com> Please review this change to use the system class loader to locate a policy provider specified with the policy.provider security property. The current implementation tries to load the provider using the extension class loader. This will no longer work when the extension mechanism is removed, which is proposed as part of JEP 220: http://openjdk.java.net/jeps/220 webrev: http://cr.openjdk.java.net/~mullan/webrevs/8075706/webrev.01/ Thanks, Sean From mandy.chung at oracle.com Fri May 1 16:33:24 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 01 May 2015 09:33:24 -0700 Subject: RFR: JDK-8075706 : Policy implementation does not allow policy.provider to be on the class path In-Reply-To: <55437626.7070501@oracle.com> References: <55437626.7070501@oracle.com> Message-ID: <5543AAD4.2070402@oracle.com> On 05/01/2015 05:48 AM, Sean Mullan wrote: > Please review this change to use the system class loader to locate a > policy provider specified with the policy.provider security property. > The current implementation tries to load the provider using the > extension class loader. This will no longer work when the extension > mechanism is removed, which is proposed as part of JEP 220: > http://openjdk.java.net/jeps/220 > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8075706/webrev.01/ > Looks okay. Nit: line 208-209 - this is rather hard to read. probably worth some cleanup/adjustment. CustomPolicy.implies 50 if (pd == policyPd) { 51 return true; 52 } This is okay for the test. Just for my understanding, for real world custom policy, should it check the code source in case the sensitive operation triggering a permission check involving other classes? Mandy From vincent.x.ryan at oracle.com Fri May 1 22:39:07 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 1 May 2015 23:39:07 +0100 Subject: [9] request for review 8079129: NullPointerException in PKCS#12 Keystore in PKCS12KeyStore.java Message-ID: <2E3BAF82-4DD7-4C59-B5B8-6AC3106BDB69@oracle.com> Please review this fix to correct the PKCS12 encoding when a secret key is being stored in one keystore entry and a certificate in another. Thanks. Bug: https://bugs.openjdk.java.net/browse/JDK-8079129 Webrev: http://cr.openjdk.java.net/~vinnie/8079129/webrev.00/ From weijun.wang at oracle.com Sat May 2 01:22:33 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 02 May 2015 09:22:33 +0800 Subject: [9] request for review 8079129: NullPointerException in PKCS#12 Keystore in PKCS12KeyStore.java In-Reply-To: <2E3BAF82-4DD7-4C59-B5B8-6AC3106BDB69@oracle.com> References: <2E3BAF82-4DD7-4C59-B5B8-6AC3106BDB69@oracle.com> Message-ID: <554426D9.5000305@oracle.com> Is it safe to just run for-each on certs (if it's not null)? --Max On 5/2/2015 6:39 AM, Vincent Ryan wrote: > Please review this fix to correct the PKCS12 encoding when a secret key is being stored in one keystore entry and a certificate in another. > > Thanks. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8079129 > Webrev: http://cr.openjdk.java.net/~vinnie/8079129/webrev.00/ > From weijun.wang at oracle.com Mon May 4 08:49:47 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 04 May 2015 16:49:47 +0800 Subject: [9] RFR: 8076486: javax/security/auth/Subject/doAs/NestedActions.java fails if extra VM options are given In-Reply-To: <5540FC52.6030802@oracle.com> References: <554086E0.9080007@oracle.com> <5540E4DC.3080802@oracle.com> <5540FC52.6030802@oracle.com> Message-ID: <554732AB.2090307@oracle.com> Artem If a string starts with whitespace(s), the first element of split("\\s+") will be an empty string. If you can be sure JAVA_OPTS does not have them, your code change is fine. Thanks Max On 4/29/2015 11:44 PM, Artem Smotrakov wrote: > Hi Max, > > These fancy things sometimes make me forget about simpler ways :-) > > Please take a look > > http://cr.openjdk.java.net/~asmotrak/8076486/webrev.01/ > > Thanks! > > Artem > > On 04/29/2015 05:04 PM, Weijun Wang wrote: >> Maybe you can call JAVA_OPTS.trim().split("\\s+") to avoid the filtering. >> >> And it seems Collections.addAll() can add an array to a list. >> >> Of course, you are free to exercise any fancy jdk8 features. :-) >> >> Thanks >> Max >> >> On 4/29/2015 3:23 PM, Artem Smotrakov wrote: >>> Hello, >>> >>> Please review this fix for >>> javax/security/auth/Subject/doAs/NestedActions.java test. >>> >>> The test runs java in a separate process. It fails if multiple java >>> options are passed because ProcessBuilder expects each parameter to be >>> put in to a separate array element, but the test didn't do that. I >>> updated the test to split java option string, and put each option in a >>> separate array element. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076486 >>> Webrev: http://cr.openjdk.java.net/~asmotrak/8076486/webrev.00/ >>> >>> Artem > From weijun.wang at oracle.com Mon May 4 09:21:49 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 04 May 2015 17:21:49 +0800 Subject: RFR 8078495: End time checking for native TGT is wrong In-Reply-To: <5539B896.6090006@oracle.com> References: <5539B896.6090006@oracle.com> Message-ID: <55473A2D.4040000@oracle.com> Ping again. On 4/24/2015 11:29 AM, Weijun Wang wrote: > Hi All > > Please review a fix at > > http://cr.openjdk.java.net/~weijun/8078495/webrev.00 > > which is essentially > > GetSystemTimeAsFileTime(&Now); > EndTime.dwLowDateTime = msticket->EndTime.LowPart; > EndTime.dwHighDateTime = msticket->EndTime.HighPart; > - FileTimeToLocalFileTime(&EndTime, &LocalEndTime); > - if (CompareFileTime(&Now, &LocalEndTime) < 0) { > + if (CompareFileTime(&Now, &EndTime) < 0) { > > MSDN explicitly specifies that GetSystemTimeAsFileTime() [1] returns a > UTC time. It is not very clear about KERB_EXTERNAL_TICKET [2], but > according to my observation and the fact that it is directly converted > to a KerberosTime string in the BuildKerberosTime() function, I believe > it's also UTC. > > Anyway, the FILETIME structure is a little confusing, its spec [3] says > it's an elapsed time from an MS epoch, so it should be timezone > independent. But then there is FileTimeToLocalFileTime function which > means it can be dependent. > > I believe the bug was not spotted earlier because when Java sees an > expired ticket, it always tries to reacquire one, and returns a valid > ticket anyway. (Fortunately it has not tried to validate the new ticket > again). > > Thanks > Max > > [1] > https://msdn.microsoft.com/en-us/library/windows/desktop/ms724397%28v=vs.85%29.aspx > > [2] > https://msdn.microsoft.com/en-us/library/windows/desktop/aa378073%28v=vs.85%29.aspx > > [3] > https://msdn.microsoft.com/en-us/library/windows/desktop/ms724284%28v=vs.85%29.aspx > From xuelei.fan at oracle.com Mon May 4 09:51:21 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 04 May 2015 17:51:21 +0800 Subject: RFR 8078495: End time checking for native TGT is wrong In-Reply-To: <55473A2D.4040000@oracle.com> References: <5539B896.6090006@oracle.com> <55473A2D.4040000@oracle.com> Message-ID: <55474119.70101@oracle.com> Looks fine to me. Xuelei On 5/4/2015 5:21 PM, Weijun Wang wrote: > Ping again. > > On 4/24/2015 11:29 AM, Weijun Wang wrote: >> Hi All >> >> Please review a fix at >> >> http://cr.openjdk.java.net/~weijun/8078495/webrev.00 >> >> which is essentially >> >> GetSystemTimeAsFileTime(&Now); >> EndTime.dwLowDateTime = msticket->EndTime.LowPart; >> EndTime.dwHighDateTime = msticket->EndTime.HighPart; >> - FileTimeToLocalFileTime(&EndTime, &LocalEndTime); >> - if (CompareFileTime(&Now, &LocalEndTime) < 0) { >> + if (CompareFileTime(&Now, &EndTime) < 0) { >> >> MSDN explicitly specifies that GetSystemTimeAsFileTime() [1] returns a >> UTC time. It is not very clear about KERB_EXTERNAL_TICKET [2], but >> according to my observation and the fact that it is directly converted >> to a KerberosTime string in the BuildKerberosTime() function, I believe >> it's also UTC. >> >> Anyway, the FILETIME structure is a little confusing, its spec [3] says >> it's an elapsed time from an MS epoch, so it should be timezone >> independent. But then there is FileTimeToLocalFileTime function which >> means it can be dependent. >> >> I believe the bug was not spotted earlier because when Java sees an >> expired ticket, it always tries to reacquire one, and returns a valid >> ticket anyway. (Fortunately it has not tried to validate the new ticket >> again). >> >> Thanks >> Max >> >> [1] >> https://msdn.microsoft.com/en-us/library/windows/desktop/ms724397%28v=vs.85%29.aspx >> >> >> [2] >> https://msdn.microsoft.com/en-us/library/windows/desktop/aa378073%28v=vs.85%29.aspx >> >> >> [3] >> https://msdn.microsoft.com/en-us/library/windows/desktop/ms724284%28v=vs.85%29.aspx >> >> From vincent.x.ryan at oracle.com Mon May 4 10:08:39 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 4 May 2015 11:08:39 +0100 Subject: [9] request for review 8079129: NullPointerException in PKCS#12 Keystore in PKCS12KeyStore.java In-Reply-To: <554426D9.5000305@oracle.com> References: <2E3BAF82-4DD7-4C59-B5B8-6AC3106BDB69@oracle.com> <554426D9.5000305@oracle.com> Message-ID: Which line? > On 2 May 2015, at 02:22, Weijun Wang wrote: > > Is it safe to just run for-each on certs (if it's not null)? > > --Max > > On 5/2/2015 6:39 AM, Vincent Ryan wrote: >> Please review this fix to correct the PKCS12 encoding when a secret key is being stored in one keystore entry and a certificate in another. >> >> Thanks. >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8079129 >> Webrev: http://cr.openjdk.java.net/~vinnie/8079129/webrev.00/ >> From weijun.wang at oracle.com Mon May 4 12:10:39 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 04 May 2015 20:10:39 +0800 Subject: [9] request for review 8079129: NullPointerException in PKCS#12 Keystore in PKCS12KeyStore.java In-Reply-To: References: <2E3BAF82-4DD7-4C59-B5B8-6AC3106BDB69@oracle.com> <554426D9.5000305@oracle.com> Message-ID: <554761BF.9010307@oracle.com> 1662 for (int i = 0; i < chainLen; i++) { On 5/4/2015 6:08 PM, Vincent Ryan wrote: > Which line? > >> On 2 May 2015, at 02:22, Weijun Wang wrote: >> >> Is it safe to just run for-each on certs (if it's not null)? >> >> --Max >> >> On 5/2/2015 6:39 AM, Vincent Ryan wrote: >>> Please review this fix to correct the PKCS12 encoding when a secret key is being stored in one keystore entry and a certificate in another. >>> >>> Thanks. >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8079129 >>> Webrev: http://cr.openjdk.java.net/~vinnie/8079129/webrev.00/ >>> > From sean.mullan at oracle.com Mon May 4 12:31:51 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 04 May 2015 08:31:51 -0400 Subject: RFR: JDK-8075706 : Policy implementation does not allow policy.provider to be on the class path In-Reply-To: <5543AAD4.2070402@oracle.com> References: <55437626.7070501@oracle.com> <5543AAD4.2070402@oracle.com> Message-ID: <554766B7.3060705@oracle.com> On 05/01/2015 12:33 PM, Mandy Chung wrote: > > > On 05/01/2015 05:48 AM, Sean Mullan wrote: >> Please review this change to use the system class loader to locate a >> policy provider specified with the policy.provider security property. >> The current implementation tries to load the provider using the >> extension class loader. This will no longer work when the extension >> mechanism is removed, which is proposed as part of JEP 220: >> http://openjdk.java.net/jeps/220 >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8075706/webrev.01/ >> > > Looks okay. > > Nit: line 208-209 - this is rather hard to read. probably worth some > cleanup/adjustment. I thought about that, but I think it's best if that code is left as-is for now. It is already bumping up against the 80 char limit, so I would have to refactor that into another method but there are some subtle concurrency issues, so I would prefer not to break up the code just to do that. I'll look at this again later as part of another bug. > CustomPolicy.implies > > 50 if (pd == policyPd) { > 51 return true; > 52 } > > This is okay for the test. Just for my understanding, for real world > custom policy, should it check the code source in case the sensitive > operation triggering a permission check involving other classes? Permissions are granted per ProtectionDomain (PD) so this is sufficient. However, typically the policy provider would be in a separate PD from other code (for example, by packaging it in a separate JAR file), but this is sufficient for testing purposes. If you remove the lines above from the test, you will get a StackOverflowError. Thanks, Sean From Alan.Bateman at oracle.com Mon May 4 14:55:10 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 May 2015 15:55:10 +0100 Subject: RFR: JDK-8075706 : Policy implementation does not allow policy.provider to be on the class path In-Reply-To: <55437626.7070501@oracle.com> References: <55437626.7070501@oracle.com> Message-ID: <5547884E.4090507@oracle.com> On 01/05/2015 13:48, Sean Mullan wrote: > Please review this change to use the system class loader to locate a > policy provider specified with the policy.provider security property. > The current implementation tries to load the provider using the > extension class loader. This will no longer work when the extension > mechanism is removed, which is proposed as part of JEP 220: > http://openjdk.java.net/jeps/220 > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8075706/webrev.01/ The change looks okay but I wonder if there is an opportunity to do some clean-up. One thing that is a bit icky is the catching of Exception for the case that the policy class is loaded by boot loader but it can't be instantiated for some reason. It might be better to replace this with Class.forName(policy_class, false, null) and only fallback to trying again with the SCL if CNFE is thrown. That way you could have once place to instantiate the policy class and log the exception if it fails. -Alan. From mandy.chung at oracle.com Mon May 4 17:15:18 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 04 May 2015 10:15:18 -0700 Subject: RFR: JDK-8075706 : Policy implementation does not allow policy.provider to be on the class path In-Reply-To: <554766B7.3060705@oracle.com> References: <55437626.7070501@oracle.com> <5543AAD4.2070402@oracle.com> <554766B7.3060705@oracle.com> Message-ID: <5547A926.80506@oracle.com> On 05/04/2015 05:31 AM, Sean Mullan wrote: > >> CustomPolicy.implies >> >> 50 if (pd == policyPd) { >> 51 return true; >> 52 } >> >> This is okay for the test. Just for my understanding, for real world >> custom policy, should it check the code source in case the sensitive >> operation triggering a permission check involving other classes? > > Permissions are granted per ProtectionDomain (PD) so this is > sufficient. However, typically the policy provider would be in a > separate PD from other code (for example, by packaging it in a > separate JAR file), but this is sufficient for testing purposes. If > you remove the lines above from the test, you will get a > StackOverflowError. Right this is sufficient for testing purpose. My comment is only for my understanding of the internal implementation. I see that SecureClassLoader caches one ProtectionDomain per code source and so checking "==" PD instance works most of the cases (maybe all cases in practice) while a custom class loader could instantiate different PD objects to define classes from the same code source. Anyway, no change is needed for the test. Mandy From sean.mullan at oracle.com Mon May 4 19:56:30 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 04 May 2015 15:56:30 -0400 Subject: RFR: JDK-8075706 : Policy implementation does not allow policy.provider to be on the class path In-Reply-To: <5547A926.80506@oracle.com> References: <55437626.7070501@oracle.com> <5543AAD4.2070402@oracle.com> <554766B7.3060705@oracle.com> <5547A926.80506@oracle.com> Message-ID: <5547CEEE.5020707@oracle.com> On 05/04/2015 01:15 PM, Mandy Chung wrote: > > > On 05/04/2015 05:31 AM, Sean Mullan wrote: >> >>> CustomPolicy.implies >>> >>> 50 if (pd == policyPd) { >>> 51 return true; >>> 52 } >>> >>> This is okay for the test. Just for my understanding, for real world >>> custom policy, should it check the code source in case the sensitive >>> operation triggering a permission check involving other classes? >> >> Permissions are granted per ProtectionDomain (PD) so this is >> sufficient. However, typically the policy provider would be in a >> separate PD from other code (for example, by packaging it in a >> separate JAR file), but this is sufficient for testing purposes. If >> you remove the lines above from the test, you will get a >> StackOverflowError. > > Right this is sufficient for testing purpose. > > My comment is only for my understanding of the internal implementation. > I see that SecureClassLoader caches one ProtectionDomain per code source > and so checking "==" PD instance works most of the cases (maybe all > cases in practice) while a custom class loader could instantiate > different PD objects to define classes from the same code source. > Anyway, no change is needed for the test. Ok. I will be thinking more about this issue later. Right now I just want to gently fix this issue without changing the code too much :) --Sean From sean.mullan at oracle.com Mon May 4 20:14:33 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 04 May 2015 16:14:33 -0400 Subject: RFR: JDK-8075706 : Policy implementation does not allow policy.provider to be on the class path In-Reply-To: <5547884E.4090507@oracle.com> References: <55437626.7070501@oracle.com> <5547884E.4090507@oracle.com> Message-ID: <5547D329.6040008@oracle.com> On 05/04/2015 10:55 AM, Alan Bateman wrote: > On 01/05/2015 13:48, Sean Mullan wrote: >> Please review this change to use the system class loader to locate a >> policy provider specified with the policy.provider security property. >> The current implementation tries to load the provider using the >> extension class loader. This will no longer work when the extension >> mechanism is removed, which is proposed as part of JEP 220: >> http://openjdk.java.net/jeps/220 >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8075706/webrev.01/ > The change looks okay but I wonder if there is an opportunity to do some > clean-up. Yes, definitely, but OTOH it's been mostly working fine for years, and it's a fragile area, so we need to proceed with care :) > One thing that is a bit icky is the catching of Exception for the case > that the policy class is loaded by boot loader but it can't be > instantiated for some reason. It might be better to replace this with > Class.forName(policy_class, false, null) and only fallback to trying > again with the SCL if CNFE is thrown. That way you could have once place > to instantiate the policy class and log the exception if it fails. That seems like a good idea. I'll change it, and if I get a good JPRT run, I'll proceed with that change. --Sean From jason.uh at oracle.com Tue May 5 00:49:19 2015 From: jason.uh at oracle.com (Jason Uh) Date: Mon, 04 May 2015 17:49:19 -0700 Subject: [9] RFR: 8058543: Certificate returns NULL Subject Alternative Name if it is in X400Address type Message-ID: <5548138F.6070405@oracle.com> Please review this fix, which enables parsing of X400Address-type Subject Alternative Names. webrev: http://cr.openjdk.java.net/~juh/8058543/00/ bug: https://bugs.openjdk.java.net/browse/JDK-8058543 Jason From weijun.wang at oracle.com Tue May 5 01:00:19 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 05 May 2015 09:00:19 +0800 Subject: [9] RFR: 8058543: Certificate returns NULL Subject Alternative Name if it is in X400Address type In-Reply-To: <5548138F.6070405@oracle.com> References: <5548138F.6070405@oracle.com> Message-ID: <55481623.4000507@oracle.com> Looks fine. Thanks Max On 5/5/2015 8:49 AM, Jason Uh wrote: > Please review this fix, which enables parsing of X400Address-type > Subject Alternative Names. > > webrev: http://cr.openjdk.java.net/~juh/8058543/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8058543 > > Jason From vincent.x.ryan at oracle.com Tue May 5 12:32:12 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 5 May 2015 13:32:12 +0100 Subject: [9] request for review 8079129: NullPointerException in PKCS#12 Keystore in PKCS12KeyStore.java In-Reply-To: <554761BF.9010307@oracle.com> References: <2E3BAF82-4DD7-4C59-B5B8-6AC3106BDB69@oracle.com> <554426D9.5000305@oracle.com> <554761BF.9010307@oracle.com> Message-ID: <3AF0F431-2591-4457-8F5E-CB5EC0E4C5A3@oracle.com> Replacing the for loop below with a for-each loop on certs would be fine except that certs can be null. I could initialize certs with an empty array on each iteration of the outer loop but it doesn?t seem to gain much overall. > On 4 May 2015, at 13:10, Weijun Wang wrote: > > 1662 for (int i = 0; i < chainLen; i++) { > > > On 5/4/2015 6:08 PM, Vincent Ryan wrote: >> Which line? >> >>> On 2 May 2015, at 02:22, Weijun Wang wrote: >>> >>> Is it safe to just run for-each on certs (if it's not null)? >>> >>> --Max >>> >>> On 5/2/2015 6:39 AM, Vincent Ryan wrote: >>>> Please review this fix to correct the PKCS12 encoding when a secret key is being stored in one keystore entry and a certificate in another. >>>> >>>> Thanks. >>>> >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8079129 >>>> Webrev: http://cr.openjdk.java.net/~vinnie/8079129/webrev.00/ >>>> >> From weijun.wang at oracle.com Tue May 5 14:10:04 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 05 May 2015 22:10:04 +0800 Subject: [9] request for review 8079129: NullPointerException in PKCS#12 Keystore in PKCS12KeyStore.java In-Reply-To: <3AF0F431-2591-4457-8F5E-CB5EC0E4C5A3@oracle.com> References: <2E3BAF82-4DD7-4C59-B5B8-6AC3106BDB69@oracle.com> <554426D9.5000305@oracle.com> <554761BF.9010307@oracle.com> <3AF0F431-2591-4457-8F5E-CB5EC0E4C5A3@oracle.com> Message-ID: <5548CF3C.1080905@oracle.com> Anyway it looks redundant and error-prone to maintain the length of an array in a separate variable. --Max On 5/5/2015 8:32 PM, Vincent Ryan wrote: > Replacing the for loop below with a for-each loop on certs would be fine except that certs can be null. > I could initialize certs with an empty array on each iteration of the outer loop but it doesn?t seem to gain much overall. > > >> On 4 May 2015, at 13:10, Weijun Wang wrote: >> >> 1662 for (int i = 0; i < chainLen; i++) { >> >> >> On 5/4/2015 6:08 PM, Vincent Ryan wrote: >>> Which line? >>> >>>> On 2 May 2015, at 02:22, Weijun Wang wrote: >>>> >>>> Is it safe to just run for-each on certs (if it's not null)? >>>> >>>> --Max >>>> >>>> On 5/2/2015 6:39 AM, Vincent Ryan wrote: >>>>> Please review this fix to correct the PKCS12 encoding when a secret key is being stored in one keystore entry and a certificate in another. >>>>> >>>>> Thanks. >>>>> >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8079129 >>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8079129/webrev.00/ >>>>> >>> > From vincent.x.ryan at oracle.com Tue May 5 14:44:20 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 5 May 2015 15:44:20 +0100 Subject: [9] request for review 8079129: NullPointerException in PKCS#12 Keystore in PKCS12KeyStore.java In-Reply-To: <5548CF3C.1080905@oracle.com> References: <2E3BAF82-4DD7-4C59-B5B8-6AC3106BDB69@oracle.com> <554426D9.5000305@oracle.com> <554761BF.9010307@oracle.com> <3AF0F431-2591-4457-8F5E-CB5EC0E4C5A3@oracle.com> <5548CF3C.1080905@oracle.com> Message-ID: <3CDF4917-0557-4475-A180-8E5555A006AC@oracle.com> OK. How about this? --- a/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java +++ b/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 1999, 2014, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1999, 2015, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -1642,23 +1642,22 @@ Entry entry = entries.get(alias); // certificate chain - int chainLen = 1; Certificate[] certs = null; if (entry instanceof PrivateKeyEntry) { PrivateKeyEntry keyEntry = (PrivateKeyEntry) entry; - if (keyEntry.chain == null) { - chainLen = 0; - } else { - chainLen = keyEntry.chain.length; - } - certs = keyEntry.chain; - + if (keyEntry.chain != null) { + certs = keyEntry.chain; + } else { + certs = new Certificate[0]; + } } else if (entry instanceof CertEntry) { - certs = new Certificate[]{((CertEntry) entry).cert}; + certs = new Certificate[]{((CertEntry) entry).cert}; + } else { + certs = new Certificate[0]; } - for (int i = 0; i < chainLen; i++) { + for (int i = 0; i < certs.length; i++) { // create SafeBag of Type CertBag DerOutputStream safeBag = new DerOutputStream(); safeBag.putOID(CertBag_OID); > On 5 May 2015, at 15:10, Weijun Wang wrote: > > Anyway it looks redundant and error-prone to maintain the length of an array in a separate variable. > > --Max > > On 5/5/2015 8:32 PM, Vincent Ryan wrote: >> Replacing the for loop below with a for-each loop on certs would be fine except that certs can be null. >> I could initialize certs with an empty array on each iteration of the outer loop but it doesn?t seem to gain much overall. >> >> >>> On 4 May 2015, at 13:10, Weijun Wang wrote: >>> >>> 1662 for (int i = 0; i < chainLen; i++) { >>> >>> >>> On 5/4/2015 6:08 PM, Vincent Ryan wrote: >>>> Which line? >>>> >>>>> On 2 May 2015, at 02:22, Weijun Wang wrote: >>>>> >>>>> Is it safe to just run for-each on certs (if it's not null)? >>>>> >>>>> --Max >>>>> >>>>> On 5/2/2015 6:39 AM, Vincent Ryan wrote: >>>>>> Please review this fix to correct the PKCS12 encoding when a secret key is being stored in one keystore entry and a certificate in another. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8079129 >>>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8079129/webrev.00/ >>>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue May 5 14:52:32 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 05 May 2015 22:52:32 +0800 Subject: [9] request for review 8079129: NullPointerException in PKCS#12 Keystore in PKCS12KeyStore.java In-Reply-To: <3CDF4917-0557-4475-A180-8E5555A006AC@oracle.com> References: <2E3BAF82-4DD7-4C59-B5B8-6AC3106BDB69@oracle.com> <554426D9.5000305@oracle.com> <554761BF.9010307@oracle.com> <3AF0F431-2591-4457-8F5E-CB5EC0E4C5A3@oracle.com> <5548CF3C.1080905@oracle.com> <3CDF4917-0557-4475-A180-8E5555A006AC@oracle.com> Message-ID: <5548D930.2050701@oracle.com> That's good, but there is no need to assign null in Certificate[] certs = null; Or, maybe you can add "if (certs != null)" around the loop, but you might not like an extra indentation. --Max On 5/5/2015 10:44 PM, Vincent Ryan wrote: > OK. How about this? > > --- a/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java > +++ b/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1999, 2014, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1999, 2015, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -1642,23 +1642,22 @@ > Entry entry = entries.get(alias); > > > // certificate chain > - int chainLen = 1; > Certificate[] certs = null; > > > if (entry instanceof PrivateKeyEntry) { > PrivateKeyEntry keyEntry = (PrivateKeyEntry) entry; > - if (keyEntry.chain == null) { > - chainLen = 0; > - } else { > - chainLen = keyEntry.chain.length; > - } > - certs = keyEntry.chain; > - > + if (keyEntry.chain != null) { > + certs = keyEntry.chain; > + } else { > + certs = new Certificate[0]; > + } > } else if (entry instanceof CertEntry) { > - certs = new Certificate[]{((CertEntry) entry).cert}; > + certs = new Certificate[]{((CertEntry) entry).cert}; > + } else { > + certs = new Certificate[0]; > } > > > - for (int i = 0; i < chainLen; i++) { > + for (int i = 0; i < certs.length; i++) { > // create SafeBag of Type CertBag > DerOutputStream safeBag = new DerOutputStream(); > safeBag.putOID(CertBag_OID); > > > >> On 5 May 2015, at 15:10, Weijun Wang > > wrote: >> >> Anyway it looks redundant and error-prone to maintain the length of an >> array in a separate variable. >> >> --Max >> >> On 5/5/2015 8:32 PM, Vincent Ryan wrote: >>> Replacing the for loop below with a for-each loop on certs would be >>> fine except that certs can be null. >>> I could initialize certs with an empty array on each iteration of the >>> outer loop but it doesn?t seem to gain much overall. >>> >>> >>>> On 4 May 2015, at 13:10, Weijun Wang >>> > wrote: >>>> >>>> 1662 for (int i = 0; i < chainLen; i++) { >>>> >>>> >>>> On 5/4/2015 6:08 PM, Vincent Ryan wrote: >>>>> Which line? >>>>> >>>>>> On 2 May 2015, at 02:22, Weijun Wang >>>>> > wrote: >>>>>> >>>>>> Is it safe to just run for-each on certs (if it's not null)? >>>>>> >>>>>> --Max >>>>>> >>>>>> On 5/2/2015 6:39 AM, Vincent Ryan wrote: >>>>>>> Please review this fix to correct the PKCS12 encoding when a >>>>>>> secret key is being stored in one keystore entry and a >>>>>>> certificate in another. >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8079129 >>>>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8079129/webrev.00/ >>>>>>> >>>>> >>> > From vincent.x.ryan at oracle.com Tue May 5 14:53:25 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 5 May 2015 15:53:25 +0100 Subject: [9] request for review 8079129: NullPointerException in PKCS#12 Keystore in PKCS12KeyStore.java In-Reply-To: <5548D930.2050701@oracle.com> References: <2E3BAF82-4DD7-4C59-B5B8-6AC3106BDB69@oracle.com> <554426D9.5000305@oracle.com> <554761BF.9010307@oracle.com> <3AF0F431-2591-4457-8F5E-CB5EC0E4C5A3@oracle.com> <5548CF3C.1080905@oracle.com> <3CDF4917-0557-4475-A180-8E5555A006AC@oracle.com> <5548D930.2050701@oracle.com> Message-ID: <7E8E35FF-82A0-4EC7-860F-EF1F18938FBD@oracle.com> I?ll skip the initialization. Thanks. > On 5 May 2015, at 15:52, Weijun Wang wrote: > > That's good, but there is no need to assign null in > > Certificate[] certs = null; > > Or, maybe you can add "if (certs != null)" around the loop, but you might not like an extra indentation. > > --Max > > On 5/5/2015 10:44 PM, Vincent Ryan wrote: >> OK. How about this? >> >> --- a/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java >> +++ b/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1999, 2014, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 1999, 2015, Oracle and/or its affiliates. All rights >> reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -1642,23 +1642,22 @@ >> Entry entry = entries.get(alias); >> >> >> // certificate chain >> - int chainLen = 1; >> Certificate[] certs = null; >> >> >> if (entry instanceof PrivateKeyEntry) { >> PrivateKeyEntry keyEntry = (PrivateKeyEntry) entry; >> - if (keyEntry.chain == null) { >> - chainLen = 0; >> - } else { >> - chainLen = keyEntry.chain.length; >> - } >> - certs = keyEntry.chain; >> - >> + if (keyEntry.chain != null) { >> + certs = keyEntry.chain; >> + } else { >> + certs = new Certificate[0]; >> + } >> } else if (entry instanceof CertEntry) { >> - certs = new Certificate[]{((CertEntry) entry).cert}; >> + certs = new Certificate[]{((CertEntry) entry).cert}; >> + } else { >> + certs = new Certificate[0]; >> } >> >> >> - for (int i = 0; i < chainLen; i++) { >> + for (int i = 0; i < certs.length; i++) { >> // create SafeBag of Type CertBag >> DerOutputStream safeBag = new DerOutputStream(); >> safeBag.putOID(CertBag_OID); >> >> >> >>> On 5 May 2015, at 15:10, Weijun Wang >> > wrote: >>> >>> Anyway it looks redundant and error-prone to maintain the length of an >>> array in a separate variable. >>> >>> --Max >>> >>> On 5/5/2015 8:32 PM, Vincent Ryan wrote: >>>> Replacing the for loop below with a for-each loop on certs would be >>>> fine except that certs can be null. >>>> I could initialize certs with an empty array on each iteration of the >>>> outer loop but it doesn?t seem to gain much overall. >>>> >>>> >>>>> On 4 May 2015, at 13:10, Weijun Wang >>>> > wrote: >>>>> >>>>> 1662 for (int i = 0; i < chainLen; i++) { >>>>> >>>>> >>>>> On 5/4/2015 6:08 PM, Vincent Ryan wrote: >>>>>> Which line? >>>>>> >>>>>>> On 2 May 2015, at 02:22, Weijun Wang >>>>>> > wrote: >>>>>>> >>>>>>> Is it safe to just run for-each on certs (if it's not null)? >>>>>>> >>>>>>> --Max >>>>>>> >>>>>>> On 5/2/2015 6:39 AM, Vincent Ryan wrote: >>>>>>>> Please review this fix to correct the PKCS12 encoding when a >>>>>>>> secret key is being stored in one keystore entry and a >>>>>>>> certificate in another. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8079129 >>>>>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8079129/webrev.00/ >>>>>>>> >>>>>> >>>> >> From vincent.x.ryan at oracle.com Tue May 5 15:17:10 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 5 May 2015 16:17:10 +0100 Subject: [9] request for review 8079129: NullPointerException in PKCS#12 Keystore in PKCS12KeyStore.java In-Reply-To: <7E8E35FF-82A0-4EC7-860F-EF1F18938FBD@oracle.com> References: <2E3BAF82-4DD7-4C59-B5B8-6AC3106BDB69@oracle.com> <554426D9.5000305@oracle.com> <554761BF.9010307@oracle.com> <3AF0F431-2591-4457-8F5E-CB5EC0E4C5A3@oracle.com> <5548CF3C.1080905@oracle.com> <3CDF4917-0557-4475-A180-8E5555A006AC@oracle.com> <5548D930.2050701@oracle.com> <7E8E35FF-82A0-4EC7-860F-EF1F18938FBD@oracle.com> Message-ID: FYI updated webrev at: http://cr.openjdk.java.net/~vinnie/8079129/webrev.01/ > On 5 May 2015, at 15:53, Vincent Ryan wrote: > > I?ll skip the initialization. > Thanks. > > >> On 5 May 2015, at 15:52, Weijun Wang wrote: >> >> That's good, but there is no need to assign null in >> >> Certificate[] certs = null; >> >> Or, maybe you can add "if (certs != null)" around the loop, but you might not like an extra indentation. >> >> --Max >> >> On 5/5/2015 10:44 PM, Vincent Ryan wrote: >>> OK. How about this? >>> >>> --- a/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java >>> +++ b/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 1999, 2014, Oracle and/or its affiliates. All rights >>> reserved. >>> + * Copyright (c) 1999, 2015, Oracle and/or its affiliates. All rights >>> reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or modify it >>> @@ -1642,23 +1642,22 @@ >>> Entry entry = entries.get(alias); >>> >>> >>> // certificate chain >>> - int chainLen = 1; >>> Certificate[] certs = null; >>> >>> >>> if (entry instanceof PrivateKeyEntry) { >>> PrivateKeyEntry keyEntry = (PrivateKeyEntry) entry; >>> - if (keyEntry.chain == null) { >>> - chainLen = 0; >>> - } else { >>> - chainLen = keyEntry.chain.length; >>> - } >>> - certs = keyEntry.chain; >>> - >>> + if (keyEntry.chain != null) { >>> + certs = keyEntry.chain; >>> + } else { >>> + certs = new Certificate[0]; >>> + } >>> } else if (entry instanceof CertEntry) { >>> - certs = new Certificate[]{((CertEntry) entry).cert}; >>> + certs = new Certificate[]{((CertEntry) entry).cert}; >>> + } else { >>> + certs = new Certificate[0]; >>> } >>> >>> >>> - for (int i = 0; i < chainLen; i++) { >>> + for (int i = 0; i < certs.length; i++) { >>> // create SafeBag of Type CertBag >>> DerOutputStream safeBag = new DerOutputStream(); >>> safeBag.putOID(CertBag_OID); >>> >>> >>> >>>> On 5 May 2015, at 15:10, Weijun Wang >>> > wrote: >>>> >>>> Anyway it looks redundant and error-prone to maintain the length of an >>>> array in a separate variable. >>>> >>>> --Max >>>> >>>> On 5/5/2015 8:32 PM, Vincent Ryan wrote: >>>>> Replacing the for loop below with a for-each loop on certs would be >>>>> fine except that certs can be null. >>>>> I could initialize certs with an empty array on each iteration of the >>>>> outer loop but it doesn?t seem to gain much overall. >>>>> >>>>> >>>>>> On 4 May 2015, at 13:10, Weijun Wang >>>>> > wrote: >>>>>> >>>>>> 1662 for (int i = 0; i < chainLen; i++) { >>>>>> >>>>>> >>>>>> On 5/4/2015 6:08 PM, Vincent Ryan wrote: >>>>>>> Which line? >>>>>>> >>>>>>>> On 2 May 2015, at 02:22, Weijun Wang >>>>>>> > wrote: >>>>>>>> >>>>>>>> Is it safe to just run for-each on certs (if it's not null)? >>>>>>>> >>>>>>>> --Max >>>>>>>> >>>>>>>> On 5/2/2015 6:39 AM, Vincent Ryan wrote: >>>>>>>>> Please review this fix to correct the PKCS12 encoding when a >>>>>>>>> secret key is being stored in one keystore entry and a >>>>>>>>> certificate in another. >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8079129 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8079129/webrev.00/ >>>>>>>>> >>>>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue May 5 15:23:28 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 05 May 2015 23:23:28 +0800 Subject: [9] request for review 8079129: NullPointerException in PKCS#12 Keystore in PKCS12KeyStore.java In-Reply-To: References: <2E3BAF82-4DD7-4C59-B5B8-6AC3106BDB69@oracle.com> <554426D9.5000305@oracle.com> <554761BF.9010307@oracle.com> <3AF0F431-2591-4457-8F5E-CB5EC0E4C5A3@oracle.com> <5548CF3C.1080905@oracle.com> <3CDF4917-0557-4475-A180-8E5555A006AC@oracle.com> <5548D930.2050701@oracle.com> <7E8E35FF-82A0-4EC7-860F-EF1F18938FBD@oracle.com> Message-ID: <5548E070.90007@oracle.com> Good. Thanks Max On 5/5/2015 11:17 PM, Vincent Ryan wrote: > FYI updated webrev at: > http://cr.openjdk.java.net/~vinnie/8079129/webrev.01/ > > >> On 5 May 2015, at 15:53, Vincent Ryan > > wrote: >> >> I?ll skip the initialization. >> Thanks. >> >> >>> On 5 May 2015, at 15:52, Weijun Wang >> > wrote: >>> >>> That's good, but there is no need to assign null in >>> >>> Certificate[] certs = null; >>> >>> Or, maybe you can add "if (certs != null)" around the loop, but you >>> might not like an extra indentation. >>> >>> --Max >>> >>> On 5/5/2015 10:44 PM, Vincent Ryan wrote: >>>> OK. How about this? >>>> >>>> --- >>>> a/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java >>>> +++ >>>> b/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 1999, 2014, Oracle and/or its affiliates. All rights >>>> reserved. >>>> + * Copyright (c) 1999, 2015, Oracle and/or its affiliates. All rights >>>> reserved. >>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>> * >>>> * This code is free software; you can redistribute it and/or modify it >>>> @@ -1642,23 +1642,22 @@ >>>> Entry entry = entries.get(alias); >>>> >>>> >>>> // certificate chain >>>> - int chainLen = 1; >>>> Certificate[] certs = null; >>>> >>>> >>>> if (entry instanceof PrivateKeyEntry) { >>>> PrivateKeyEntry keyEntry = (PrivateKeyEntry) entry; >>>> - if (keyEntry.chain == null) { >>>> - chainLen = 0; >>>> - } else { >>>> - chainLen = keyEntry.chain.length; >>>> - } >>>> - certs = keyEntry.chain; >>>> - >>>> + if (keyEntry.chain != null) { >>>> + certs = keyEntry.chain; >>>> + } else { >>>> + certs = new Certificate[0]; >>>> + } >>>> } else if (entry instanceof CertEntry) { >>>> - certs = new Certificate[]{((CertEntry) entry).cert}; >>>> + certs = new Certificate[]{((CertEntry) entry).cert}; >>>> + } else { >>>> + certs = new Certificate[0]; >>>> } >>>> >>>> >>>> - for (int i = 0; i < chainLen; i++) { >>>> + for (int i = 0; i < certs.length; i++) { >>>> // create SafeBag of Type CertBag >>>> DerOutputStream safeBag = new DerOutputStream(); >>>> safeBag.putOID(CertBag_OID); >>>> >>>> >>>> >>>>> On 5 May 2015, at 15:10, Weijun Wang >>>> >>>>> > wrote: >>>>> >>>>> Anyway it looks redundant and error-prone to maintain the length of an >>>>> array in a separate variable. >>>>> >>>>> --Max >>>>> >>>>> On 5/5/2015 8:32 PM, Vincent Ryan wrote: >>>>>> Replacing the for loop below with a for-each loop on certs would be >>>>>> fine except that certs can be null. >>>>>> I could initialize certs with an empty array on each iteration of the >>>>>> outer loop but it doesn?t seem to gain much overall. >>>>>> >>>>>> >>>>>>> On 4 May 2015, at 13:10, Weijun Wang >>>>>> >>>>>>> > wrote: >>>>>>> >>>>>>> 1662 for (int i = 0; i < chainLen; i++) { >>>>>>> >>>>>>> >>>>>>> On 5/4/2015 6:08 PM, Vincent Ryan wrote: >>>>>>>> Which line? >>>>>>>> >>>>>>>>> On 2 May 2015, at 02:22, Weijun Wang >>>>>>>> >>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> Is it safe to just run for-each on certs (if it's not null)? >>>>>>>>> >>>>>>>>> --Max >>>>>>>>> >>>>>>>>> On 5/2/2015 6:39 AM, Vincent Ryan wrote: >>>>>>>>>> Please review this fix to correct the PKCS12 encoding when a >>>>>>>>>> secret key is being stored in one keystore entry and a >>>>>>>>>> certificate in another. >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8079129 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8079129/webrev.00/ >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> > From artem.smotrakov at oracle.com Tue May 5 16:01:35 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 05 May 2015 19:01:35 +0300 Subject: [9] RFR: 8076486: javax/security/auth/Subject/doAs/NestedActions.java fails if extra VM options are given In-Reply-To: <554732AB.2090307@oracle.com> References: <554086E0.9080007@oracle.com> <5540E4DC.3080802@oracle.com> <5540FC52.6030802@oracle.com> <554732AB.2090307@oracle.com> Message-ID: <5548E95F.4080401@oracle.com> Hi Max, It works fine if a sting starts with a whitespace. It looks like that jtreg removes whitespaces. Here is a command to run the test, and a piece of jtr file: ${JAVA_HOME}/bin/java -jar /home/artem/tools/jtreg/4.1/lib/jtreg.jar -a -v -testjdk ${JAVA_HOME} -javaoptions:" -XX:+UseG1GC -XX:+CreateMinidumpOnCrash " -dir:/home/artem/ws/jdk/jdk9_dev_jaas_nested_action_tests/jdk/test javax/security/auth/Subject/doAs/NestedActions.java ... /home/artem/jdk/jdk1.9.0b61/bin/java \\ -Dtest.vm.opts= \\ -Dtest.jdk=/home/artem/jdk/jdk1.9.0b61 \\ -Dtest.timeout.factor=1.0 \\ -Dtest.src.path=/home/artem/ws/jdk/jdk9_dev_jaas_nested_action_tests/jdk/test/javax/security/auth/Subject/doAs:/home/artem/ws/jdk/jdk9_dev_jaas_nested_action_tests/jdk/test/lib/testlibrary \\ -Dtest.compiler.opts= \\ -Dcompile.jdk=/home/artem/jdk/jdk1.9.0b61 \\ -Dtest.classes=/home/artem/results/jaas_nested_action_tests/JTwork/classes/javax/security/auth/Subject/doAs \\ -Dtest.class.path=/home/artem/results/jaas_nested_action_tests/JTwork/classes/javax/security/auth/Subject/doAs:/home/artem/results/jaas_nested_action_tests/JTwork/classes/lib/testlibrary \\ -Dtest.java.opts='-XX:+UseG1GC -XX:+CreateMinidumpOnCrash' \\ -Dtest.src=/home/artem/ws/jdk/jdk9_dev_jaas_nested_action_tests/jdk/test/javax/security/auth/Subject/doAs \\ -Dtest.tool.vm.opts= \\ -XX:+UseG1GC -XX:+CreateMinidumpOnCrash \\ com.sun.javatest.regtest.MainWrapper /home/artem/results/jaas_nested_action_tests/JTwork/classes/javax/security/auth/Subject/doAs/NestedActions.jta NestedActionsTwoPrincipals policy.two.principals NestedActionsTwoPrincipals.jar WriteToFileAction.jar ReadFromFileAction.jar ReadPropertyAction.jar ... But anyway, I added trim(), so now the test doesn't rely on jtreg. Please take a look: http://cr.openjdk.java.net/~asmotrak/8076486/webrev.02/ Artem On 05/04/2015 11:49 AM, Weijun Wang wrote: > Artem > > If a string starts with whitespace(s), the first element of > split("\\s+") will be an empty string. If you can be sure JAVA_OPTS > does not have them, your code change is fine. > > Thanks > Max > > On 4/29/2015 11:44 PM, Artem Smotrakov wrote: >> Hi Max, >> >> These fancy things sometimes make me forget about simpler ways :-) >> >> Please take a look >> >> http://cr.openjdk.java.net/~asmotrak/8076486/webrev.01/ >> >> Thanks! >> >> Artem >> >> On 04/29/2015 05:04 PM, Weijun Wang wrote: >>> Maybe you can call JAVA_OPTS.trim().split("\\s+") to avoid the >>> filtering. >>> >>> And it seems Collections.addAll() can add an array to a list. >>> >>> Of course, you are free to exercise any fancy jdk8 features. :-) >>> >>> Thanks >>> Max >>> >>> On 4/29/2015 3:23 PM, Artem Smotrakov wrote: >>>> Hello, >>>> >>>> Please review this fix for >>>> javax/security/auth/Subject/doAs/NestedActions.java test. >>>> >>>> The test runs java in a separate process. It fails if multiple java >>>> options are passed because ProcessBuilder expects each parameter to be >>>> put in to a separate array element, but the test didn't do that. I >>>> updated the test to split java option string, and put each option in a >>>> separate array element. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076486 >>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8076486/webrev.00/ >>>> >>>> Artem >> From steffen.mueller4 at kit.edu Tue May 5 13:08:03 2015 From: steffen.mueller4 at kit.edu (Mueller, Steffen (AIFB)) Date: Tue, 5 May 2015 15:08:03 +0200 Subject: SSLSocket renegotiation issue (JSSE) Message-ID: <0138BCE7F443E641ACB114A667C0AEA8A40E4F3B4A@KIT-MSX-05.kit.edu> Hi, We have previously posted the following questions at jdk8-dev at openjdk.java.net in a slightly different version - we have some further insights, since we have posted the questions the last time. A member of jdk8-dev at openjdk.java.net advised us to post the questions here again... We did not find anything regarding our questions in the archive or in the Web. We have some questions regarding the renegotiation of SSLSockets (JSSE). Preconditions: - We installed the OpenJDK 8 update 40 (+ JCE unlimited strength policies) to run a distributed system that replicates its state over SSL-based socket connections - It is a peer-to-peer system. So, there is a set of socket connections between the various nodes of the distributed system - We only allow TLS 1.2 connections, so we get the SSLContext within the application by invoking: SSLContext ctx = SSLContext.getInstance("TLSv1.2"); KeyManager[] kms = KeyManagerFactory.getInstance("SunX509").getKeyManagers(); TrustManager[] tms = TrustManagerFactory.getInstance("SunX509").getTrustManagers(); ctx.init(kms, tms, null); - Furthermore, we enable a list of cipher suites for socket, i.e., we invoke socket.setEnabledCipherSuites(new String[]{"TLS_RSA_WITH_AES_128_CBC_SHA","TLS_RSA_WITH_AES_256_CBC_SHA","TLS_DHE_RSA_WITH_AES_128_CBC_SHA",...}); Goal: After the connection is established and used by the nodes to communicate their states within the cluster, we need to renegotiate the SSL connection after a while. Additionally, we want to change the negotiated cipher suite. For example, if the negotiated cipher suite is "TLS_RSA_WITH_AES_256_CBC_SHA" we want to change the cipher suite to "TLS_RSA_WITH_AES_128_CBC_SHA". So, we invoke: socket.setEnabledCipherSuites(new String[]{"TLS_RSA_WITH_AES_128_CBC_SHA"}); if(!resume) socket.getSession().invalidate(); socket.startHandshake(); Problem: However, the cipher suite does not change (neither resume = true nor resume = false). Even the renegotiation is not always performed. A previously registered HandshakeCompletedListener is not invoked anyway. And if the debug log indicates that the handshake have been performed the previously negotiated cipher suite ("TLS_RSA_WITH_AES_256_CBC_SHA") is used again. The debug log does not give us any hint what could be wrong. We tested the renegotiation procedure on an adjusted JDK-Test case (RejectClientRenego)... It works. However, in the test case (RejectClientRenego) the application layer does not send any application data to the SSLSocket while the renegotiation is being done... Furthermore, the test case is a single thread case. In our system multiple worker threads communicate over one socket connection and the renegotiation is invoked by a JMX MBean. So, we have the questions: Are we doing something wrong? Is it possible/allowed to renegotiate the cipher suite for a connected socket which is used continuously by the application layer while the renegotiation is performed? Following the Javadoc of javax.net.ssl.SSLSocket.startHandshake() this should be possible ("If data has already been sent on the connection, it continues to flow during this handshake. When the handshake completes, this will be signaled with an event."). Do you have any other hints to solve our problems/to implement the desired behavior? ... Thanks Steffen Mueller -------------- next part -------------- An HTML attachment was scrubbed... URL: From fweimer at redhat.com Tue May 5 18:54:56 2015 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 05 May 2015 20:54:56 +0200 Subject: [9] RFC: 8061798: Add support for TLS_FALLBACK_SCSV (RFC 7507) Message-ID: <55491200.6010308@redhat.com> Here's a slightly updated version of the patch to implement TLS_FALLBACK_SCSV: Compared to the previous version, I added a references to RFC 7507, and addressed some drift in CipherSuite.java. I still believe very strongly that the additional APIs are desirable. If we put the cipher suite into the regular cipher suite selector, administrators will add it to application configurations ?to fix POODLE?. This works fine right now, but will create a new form of TLS intolerance once servers start supporting TLS 1.3. With separate APIs, this is less likely because for this to happen, applications would have to actually support this as a configuration option, which hopefully will not pass code review. For the backport to JDK8, I propose to backport the server-side change only, so there will be no API impact. -- Florian Weimer / Red Hat Product Security From sean.mullan at oracle.com Tue May 5 21:37:47 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 05 May 2015 17:37:47 -0400 Subject: RFR: JDK-8075706 : Policy implementation does not allow policy.provider to be on the class path In-Reply-To: <5547D329.6040008@oracle.com> References: <55437626.7070501@oracle.com> <5547884E.4090507@oracle.com> <5547D329.6040008@oracle.com> Message-ID: <5549382B.8040506@oracle.com> I was trying to avoid too many changes, but in the end I decided it was better to refactor some of this code into a new method. So here is the new webrev: http://cr.openjdk.java.net/~mullan/webrevs/8075706/webrev.02/ Changes include: - bootstrapping code moved to new method named loadPolicyProvider - added Alan's suggestion to fallback to SCL only if CNFE is thrown - instantiated default policy provider directly instead of using reflection if property has not been changed or is not set - addressed Mandy's comment about formatting - enhanced test to cover more cases Thanks, Sean On 05/04/2015 04:14 PM, Sean Mullan wrote: > On 05/04/2015 10:55 AM, Alan Bateman wrote: >> On 01/05/2015 13:48, Sean Mullan wrote: >>> Please review this change to use the system class loader to locate a >>> policy provider specified with the policy.provider security property. >>> The current implementation tries to load the provider using the >>> extension class loader. This will no longer work when the extension >>> mechanism is removed, which is proposed as part of JEP 220: >>> http://openjdk.java.net/jeps/220 >>> >>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8075706/webrev.01/ >> The change looks okay but I wonder if there is an opportunity to do some >> clean-up. > > Yes, definitely, but OTOH it's been mostly working fine for years, and > it's a fragile area, so we need to proceed with care :) > >> One thing that is a bit icky is the catching of Exception for the case >> that the policy class is loaded by boot loader but it can't be >> instantiated for some reason. It might be better to replace this with >> Class.forName(policy_class, false, null) and only fallback to trying >> again with the SCL if CNFE is thrown. That way you could have once place >> to instantiate the policy class and log the exception if it fails. > > That seems like a good idea. I'll change it, and if I get a good JPRT > run, I'll proceed with that change. > > --Sean From xuelei.fan at oracle.com Tue May 5 23:42:13 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 06 May 2015 07:42:13 +0800 Subject: [9] RFC: 8061798: Add support for TLS_FALLBACK_SCSV (RFC 7507) In-Reply-To: <55491200.6010308@redhat.com> References: <55491200.6010308@redhat.com> Message-ID: <55495555.2040004@oracle.com> As additional APIs are strongly desired, what do you think to make the API more general and easy to use? For example, using the name: SSLParameters.setUseFallbackMode(boolean isFallback) boolean SSLParameters.getuseFallbackMode() We can implement more for this parameters if need to take care of additional more problems during fallback negotiation. Instinctively, developers and code reviewers would not call this APIs unless this is a real fallback negotiation, I think. Thanks, Xuelei On 5/6/2015 2:54 AM, Florian Weimer wrote: > Here's a slightly updated version of the patch to implement > TLS_FALLBACK_SCSV: > > > > Compared to the previous version, I added a references to RFC 7507, and > addressed some drift in CipherSuite.java. > > I still believe very strongly that the additional APIs are desirable. > If we put the cipher suite into the regular cipher suite selector, > administrators will add it to application configurations ?to fix > POODLE?. This works fine right now, but will create a new form of TLS > intolerance once servers start supporting TLS 1.3. With separate APIs, > this is less likely because for this to happen, applications would have > to actually support this as a configuration option, which hopefully will > not pass code review. > > For the backport to JDK8, I propose to backport the server-side change > only, so there will be no API impact. > From weijun.wang at oracle.com Wed May 6 01:24:14 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 06 May 2015 09:24:14 +0800 Subject: [9] RFR: 8076486: javax/security/auth/Subject/doAs/NestedActions.java fails if extra VM options are given In-Reply-To: <5548E95F.4080401@oracle.com> References: <554086E0.9080007@oracle.com> <5540E4DC.3080802@oracle.com> <5540FC52.6030802@oracle.com> <554732AB.2090307@oracle.com> <5548E95F.4080401@oracle.com> Message-ID: <55496D3E.8050201@oracle.com> Great. It's now at http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fff8ab918557. Thanks Max On 5/6/2015 12:01 AM, Artem Smotrakov wrote: > Hi Max, > > It works fine if a sting starts with a whitespace. It looks like that > jtreg removes whitespaces. Here is a command to run the test, and a > piece of jtr file: > > ${JAVA_HOME}/bin/java -jar /home/artem/tools/jtreg/4.1/lib/jtreg.jar -a > -v -testjdk ${JAVA_HOME} -javaoptions:" -XX:+UseG1GC > -XX:+CreateMinidumpOnCrash " > -dir:/home/artem/ws/jdk/jdk9_dev_jaas_nested_action_tests/jdk/test > javax/security/auth/Subject/doAs/NestedActions.java > > ... > /home/artem/jdk/jdk1.9.0b61/bin/java \\ > -Dtest.vm.opts= \\ > -Dtest.jdk=/home/artem/jdk/jdk1.9.0b61 \\ > -Dtest.timeout.factor=1.0 \\ > -Dtest.src.path=/home/artem/ws/jdk/jdk9_dev_jaas_nested_action_tests/jdk/test/javax/security/auth/Subject/doAs:/home/artem/ws/jdk/jdk9_dev_jaas_nested_action_tests/jdk/test/lib/testlibrary > \\ > -Dtest.compiler.opts= \\ > -Dcompile.jdk=/home/artem/jdk/jdk1.9.0b61 \\ > -Dtest.classes=/home/artem/results/jaas_nested_action_tests/JTwork/classes/javax/security/auth/Subject/doAs > \\ > -Dtest.class.path=/home/artem/results/jaas_nested_action_tests/JTwork/classes/javax/security/auth/Subject/doAs:/home/artem/results/jaas_nested_action_tests/JTwork/classes/lib/testlibrary > \\ > -Dtest.java.opts='-XX:+UseG1GC -XX:+CreateMinidumpOnCrash' \\ > -Dtest.src=/home/artem/ws/jdk/jdk9_dev_jaas_nested_action_tests/jdk/test/javax/security/auth/Subject/doAs > \\ > -Dtest.tool.vm.opts= \\ > -XX:+UseG1GC -XX:+CreateMinidumpOnCrash \\ > com.sun.javatest.regtest.MainWrapper > /home/artem/results/jaas_nested_action_tests/JTwork/classes/javax/security/auth/Subject/doAs/NestedActions.jta > NestedActionsTwoPrincipals policy.two.principals > NestedActionsTwoPrincipals.jar WriteToFileAction.jar > ReadFromFileAction.jar ReadPropertyAction.jar > ... > > But anyway, I added trim(), so now the test doesn't rely on jtreg. > Please take a look: > > http://cr.openjdk.java.net/~asmotrak/8076486/webrev.02/ > > Artem > > On 05/04/2015 11:49 AM, Weijun Wang wrote: >> Artem >> >> If a string starts with whitespace(s), the first element of >> split("\\s+") will be an empty string. If you can be sure JAVA_OPTS >> does not have them, your code change is fine. >> >> Thanks >> Max >> >> On 4/29/2015 11:44 PM, Artem Smotrakov wrote: >>> Hi Max, >>> >>> These fancy things sometimes make me forget about simpler ways :-) >>> >>> Please take a look >>> >>> http://cr.openjdk.java.net/~asmotrak/8076486/webrev.01/ >>> >>> Thanks! >>> >>> Artem >>> >>> On 04/29/2015 05:04 PM, Weijun Wang wrote: >>>> Maybe you can call JAVA_OPTS.trim().split("\\s+") to avoid the >>>> filtering. >>>> >>>> And it seems Collections.addAll() can add an array to a list. >>>> >>>> Of course, you are free to exercise any fancy jdk8 features. :-) >>>> >>>> Thanks >>>> Max >>>> >>>> On 4/29/2015 3:23 PM, Artem Smotrakov wrote: >>>>> Hello, >>>>> >>>>> Please review this fix for >>>>> javax/security/auth/Subject/doAs/NestedActions.java test. >>>>> >>>>> The test runs java in a separate process. It fails if multiple java >>>>> options are passed because ProcessBuilder expects each parameter to be >>>>> put in to a separate array element, but the test didn't do that. I >>>>> updated the test to split java option string, and put each option in a >>>>> separate array element. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076486 >>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8076486/webrev.00/ >>>>> >>>>> Artem >>> > From valerie.peng at oracle.com Wed May 6 02:21:17 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 05 May 2015 19:21:17 -0700 Subject: RFR 8078439: Kerberos auth fails if client proposes MS krb5 OID In-Reply-To: <5541F0A8.9050307@oracle.com> References: <553B15D9.2020609@oracle.com> <553C4B8D.1010003@oracle.com> <55418751.3030001@oracle.com> <5541F0A8.9050307@oracle.com> Message-ID: <55497A9D.9050701@oracle.com> Looks good to me. Thanks, Valerie On 4/30/2015 2:06 AM, Weijun Wang wrote: > Hi Valerie > > I've updated the test a little to make sure the exception is NO_CRED > and it's sent from the krb5 mech. > > It passed on my own machine and I'm running a JPRT job now. > > The webrev is at http://cr.openjdk.java.net/~weijun/8078439/webrev.02/ > > Thanks > Max > > On 4/30/2015 9:37 AM, Valerie Peng wrote: >> I think your current approach of using the mechList[0] makes sense. As >> long as the rest of our code will recognize this MS krb5 OID, it will be >> fine. >> >> The source changes look fine to me. >> Just some nits on the regression test "MSOID.java": >> 1) line 57 has a typo, aceptor -> acceptor >> 2) line 59, currently, this test will accept all GSSException as the >> expected exception which may be a little bit too liberal. Any chance >> that we can narrow it down to a certain error status code? Just so we >> don't accidentally allow the wrong exceptions. >> >> Thanks, >> Valerie >> >> On 4/25/2015 7:21 PM, Weijun Wang wrote: >>> Hi All >>> >>> I've updated the webrev at >>> >>> http://cr.openjdk.java.net/~weijun/8078439/webrev.01/ >>> >>> The only change is >>> >>> @@ -548,6 +548,7 @@ >>> "mechToken is missing"); >>> } >>> accept_token = GSS_acceptSecContext(mechToken); >>> + mech_wanted = mechList[0]; >>> } else { >>> accept_token = null; >>> } >>> >>> This means the supportedMech in response will be MS_KRB5_OID if it was >>> the preferred mech in the request. >>> >>> In my webrev.00, I insisted using the "correct" OID because that was >>> the way before JDK-8048194 and no one complained about it. Therefore I >>> think the client side is able to find out that it's also a flavor of >>> Kerberos 5 and has accepted it happily. So why fix it if it's not >>> broken? >>> >>> However, after writing a SSPI client myself, I find out that it does >>> not accept the "correct" ID and fail. Why didn't people notice that? >>> My understanding is that until now a client that sends those OIDs has >>> always been a browser, and this browser simply ignores the response if >>> it already sees a "200 OK" HTTP status. >>> >>> Thanks >>> Max >>> >>> On 4/25/2015 12:19 PM, Weijun Wang wrote: >>>> Hi All >>>> >>>> Please review a fix at >>>> >>>> http://cr.openjdk.java.net/~weijun/8078439 >>>> >>>> This is a regression triggered by JDK-8048194. In SPNEGO, a client >>>> might >>>> send NegTokenInit with OIDs being {MS_KRB5_OID, KRB5_OID} along with a >>>> krb5 AP-REQ as mechToken. Java did not understand MS_KRB5_OID but >>>> before >>>> JDK-8048194 it blindly accepted the mechToken and everything just went >>>> on fine. After JDK-8048194, it rejects the unknown OID and cannot >>>> establish a security context. >>>> >>>> The fix adds a tweak to recognize the MS_KRB5_OID. >>>> >>>> *Ivan*: >>>> >>>> Can you try out the patch on jdk8u? >>>> >>>> Thanks >>>> Max From fweimer at redhat.com Wed May 6 13:42:59 2015 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 06 May 2015 15:42:59 +0200 Subject: [9] RFC: 8061798: Add support for TLS_FALLBACK_SCSV (RFC 7507) In-Reply-To: <55495555.2040004@oracle.com> References: <55491200.6010308@redhat.com> <55495555.2040004@oracle.com> Message-ID: <554A1A63.8070809@redhat.com> On 05/06/2015 01:42 AM, Xuelei Fan wrote: > As additional APIs are strongly desired, what do you think to make the > API more general and easy to use? For example, using the name: > > SSLParameters.setUseFallbackMode(boolean isFallback) > boolean SSLParameters.getuseFallbackMode() > > We can implement more for this parameters if need to take care of > additional more problems during fallback negotiation. Instinctively, > developers and code reviewers would not call this APIs unless this is a > real fallback negotiation, I think. Sounds reasonable. I have add an @implNote mentioning that the default provider sends TLS_FALLBACK_SCSV. There are now additional tests which explicitly verify the cipher suite list sent by the client. -- Florian Weimer / Red Hat Product Security From alexander.v.stepanov at oracle.com Wed May 6 14:24:49 2015 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Wed, 06 May 2015 17:24:49 +0300 Subject: RFR [9] 8079478: some docs cleanup for sun.security Message-ID: <554A2431.6080503@oracle.com> Hello, Could you please review the following fix http://cr.openjdk.java.net/~avstepan/8079478/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8079478 Just some doc fixes. Please note: not sure if these docs should be fixed at all because in the new modular system these packages should (probably) not be visible. So please let me know if the fix is useless. Thanks, Alexander From weijun.wang at oracle.com Wed May 6 14:51:17 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 06 May 2015 22:51:17 +0800 Subject: RFR [9] 8079478: some docs cleanup for sun.security In-Reply-To: <554A2431.6080503@oracle.com> References: <554A2431.6080503@oracle.com> Message-ID: <554A2A65.5010906@oracle.com> I think they are good, at least for those wrong tags or @params with wrong names. It's always nice to use correct format even if the doc is not published. You're welcomed to fix other docs in java.security.* or jdk.security.* modules. Is there a handy tool so that we don't make same mistakes later? I know IntelliJ IDEA will show errors for wrong @params names, but it does not care about useless

s. Thanks Max On 5/6/2015 10:24 PM, alexander stepanov wrote: > Hello, > > Could you please review the following fix > http://cr.openjdk.java.net/~avstepan/8079478/webrev.00/ > > for > https://bugs.openjdk.java.net/browse/JDK-8079478 > > Just some doc fixes. > > Please note: not sure if these docs should be fixed at all because in > the new modular system these packages should (probably) not be visible. > > So please let me know if the fix is useless. > > Thanks, > Alexander > From alexander.v.stepanov at oracle.com Wed May 6 15:54:28 2015 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Wed, 06 May 2015 18:54:28 +0300 Subject: RFR [9] 8079478: some docs cleanup for sun.security In-Reply-To: <554A2A65.5010906@oracle.com> References: <554A2431.6080503@oracle.com> <554A2A65.5010906@oracle.com> Message-ID: <554A3934.6030208@oracle.com> Hello Max, Thanks! > Is there a handy tool so that we don't make same mistakes later? tidy tool (http://www.html-tidy.org/ - I guess on Ubuntu it could be installed by means of "apt-get install tidy") usually report such "empty

" warnings - but it checks the resulting HTML files, not the sources (so at first the docs should be built by means of javadoc). Unfortunately it does not recognize erroneous javadoc tags, like "@params" or "@returns", only HTML markup issues. Regards, Alexander On 06.05.2015 17:51, Weijun Wang wrote: > I think they are good, at least for those wrong tags or @params with > wrong names. It's always nice to use correct format even if the doc is > not published. > > You're welcomed to fix other docs in java.security.* or jdk.security.* > modules. > > Is there a handy tool so that we don't make same mistakes later? I > know IntelliJ IDEA will show errors for wrong @params names, but it > does not care about useless

s. > > Thanks > Max > > On 5/6/2015 10:24 PM, alexander stepanov wrote: >> Hello, >> >> Could you please review the following fix >> http://cr.openjdk.java.net/~avstepan/8079478/webrev.00/ >> >> for >> https://bugs.openjdk.java.net/browse/JDK-8079478 >> >> Just some doc fixes. >> >> Please note: not sure if these docs should be fixed at all because in >> the new modular system these packages should (probably) not be visible. >> >> So please let me know if the fix is useless. >> >> Thanks, >> Alexander >> From openjdk at suche.org Wed May 6 18:32:36 2015 From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Wed, 6 May 2015 20:32:36 +0200 Subject: [9] RFC: 8061798: Add support for TLS_FALLBACK_SCSV (RFC 7507) In-Reply-To: <554A1A63.8070809@redhat.com> References: <55491200.6010308@redhat.com> <55495555.2040004@oracle.com> <554A1A63.8070809@redhat.com> Message-ID: <554A5E44.4020405@suche.org> Hi, i looked at the patch files looks OK for me too. Since i also implemented it i can tel the server part ist ok. Once think i found maybe an optimisation: instead of mesg.protocolVersion.compareTo(getActiveProtocols().max) < 0 maybe use mesg.protocolVersion.v < getActiveProtocols().max.v in the server handshaker. Gru? Thomas On 06.05.2015 15:42, Florian Weimer wrote: > On 05/06/2015 01:42 AM, Xuelei Fan wrote: >> As additional APIs are strongly desired, what do you think to make the >> API more general and easy to use? For example, using the name: >> >> SSLParameters.setUseFallbackMode(boolean isFallback) >> boolean SSLParameters.getuseFallbackMode() >> >> We can implement more for this parameters if need to take care of >> additional more problems during fallback negotiation. Instinctively, >> developers and code reviewers would not call this APIs unless this is a >> real fallback negotiation, I think. > Sounds reasonable. I have add an @implNote mentioning that the default > provider sends TLS_FALLBACK_SCSV. > > > > There are now additional tests which explicitly verify the cipher suite > list sent by the client. > From xuelei.fan at oracle.com Wed May 6 23:39:47 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 07 May 2015 07:39:47 +0800 Subject: [9] RFC: 8061798: Add support for TLS_FALLBACK_SCSV (RFC 7507) In-Reply-To: <554A1A63.8070809@redhat.com> References: <55491200.6010308@redhat.com> <55495555.2040004@oracle.com> <554A1A63.8070809@redhat.com> Message-ID: <554AA643.4050101@oracle.com> On 5/6/2015 9:42 PM, Florian Weimer wrote: > On 05/06/2015 01:42 AM, Xuelei Fan wrote: >> As additional APIs are strongly desired, what do you think to make the >> API more general and easy to use? For example, using the name: >> >> SSLParameters.setUseFallbackMode(boolean isFallback) >> boolean SSLParameters.getuseFallbackMode() >> >> We can implement more for this parameters if need to take care of >> additional more problems during fallback negotiation. Instinctively, >> developers and code reviewers would not call this APIs unless this is a >> real fallback negotiation, I think. > > Sounds reasonable. I have add an @implNote mentioning that the default > provider sends TLS_FALLBACK_SCSV. > > > I guess the new webrev may be: http://cr.openjdk.java.net/~fweimer/8061798/webrev.02/ Xuelei > There are now additional tests which explicitly verify the cipher suite > list sent by the client. > From fweimer at redhat.com Thu May 7 06:01:22 2015 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 07 May 2015 08:01:22 +0200 Subject: [9] RFC: 8061798: Add support for TLS_FALLBACK_SCSV (RFC 7507) In-Reply-To: <554AA643.4050101@oracle.com> References: <55491200.6010308@redhat.com> <55495555.2040004@oracle.com> <554A1A63.8070809@redhat.com> <554AA643.4050101@oracle.com> Message-ID: <554AFFB2.6070500@redhat.com> On 05/07/2015 01:39 AM, Xuelei Fan wrote: > On 5/6/2015 9:42 PM, Florian Weimer wrote: >> On 05/06/2015 01:42 AM, Xuelei Fan wrote: >>> As additional APIs are strongly desired, what do you think to make the >>> API more general and easy to use? For example, using the name: >>> >>> SSLParameters.setUseFallbackMode(boolean isFallback) >>> boolean SSLParameters.getuseFallbackMode() >>> >>> We can implement more for this parameters if need to take care of >>> additional more problems during fallback negotiation. Instinctively, >>> developers and code reviewers would not call this APIs unless this is a >>> real fallback negotiation, I think. >> >> Sounds reasonable. I have add an @implNote mentioning that the default >> provider sends TLS_FALLBACK_SCSV. >> >> >> > I guess the new webrev may be: > http://cr.openjdk.java.net/~fweimer/8061798/webrev.02/ Right, sorry. -- Florian Weimer / Red Hat Product Security From zaiyao.liu at oracle.com Fri May 8 05:41:43 2015 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Fri, 08 May 2015 13:41:43 +0800 Subject: RFR 8048820: Implement tests for SecretKeyFactory In-Reply-To: <552618DF.7040502@oracle.com> References: <552618DF.7040502@oracle.com> Message-ID: <554C4C97.3050703@oracle.com> Hi Xuelei, Can you help to review this test code? Thanks Kevin ? 2015/4/9 14:14, zaiyao liu ??: > Hi All, > > Please review a couple of new tests for SecretKeyFactory.translateKey(). > > https://bugs.openjdk.java.net/browse/JDK-8048820 > http://cr.openjdk.java.net/~zailiu/8048820/webrev.00/ > > Thanks > > Kevin From zaiyao.liu at oracle.com Fri May 8 05:42:49 2015 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Fri, 08 May 2015 13:42:49 +0800 Subject: RFR 8048599: Tests for key wrap and unwrap operations In-Reply-To: <55272A3D.4060308@oracle.com> References: <55272A3D.4060308@oracle.com> Message-ID: <554C4CD9.8080305@oracle.com> Hi Max, Can you help to review this test code? Thanks Kevin ? 2015/4/10 9:41, zaiyao liu ??: > Hi All, > > Please help to review the new test for wrap and unwrap operations with > crypto keys. > > Webrev : http://cr.openjdk.java.net/~zailiu/8048599/webrev.00/ > JDK bug: https://bugs.openjdk.java.net/browse/JDK-8048599 > > Thanks > > Kevin From xuelei.fan at oracle.com Fri May 8 05:49:09 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 08 May 2015 13:49:09 +0800 Subject: RFR 8048820: Implement tests for SecretKeyFactory In-Reply-To: <554C4C97.3050703@oracle.com> References: <552618DF.7040502@oracle.com> <554C4C97.3050703@oracle.com> Message-ID: <554C4E55.4050901@oracle.com> Looks fine to me. Xuelei On 5/8/2015 1:41 PM, zaiyao liu wrote: > Hi Xuelei, > > Can you help to review this test code? > > Thanks > Kevin > ? 2015/4/9 14:14, zaiyao liu ??: >> Hi All, >> >> Please review a couple of new tests for SecretKeyFactory.translateKey(). >> >> https://bugs.openjdk.java.net/browse/JDK-8048820 >> http://cr.openjdk.java.net/~zailiu/8048820/webrev.00/ >> >> Thanks >> >> Kevin > From zaiyao.liu at oracle.com Fri May 8 05:58:05 2015 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Fri, 08 May 2015 13:58:05 +0800 Subject: RFR 8048820: Implement tests for SecretKeyFactory In-Reply-To: <554C4E55.4050901@oracle.com> References: <552618DF.7040502@oracle.com> <554C4C97.3050703@oracle.com> <554C4E55.4050901@oracle.com> Message-ID: <554C506D.6020308@oracle.com> Hi Xuelei, Thanks for review, Can you help to push it? Full comments: 8048820:Implement tests for SecretKeyFactory Reviewed-by: xuelei Contributed-by: Zaiyao Liu Thanks again. Kevin ? 2015/5/8 13:49, Xuelei Fan ??: > Looks fine to me. > > Xuelei > > On 5/8/2015 1:41 PM, zaiyao liu wrote: >> Hi Xuelei, >> >> Can you help to review this test code? >> >> Thanks >> Kevin >> ? 2015/4/9 14:14, zaiyao liu ??: >>> Hi All, >>> >>> Please review a couple of new tests for SecretKeyFactory.translateKey(). >>> >>> https://bugs.openjdk.java.net/browse/JDK-8048820 >>> http://cr.openjdk.java.net/~zailiu/8048820/webrev.00/ >>> >>> Thanks >>> >>> Kevin From sean.mullan at oracle.com Fri May 8 11:34:37 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 08 May 2015 07:34:37 -0400 Subject: RFR: JDK-6470634: (smartcardio) Typos at CardTerminals.list(CardTerminals.State) javadoc Message-ID: <554C9F4D.8010804@oracle.com> Please review this trivial fix to fix a couple of doc errors in the smartcardio API. Bug: https://bugs.openjdk.java.net/browse/JDK-6470634 Diffs: --- a/src/java.smartcardio/share/classes/javax/smartcardio/CardTerminals.java Fri May 08 11:02:33 2015 +0100 +++ b/src/java.smartcardio/share/classes/javax/smartcardio/CardTerminals.java Fri May 08 07:30:18 2015 -0400 @@ -94,9 +94,9 @@ * * @param state the State * @return an unmodifiable list of all terminals matching the specified - * attribute. + * state. * - * @throws NullPointerException if attr is null + * @throws NullPointerException if state is null * @throws CardException if the card operation failed */ public abstract List list(State state) throws CardException; Thanks, Sean From xuelei.fan at oracle.com Fri May 8 11:38:53 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 08 May 2015 19:38:53 +0800 Subject: RFR: JDK-6470634: (smartcardio) Typos at CardTerminals.list(CardTerminals.State) javadoc In-Reply-To: <554C9F4D.8010804@oracle.com> References: <554C9F4D.8010804@oracle.com> Message-ID: <554CA04D.50706@oracle.com> Looks fine to me. Xuelei On 5/8/2015 7:34 PM, Sean Mullan wrote: > Please review this trivial fix to fix a couple of doc errors in the > smartcardio API. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6470634 > > Diffs: > > --- > a/src/java.smartcardio/share/classes/javax/smartcardio/CardTerminals.java > Fri May 08 11:02:33 2015 +0100 > +++ > b/src/java.smartcardio/share/classes/javax/smartcardio/CardTerminals.java > Fri May 08 07:30:18 2015 -0400 > @@ -94,9 +94,9 @@ > * > * @param state the State > * @return an unmodifiable list of all terminals matching the > specified > - * attribute. > + * state. > * > - * @throws NullPointerException if attr is null > + * @throws NullPointerException if state is null > * @throws CardException if the card operation failed > */ > public abstract List list(State state) throws > CardException; > > Thanks, > Sean From weijun.wang at oracle.com Fri May 8 15:00:49 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 08 May 2015 23:00:49 +0800 Subject: RFR 8031111: fix krb5 caddr (and 8079821: MSOID2.java test is not perfect) Message-ID: <554CCFA1.4070800@oracle.com> Hi Valerie Please review the code change at http://cr.openjdk.java.net/~weijun/8031111/webrev.00/ The codes to read local addresses are updated. We are also supporting the extra_addresses krb5.conf setting. This code change triggers a bug (MSOID2.java) in a test I've recently added, please also review the change at http://cr.openjdk.java.net/~weijun/8079821/webrev.00/ Thanks Max From Alan.Bateman at oracle.com Fri May 8 15:11:27 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 08 May 2015 16:11:27 +0100 Subject: RFR: JDK-8075706 : Policy implementation does not allow policy.provider to be on the class path In-Reply-To: <5549382B.8040506@oracle.com> References: <55437626.7070501@oracle.com> <5547884E.4090507@oracle.com> <5547D329.6040008@oracle.com> <5549382B.8040506@oracle.com> Message-ID: <554CD21F.30707@oracle.com> On 05/05/2015 22:37, Sean Mullan wrote: > I was trying to avoid too many changes, but in the end I decided it > was better to refactor some of this code into a new method. So here is > the new webrev: > > http://cr.openjdk.java.net/~mullan/webrevs/8075706/webrev.02/ > > Changes include: > > - bootstrapping code moved to new method named loadPolicyProvider > - added Alan's suggestion to fallback to SCL only if CNFE is thrown > - instantiated default policy provider directly instead of using > reflection if property has not been changed or is not set > - addressed Mandy's comment about formatting > - enhanced test to cover more cases > I don't have cycles to look at the test but the changes to PolicyFile looks okay, and in line with what was there previously. As getting the value of the security.provider property involves a permission check then I assume that isSet is guaranteed to be called before this code executes, otherwise there would be another potential way to get recursive initialization. One small inconsistency is that Class.forName when trying to locate the provider on the boot loader doesn't run the static initializers whereas it does for the attempt to locate it via the system class loader. -Alan. From sean.mullan at oracle.com Fri May 8 15:28:46 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 08 May 2015 11:28:46 -0400 Subject: RFR: JDK-8075706 : Policy implementation does not allow policy.provider to be on the class path In-Reply-To: <554CD21F.30707@oracle.com> References: <55437626.7070501@oracle.com> <5547884E.4090507@oracle.com> <5547D329.6040008@oracle.com> <5549382B.8040506@oracle.com> <554CD21F.30707@oracle.com> Message-ID: <554CD62E.4010409@oracle.com> On 05/08/2015 11:11 AM, Alan Bateman wrote: > On 05/05/2015 22:37, Sean Mullan wrote: >> I was trying to avoid too many changes, but in the end I decided it >> was better to refactor some of this code into a new method. So here is >> the new webrev: >> >> http://cr.openjdk.java.net/~mullan/webrevs/8075706/webrev.02/ >> >> Changes include: >> >> - bootstrapping code moved to new method named loadPolicyProvider >> - added Alan's suggestion to fallback to SCL only if CNFE is thrown >> - instantiated default policy provider directly instead of using >> reflection if property has not been changed or is not set >> - addressed Mandy's comment about formatting >> - enhanced test to cover more cases >> > I don't have cycles to look at the test but the changes to PolicyFile > looks okay, and in line with what was there previously. As getting the > value of the security.provider property involves a permission check then > I assume that isSet is guaranteed to be called before this code > executes, otherwise there would be another potential way to get > recursive initialization. I don't think it is an issue, because it gets the property inside a doPriv and thus only system code is on the stack and the ACC is null, and so it never calls the policy provider. > One small inconsistency is that Class.forName when trying to locate the > provider on the boot loader doesn't run the static initializers whereas > it does for the attempt to locate it via the system class loader. Yes, that was there previously. --Sean From sean.mullan at oracle.com Fri May 8 18:09:47 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 08 May 2015 14:09:47 -0400 Subject: RFR: 8034820: Wrong isAssignableFrom test when adding Principal to Subject Message-ID: <554CFBEB.5030804@oracle.com> Please review this fairly trivial fix to correct an incorrect usage of Class.isAssignableFrom to check if a class is a superclass. bug: https://bugs.openjdk.java.net/browse/JDK-8034820 webrev: http://cr.openjdk.java.net/~mullan/webrevs/8034820/webrev.01/ Thanks, Sean From valerie.peng at oracle.com Fri May 8 23:05:12 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 08 May 2015 16:05:12 -0700 Subject: RFR: 8034820: Wrong isAssignableFrom test when adding Principal to Subject In-Reply-To: <554CFBEB.5030804@oracle.com> References: <554CFBEB.5030804@oracle.com> Message-ID: <554D4128.5040901@oracle.com> Looks good. Thanks, Valerie On 5/8/2015 11:09 AM, Sean Mullan wrote: > Please review this fairly trivial fix to correct an incorrect usage of > Class.isAssignableFrom to check if a class is a superclass. > > bug: https://bugs.openjdk.java.net/browse/JDK-8034820 > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8034820/webrev.01/ > > Thanks, > Sean From mandy.chung at oracle.com Fri May 8 23:07:58 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 08 May 2015 16:07:58 -0700 Subject: RFR: JDK-8075706 : Policy implementation does not allow policy.provider to be on the class path In-Reply-To: <5549382B.8040506@oracle.com> References: <55437626.7070501@oracle.com> <5547884E.4090507@oracle.com> <5547D329.6040008@oracle.com> <5549382B.8040506@oracle.com> Message-ID: <554D41CE.7030405@oracle.com> On 05/05/2015 02:37 PM, Sean Mullan wrote: > So here is the new webrev: > > http://cr.openjdk.java.net/~mullan/webrevs/8075706/webrev.02/ From mandy.chung at oracle.com Fri May 8 23:13:03 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 08 May 2015 16:13:03 -0700 Subject: RFR: JDK-8075706 : Policy implementation does not allow policy.provider to be on the class path In-Reply-To: <554D41CE.7030405@oracle.com> References: <55437626.7070501@oracle.com> <5547884E.4090507@oracle.com> <5547D329.6040008@oracle.com> <5549382B.8040506@oracle.com> <554D41CE.7030405@oracle.com> Message-ID: <554D42FF.3060308@oracle.com> On 05/05/2015 02:37 PM, Sean Mullan wrote: > So here is the new webrev: > > http://cr.openjdk.java.net/~mullan/webrevs/8075706/webrev.02/ It now instantiates the built-in policy file class if "policy.provider" not set at the beginning. Is it really necessary to load the custom policy provider class with boot loader first and then system class loader if not found? I wonder if this can be simplified to use system class loader directly. There might be some history hiding there? Nit: With diamond with anonymous classes support, you can simply use <>. Mandy From zaiyao.liu at oracle.com Mon May 11 02:14:39 2015 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Mon, 11 May 2015 10:14:39 +0800 Subject: RFR 8048599: Tests for key wrap and unwrap operations In-Reply-To: <55272A3D.4060308@oracle.com> References: <55272A3D.4060308@oracle.com> Message-ID: <5550108F.3070903@oracle.com> Hi Brad, Can you help to review this test code? Thanks Kevin ? 2015/4/10 9:41, zaiyao liu ??: > Hi All, > > Please help to review the new test for wrap and unwrap operations with > crypto keys. > > Webrev : http://cr.openjdk.java.net/~zailiu/8048599/webrev.00/ > JDK bug: https://bugs.openjdk.java.net/browse/JDK-8048599 > > Thanks > > Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon May 11 20:01:16 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 11 May 2015 16:01:16 -0400 Subject: RFR: JDK-8075706 : Policy implementation does not allow policy.provider to be on the class path In-Reply-To: <554D42FF.3060308@oracle.com> References: <55437626.7070501@oracle.com> <5547884E.4090507@oracle.com> <5547D329.6040008@oracle.com> <5549382B.8040506@oracle.com> <554D41CE.7030405@oracle.com> <554D42FF.3060308@oracle.com> Message-ID: <55510A8C.4010808@oracle.com> On 05/08/2015 07:13 PM, Mandy Chung wrote: > On 05/05/2015 02:37 PM, Sean Mullan wrote: >> So here is the new webrev: >> >> http://cr.openjdk.java.net/~mullan/webrevs/8075706/webrev.02/ > > It now instantiates the built-in policy file class if "policy.provider" > not set at the beginning. Is it really necessary to load the custom > policy provider class with boot loader first and then system class > loader if not found? I wonder if this can be simplified to use system > class loader directly. There might be some history hiding there? I don't have the history but if I had to guess it might have been thought to be an optimization to avoid searching through the classloader hierachy to find the extension classloader. Now that we are using the system classloader, I don't think it is necessary and the code is much cleaner if I change it as you suggest. New webrev: http://cr.openjdk.java.net/~mullan/webrevs/8075706/webrev.03/ > > Nit: With diamond with anonymous classes support, you can simply use <>. I tried that but I got a compiler error: > error: illegal start of type AccessController.doPrivileged((PrivilegedAction<>) It's possible this new feature doesn't work with lambda expressions and doPrivileged because of the additional cast that is required to distinguish the Action type. I'll experiment with it separately but for now I am just going to keep the code as-is. --Sean From mandy.chung at oracle.com Mon May 11 20:24:22 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 11 May 2015 13:24:22 -0700 Subject: RFR: JDK-8075706 : Policy implementation does not allow policy.provider to be on the class path In-Reply-To: <55510A8C.4010808@oracle.com> References: <55437626.7070501@oracle.com> <5547884E.4090507@oracle.com> <5547D329.6040008@oracle.com> <5549382B.8040506@oracle.com> <554D41CE.7030405@oracle.com> <554D42FF.3060308@oracle.com> <55510A8C.4010808@oracle.com> Message-ID: <55510FF6.5060602@oracle.com> On 05/11/2015 01:01 PM, Sean Mullan wrote: > I don't have the history but if I had to guess it might have been > thought to be an optimization to avoid searching through the > classloader hierachy to find the extension classloader. Now that we > are using the system classloader, I don't think it is necessary and > the code is much cleaner if I change it as you suggest. New webrev: > > http://cr.openjdk.java.net/~mullan/webrevs/8075706/webrev.03/ Looks good. Mandy From artem.smotrakov at oracle.com Tue May 12 14:28:49 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 12 May 2015 17:28:49 +0300 Subject: [9] RFR: 8050374: More Signature tests In-Reply-To: <5535DF59.1070203@oracle.com> References: <5535DF59.1070203@oracle.com> Message-ID: <55520E21.10301@oracle.com> Hello, I added 'randomness' key, and updated Offsets.java to use jdk.testlibrary.RandomFactory. Please take a look: http://cr.openjdk.java.net/~asmotrak/8050374/webrev.01/ Artem On 04/21/2015 08:25 AM, Artem Smotrakov wrote: > Hello, > > Please review a couple of new tests for Signature and SignedObject. > The test use different providers, that's why I put them to > provider-specific locations. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8050374 > Webrev: http://cr.openjdk.java.net/~asmotrak/8050374/webrev.00/ > > Artem From artem.smotrakov at oracle.com Tue May 12 15:32:19 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 12 May 2015 18:32:19 +0300 Subject: [9] RFR: 8074784: Additional tests for XML DSig API Message-ID: <55521D03.5000800@oracle.com> 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 vincent.x.ryan at oracle.com Wed May 13 11:07:10 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 13 May 2015 12:07:10 +0100 Subject: [9] request for review 8068180: sun/security/pkcs11 tests are still in ProblemList.txt Message-ID: <7AE17F5F-15E6-451C-A3DE-0FFA704B0672@oracle.com> Please review this trivial change to liberate the following 4 tests from the problem list: sun/security/pkcs11/Secmod/AddPrivateKey.java sun/security/pkcs11/ec/ReadCertificates.java sun/security/pkcs11/ec/ReadPKCS12.java sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java These tests were failing due to an ancient version of NSS on but now pass without problems. Bug: https://bugs.openjdk.java.net/browse/JDK-8068180 Webrev: http://cr.openjdk.java.net/~vinnie/8068180/webrev.00/ Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed May 13 11:46:20 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 13 May 2015 07:46:20 -0400 Subject: [9] request for review 8068180: sun/security/pkcs11 tests are still in ProblemList.txt In-Reply-To: <7AE17F5F-15E6-451C-A3DE-0FFA704B0672@oracle.com> References: <7AE17F5F-15E6-451C-A3DE-0FFA704B0672@oracle.com> Message-ID: <5553398C.7020504@oracle.com> Looks good to me. --Sean On 05/13/2015 07:07 AM, Vincent Ryan wrote: > Please review this trivial change to liberate the following 4 tests from > the problem list: > > sun/security/pkcs11/Secmod/AddPrivateKey.java > sun/security/pkcs11/ec/ReadCertificates.java > sun/security/pkcs11/ec/ReadPKCS12.java > sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java > > These tests were failing due to an ancient version of NSS on but now > pass without problems. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8068180 > Webrev: http://cr.openjdk.java.net/~vinnie/8068180/webrev.00/ > > Thanks. From vincent.x.ryan at oracle.com Wed May 13 11:58:21 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 13 May 2015 12:58:21 +0100 Subject: [9] request for review 8068180: sun/security/pkcs11 tests are still in ProblemList.txt In-Reply-To: <5553398C.7020504@oracle.com> References: <7AE17F5F-15E6-451C-A3DE-0FFA704B0672@oracle.com> <5553398C.7020504@oracle.com> Message-ID: <1679D583-9F20-46DA-A05B-7ED6F2CB2226@oracle.com> Thanks. > On 13 May 2015, at 12:46, Sean Mullan wrote: > > Looks good to me. > > --Sean > > On 05/13/2015 07:07 AM, Vincent Ryan wrote: >> Please review this trivial change to liberate the following 4 tests from >> the problem list: >> >> sun/security/pkcs11/Secmod/AddPrivateKey.java >> sun/security/pkcs11/ec/ReadCertificates.java >> sun/security/pkcs11/ec/ReadPKCS12.java >> sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java >> >> These tests were failing due to an ancient version of NSS on but now >> pass without problems. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8068180 >> Webrev: http://cr.openjdk.java.net/~vinnie/8068180/webrev.00/ >> >> Thanks. From weijun.wang at oracle.com Wed May 13 14:16:08 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 13 May 2015 22:16:08 +0800 Subject: RFR 8077102: dns_lookup_realm should be false by default Message-ID: <55535CA8.7000400@oracle.com> Hi All Please take a look at http://cr.openjdk.java.net/~weijun/8077102/webrev.00/ Before this fix, dns_lookup_realm true is by default. This is not consistent with other krb5 vendors. It also leads to lot of time waste when Kerberos 5 is not configured at all. The no-krb5.conf test case in ConfPlusProp.java is removed because with dns_lookup_kdc still being true by default, the test can timeout on some systems. Thanks Max From vincent.x.ryan at oracle.com Wed May 13 15:52:30 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 13 May 2015 16:52:30 +0100 Subject: [9] request for review 8072578: ProbeKeystores.java creates files in test.src Message-ID: <97CF4664-250E-40FB-B8A9-3426C55BCC8E@oracle.com> Please review this test correction to avoid creating temporary keystore files in the test source directory. Thanks. Bug: https://bugs.openjdk.java.net/browse/JDK-8072578 Webrev: http://cr.openjdk.java.net/~vinnie/8072578/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Thu May 14 00:27:56 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 13 May 2015 17:27:56 -0700 Subject: RFR 8077102: dns_lookup_realm should be false by default In-Reply-To: <55535CA8.7000400@oracle.com> References: <55535CA8.7000400@oracle.com> Message-ID: <5553EC0C.30708@oracle.com> Changes look fine. Thanks, Valerie On 5/13/2015 7:16 AM, Weijun Wang wrote: > Hi All > > Please take a look at > > http://cr.openjdk.java.net/~weijun/8077102/webrev.00/ > > Before this fix, dns_lookup_realm true is by default. This is not > consistent with other krb5 vendors. It also leads to lot of time waste > when Kerberos 5 is not configured at all. > > The no-krb5.conf test case in ConfPlusProp.java is removed because > with dns_lookup_kdc still being true by default, the test can timeout > on some systems. > > Thanks > Max From weijun.wang at oracle.com Thu May 14 05:30:04 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 14 May 2015 13:30:04 +0800 Subject: On 8058290: JAAS Krb5LoginModule has suspect ticket-renewal logic, relies on clockskew grace Message-ID: <555432DC.6020101@oracle.com> Hi All This is about the bug https://bugs.openjdk.java.net/browse/JDK-8058290 I'm now thinking that with renewTGT=true we should always renew the ticket no matter if it's new or old. This means the TGT will be always the latest inside the subject. How is your opinion? The source fix will be easy but I'd like to get some feedback before writing regression tests for it. Thanks Max From weijun.wang at oracle.com Thu May 14 14:29:37 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 14 May 2015 22:29:37 +0800 Subject: [9] request for review 8072578: ProbeKeystores.java creates files in test.src In-Reply-To: <97CF4664-250E-40FB-B8A9-3426C55BCC8E@oracle.com> References: <97CF4664-250E-40FB-B8A9-3426C55BCC8E@oracle.com> Message-ID: <5554B151.2060107@oracle.com> Hi Vinnie Is there any reason why they cannot be simply created in the current directory? In fact, if you put them there, then you don't need to clean them up because jtreg will do that for you. If the test fails some day, they will be retained for your diagnostics. Thanks Max On 5/13/2015 11:52 PM, Vincent Ryan wrote: > Please review this test correction to avoid creating temporary keystore > files in the test source directory. > Thanks. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8072578 > Webrev: http://cr.openjdk.java.net/~vinnie/8072578/webrev.00/ > > From vincent.x.ryan at oracle.com Thu May 14 15:14:14 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 14 May 2015 16:14:14 +0100 Subject: [9] request for review 8072578: ProbeKeystores.java creates files in test.src In-Reply-To: <5554B151.2060107@oracle.com> References: <97CF4664-250E-40FB-B8A9-3426C55BCC8E@oracle.com> <5554B151.2060107@oracle.com> Message-ID: <3A7E01F7-7158-4C63-8F58-5B5DEAB9FEF7@oracle.com> That makes more sense. I?ve updated the webrev in place. > On 14 May 2015, at 15:29, Weijun Wang wrote: > > Hi Vinnie > > Is there any reason why they cannot be simply created in the current directory? > > In fact, if you put them there, then you don't need to clean them up because jtreg will do that for you. If the test fails some day, they will be retained for your diagnostics. > > Thanks > Max > > On 5/13/2015 11:52 PM, Vincent Ryan wrote: >> Please review this test correction to avoid creating temporary keystore >> files in the test source directory. >> Thanks. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8072578 >> Webrev: http://cr.openjdk.java.net/~vinnie/8072578/webrev.00/ >> >> From artem.smotrakov at oracle.com Fri May 15 16:25:24 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 15 May 2015 19:25:24 +0300 Subject: [9] RFR: 8079138: Additional negative tests for XML signature processing Message-ID: <55561DF4.9030405@oracle.com> Hello, Please review a couple of negative tests which check that invalid XML digital signatures are rejected. Bug: https://bugs.openjdk.java.net/browse/JDK-8079138 Webrev: http://cr.openjdk.java.net/~asmotrak/8079138/webrev.01/ Artem From sean.mullan at oracle.com Fri May 15 17:01:31 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 15 May 2015 13:01:31 -0400 Subject: RFR: 8055753: Use ConcurrentHashMap to map ProtectionDomain to PermissionCollection Message-ID: <5556266B.3030506@oracle.com> This is the first in a series of fixes that I will be sending out for review for JEP 232 (Improve Secure Application Performance) [1]. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8055753/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8055753 This fix changes the ProtectionDomain (PD) cache from a synchronized HashMap to a ConcurrentHashMap. This increases the throughput of the Policy.implies method up to ~3x (when the PD is cached) as more threads are added. The bug contains a performance chart with more details. Since the previous code used a WeakHashMap, and there is no equivalent WeakConcurrentHashMap, I have added some additional code to check for and remove weak keys from the ConcurrentHashMap. Finally, I had to undo the fix for JDK-8078989 [2] in this fix. That fix has some problems and is likely the cause of another regression we have seen [3]. I am still investigating that, but I will likely re-open that bug before I push this fix back. Thanks, Sean [1] http://openjdk.java.net/jeps/232 [2] https://bugs.openjdk.java.net/browse/JDK-8078989 [3] https://bugs.openjdk.java.net/browse/JDK-8077418 From ivan.gerasimov at oracle.com Fri May 15 17:28:41 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 15 May 2015 20:28:41 +0300 Subject: RFR: 8080522: Optimize string operations in java.base/share/classes/sun/security/x509/ Message-ID: <55562CC9.8010200@oracle.com> Hello! Would you please help review this cleanup fix. This is meant to deal only with String-related operations. http://cr.openjdk.java.net/~igerasim/8080522/00/webrev/ Sincerely yours, Ivan From artem.smotrakov at oracle.com Fri May 15 18:23:42 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 15 May 2015 21:23:42 +0300 Subject: [9] RFR: 8079140: IgnoreAllErrorHandler should use doPrivileged when it reads system properties Message-ID: <555639AE.6010706@oracle.com> Hello, Please review this fix for 9. If security manager is enabled, but "org.jcp.xml.dsig.secureValidation" property is off, IgnoreAllErrorHandler tries to read two system properties. If appropriate permissions are not granted, it fails with ExceptionInInitializerError. Changes: - updated IgnoreAllErrorHandler to read system properties in doPrivileged() method - added "final" and @Override annotations - added ErrorHandlerPermissions test Bug: https://bugs.openjdk.java.net/browse/JDK-8079140 Webrev: http://cr.openjdk.java.net/~asmotrak/8079140/webrev.00/ Artem From fengzm at sg.ibm.com Fri May 15 20:04:33 2015 From: fengzm at sg.ibm.com (Zhemin Feng) Date: Sat, 16 May 2015 04:04:33 +0800 Subject: AUTO: Zhemin Feng is out of the office (returning 05/18/2015) Message-ID: I am out of the office until 05/18/2015. I will take leave from 15th May, and will be back on 18th May. Please contact Ke Pi/Singapore/IBM and Tianyu Tang/Singapore/IBM for Java Security L3 work. Best regards, Feng Zhemin Note: This is an automated response to your message "security-dev Digest, Vol 95, Issue 10" sent on 05/16/2015 1:28:45. This is the only notification you will receive while this person is away. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon May 18 14:00:01 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 18 May 2015 10:00:01 -0400 Subject: [9] RFR: 8079140: IgnoreAllErrorHandler should use doPrivileged when it reads system properties In-Reply-To: <555639AE.6010706@oracle.com> References: <555639AE.6010706@oracle.com> Message-ID: <5559F061.8060603@oracle.com> Hi Artem, This fix looks good but I would prefer that you did not use a lambda expression for reading the system properties (lines 50-52) because ideally this code needs to stay in sync with the Apache Santuario implementation which still supports JDK 1.6 and up. Thanks, Sean On 05/15/2015 02:23 PM, Artem Smotrakov wrote: > Hello, > > Please review this fix for 9. > > If security manager is enabled, but "org.jcp.xml.dsig.secureValidation" > property is off, IgnoreAllErrorHandler tries to read two system > properties. If appropriate permissions are not granted, it fails with > ExceptionInInitializerError. > > Changes: > - updated IgnoreAllErrorHandler to read system properties in > doPrivileged() method > - added "final" and @Override annotations > - added ErrorHandlerPermissions test > > Bug: https://bugs.openjdk.java.net/browse/JDK-8079140 > Webrev: http://cr.openjdk.java.net/~asmotrak/8079140/webrev.00/ > > Artem From sean.mullan at oracle.com Mon May 18 14:04:19 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 18 May 2015 10:04:19 -0400 Subject: RFR: 8080522: Optimize string operations in java.base/share/classes/sun/security/x509/ In-Reply-To: <55562CC9.8010200@oracle.com> References: <55562CC9.8010200@oracle.com> Message-ID: <5559F163.4080501@oracle.com> This cleanup fix looks good. --Sean On 05/15/2015 01:28 PM, Ivan Gerasimov wrote: > Hello! > > Would you please help review this cleanup fix. > This is meant to deal only with String-related operations. > > http://cr.openjdk.java.net/~igerasim/8080522/00/webrev/ > > Sincerely yours, > Ivan From sean.mullan at oracle.com Mon May 18 14:19:10 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 18 May 2015 10:19:10 -0400 Subject: [9] RFR: 8079138: Additional negative tests for XML signature processing In-Reply-To: <55561DF4.9030405@oracle.com> References: <55561DF4.9030405@oracle.com> Message-ID: <5559F4DE.6030606@oracle.com> These new tests look fine to me. --Sean On 05/15/2015 12:25 PM, Artem Smotrakov wrote: > Hello, > > Please review a couple of negative tests which check that invalid XML > digital signatures are rejected. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8079138 > Webrev: http://cr.openjdk.java.net/~asmotrak/8079138/webrev.01/ > > Artem From artem.smotrakov at oracle.com Mon May 18 15:17:49 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 18 May 2015 18:17:49 +0300 Subject: [9] RFR: 8079140: IgnoreAllErrorHandler should use doPrivileged when it reads system properties In-Reply-To: <5559F061.8060603@oracle.com> References: <555639AE.6010706@oracle.com> <5559F061.8060603@oracle.com> Message-ID: <555A029D.3090207@oracle.com> Hi Sean, Ok, I updated the webrev, please take a look: http://cr.openjdk.java.net/~asmotrak/8079140/webrev.01/ Artem On 05/18/2015 05:00 PM, Sean Mullan wrote: > Hi Artem, > > This fix looks good but I would prefer that you did not use a lambda > expression for reading the system properties (lines 50-52) because > ideally this code needs to stay in sync with the Apache Santuario > implementation which still supports JDK 1.6 and up. > > Thanks, > Sean > > On 05/15/2015 02:23 PM, Artem Smotrakov wrote: >> Hello, >> >> Please review this fix for 9. >> >> If security manager is enabled, but "org.jcp.xml.dsig.secureValidation" >> property is off, IgnoreAllErrorHandler tries to read two system >> properties. If appropriate permissions are not granted, it fails with >> ExceptionInInitializerError. >> >> Changes: >> - updated IgnoreAllErrorHandler to read system properties in >> doPrivileged() method >> - added "final" and @Override annotations >> - added ErrorHandlerPermissions test >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8079140 >> Webrev: http://cr.openjdk.java.net/~asmotrak/8079140/webrev.00/ >> >> Artem From jason.uh at oracle.com Tue May 19 23:17:05 2015 From: jason.uh at oracle.com (Jason Uh) Date: Tue, 19 May 2015 16:17:05 -0700 Subject: [9] RFR 8079693: Add support for ECDSA P-384 and P-521 curves to XML Signature Message-ID: <555BC471.8020404@oracle.com> Please review this change, which adds support for two curves to XML Signature. webrev: http://cr.openjdk.java.net/~juh/8079693/00/ bug: https://bugs.openjdk.java.net/browse/JDK-8079693 Thanks, Jason From bradford.wetmore at oracle.com Wed May 20 00:30:02 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 19 May 2015 17:30:02 -0700 Subject: JEP 244: TLS Application-Layer Protocol Negotiation Extension In-Reply-To: <552C8356.2020804@oracle.com> References: <20150409223635.74AFC555B2@eggemoggin.niobe.net> <552BD9AD.7070000@suche.org> <552BED2A.70903@redhat.com> <552BF95E.6090604@suche.org> <552C8356.2020804@oracle.com> Message-ID: <555BD58A.8070302@oracle.com> Hi Simone/Thomas/David/others, Thomas wrote: > would it not be an great idea to combine all these new extensions to > an generic way how to handle the SSL Protocol Handshake ? I've finally been able to deep dive back into ALPN, specifically looking at the ideas of a general Hello extension framework, but also a more general handshaking framework that could support additional/future handshake message types (e.g. NPN/CertificateStatus/SupplementalData/SessionTicket). After reading lots of current/proposed/private TLS extension RFCs[1][4], I concur with much of what Xuelei wrote previously (see below). I also agree that having a Hello+extension explorer/modifier would have some utility for ALPN and a few others (including TLS_FALLBACK_SCSV), but many of the current extensions require modifications to the protocol/calculations and/or the KeyManager/TrustManagers and thus can't simply be bolted into SunJSSE using the current APIs/implementations. In most cases, it requires modification of the underlying SunJSSE implementation to support them, or else a strong working knowledge of the TLS protocol to make the right insertions in the right place. I have varying degrees of familiarity with these extensions, so I may have missed an obvious way to implement something and am certainly open to suggestions, but here's the current extension list and my notes: # Extension Name Reference = ============== ========= 0 server_name [RFC6066] Currently supported 1 max_fragment_length [RFC6066] No: Protocol I/O modifications needed to generate proper sized packets. 2 client_certificate_url [RFC6066] No: Requires new KM/TM API style that knows how to fetch URLs 3 trusted_ca_keys [RFC6066] Yes: pretty straightforward 4 truncated_hmac [RFC6066] No: Protocol modifications needed 5 status_request [RFC6066] Currently under development for JDK 9[2] 6 user_mapping [RFC4681] Possible: need to insert Supplemental Data handshake message type into right place in handshake, but probably not too difficult. 7 client_authz [RFC5878] 8 server_authz [RFC5878] Possible: also must insert Supplemental Data into the right places in handshake, but probably not too difficult. 9 cert_type [RFC6091] No: Currently only support X509KM/X509TM, not OpenPGP credentials. 10 elliptic_curves [RFC4492] 11 ec_point_formats [RFC4492] Currently supported 12 srp [RFC5054] No: Requires new ciphersuites and ClientKeyExchange format support. 13 signature_algorithms [RFC5246] Currently supported 14 use_srtp [RFC5764] No: APIs do not expose the PRF and TLS master secret mechanisms. Might be able to talk RTP using socket overlays, but the other issues make this impossible. 15 heartbeat [RFC6520] No: Don't support heartbeat message type. 16 application_layer_protocol_negotiation [RFC7301] Currently under development for JDK 9[3] 17 status_request_v2 [RFC6961] Currently under development for JDK 9[2] 18 signed_certificate_timestamp [RFC6962] No: We might be able to support this extension, but it would be incomplete as OCSP doesn't support 1.3.6.1.4.1.11129.2.4.5. Clients must support X509v3 cert extension, TLS exension, and OCSP: servers only need to support one. 19 client_certificate_type [RFC7250] 20 server_certificate_type [RFC7250] No: We do support X509 certs, but we don't support Raw Public Keys with our current impl so this would not be a complete implementation. 21 padding [draft-ietf-tls-padding] Yes: but would require educated guesses on how much padding to add. 22 encrypt_then_mac [RFC7366] No: protocol modifications needed 23 extended_master_secret [draft-ietf-tls-session-hash] No: would require changes to the PRF computation parameters. 35 SessionTicket TLS [RFC4507] Possible: requires new SessionTicket message be sent in the right place, probably not too difficult. 13172 NPN [4] Possible: requires insertion of a NextProtocol message between CCS and Finished. 65281 renegotiation_info [RFC5746] Currently supported I also looked at extending the handshake examiner for channel bindings using either raw TLS X509Certs or Finished messages. It seems easier to me if developers had 2-4 methods with descriptive names rather than having to use a generic handshake message examiner/modifier and an intimate working knowledge of the TLS protocol. At this point, my feeling is to provide a default ALPN selector (using the server-ordered list), but also have a Hello Callback+Examiner with the ability to add/modify/delete extensions upon receipt/before transmission, including handling unknown/future extensions (getEncoded()). It will be up to the application to parse/handle said extensions. That would help guide HTTP-2 protocol/ciphersuite/ALPN selection (i.e. fallback to HTTP/1.1 if not TLSv1.2), plus the TLS_FALLBACK_SCSV (however, Florian's work might be in place soon), but I'm not sure how much additional use it will be. Initially I would probably expose via API only the supported extensions, along with an API for determining if an "unknown" extension is supported by the underlying implementation (SSLSocket/SSLEngine.isExtensionSupported()?). One last comment, the IETF released RFC 7540 (HTTP/2) last Friday. There are a few tweaks that we will need to make regarding keysizes, ciphersuites, and TLS renegotiation. We'll be filing bugs on those shortly. Thanks, Brad [1] http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml [2] https://bugs.openjdk.java.net/browse/JDK-8046321 JEP 249: OCSP Stapling for TLS [3] https://bugs.openjdk.java.net/browse/JDK-8051498 JEP 244: TLS Application-Layer Protocol Negotiation Extension [4] https://technotes.googlecode.com/git/nextprotoneg.html On 4/13/2015 8:02 PM, Xuelei Fan wrote: > Thanks for the proposal. > > A general TLS/DTLS extension API and pluginable extension implementation > is a good idea. But as there is no rules about how an extension may > impact the handshake flow, it is not easy to define a general APIs for > all existing known or unknown extensions and future extensions. For > example, an extension may impact the cipher suite selection, may need to > define new handshake messages, may need new algorithm implementation, > may impact the algorithm used to sign handshake messages, may impact the > algorithm used to protected application data, etc. An extension may > impact every details of handshaking, not only the client hello and > server hello messages. It would be great if there are general APIs that > are simple and cover the possible impact in every details of > handshaking. I'm open for more advices. > > Maybe we can have APIs to define the extension parameters, rather than > the handshake implementation. But as we already have SSLParameters, I > don't think we need extra APIs for extension parameters any more. > > JSSE is open source and an provider based framework. Alternatively, > we'd like to accept extension implementation contributions, or developer > can define their own private provider if necessary. > > Regards, > Xuelei > > On 4/14/2015 1:14 AM, Thomas Lu?nig wrote: >> Hi, >> >> this could be an interface for such an Callback. >> It allow hello extensions as well as handshake extensions. >> If it would be really clean we would have an handler for: >> - NPN >> - ALPN >> - Channel ID >> - ZertificateSignature >> - OCSP-Stapling >> - ServerName >> - Session Ticket >> >> The handler could be also used for handling: >> - TLS_FALLBACK_SCSV >> >> The current way is that all these extensions are in the sun Private >> package space >> and to make it even worse each extension is written in another way. >> Also i am missing an API defined way to extend the list in >> sun.security.ssl.CipherSuite. >> >> Gru? Thomas >> >> public interface HelloHandler { >> /** >> * Allow to add extesions to Server/Client Hello >> * based on the Client/Server hello */ >> public void handleHelloMessage(ClientHello clientHello, ServerHello serverHello); >> /** Allow to add new Handshake Messages based on >> * the Client/Server Hello >> */ >> public void sendHandshakeMessage(HandshakeOutStream handshakeOutStream, ClientHello clientHello, ServerHello serverHello); >> /** >> * define an order of the extensions >> */ >> Class runBefore(); >> /** >> * define an order of the extensions >> */ >> Class runAfter(); >> } >> >> >> >>> Hi, >>> >>> On Mon, Apr 13, 2015 at 6:22 PM, David M. Lloyd wrote: >>>> Do you know of a Java TLS implementation that has APIs like this already? I >>>> am also interested in this for the ability to implement authentication >>>> mechanisms (GSSAPI and SASL) that rely on channel binding, so I would like >>>> to see such an API materialize as well. >>> I posted a while back such APIs from 3rd party JSSE implementations: >>> http://mail.openjdk.java.net/pipermail/security-dev/2014-August/011014.html >>> (at the end). >>> >>> The problem that has been raised is that if you offer a generic TLS >>> extensions API, then the extension may have a semantic that it's not >>> implemented. >>> >>> Imagine this TLS extensions API already existed, to add extensions to SSLEngine. >>> Now, ALPN comes along as a new TLS extension. An application could >>> create their own ALPNExtension subclass (extending a standard one >>> provided by the TLS extensions API), and add it to the ClientHello. >>> But there is no code in the JDK that calls the application, asking (on >>> the server) to select one of the protocols, for then send back the >>> chosen protocol to the client. >>> This could be solved by a callback API at the moment the ClientHello >>> is received by the server (and the ServerHello by the client), so the >>> application can examine the ALPN protocols. >>> >>> The NPN extension was doing something even more complicated, creating >>> an additional TLS message that needed to be sent at the right time. >>> >>> It may be that a TLS extensions API (to add/remove/query TLS >>> extensions) *and* a callback API to analyze "hello" messages when they >>> are received is enough to cover a lot of cases, perhaps even all >>> currently existing ones. >>> >>> I asked for feedback some time ago about the status of the ALPN >>> implementation; would be great if the security team could update the >>> current status. >>> >> > From weijun.wang at oracle.com Wed May 20 02:20:51 2015 From: weijun.wang at oracle.com (Oracle) Date: Wed, 20 May 2015 10:20:51 +0800 Subject: RFR: 8055753: Use ConcurrentHashMap to map ProtectionDomain to PermissionCollection In-Reply-To: <5556266B.3030506@oracle.com> References: <5556266B.3030506@oracle.com> Message-ID: <8A943E2F-8BF9-4027-A7B2-0A582F0BBF4D@oracle.com> The code change looks fine. Some tiny suggestions on styles: Is it possible to move the definition of Key before key is assigned? Some left braces ("{") are on new lines, looks inconsistent with others. Line 465, /* -> /**. Thanks Max > ? 2015?5?16????1:01?Sean Mullan ??? > > This is the first in a series of fixes that I will be sending out for review for JEP 232 (Improve Secure Application Performance) [1]. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8055753/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8055753 > > This fix changes the ProtectionDomain (PD) cache from a synchronized HashMap to a ConcurrentHashMap. This increases the throughput of the Policy.implies method up to ~3x (when the PD is cached) as more threads are added. The bug contains a performance chart with more details. > > Since the previous code used a WeakHashMap, and there is no equivalent WeakConcurrentHashMap, I have added some additional code to check for and remove weak keys from the ConcurrentHashMap. > > Finally, I had to undo the fix for JDK-8078989 [2] in this fix. That fix has some problems and is likely the cause of another regression we have seen [3]. I am still investigating that, but I will likely re-open that bug before I push this fix back. > > Thanks, > Sean > > [1] http://openjdk.java.net/jeps/232 > [2] https://bugs.openjdk.java.net/browse/JDK-8078989 > [3] https://bugs.openjdk.java.net/browse/JDK-8077418 From weijun.wang at oracle.com Wed May 20 09:59:41 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 20 May 2015 17:59:41 +0800 Subject: [9] request for review 8072578: ProbeKeystores.java creates files in test.src In-Reply-To: <3A7E01F7-7158-4C63-8F58-5B5DEAB9FEF7@oracle.com> References: <97CF4664-250E-40FB-B8A9-3426C55BCC8E@oracle.com> <5554B151.2060107@oracle.com> <3A7E01F7-7158-4C63-8F58-5B5DEAB9FEF7@oracle.com> Message-ID: <555C5B0D.3030607@oracle.com> The code change looks fine. If it were me, I won't do any clean up. --Max On 5/14/2015 11:14 PM, Vincent Ryan wrote: > That makes more sense. I?ve updated the webrev in place. > > >> On 14 May 2015, at 15:29, Weijun Wang wrote: >> >> Hi Vinnie >> >> Is there any reason why they cannot be simply created in the current directory? >> >> In fact, if you put them there, then you don't need to clean them up because jtreg will do that for you. If the test fails some day, they will be retained for your diagnostics. >> >> Thanks >> Max >> >> On 5/13/2015 11:52 PM, Vincent Ryan wrote: >>> Please review this test correction to avoid creating temporary keystore >>> files in the test source directory. >>> Thanks. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8072578 >>> Webrev: http://cr.openjdk.java.net/~vinnie/8072578/webrev.00/ >>> >>> > From vincent.x.ryan at oracle.com Wed May 20 10:56:49 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 20 May 2015 11:56:49 +0100 Subject: [9] request for review 8072578: ProbeKeystores.java creates files in test.src In-Reply-To: <555C5B0D.3030607@oracle.com> References: <97CF4664-250E-40FB-B8A9-3426C55BCC8E@oracle.com> <5554B151.2060107@oracle.com> <3A7E01F7-7158-4C63-8F58-5B5DEAB9FEF7@oracle.com> <555C5B0D.3030607@oracle.com> Message-ID: <0D67AD47-9E71-4CD1-812E-273DCD870A3E@oracle.com> > On 20 May 2015, at 10:59, Weijun Wang wrote: > > The code change looks fine. Thanks. > > If it were me, I won't do any clean up. Previously there were some problems with cleanup on Windows. If that cleanup code is no longer necessary I?ll remove it. > > --Max > > On 5/14/2015 11:14 PM, Vincent Ryan wrote: >> That makes more sense. I?ve updated the webrev in place. >> >> >>> On 14 May 2015, at 15:29, Weijun Wang wrote: >>> >>> Hi Vinnie >>> >>> Is there any reason why they cannot be simply created in the current directory? >>> >>> In fact, if you put them there, then you don't need to clean them up because jtreg will do that for you. If the test fails some day, they will be retained for your diagnostics. >>> >>> Thanks >>> Max >>> >>> On 5/13/2015 11:52 PM, Vincent Ryan wrote: >>>> Please review this test correction to avoid creating temporary keystore >>>> files in the test source directory. >>>> Thanks. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8072578 >>>> Webrev: http://cr.openjdk.java.net/~vinnie/8072578/webrev.00/ >>>> >>>> >> From ivan.gerasimov at oracle.com Wed May 20 16:58:09 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 20 May 2015 19:58:09 +0300 Subject: [8u-dev] Request for review AND approval to backport: 8077102: Message-ID: <555CBD21.6060207@oracle.com> Hi! The backport required some manual editing, thus I'm asking for a review too. Would you please review and approve backporting this fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8077102 WEBREV: http://cr.openjdk.java.net/~igerasim/8077102/00/webrev/ The fix was tested on all available platforms, no failures. Sincerely yours, Ivan From openjdk at suche.org Wed May 20 19:15:30 2015 From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Wed, 20 May 2015 21:15:30 +0200 Subject: JEP 244: TLS Application-Layer Protocol Negotiation Extension In-Reply-To: <555BD58A.8070302@oracle.com> References: <20150409223635.74AFC555B2@eggemoggin.niobe.net> <552BD9AD.7070000@suche.org> <552BED2A.70903@redhat.com> <552BF95E.6090604@suche.org> <552C8356.2020804@oracle.com> <555BD58A.8070302@oracle.com> Message-ID: <555CDD52.1020301@suche.org> Hi, 1) There are two types of extensions: a) That modify the directly how the engine works like [max_fragment_length,heartbeat,encrypt_then_mac,extended_master_secret,SessionTicket,...] b) That provide information (modify the network protocol) like [npn,alpn,status_request,...] 2) Some of the extionsions could be called deprecated like heartbeat, npn and compression signed_certificate_timestamp -> could be done without ocsp interference via extra handshake message like you can see it on https://suche.org there are 3 ways how this can be archived Included in Certificate, OCSP-Response, Extra handshake Message. extended_master_secret -> would be hard to implement. There are two ways to enable better plugin/develop: + Expose the client handshake to KeyManager/TrustManager/Client/Server + Generic way to add extra messages [status_request, user_mapping, client_authz, server_authz, application_layer_protocol_negotiation, status_request_v2, signed_certificate_timestamp, npn, TLS_FALLBACK_SCSV Specially the information what the client can could be interesting for site owner to decide what he should take care and what is so unusual that it can be ignored. Gru? Thomas From sean.mullan at oracle.com Wed May 20 19:52:15 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 20 May 2015 15:52:15 -0400 Subject: [9] RFR: 8074784: Additional tests for XML DSig API In-Reply-To: <55521D03.5000800@oracle.com> References: <55521D03.5000800@oracle.com> Message-ID: <555CE5EF.5030409@oracle.com> 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.mullan at oracle.com Wed May 20 20:17:05 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 20 May 2015 16:17:05 -0400 Subject: RFR: 8055753: Use ConcurrentHashMap to map ProtectionDomain to PermissionCollection In-Reply-To: <8A943E2F-8BF9-4027-A7B2-0A582F0BBF4D@oracle.com> References: <5556266B.3030506@oracle.com> <8A943E2F-8BF9-4027-A7B2-0A582F0BBF4D@oracle.com> Message-ID: <555CEBC1.3080205@oracle.com> On 05/19/2015 10:20 PM, Oracle wrote: > The code change looks fine. > > Some tiny suggestions on styles: > > Is it possible to move the definition of Key before key is assigned? Sure. I will move it to the top of the class. > Some left braces ("{") are on new lines, looks inconsistent with others. Ok, will fix. > Line 465, /* -> /**. Will fix. Thanks, Sean > > Thanks > Max > >> ? 2015?5?16????1:01?Sean Mullan ??? >> >> This is the first in a series of fixes that I will be sending out for review for JEP 232 (Improve Secure Application Performance) [1]. >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8055753/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8055753 >> >> This fix changes the ProtectionDomain (PD) cache from a synchronized HashMap to a ConcurrentHashMap. This increases the throughput of the Policy.implies method up to ~3x (when the PD is cached) as more threads are added. The bug contains a performance chart with more details. >> >> Since the previous code used a WeakHashMap, and there is no equivalent WeakConcurrentHashMap, I have added some additional code to check for and remove weak keys from the ConcurrentHashMap. >> >> Finally, I had to undo the fix for JDK-8078989 [2] in this fix. That fix has some problems and is likely the cause of another regression we have seen [3]. I am still investigating that, but I will likely re-open that bug before I push this fix back. >> >> Thanks, >> Sean >> >> [1] http://openjdk.java.net/jeps/232 >> [2] https://bugs.openjdk.java.net/browse/JDK-8078989 >> [3] https://bugs.openjdk.java.net/browse/JDK-8077418 From artem.smotrakov at oracle.com Wed May 20 20:16:37 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 20 May 2015 23:16:37 +0300 Subject: [9] RFR: 8074784: Additional tests for XML DSig API In-Reply-To: <555CE5EF.5030409@oracle.com> References: <55521D03.5000800@oracle.com> <555CE5EF.5030409@oracle.com> Message-ID: <555CEBA5.30403@oracle.com> 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). 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. 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 xuelei.fan at oracle.com Thu May 21 01:25:51 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 21 May 2015 09:25:51 +0800 Subject: [JEP-219/JDK-8043758] Code Review Request: Datagram Transport Layer Security (DTLS) Message-ID: <555D341F.3050906@oracle.com> Hi, Please review DTLS implementation [JEP-219/JDK-8043758]: webrev: http://cr.openjdk.java.net/~xuelei/8043758/webrev.latest/ JBS: https://bugs.openjdk.java.net/browse/JDK-8043758 I would greatly appreciate it if you could send me feedback on or before May 28, 2015. Thanks & Regards, Xuelei Fan From valerie.peng at oracle.com Thu May 21 04:21:06 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 20 May 2015 21:21:06 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, Message-ID: <555D5D32.9010908@oracle.com> Sean, Could you please review this change? The changes are mostly the same as the prototype in Jake, but I have to make some modification due to the difference in ServiceLoader lookup in OpenJDK (corresponding META-INF/services/java.security.Provider files in each module) and the related makefile change (merge their content into one for the final image build). Then, I adjusted the Provider.configure() method to take a single String argument to be consistent with the "providerarg" option that keytool defined. In addition, I also made some misc changes, such as configuring the providers inside ProviderConfig instead of ProviderLoader, add back the doPrivileged block to all the provider constructors. I also have second thought on making the switch to privider name (instead of provider class name) in java.security file, so I reverted the changes on that - that SunPKCS11 provider has its name specified in its configuration file, so when ServiceLoader loads the PKCS11 provider, the configuration file has not been passed to it, so the name is not known at that time. Thus, using the class name for the provider list entry seems to fit the flow better. I also updated the default policy for SunPKCS11 provider given its recent change of using sun.misc. Webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.00/ CCC: http://ccc.us.oracle.com/7191662 Thanks, Valerie From mandy.chung at oracle.com Thu May 21 05:39:11 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 20 May 2015 22:39:11 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: <555D5D32.9010908@oracle.com> References: <555D5D32.9010908@oracle.com> Message-ID: <69BD6B3C-3C85-419F-A7F0-27D1DD9078C6@oracle.com> > On May 20, 2015, at 9:21 PM, Valerie Peng wrote: > > Sean, > > Could you please review this change? The changes are mostly the same as the prototype in Jake, but I have to make some modification due to the difference in ServiceLoader lookup in OpenJDK (corresponding META-INF/services/java.security.Provider files in each module) and the related makefile change (merge their content into one for the final image build). Then, I adjusted the Provider.configure() method to take a single String argument to be consistent with the "providerarg" option that keytool defined. > > In addition, I also made some misc changes, such as configuring the providers inside ProviderConfig instead of ProviderLoader, add back the doPrivileged block to all the provider constructors. I also have second thought on making the switch to privider name (instead of provider class name) in java.security file, so I reverted the changes on that - that SunPKCS11 provider has its name specified in its configuration file, so when ServiceLoader loads the PKCS11 provider, the configuration file has not been passed to it, so the name is not known at that time. Thus, using the class name for the provider list entry seems to fit the flow better. I also updated the default policy for SunPKCS11 provider given its recent change of using sun.misc. > > Webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.00/ > CCC: http://ccc.us.oracle.com/7191662 A quick comment on the META-INF/services config files and the makefile. Merging the service config files is temporary until the module system is moving further along. src/jdk.crypto.ucrypto/solaris/classes/META-INF/services/java.security.Provider.html and other os-specific service configuration: 1 #[solaris]com.oracle.security.ucrypto.UcryptoProvider - why is this commented out? Does the makefile uncomment it? It should be simple concatenation with The makefile doesn?t seem right though. make/gensrc/Gensrc-java.naming.gmk.html 96 jdk.crypto.ec: $(GENSRC_PROVIDER) 98 all: jdk.crypto.ec java.naming doesn?t seem an appropriate module to be the main module for containing all service provider config files. I initially propose to use jdk.crypto.ec as the gensrc module as indicated in line 96,98. You can rename the file to Gensrc-jdk.crypto.ec and update the content.. GENSRC_PROVIDER := $(SUPPORT_OUTPUTDIR)/gensrc/java.naming/META-INF/services/java.security.Provider GENSRC_PROVIDER is the output file. line 79-89 is building the target list. I think you need another variable to build up the target list but not GENSRC_PROVIDER. You can reference how Gensrc-jdk.jdi.gmk concatenates the service config for jdk.jdi and dk.hotspot.agent module. # Filter com.sun.jdi.connect.Connector $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector: \ $(JDK_TOPDIR)/src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.Connector \ $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services $(process-provider) # Copy the same service file into jdk.hotspot.agent so that they are kept the same. $(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/META-INF/services/com.sun.jdi.connect.Connector: \ $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector $(install-file) Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu May 21 06:46:20 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 21 May 2015 14:46:20 +0800 Subject: [8u-dev] Request for review AND approval to backport: 8077102: In-Reply-To: <555CBD21.6060207@oracle.com> References: <555CBD21.6060207@oracle.com> Message-ID: <555D7F3C.5050605@oracle.com> Code change is fine. Thanks Max On 5/21/2015 12:58 AM, Ivan Gerasimov wrote: > Hi! > > The backport required some manual editing, thus I'm asking for a review > too. > Would you please review and approve backporting this fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8077102 > WEBREV: http://cr.openjdk.java.net/~igerasim/8077102/00/webrev/ > > The fix was tested on all available platforms, no failures. > > Sincerely yours, > Ivan From sean.coffey at oracle.com Thu May 21 07:58:24 2015 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Thu, 21 May 2015 08:58:24 +0100 Subject: Fwd: 8078439: 8048194: possible bug in commit for these two fixes In-Reply-To: <1432164509.64528.BPMail_high_carrier@web162905.mail.bf1.yahoo.com> References: <1432164509.64528.BPMail_high_carrier@web162905.mail.bf1.yahoo.com> Message-ID: <555D9020.50903@oracle.com> FYI, concerns from Darwin on the 8078439: 8048194 fixes. regards, Sean. -------- Forwarded Message -------- Subject: 8078439: 8048194: possible bug in commit for these two fixes Date: Wed, 20 May 2015 16:28:29 -0700 From: Darwin Felix To: jdk8u-dev at openjdk.java.net CC: darwinfelix at users.sourceforge.net 8078439: 8048194: possible bug in commit for these two fixes It appears that this commit has a bug: http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/d777e2918a77/src/share/classes/sun/security/jgss/spnego/SpNegoContext.java Fundamentally, it appears that this commit desires to honor the initiator/client's preferred mechanism - first one in the list of mechanisms the client is offering to the target/server. However, the commit does not allow for the condition where the server can only support a different mechanism from the client's offering/list (server not able to support mechList[0] but is able to support mechList[N]). In my humble opinion, based on my quick glance of the code, this commit is broken because the server is no longer allowed to select from one of the other mechanisms from the client's list. This next commit also appears to have a bug: http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/9ab9f20e9bdd/src/share/classes/sun/security/jgss/spnego/SpNegoContext.java It appears that this commit also desires to honor the initiator/client's preferred mechanism. However, this commit also appears to suffer from the condition where the server can only support a different mechanism from the client's offering/list (server not able to support mechList[0] but is able to support mechList[N]). Perhaps the above two (2) commits should be reverted? An alternative approach to supporting/honoring the initiator/client's preferred mechanism: Prior to the above two (2) commits, SpNegoContext.java suffered from the condition where it did not make an attempt/consider to use the initiator/client's preferred mechanism. Instead, the code would find a mechanism from the client's list that the server can support. Meaning, the server's supported/preferred mechanisms is the outer loop and the client's supported/preferred mechanism is the inner loop (preference specified by its order in the list). Here's what the code looked like prior to the above two (2) commits: http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/1a3de3cdc684/src/share/classes/sun/security/jgss/spnego/SpNegoContext.java Perhaps, if we simply place the client's list as the outer loop and the server's list as the inner loop, we might be able to honor the client's preferred mechanism while ensuring that the chosen mechanism is one that the server can support. For example, have a look at the implementation of the method named SpNegoContext.negotiate_mech_type(supported_mechSet, mechList) Notice that the server's list is chosen as being the outer loop. It might make more sense to have the client's list be the outer loop. If possible, I would like to discuss the possibility of reverting the above two commits and instead implement my proposed change (mechList as the outer loop and supported_mechSet as the inner loop) to the method named negotiate_mech_type. thanks, -darwin -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Thu May 21 08:32:20 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Thu, 21 May 2015 09:32:20 +0100 Subject: [8u-dev] Request for review AND approval to backport: 8077102: In-Reply-To: <555D7F3C.5050605@oracle.com> References: <555CBD21.6060207@oracle.com> <555D7F3C.5050605@oracle.com> Message-ID: <555D9814.3000106@oracle.com> Approved. Regards, Sean. On 21/05/2015 07:46, Weijun Wang wrote: > Code change is fine. > > Thanks > Max > > On 5/21/2015 12:58 AM, Ivan Gerasimov wrote: >> Hi! >> >> The backport required some manual editing, thus I'm asking for a review >> too. >> Would you please review and approve backporting this fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8077102 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8077102/00/webrev/ >> >> The fix was tested on all available platforms, no failures. >> >> Sincerely yours, >> Ivan From weijun.wang at oracle.com Thu May 21 10:07:48 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 21 May 2015 18:07:48 +0800 Subject: [JEP-219/JDK-8043758] Code Review Request: Datagram Transport Layer Security (DTLS) In-Reply-To: <555D341F.3050906@oracle.com> References: <555D341F.3050906@oracle.com> Message-ID: <555DAE74.8070708@oracle.com> NEED_UNWRAP_AGAIN: So you are asking the user to call unwrap() on nothing? Or no matter what the argument is you just don't touch it? I'd rather see a new status NEED_PROCEED and a new method proceed() that has no argument at all. Tests: I see you send/receive data with DatagramSocket. Not sure how UDP on localhost is more reliable than on a network, but is it possible to just pass the byte arrays between client and server? It's also easier to simulate packet loss and wrong order this way. --Max On 5/21/2015 9:25 AM, Xuelei Fan wrote: > Hi, > > Please review DTLS implementation [JEP-219/JDK-8043758]: > > webrev: http://cr.openjdk.java.net/~xuelei/8043758/webrev.latest/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8043758 > > I would greatly appreciate it if you could send me feedback on or before > May 28, 2015. > > Thanks & Regards, > Xuelei Fan > From xuelei.fan at oracle.com Thu May 21 11:19:46 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 21 May 2015 19:19:46 +0800 Subject: [JEP-219/JDK-8043758] Code Review Request: Datagram Transport Layer Security (DTLS) In-Reply-To: <555DAE74.8070708@oracle.com> References: <555D341F.3050906@oracle.com> <555DAE74.8070708@oracle.com> Message-ID: <555DBF52.104@oracle.com> On 5/21/2015 6:07 PM, Weijun Wang wrote: > NEED_UNWRAP_AGAIN: > > So you are asking the user to call unwrap() on nothing? Or no matter > what the argument is you just don't touch it? As previous behaviors, the argument may be not touched. For this case, the input would not be touched. > I'd rather see a new > status NEED_PROCEED and a new method proceed() that has no argument at all. > Add a new method would make the application code more complicated. At present, applications only need to call wrap() and unwrap(), and need not to concern about whether the method would produce bytes or not. I want to keep it simple as before. > Tests: > > I see you send/receive data with DatagramSocket. Not sure how UDP on > localhost is more reliable than on a network, but is it possible to just > pass the byte arrays between client and server? It's also easier to > simulate packet loss and wrong order this way. > Yes, it is easier. However, some of the tests are also used to illustrate how to do DTLS programming. I may use client and server byte exchange directly later, if more tests are required. Thanks, Xuelei > --Max > > On 5/21/2015 9:25 AM, Xuelei Fan wrote: >> Hi, >> >> Please review DTLS implementation [JEP-219/JDK-8043758]: >> >> webrev: http://cr.openjdk.java.net/~xuelei/8043758/webrev.latest/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8043758 >> >> I would greatly appreciate it if you could send me feedback on or before >> May 28, 2015. >> >> Thanks & Regards, >> Xuelei Fan >> From konstantin.shefov at oracle.com Thu May 21 11:31:11 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Thu, 21 May 2015 14:31:11 +0300 Subject: [JEP-219/JDK-8043758] Code Review Request: Datagram Transport Layer Security (DTLS) In-Reply-To: <555DBF52.104@oracle.com> References: <555D341F.3050906@oracle.com> <555DAE74.8070708@oracle.com> <555DBF52.104@oracle.com> Message-ID: <555DC1FF.9060904@oracle.com> Hi Xuelei, You have the following tests: "DTLSOverDatagram.java", "Reordered.java", "Retransmission.java". Their code is pretty much the same despite some differences. I think it would be better to create a base test class with all common code and then inherit tests from that class to avoid code duplication. -Konstantin On 21.05.2015 14:19, Xuelei Fan wrote: > Hi, > >> > >>Please review DTLS implementation [JEP-219/JDK-8043758]: > >> > >>webrev:http://cr.openjdk.java.net/~xuelei/8043758/webrev.latest/ > >>JBS:https://bugs.openjdk.java.net/browse/JDK-8043758 > >> > >>I would greatly appreciate it if you could send me feedback on or before > >>May 28, 2015. > >> > >>Thanks & Regards, > >>Xuelei Fan From xuelei.fan at oracle.com Thu May 21 11:34:28 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 21 May 2015 19:34:28 +0800 Subject: [JEP-219/JDK-8043758] Code Review Request: Datagram Transport Layer Security (DTLS) In-Reply-To: <555DC1FF.9060904@oracle.com> References: <555D341F.3050906@oracle.com> <555DAE74.8070708@oracle.com> <555DBF52.104@oracle.com> <555DC1FF.9060904@oracle.com> Message-ID: <555DC2C4.8070206@oracle.com> On 5/21/2015 7:31 PM, Konstantin Shefov wrote: > Hi Xuelei, > > You have the following tests: "DTLSOverDatagram.java", "Reordered.java", > "Retransmission.java". Their code is pretty much the same despite some > differences. > I think it would be better to create a base test class with all common > code and then inherit tests from that class to avoid code duplication. > Yes. That's also a point I want to address. If I cannot do it before May 28, I would create a new bug to track the improvement. Thanks, Xuelei > -Konstantin > > On 21.05.2015 14:19, Xuelei Fan wrote: >> Hi, >> >> >> >>Please review DTLS implementation [JEP-219/JDK-8043758]: >> >> >> >>webrev:http://cr.openjdk.java.net/~xuelei/8043758/webrev.latest/ >> >>JBS:https://bugs.openjdk.java.net/browse/JDK-8043758 >> >> >> >>I would greatly appreciate it if you could send me feedback on or >> before >> >>May 28, 2015. >> >> >> >>Thanks & Regards, >> >>Xuelei Fan > From vincent.x.ryan at oracle.com Thu May 21 15:44:36 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 21 May 2015 16:44:36 +0100 Subject: [8u] request for review: 8062552 Support keystore type detection for JKS and PKCS12 keystores Message-ID: <033093D0-42E0-462F-A071-4EA5420541C0@oracle.com> Please review this enhancement to JDK 8u that addresses a compatibility risk for certain applications that access keystores across JDK 8 and JDK 9 releases. The issue arises because the default keystore type is now PKCS12 in JDK 9 but is JKS in earlier releases. The problem can occur when a keystore is created on JDK 9 using the default keystore type but accessed on JDK 8 also using the default keystore type. This keystore type mismatch results in an error. The change introduces a keystore compatibility mode for JKS keystores where both JKS and PKCS12 file formats are understood. Similar behaviour is already present in JDK 9 (JEP-229). The keystore.type.compat security property controls whether the mode is enabled or not. By default it is enabled. This enhancement enables at risk applications to continue to function across JDK 8 and JDK 9 without requiring any application code changes. Thanks. Bug: https://bugs.openjdk.java.net/browse/JDK-8062552 Webrev: http://cr.openjdk.java.net/~vinnie/8062552/webrev.01/ From sean.mullan at oracle.com Thu May 21 17:26:35 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 21 May 2015 13:26:35 -0400 Subject: [9] RFR 8079693: Add support for ECDSA P-384 and P-521 curves to XML Signature In-Reply-To: <555BC471.8020404@oracle.com> References: <555BC471.8020404@oracle.com> Message-ID: <555E154B.6070907@oracle.com> Minor typo on line 438 of DOMKeyValue: s/the one/one/ Otherwise, looks good. --Sean On 05/19/2015 07:17 PM, Jason Uh wrote: > Please review this change, which adds support for two curves to XML > Signature. > > webrev: http://cr.openjdk.java.net/~juh/8079693/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8079693 > > Thanks, > Jason From openjdk at suche.org Thu May 21 22:02:22 2015 From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Fri, 22 May 2015 00:02:22 +0200 Subject: [8u] request for review: 8062552 Support keystore type detection for JKS and PKCS12 keystores In-Reply-To: <033093D0-42E0-462F-A071-4EA5420541C0@oracle.com> References: <033093D0-42E0-462F-A071-4EA5420541C0@oracle.com> Message-ID: <555E55EE.5060207@suche.org> Hi, most of it look ok for me, but in "http://cr.openjdk.java.net/~vinnie/8062552/webrev.01/src/share/classes/sun/security/util/KeyStoreDelegator.java.patch" i found in the method engineLoad the exception handling an bit ugly. + } catch (Exception e) { + + // incorrect password + if (e instanceof IOException && + e.getCause() instanceof UnrecoverableKeyException) { + throw (IOException)e; + } + + try { + // Ignore secondary keystore when no compatibility mode + if (!compatModeEnabled) { + throw e; + } i would have expected: + } catch (Exception e) { + if (!compatModeEnabled) { + throw e; + } + + // incorrect password + if (e instanceof IOException && + e.getCause() instanceof UnrecoverableKeyException) { + throw (IOException)e; + } + + try { + // Ignore secondary keystore when no compatibility mode because if no compatModeEnabled i would expect that the exception if transparently thrown. And since JDK8 this is allowed tho throw an Exception if it was catched and can only by an declared one. Also this only compare an boolean instead of two instanceof + additional exception handling. Gru? Thomas From valerie.peng at oracle.com Thu May 21 22:03:15 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 21 May 2015 15:03:15 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: <69BD6B3C-3C85-419F-A7F0-27D1DD9078C6@oracle.com> References: <555D5D32.9010908@oracle.com> <69BD6B3C-3C85-419F-A7F0-27D1DD9078C6@oracle.com> Message-ID: <555E5623.3020900@oracle.com> Mandy, Please find comments in line. On 5/20/2015 10:39 PM, Mandy Chung wrote: > > A quick comment on the META-INF/services config files and the > makefile. Merging the service config files is temporary until the > module system is moving further along. > > src/jdk.crypto.ucrypto/solaris/classes/META-INF/services/java.security.Provider.html > and other os-specific service configuration: > 1 #[solaris]com.oracle.security.ucrypto.UcryptoProvider > > - why is this commented out? Does the makefile uncomment it? It > should be simple > concatenation with In an example that I found through another makefile, it would uncomment the entry start with "#[OS]" (and process/remove this prefix) when the OS matches. We need OS-specific file processing when concatenate these files. > The makefile doesn?t seem right though. > > make/gensrc/Gensrc-java.naming.gmk.html > > 96 jdk.crypto.ec: $(GENSRC_PROVIDER) > 98 all: jdk.crypto.ec > > java.naming doesn?t seem an appropriate module to be the main module > for containing all service provider config files. I initially propose > to use jdk.crypto.ec as the gensrc module as indicated in line 96,98. What decides if it's appropriate or not? These are not just crypto providers that we are defining here, but all classes which extend from java.security.Provider. I recall using jdk.crypto.ec as the gensrc module as you suggested initially. But when testing it, it doesn't seem to work as expected. I ended up using java.naming as that's the one ended up in the final image instead of the concatenated one under jdk.crypto.ec. Could there be some alphabetic ordering when processing/building these modules? Well, since this is really a hack and only temporary, does it really matter whether it's under java.naming or jdk.crypto.ec? Both contains providers for the java.security provider list. The key thing is that the resulting image works. Valerie > > You can rename the file to Gensrc-jdk.crypto.ec and update the content.. > > GENSRC_PROVIDER := > $(SUPPORT_OUTPUTDIR)/gensrc/java.naming/META-INF/services/java.security.Provider > > GENSRC_PROVIDER is the output file. line 79-89 is building the target > list. I think you need another variable to build up the target list > but not GENSRC_PROVIDER. > > You can reference how Gensrc-jdk.jdi.gmk concatenates the service > config for jdk.jdi and dk.hotspot.agent module. > > # Filter com.sun.jdi.connect.Connector > $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector: > \ > > $(JDK_TOPDIR)/src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.Connector \ > $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services > $(process-provider) > > # Copy the same service file into jdk.hotspot.agent so that they are > kept the same. > $(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/META-INF/services/com.sun.jdi.connect.Connector: \ > > $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector > $(install-file) > > Mandy From valerie.peng at oracle.com Thu May 21 22:07:23 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 21 May 2015 15:07:23 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: <555E5623.3020900@oracle.com> References: <555D5D32.9010908@oracle.com> <69BD6B3C-3C85-419F-A7F0-27D1DD9078C6@oracle.com> <555E5623.3020900@oracle.com> Message-ID: <555E571B.2080009@oracle.com> But you are correct that the content which uses jdk.crypto.ec seems inconsistent to the file name. I will fix those and re-test. Thanks, Valerie On 5/21/2015 3:03 PM, Valerie Peng wrote: > Mandy, > > Please find comments in line. > > On 5/20/2015 10:39 PM, Mandy Chung wrote: >> >> A quick comment on the META-INF/services config files and the >> makefile. Merging the service config files is temporary until the >> module system is moving further along. >> >> src/jdk.crypto.ucrypto/solaris/classes/META-INF/services/java.security.Provider.html >> >> and other os-specific service configuration: >> 1 #[solaris]com.oracle.security.ucrypto.UcryptoProvider >> >> - why is this commented out? Does the makefile uncomment it? It >> should be simple >> concatenation with > > In an example that I found through another makefile, it would > uncomment the entry start with "#[OS]" (and process/remove this > prefix) when the OS matches. We need OS-specific file processing when > concatenate these files. > >> The makefile doesn?t seem right though. >> >> make/gensrc/Gensrc-java.naming.gmk.html >> >> 96 jdk.crypto.ec: $(GENSRC_PROVIDER) >> 98 all: jdk.crypto.ec >> >> java.naming doesn?t seem an appropriate module to be the main module >> for containing all service provider config files. I initially >> propose to use jdk.crypto.ec as the gensrc module as indicated in >> line 96,98. > > What decides if it's appropriate or not? These are not just crypto > providers that we are defining here, but all classes which extend from > java.security.Provider. I recall using jdk.crypto.ec as the gensrc > module as you suggested initially. But when testing it, it doesn't > seem to work as expected. I ended up using java.naming as that's the > one ended up in the final image instead of the concatenated one under > jdk.crypto.ec. Could there be some alphabetic ordering when > processing/building these modules? > > Well, since this is really a hack and only temporary, does it really > matter whether it's under java.naming or jdk.crypto.ec? Both contains > providers for the java.security provider list. The key thing is that > the resulting image works. > Valerie >> >> You can rename the file to Gensrc-jdk.crypto.ec and update the content.. >> >> GENSRC_PROVIDER := >> $(SUPPORT_OUTPUTDIR)/gensrc/java.naming/META-INF/services/java.security.Provider >> >> GENSRC_PROVIDER is the output file. line 79-89 is building the >> target list. I think you need another variable to build up the >> target list but not GENSRC_PROVIDER. >> >> You can reference how Gensrc-jdk.jdi.gmk concatenates the service >> config for jdk.jdi and dk.hotspot.agent module. >> >> # Filter com.sun.jdi.connect.Connector >> $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector: >> \ >> >> $(JDK_TOPDIR)/src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.Connector >> \ >> $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services >> $(process-provider) >> >> # Copy the same service file into jdk.hotspot.agent so that they are >> kept the same. >> $(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/META-INF/services/com.sun.jdi.connect.Connector: >> \ >> >> $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector >> $(install-file) >> >> Mandy From mandy.chung at oracle.com Fri May 22 00:46:58 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 21 May 2015 17:46:58 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: <555E5623.3020900@oracle.com> References: <555D5D32.9010908@oracle.com> <69BD6B3C-3C85-419F-A7F0-27D1DD9078C6@oracle.com> <555E5623.3020900@oracle.com> Message-ID: I?m including build-dev and we need to ask for Erik and Magnus advice what?s the best way to work around this. Erik, Magnus, Security providers now become service providers. They are provided from 11 different modules, 3 of them are os-specific. The current image builder doesn?t merge duplicate resources and we currently work around it in the build doing the merge as it?s temporary until the module system is moving further. Gensrc-jdk.jdi.gmk is the example. Valerie has a patch attempting to concatenate them and it turns out that it might not be straight forward I have thought. http://cr.openjdk.java.net/~valeriep/7191662/webrev.00/make/gensrc/Gensrc-java.naming.gmk.html As we can?t say which one image builder will pick, it needs to copy gensrc (merged version) to all modules/$MODULE/META-INF/services/java.security.Provider config files. I wonder if it?s quicker to hack ImageBuilder to special case the service config file and merge them. Any thought? > On May 21, 2015, at 3:03 PM, Valerie Peng wrote: > > Mandy, > > Please find comments in line. > > On 5/20/2015 10:39 PM, Mandy Chung wrote: >> >> A quick comment on the META-INF/services config files and the makefile. Merging the service config files is temporary until the module system is moving further along. >> >> src/jdk.crypto.ucrypto/solaris/classes/META-INF/services/java.security.Provider.html >> and other os-specific service configuration: >> 1 #[solaris]com.oracle.security.ucrypto.UcryptoProvider >> >> - why is this commented out? Does the makefile uncomment it? It should be simple >> concatenation with > > In an example that I found through another makefile, it would uncomment the entry start with "#[OS]" (and process/remove this prefix) when the OS matches. We need OS-specific file processing when concatenate these files. Ah? that?s from Gensrc-jdk.jdi.gmk. The service config file contains a mixture of cross-neutral and os-specific providers. That?s not the example to copy. define process-provider $(MKDIR) -p $(@D) $(CAT) $^ > $@ endef > > What decides if it's appropriate or not? These are not just crypto providers that we are defining here, but all classes which extend from java.security.Provider. I recall using jdk.crypto.ec as the gensrc module as you suggested initially. But when testing it, it doesn't seem to work as expected. I ended up using java.naming as that's the one ended up in the final image instead of the concatenated one under jdk.crypto.ec. Could there be some alphabetic ordering when processing/building these modules? > > Well, since this is really a hack and only temporary, does it really matter whether it's under java.naming or jdk.crypto.ec? Both contains providers for the java.security provider list. The key thing is that the resulting image works Mandy From bradford.wetmore at oracle.com Fri May 22 00:55:41 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 21 May 2015 17:55:41 -0700 Subject: TLS Handshake Message Proposal (Was: Re: JEP 244: TLS Application-Layer Protocol Negotiation Extension) In-Reply-To: <555CDD52.1020301@suche.org> References: <20150409223635.74AFC555B2@eggemoggin.niobe.net> <552BD9AD.7070000@suche.org> <552BED2A.70903@redhat.com> <552BF95E.6090604@suche.org> <552C8356.2020804@oracle.com> <555BD58A.8070302@oracle.com> <555CDD52.1020301@suche.org> Message-ID: <555E7E8D.6050202@oracle.com> Hi Thomas, After reviewing a lot of the back mail and the desires expressed, I have two orthogonal proposals to make. The first (next email) is an ALPN-specific API using a simple callback selector which I think addresses most of the protocol selection concerns. The second (below) is a more general Handshake Message framework that will allow for insertion of other HandshakeMessage types (e.g. SupplementalData/NewSessionTicket), packet capture (e.g. Fallback Signaling CipherSuite/Channel Bindings), and for adding/modifying/deleting TLS Extensions (both known/unknown). I was trying to come up with something less-involved for just the Hellos/Extensions, but it became clear that anything for those messages could easily be extended to all. There's a lot of new APIs, but I find it pretty straightforward to use. Sample code is below. These two approaches are complementary: they don't depend on each other at all. Given that we need to have ALPN support in just over a month (to allow for test/JCK/HTTP-2 development), my colleagues are concerned about taking on major API development at this date. Depending on feedback, I'm thinking of proposing that we do the first approach for JDK 9, and for the second, initiate a JEP and target the JDK 10 timeframe. On 5/20/2015 12:15 PM, Thomas Lu?nig wrote: > Hi, > > 1) There are two types of extensions: > a) That modify the directly how the engine works like > [max_fragment_length,heartbeat,encrypt_then_mac,extended_master_secret,SessionTicket,...] As a third party, these will be impossible without making your own JDK (or it being supported by the implementation). > b) That provide information (modify the network protocol) like > [npn,alpn,status_request,...] Yes. I tried to call those out in my email. > 2) Some of the extionsions could be called deprecated like heartbeat, > npn and compression NPN/compression certainly, but I wasn't aware heartbeat was deprecated. Possibly in the court of public opinion after "Heartbleed." :) Is it really deprecated in the wider TLS community? > signed_certificate_timestamp -> could be done without ocsp interference > via extra handshake message like you can see it on https://suche.org > there are 3 ways > how this can be archived Included in Certificate, OCSP-Response, Extra > handshake Message. > > extended_master_secret -> would be hard to implement. > > There are two ways to enable better plugin/develop: > + Expose the client handshake to KeyManager/TrustManager/Client/Server > + Generic way to add extra messages [status_request, user_mapping, > client_authz, server_authz, application_layer_protocol_negotiation, > status_request_v2, signed_certificate_timestamp, > npn, > TLS_FALLBACK_SCSV Before I describe the approach, in recent discussions with my colleagues, they were also concerned that this would require too much intimate knowledge of the TLS protocol. The other major concern is that this is fair amount of change to support a small number of situations. Is it worth the time to work this up if no one will actually use it? Of course, the big plus is that developers can now add functionality that we just haven't been able to do. That said, this approach does give developers full freedom to shoot themselves in the foot if they get the messages (format/values) wrong. ;) We'll do what we can in creating APIs for creating valid messages, and leave it to developers to create the rest. Here's the approach. This is just a first draft, lots of work to be done here. To provide access to the handshake, developers provide callbacks for well-defined handshake points: SSLSocket.setCallbacks(CallBack[] cbs) SSLEngine.setCallbacks(CallBack[] cbs) with: CallBack( int handshakeMessageType, enum When {INBOUND/OUTBOUND_BEFORE/OUTBOUND_AFTER}, boolean extensions, CallBackHandler) where: handshakeMessageType are the TLS numbers: hello_request(0), client_hello(1), server_hello(2), ...etc... finished(20), change_cipher_spec(254), (255) Note: CCS is not a formal handshake message, but is part of the handshake. INBOUND message is from peer, called upon receipt OUTBOUND_BEFORE message is for peer, called before generation OUTBOUND_AFTER message is for peer, called after generation message is also available for review extensions if true and handshakeMessageType is client_hello/server_hello, any bytes returned from the handlers (see below) will be added as extensions. If false or any other message type, any bytes are added as a separate message (e.g SupplementalData for user_mapping) If you duplicate an extension, it will replace the existing one in the output message. The CallBackHandler has: byte[] callBackHandler.handle( SSLSocket s, int handshakeMessageType, When w, boolean extensions, byte[] message) throws SSLException byte[] callBackHandler.handle( SSLEngine e, int handshakeMessageType, When w, boolean extensions, byte[] message) throws SSLException where: message is the raw message bytes, which is null if OUTBOUND_BEFORE. the return byte[] value is any additional message(s) to send. For the case of ClientHello/ServerHello OUTBOUND_AFTER, this would be the chance to add/replace extensions to the end of the Hello messages. This approach will also allow applications to generate/respond to unknown/future handshake message types, as we simply look in the list of callbacks and respond at the appropriate time. The messagetypes are always ints, so INBOUND unknown messages would need to be handled by the app. This would also give direct access to the Channel Bindings, both the raw cert encoding (tls-server-end-point) and FINISHED (tls-unique) messages. To assist in the parsing/generation of messages/extensions, there would be many utility classes. Anything we don't understand would be left as some kind of "undefined" message and left to the user to implement the parse/generate routines. These APIs are right out of the TLS message format specs. We have this functionality already in the sun.security.ssl level: to avoid duplication some reorg would be needed to bring them up to the javax.net.ssl level, or there needs to be a new API to call the underlying parsing implementation (probably the former): abstract class HandshakeMessage abstract byte[] getEncoded() abstract getMsgType() HelloRequest() extends HandshakeMessage ClientHello(byte[]) extends HandshakeMessage String getProtocolVersion() byte[] getRandom() byte[] getCipherSuites() String[] getCipherSuitesByName() byte[] getCompression() String[] getCompressionByName() List getExtensions() ServerHello(byte[]) extends HandshakeMessage String getProtocolVersion() byte[] getRandom() byte[] getCipherSuites() String[] getCipherSuitesByName() byte[] getCompression() String[] getCompressionByName() List getExtensions() Certificate(byte[]) extends HandshakeMessage byte[] getEncoded() X509Cert[] getCertificates() ...(skipping CertRequest/KeyExchanges/CertVerify/etc)... Finished(byte[]) extends HandshakeMessage byte[] getEncoded() UnknownMessage extends HandshakeMessage and abstract class HelloExtension() abstract getEncoded() // In case you need to replace one // (below) ALPNExtension(byte[] names) ALPNExtension(String[] names) String[] getNames() void setNames() SNIExtension(byte[] names) SNIExtension(String[] names) String[] getNames() etc... UnknownExtension() The above mechanism gives a way for the application to override any of the extensions and add additional messages. I think this addresses many of the concerns raised. For some sample code, here's a scenario with ALPN replacement, channel bindings, and generating server_authz+SupplementalData messages. // Create the Callbacks CallbackHandler myHandler = new MyHandler(); Callback[] cbs = { // Look at the ciphersuites/protocols/ALPN values. new Callback( MessageType.clientHello, INBOUND, false, myHandler), // Look at the selected ALPN value, see if the values are ok new Callback( MessageType.serverHello, OUTBOUND_AFTER, false, myHandler), // Add a RFC 5878 SupplementalData before Certificate new Callback( MessageType.certificate, OUTBOUND_BEFORE, false, myHandler), // Capture the FINISHED (tls-unique) channel binding new Callback( MessageType.finished, OUTBOUND_AFTER, false, myHandler), } // register the callbacks SSLSocket.setCallbacks(cbs); Class MyHandler extends CallbackHandler { private serverAuthz = null; private String[] alpns = null; private byte[] finished = null; public byte[] callbackHandler.handle( SSLSocket s, int handshakeMessageType, When when, boolean extensions, byte[] message) { switch(handshakeMessageType) { case MessageType.clientHello: return clientHello(new ClientHello(message)); break; case MessageType.serverHello: return serverHello(new ServerHello(message)); break; case MessageType.certificate: return certificate(); break; case MessageType.finished: return finished(new Finished(message)); break; default: // Why were we called, nothing was registered! return null; } } /* * Capture ALPN names for later. */ private byte[] clientHello(ClientHello ch) { HelloExtensions exts = ch.getExtensions(); for (Extension e : exts) { if (e instanceof ALPNExtension) alpns = e.getNames(); return null; } if (e instanceof ServerAuth) { serverAuth = e.get(); } } return null; } /* * Any additional extension cleanup? */ private byte[] serverHello(ServerHello sh) { byte[] bytes = null; HelloExtensions exts = sh.getExtensions(); for (Extension e : exts) { if (e instanceof ALPNExtension && e.getNames()[0].equals("H2") && !ch.getProtocolVersion().equals("TLSv1.2")) // We can't use HTTP/2 without TLSv1.2 (ignoring 1.3) // Replace with a valid element if (alpns == null) { continue; } for (String s : alpns) { if (!s.equals("H2") { bytes = add(new ALPNExtension(s).getEncoded()); } } throw new SSLProtocolException("ALPN: only H2 offered"); } } if (someOtherConditionThatNeedsToRemoveALPNExtension) { return new ALPNExtension(null); } // SunJSSE doesn't support server_authz, add it. if (serverAuthz != null) { doSomeProcessing(); bytes = add(myServerAuthzExtension.getEncoded()); } // Nothing else to do. return null; } /* * We got a server_auth extension from the client and sent one in * response, now generate the SupplementalData server_authz * structure. * * Handwaving for now, because there could also be one sent * before the client's cert. */ private byte[] certificate() { if (serverAuthz != null) { return new MyPrivateSupplementalDataClass(xxx).getEncoded(); } } private byte[] finished(Finished fin) { finished = fin.getEncoded(); } public byte[] getFinished(Finished fin) { return finished; } } Hope this is clear. Brad > Specially the information what the client can could be interesting for > site owner to decide what he should take care and what is so unusual > that it can be ignored. > > Gru? Thomas > From bradford.wetmore at oracle.com Fri May 22 00:55:52 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 21 May 2015 17:55:52 -0700 Subject: TLS ALPN Proposal Message-ID: <555E7E98.9050208@oracle.com> This is a fork of the previous thread: Subject: TLS Handshake Message Proposal (Was: Re: JEP 244: TLS Application-Layer Protocol Negotiation Extension) I broke this thread off to keep this proposal discussion together, but if you're interested in the history, please see the previous thread. This approach combines different suggestions from security-dev in a new way, and simplifies the ALPN selection process quite a bit. I think it addresses most of the concerns about selection that were raised. This approach can be completely separated from the Handshake mechanism I discussed in the previous message, so I'm thinking of this approach for JDK 9 and targeting the more general handshake approach for JDK 10. Here's the summary of API additions: SSLParameters: -------------- Client-side: gets/sets the list of protocol names to send. Server-side: gets/sets a ApplicationProtocolSelector which is a user-defined callback mechanism. ApplicationProtocolSelector: ---------------------------- Server-side: callback methods for SSLSocket/SSLEngine which are provided with handshake information for making the selection ExtendedSSLSession: ------------------- gets the negotiated protocol String Specifics below. The javadoc obviously needs work. class SSLParameters { ...deleted... /** * Gets the list of application protocols that will sent by * the client. * * The list could be empty, in which case no protocols will be * sent. * * @returns a list of application protocol names. */ public List getApplicationProtocols() { }; /** * Sets the list of application protocols that will sent by * the client. * * protocols could be empty, in which case no protocols will be * sent. * * @param protocols a list of application protocol names * @throws IllegalArgumentException if protocols is null. */ public void setApplicationProtocols(List protocols); /** * Gets the current server-side application layer protocol selector. * * @param the selector mechanism. * @return the current application protocol selector, or null if * there is not one. */ public ApplicationProtocolSelector getApplicationProtocolSelector() {}; /** * Sets the server-side application layer protocol selector. * * @param the selector mechanism, or null if protocol selection * should not be done. */ public void setApplicationProtocolSelector( ApplicationProtocolSelector selector) {}; } /* * A callback class on the server side that is responsible for * choosing which Application Protocol should be used in a SSL/TLS * connection. */ public abstract class ApplicationProtocolSelector { /* * SSLSocket callback to choose which Application Protocol value * to return to a SSL/TLS client * * @param sslSocket the SSLSocket for this connection * @param protocols the list of protocols advertised by the client * @param protocolVersion the negotiated protocol version * @param ciphersuite the negotiated ciphersuite * @return a non-empty protocol String to send to the client, * or null if no protocol value (i.e. extension) should be sent. * @throws SSLProtocolException if the connection should be aborted * because the the server supports none of the protocols that * the client advertised. */ public String select(SSLSocket sslSocket, String[] protocols, String protocolVersion, String ciphersuite) throws SSLProtocolException; /* * SSLEngine callback to choose which Application Protocol to return * to a SSL/TLS client. * * @param sslEngine the SSLEngine for this connection * @param protocols the list of protocols advertised by the client * @param protocolVersion the negotiated protocol version * @param ciphersuite the negotiated ciphersuite * @return a non-empty protocol String to send to the client, * or null if no protocol value should be sent. * @throws SSLProtocolException if the connection should be aborted * because the the server supports none of the protocols that * the client advertised. */ public String select(SSLEngine sslEngine, String[] protocols, String protocolVersion, String ciphersuite) throws SSLProtocolException; } If need be, we could include the received extensions or in a future version of this class. public class ExtendedSSLSession implements SSLSession { ...deleted... /** * Gets the application protocol negotiated for this connection. * * @returns the application protocol name or null if none was * negotiated. */ public String getApplicationProtocol() { }; } There was also some internal discussion about whether the values should be Strings or byte arrays. The ALPN RFC only discusses bytes, and a String.toBytes("US-ASCII") would limit the API to ASCII strings. Lastly, we could also add some convenience values for well-known values. e.g.: public static final AP_HTTP_1.1 = "http/1.1"; or in byte form: public static final AP_H2 = "h2".getBytes(""US-ASCII"); I refrained from including SPDY/*, since they are on their way out now, and NAT/STUN since there hasn't been any call for it so far. Thanks, Brad From erik.joelsson at oracle.com Fri May 22 06:58:13 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 22 May 2015 08:58:13 +0200 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: References: <555D5D32.9010908@oracle.com> <69BD6B3C-3C85-419F-A7F0-27D1DD9078C6@oracle.com> <555E5623.3020900@oracle.com> Message-ID: <555ED385.80508@oracle.com> On 2015-05-22 02:46, Mandy Chung wrote: > I?m including build-dev and we need to ask for Erik and Magnus advice what?s the best way to work around this. > > Erik, Magnus, > Security providers now become service providers. They are provided from 11 different modules, 3 of them are os-specific. The current image builder doesn?t merge duplicate resources and we currently work around it in the build doing the merge as it?s temporary until the module system is moving further. Gensrc-jdk.jdi.gmk is the example. > > Valerie has a patch attempting to concatenate them and it turns out that it might not be straight forward I have thought. > http://cr.openjdk.java.net/~valeriep/7191662/webrev.00/make/gensrc/Gensrc-java.naming.gmk.html > > As we can?t say which one image builder will pick, it needs to copy gensrc (merged version) to all modules/$MODULE/META-INF/services/java.security.Provider config files. > > I wonder if it?s quicker to hack ImageBuilder to special case the service config file and merge them. > > Any thought? I could certainly make this work in the makefile, but it is getting a bit tedious to keep these hacks going there. How hard would it be to change the ImageBuilder, which is just a temporary solution anyway, to identify and merge all service provider files with the same name that it finds? With that solution, the makefiles do not need to change as much when the module system is introduced and taking care of this properly. /Erik > >> On May 21, 2015, at 3:03 PM, Valerie Peng wrote: >> >> Mandy, >> >> Please find comments in line. >> >> On 5/20/2015 10:39 PM, Mandy Chung wrote: >>> A quick comment on the META-INF/services config files and the makefile. Merging the service config files is temporary until the module system is moving further along. >>> >>> src/jdk.crypto.ucrypto/solaris/classes/META-INF/services/java.security.Provider.html >>> and other os-specific service configuration: >>> 1 #[solaris]com.oracle.security.ucrypto.UcryptoProvider >>> >>> - why is this commented out? Does the makefile uncomment it? It should be simple >>> concatenation with >> In an example that I found through another makefile, it would uncomment the entry start with "#[OS]" (and process/remove this prefix) when the OS matches. We need OS-specific file processing when concatenate these files. > > Ah? that?s from Gensrc-jdk.jdi.gmk. The service config file contains a mixture of cross-neutral and os-specific providers. That?s not the example to copy. > > define process-provider > $(MKDIR) -p $(@D) > $(CAT) $^ > $@ > endef > > >> What decides if it's appropriate or not? These are not just crypto providers that we are defining here, but all classes which extend from java.security.Provider. I recall using jdk.crypto.ec as the gensrc module as you suggested initially. But when testing it, it doesn't seem to work as expected. I ended up using java.naming as that's the one ended up in the final image instead of the concatenated one under jdk.crypto.ec. Could there be some alphabetic ordering when processing/building these modules? >> >> Well, since this is really a hack and only temporary, does it really matter whether it's under java.naming or jdk.crypto.ec? Both contains providers for the java.security provider list. The key thing is that the resulting image works > Mandy From chris.hegarty at oracle.com Fri May 22 12:55:26 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 22 May 2015 13:55:26 +0100 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: <555ED385.80508@oracle.com> References: <555D5D32.9010908@oracle.com> <69BD6B3C-3C85-419F-A7F0-27D1DD9078C6@oracle.com> <555E5623.3020900@oracle.com> <555ED385.80508@oracle.com> Message-ID: <555F273E.9010203@oracle.com> On 22/05/15 07:58, Erik Joelsson wrote: > > On 2015-05-22 02:46, Mandy Chung wrote: >> I?m including build-dev and we need to ask for Erik and Magnus advice >> what?s the best way to work around this. >> >> Erik, Magnus, >> Security providers now become service providers. They are >> provided from 11 different modules, 3 of them are os-specific. The >> current image builder doesn?t merge duplicate resources and we >> currently work around it in the build doing the merge as it?s >> temporary until the module system is moving further. >> Gensrc-jdk.jdi.gmk is the example. >> >> Valerie has a patch attempting to concatenate them and it turns out >> that it might not be straight forward I have thought. >> >> http://cr.openjdk.java.net/~valeriep/7191662/webrev.00/make/gensrc/Gensrc-java.naming.gmk.html >> >> >> As we can?t say which one image builder will pick, it needs to copy >> gensrc (merged version) to all >> modules/$MODULE/META-INF/services/java.security.Provider config files. >> >> I wonder if it?s quicker to hack ImageBuilder to special case the >> service config file and merge them. >> >> Any thought? > I could certainly make this work in the makefile, but it is getting a > bit tedious to keep these hacks going there. How hard would it be to > change the ImageBuilder, which is just a temporary solution anyway, to > identify and merge all service provider files with the same name that it > finds? With that solution, the makefiles do not need to change as much > when the module system is introduced and taking care of this properly. I think it could be done either way. -Chris. > /Erik >> >>> On May 21, 2015, at 3:03 PM, Valerie Peng >>> wrote: >>> >>> Mandy, >>> >>> Please find comments in line. >>> >>> On 5/20/2015 10:39 PM, Mandy Chung wrote: >>>> A quick comment on the META-INF/services config files and the >>>> makefile. Merging the service config files is temporary until the >>>> module system is moving further along. >>>> >>>> src/jdk.crypto.ucrypto/solaris/classes/META-INF/services/java.security.Provider.html >>>> >>>> and other os-specific service configuration: >>>> 1 #[solaris]com.oracle.security.ucrypto.UcryptoProvider >>>> >>>> - why is this commented out? Does the makefile uncomment it? It >>>> should be simple >>>> concatenation with >>> In an example that I found through another makefile, it would >>> uncomment the entry start with "#[OS]" (and process/remove this >>> prefix) when the OS matches. We need OS-specific file processing when >>> concatenate these files. >> >> Ah? that?s from Gensrc-jdk.jdi.gmk. The service config file contains >> a mixture of cross-neutral and os-specific providers. That?s not the >> example to copy. >> >> define process-provider >> $(MKDIR) -p $(@D) >> $(CAT) $^ > $@ >> endef >> >> >>> What decides if it's appropriate or not? These are not just crypto >>> providers that we are defining here, but all classes which extend >>> from java.security.Provider. I recall using jdk.crypto.ec as the >>> gensrc module as you suggested initially. But when testing it, it >>> doesn't seem to work as expected. I ended up using java.naming as >>> that's the one ended up in the final image instead of the >>> concatenated one under jdk.crypto.ec. Could there be some alphabetic >>> ordering when processing/building these modules? >>> >>> Well, since this is really a hack and only temporary, does it really >>> matter whether it's under java.naming or jdk.crypto.ec? Both contains >>> providers for the java.security provider list. The key thing is that >>> the resulting image works >> Mandy > From sean.mullan at oracle.com Fri May 22 14:25:35 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 22 May 2015 10:25:35 -0400 Subject: RFR: 8065233: Remove Policy provider code that synchronizes on identityPolicyEntries List Message-ID: <555F3C5F.4000909@oracle.com> This is the second in a series of fixes for JEP 232 (Improve Secure Application Performance) [1]. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8065233/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8065233 This fix removes some obsolete synchronization code from the Policy implementation. This results in a slight improvement (about 2-4%) in the throughput of the Policy.getPermissions method. The bug contains a performance chart with more details. Thanks, Sean [1] http://openjdk.java.net/jeps/232 From weijun.wang at oracle.com Fri May 22 14:33:29 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 22 May 2015 22:33:29 +0800 Subject: RFR: 8065233: Remove Policy provider code that synchronizes on identityPolicyEntries List In-Reply-To: <555F3C5F.4000909@oracle.com> References: <555F3C5F.4000909@oracle.com> Message-ID: <555F3E39.2070403@oracle.com> Looks good. Are you also going to remove the policy.ignoreIdentityScope definition inside jdk\src\java.base\share\conf\security\java.security? Thanks Max On 5/22/2015 10:25 PM, Sean Mullan wrote: > This is the second in a series of fixes for JEP 232 (Improve Secure > Application Performance) [1]. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8065233/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8065233 > > This fix removes some obsolete synchronization code from the Policy > implementation. This results in a slight improvement (about 2-4%) in the > throughput of the Policy.getPermissions method. The bug contains a > performance chart with more details. > > Thanks, > Sean > > [1] http://openjdk.java.net/jeps/232 From sean.mullan at oracle.com Fri May 22 14:41:39 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 22 May 2015 10:41:39 -0400 Subject: RFR: 8065233: Remove Policy provider code that synchronizes on identityPolicyEntries List In-Reply-To: <555F3E39.2070403@oracle.com> References: <555F3C5F.4000909@oracle.com> <555F3E39.2070403@oracle.com> Message-ID: <555F4023.7010008@oracle.com> On 05/22/2015 10:33 AM, Weijun Wang wrote: > Looks good. > > Are you also going to remove the policy.ignoreIdentityScope definition > inside jdk\src\java.base\share\conf\security\java.security? Good catch. I thought that had been removed as part of JDK-6876158. Let me think this over a bit first. --Sean > > Thanks > Max > > > On 5/22/2015 10:25 PM, Sean Mullan wrote: >> This is the second in a series of fixes for JEP 232 (Improve Secure >> Application Performance) [1]. >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8065233/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8065233 >> >> This fix removes some obsolete synchronization code from the Policy >> implementation. This results in a slight improvement (about 2-4%) in the >> throughput of the Policy.getPermissions method. The bug contains a >> performance chart with more details. >> >> Thanks, >> Sean >> >> [1] http://openjdk.java.net/jeps/232 From Alan.Bateman at oracle.com Fri May 22 15:09:24 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 May 2015 16:09:24 +0100 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: <555F273E.9010203@oracle.com> References: <555D5D32.9010908@oracle.com> <69BD6B3C-3C85-419F-A7F0-27D1DD9078C6@oracle.com> <555E5623.3020900@oracle.com> <555ED385.80508@oracle.com> <555F273E.9010203@oracle.com> Message-ID: <555F46A4.8040704@oracle.com> On 22/05/2015 13:55, Chris Hegarty wrote: > : > I think it could be done either way. Valerie - have you considered not pushing the services configuration files with this change? With the change then the java.security configuration is still class names, not provider names, so the fallback should just work. This is what we've done in a few other areas (like JNDI for example). -Alan From sean.mullan at oracle.com Fri May 22 15:26:54 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 22 May 2015 11:26:54 -0400 Subject: [8u] request for review: 8062552 Support keystore type detection for JKS and PKCS12 keystores In-Reply-To: <555E55EE.5060207@suche.org> References: <033093D0-42E0-462F-A071-4EA5420541C0@oracle.com> <555E55EE.5060207@suche.org> Message-ID: <555F4ABE.5060207@oracle.com> On 05/21/2015 06:02 PM, Thomas Lu?nig wrote: > Hi, > > most of it look ok for me, but in > "http://cr.openjdk.java.net/~vinnie/8062552/webrev.01/src/share/classes/sun/security/util/KeyStoreDelegator.java.patch" > i found in the > method engineLoad the exception handling an bit ugly. > > + } catch (Exception e) { > + > + // incorrect password > + if (e instanceof IOException && > + e.getCause() instanceof UnrecoverableKeyException) { > + throw (IOException)e; > + } > + > + try { > + // Ignore secondary keystore when no compatibility mode > + if (!compatModeEnabled) { > + throw e; > + } > > i would have expected: > > + } catch (Exception e) { > + if (!compatModeEnabled) { > + throw e; > + } > + > + // incorrect password > + if (e instanceof IOException && > + e.getCause() instanceof UnrecoverableKeyException) { > + throw (IOException)e; > + } > + > + try { > + // Ignore secondary keystore when no compatibility mode > > because if no compatModeEnabled i would expect that the exception if transparently thrown. Alternatively, if there is no compatModeEnabled, there is no need to try/catch so line 203 should probably be: 203 if (stream == null || !compatModeEnabled) { and then you can remove the check for compatModeEnabled in the try/catch block. --Sean > And since JDK8 this is allowed tho throw an Exception if it was catched and can only by an declared one. > Also this only compare an boolean instead of two instanceof + additional exception handling. > > Gru? Thomas > From sean.mullan at oracle.com Fri May 22 15:27:34 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 22 May 2015 11:27:34 -0400 Subject: [8u] request for review: 8062552 Support keystore type detection for JKS and PKCS12 keystores In-Reply-To: <033093D0-42E0-462F-A071-4EA5420541C0@oracle.com> References: <033093D0-42E0-462F-A071-4EA5420541C0@oracle.com> Message-ID: <555F4AE6.7070809@oracle.com> Just a couple of other comments: - Both JavaKeyStore and JavaKeyStore$DualFormatJKS can be package-private since they are only referenced from SunEntries which is in the same package. I would also move KeyStoreDelegator into sun.security.provider and make it package-private. - Can you add a comment describing the contents of the trusted.pem cert in case we need to re-create it at some point in the future? - In KeyStoreDelegator, I think most/all of the fields can be made final. --Sean On 05/21/2015 11:44 AM, Vincent Ryan wrote: > Please review this enhancement to JDK 8u that addresses a compatibility risk for certain applications that access > keystores across JDK 8 and JDK 9 releases. The issue arises because the default keystore type is now PKCS12 in > JDK 9 but is JKS in earlier releases. The problem can occur when a keystore is created on JDK 9 using the default > keystore type but accessed on JDK 8 also using the default keystore type. This keystore type mismatch results in > an error. > > The change introduces a keystore compatibility mode for JKS keystores where both JKS and PKCS12 file formats are > understood. Similar behaviour is already present in JDK 9 (JEP-229). The keystore.type.compat security property > controls whether the mode is enabled or not. By default it is enabled. > > This enhancement enables at risk applications to continue to function across JDK 8 and JDK 9 without requiring any > application code changes. > > Thanks. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8062552 > Webrev: http://cr.openjdk.java.net/~vinnie/8062552/webrev.01/ > From simone.bordet at gmail.com Fri May 22 16:12:56 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Fri, 22 May 2015 18:12:56 +0200 Subject: TLS ALPN Proposal In-Reply-To: <555E7E98.9050208@oracle.com> References: <555E7E98.9050208@oracle.com> Message-ID: Hi, On Fri, May 22, 2015 at 2:55 AM, Bradford Wetmore wrote: > This is a fork of the previous thread: > > Subject: TLS Handshake Message Proposal > (Was: Re: JEP 244: TLS Application-Layer Protocol > Negotiation Extension) > > I broke this thread off to keep this proposal discussion together, but if > you're interested in the history, please see the previous thread. > > This approach combines different suggestions from security-dev in a new way, > and simplifies the ALPN selection process quite a bit. I think it addresses > most of the concerns about selection that were raised. > > This approach can be completely separated from the Handshake mechanism I > discussed in the previous message, so I'm thinking of this approach for JDK > 9 and targeting the more general handshake approach for JDK 10. > > Here's the summary of API additions: > > > SSLParameters: > -------------- > Client-side: gets/sets the list of protocol names to send. > Server-side: gets/sets a ApplicationProtocolSelector which is a > user-defined callback mechanism. > > ApplicationProtocolSelector: > ---------------------------- > Server-side: callback methods for SSLSocket/SSLEngine which > are provided with handshake information for making > the selection > > ExtendedSSLSession: > ------------------- > gets the negotiated protocol String If I understand correctly, SSLParameters will have methods that can only be used by one side of the TLS protocol (e.g. client or server, but not both). It's already like this for other things (e.g. SNI) so it will work, but I had hoped for some kind of reworking in this area too, but I'm digressing. > /* > * A callback class on the server side that is responsible for > * choosing which Application Protocol should be used in a SSL/TLS > * connection. > */ > public abstract class ApplicationProtocolSelector { > > /* > * SSLSocket callback to choose which Application Protocol value > * to return to a SSL/TLS client > * > * @param sslSocket the SSLSocket for this connection > * @param protocols the list of protocols advertised by the client > * @param protocolVersion the negotiated protocol version > * @param ciphersuite the negotiated ciphersuite > * @return a non-empty protocol String to send to the client, > * or null if no protocol value (i.e. extension) should be sent. > * @throws SSLProtocolException if the connection should be aborted > * because the the server supports none of the protocols that > * the client advertised. > */ > public String select(SSLSocket sslSocket, String[] protocols, > String protocolVersion, String ciphersuite) > throws SSLProtocolException; We are currently getting the protocolVersion and the cipherSuite via: [sslSocket|sslEngine].getHandshakeSession().get[Protocol|CipherSuite]() If this is correct, perhaps there is no need to pass those 2 parameters to select() ? I would suggest that if SSLParameters.setApplicationProtocols() takes a List, then also select() should take a List, rather than a String[]. Since it's the server picking the protocols, would be handy to have the client protocols in a List in order to call contains(), etc. on it. I would suggest to throw SSLException rather than the too specific SSLProtocolException (which may also be misleading, since its javadoc hints at a "flaw in one of the protocol implementations", while in this case it is just a failure to negotiate an *application* protocol - perfectly fine from the point of view of the TLS protocol). Would be great if we could make this class a FunctionalInterface, but I guess it's not easy due to lack of commonality between SSLSocket and SSLEngine. Unless there is a way to abstract something out of those 2 :) > public class ExtendedSSLSession implements SSLSession { > > ...deleted... > > /** > * Gets the application protocol negotiated for this connection. > * > * @returns the application protocol name or null if none was > * negotiated. > */ > public String getApplicationProtocol() { }; > } How would this case be covered: * client sends protocol list "foo","bar" * server sends back "bax". * client has to decide what to do. The only chance to call ExtendedSSLSession.getApplicationProtocol() would be *after* the handshake is completed, right ? Do you plan to hardcode the abort of the handshake with an alert_120, or give the application a chance (just asking) ? > There was also some internal discussion about whether the values should be > Strings or byte arrays. The ALPN RFC only discusses bytes, and a > String.toBytes("US-ASCII") would limit the API to ASCII strings. > > Lastly, we could also add some convenience values for well-known values. > e.g.: > > public static final AP_HTTP_1.1 = "http/1.1"; > > or in byte form: > > public static final AP_H2 = "h2".getBytes(""US-ASCII"); > > I refrained from including SPDY/*, since they are on their way out now, and > NAT/STUN since there hasn't been any call for it so far. I agree that only http/1.1 and h2 deserve a constant. -- 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 xuelei.fan at oracle.com Fri May 22 16:41:52 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 23 May 2015 00:41:52 +0800 Subject: [JEP-219/JDK-8043758] Code Review Request: Datagram Transport Layer Security (DTLS) In-Reply-To: <555DC2C4.8070206@oracle.com> References: <555D341F.3050906@oracle.com> <555DAE74.8070708@oracle.com> <555DBF52.104@oracle.com> <555DC1FF.9060904@oracle.com> <555DC2C4.8070206@oracle.com> Message-ID: <555F5C50.40701@oracle.com> webrev:http://cr.openjdk.java.net/~xuelei/8043758/webrev.latest/ Updates: 1. Update to discard invalid records, rather than use an alert message, per the requirements in section 4.1.2.7, RFC 6374. 2. Update to use a base test class, simplify the test case a lot. Thanks, Xuelei On 5/21/2015 7:34 PM, Xuelei Fan wrote: > On 5/21/2015 7:31 PM, Konstantin Shefov wrote: >> Hi Xuelei, >> >> You have the following tests: "DTLSOverDatagram.java", "Reordered.java", >> "Retransmission.java". Their code is pretty much the same despite some >> differences. >> I think it would be better to create a base test class with all common >> code and then inherit tests from that class to avoid code duplication. >> > Yes. That's also a point I want to address. If I cannot do it before > May 28, I would create a new bug to track the improvement. > > Thanks, > Xuelei > >> -Konstantin >> >> On 21.05.2015 14:19, Xuelei Fan wrote: >>> Hi, >>>>> >>>>> Please review DTLS implementation [JEP-219/JDK-8043758]: >>>>> >>>>> webrev:http://cr.openjdk.java.net/~xuelei/8043758/webrev.latest/ >>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8043758 >>>>> >>>>> I would greatly appreciate it if you could send me feedback on or >>> before >>>>> May 28, 2015. >>>>> >>>>> Thanks & Regards, >>>>> Xuelei Fan >> > From joe.darcy at oracle.com Fri May 22 16:42:41 2015 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 22 May 2015 09:42:41 -0700 Subject: Fwd: JDK 9 RFR of JDK-8080901: Replace package.html files with package-info.java in the java.base module In-Reply-To: <555E62E0.5070000@oracle.com> References: <555E62E0.5070000@oracle.com> Message-ID: <555F5C81.9000107@oracle.com> Hello security library team, I neglected to include you in the original request for review of this change. I'd like to replace all the package.html files in the java.base module with package-info.java files and a few cryptography packages are involved; please review. Thanks, -Joe -------- Forwarded Message -------- Subject: JDK 9 RFR of JDK-8080901: Replace package.html files with package-info.java in the java.base module Date: Thu, 21 May 2015 15:57:36 -0700 From: joe darcy Organization: Oracle Corporation To: core-libs-dev Hello, Please review these changes to replace old-style package.html files with package-info.java files in the base module: JDK-8080901: Replace package.html files with package-info.java in the java.base module http://cr.openjdk.java.net/~darcy/8080901.0/ (The package.html file for src/java.base/share/classes/sun/reflect is just removed rather than replaced since it contains "new" porting information that was current as of 2001.) Thanks, -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.x.ryan at oracle.com Fri May 22 16:49:55 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 22 May 2015 17:49:55 +0100 Subject: JDK 9 RFR of JDK-8080901: Replace package.html files with package-info.java in the java.base module In-Reply-To: <555F5C81.9000107@oracle.com> References: <555E62E0.5070000@oracle.com> <555F5C81.9000107@oracle.com> Message-ID: <0A82756E-C3A3-4D5B-A7E1-235850A36586@oracle.com> The 3 crypto files look fine to me. BTW I did notice that you preserve the Copyright range years in all but src/java.base/share/classes/javax/crypto/package-info.java Thanks. > On 22 May 2015, at 17:42, joe darcy wrote: > > Hello security library team, > > I neglected to include you in the original request for review of this change. I'd like to replace all the package.html files in the java.base module with package-info.java files and a few cryptography packages are involved; please review. > > Thanks, > > -Joe > > > -------- Forwarded Message -------- > Subject: JDK 9 RFR of JDK-8080901: Replace package.html files with package-info.java in the java.base module > Date: Thu, 21 May 2015 15:57:36 -0700 > From: joe darcy > Organization: Oracle Corporation > To: core-libs-dev > > Hello, > > Please review these changes to replace old-style package.html files with > package-info.java files in the base module: > > JDK-8080901: Replace package.html files with package-info.java in > the java.base module > http://cr.openjdk.java.net/~darcy/8080901.0/ > > (The package.html file for src/java.base/share/classes/sun/reflect is > just removed rather than replaced since it contains "new" porting > information that was current as of 2001.) > > Thanks, > > -Joe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Fri May 22 16:53:25 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 22 May 2015 09:53:25 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: <555F46A4.8040704@oracle.com> References: <555D5D32.9010908@oracle.com> <69BD6B3C-3C85-419F-A7F0-27D1DD9078C6@oracle.com> <555E5623.3020900@oracle.com> <555ED385.80508@oracle.com> <555F273E.9010203@oracle.com> <555F46A4.8040704@oracle.com> Message-ID: <555F5F05.503@oracle.com> On 05/22/2015 08:09 AM, Alan Bateman wrote: > > On 22/05/2015 13:55, Chris Hegarty wrote: >> : >> I think it could be done either way. > > Valerie - have you considered not pushing the services configuration > files with this change? With the change then the java.security > configuration is still class names, not provider names, so the > fallback should just work. This is what we've done in a few other > areas (like JNDI for example). I wasn't aware of the other areas that move to service provider but remain being loaded with the fallback Class.forName. I would prefer java.security should convert to use the provider names as an example and also exercise the code path using service providers. If this causes much work to workaround it temporarily, I won't object the security providers are not truly service providers (no META-INF/services and java.security lists class name instead) Another option to workaround this: we only need to merge the service config files for generating the image. Can we have do the concatenation of jdk/modules/*/META-INF/services file and output to supports/image_gensrc before the images target and have the image builder to exclude all jdk/modules/*/META-INF/services files and take the supports/image_gensrc instead? This will remove the process-provider logic from Gensrc-*.gmk files. Would this be a better alternative? Mandy From joe.darcy at oracle.com Fri May 22 17:46:40 2015 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 22 May 2015 10:46:40 -0700 Subject: JDK 9 RFR of JDK-8080901: Replace package.html files with package-info.java in the java.base module In-Reply-To: <0A82756E-C3A3-4D5B-A7E1-235850A36586@oracle.com> References: <555E62E0.5070000@oracle.com> <555F5C81.9000107@oracle.com> <0A82756E-C3A3-4D5B-A7E1-235850A36586@oracle.com> Message-ID: <555F6B80.8050309@oracle.com> Thanks for the review Vinnie; I've pushed with a consistent copyright date. -Joe On 5/22/2015 9:49 AM, Vincent Ryan wrote: > The 3 crypto files look fine to me. > BTW I did notice that you preserve the Copyright range years in all > but *src/java.base/share/classes/javax/crypto/package-info.java* > > Thanks. > > >> On 22 May 2015, at 17:42, joe darcy > > wrote: >> >> Hello security library team, >> >> I neglected to include you in the original request for review of this >> change. I'd like to replace all the package.html files in the >> java.base module with package-info.java files and a few cryptography >> packages are involved; please review. >> >> Thanks, >> >> -Joe >> >> >> -------- Forwarded Message -------- >> Subject: JDK 9 RFR of JDK-8080901: Replace package.html files with >> package-info.java in the java.base module >> Date: Thu, 21 May 2015 15:57:36 -0700 >> From: joe darcy >> Organization: Oracle Corporation >> To: core-libs-dev >> >> >> >> Hello, >> >> Please review these changes to replace old-style package.html files with >> package-info.java files in the base module: >> >> JDK-8080901: Replace package.html files with package-info.java in >> the java.base module >> http://cr.openjdk.java.net/~darcy/8080901.0/ >> >> (The package.html file for src/java.base/share/classes/sun/reflect is >> just removed rather than replaced since it contains "new" porting >> information that was current as of 2001.) >> >> Thanks, >> >> -Joe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri May 22 17:52:08 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 22 May 2015 13:52:08 -0400 Subject: RFR: 8065233: Remove Policy provider code that synchronizes on identityPolicyEntries List In-Reply-To: <555F4023.7010008@oracle.com> References: <555F3C5F.4000909@oracle.com> <555F3E39.2070403@oracle.com> <555F4023.7010008@oracle.com> Message-ID: <555F6CC8.1050803@oracle.com> On 05/22/2015 10:41 AM, Sean Mullan wrote: > On 05/22/2015 10:33 AM, Weijun Wang wrote: >> Looks good. >> >> Are you also going to remove the policy.ignoreIdentityScope definition >> inside jdk\src\java.base\share\conf\security\java.security? > > Good catch. I thought that had been removed as part of JDK-6876158. Let > me think this over a bit first. After further thought, I think it makes sense to leave the property in for now. The Identity and IdentityScope classes are under consideration for removal in JDK 10, and if that is approved, we will also remove the property at that time. It's possible (though I would be very surprised) that there are 3rd party providers that support that property. For the purposes of the policy provider in the JDK, it has not supported that property since JDK-6876158 was fixed (JDK 7). Thus, I will proceed with this fix as-is, since it is just removing leftover code that is useless at this point. The one change I will make is to add a sentence to the java.security file that the default JDK policy provider does not support this property. This is just documenting existing behavior since JDK 7, so a CCC is not required. Are you ok with that? Thanks, Sean > --Sean > >> >> Thanks >> Max >> >> >> On 5/22/2015 10:25 PM, Sean Mullan wrote: >>> This is the second in a series of fixes for JEP 232 (Improve Secure >>> Application Performance) [1]. >>> >>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8065233/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8065233 >>> >>> This fix removes some obsolete synchronization code from the Policy >>> implementation. This results in a slight improvement (about 2-4%) in the >>> throughput of the Policy.getPermissions method. The bug contains a >>> performance chart with more details. >>> >>> Thanks, >>> Sean >>> >>> [1] http://openjdk.java.net/jeps/232 From sean.mullan at oracle.com Fri May 22 18:54:04 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 22 May 2015 14:54:04 -0400 Subject: TLS ALPN Proposal In-Reply-To: References: <555E7E98.9050208@oracle.com> Message-ID: <555F7B4C.5060709@oracle.com> On 05/22/2015 12:12 PM, Simone Bordet wrote: > Would be great if we could make this class a FunctionalInterface Yes, that would be nice. >, but > I guess it's not easy due to lack of commonality between SSLSocket and > SSLEngine. > Unless there is a way to abstract something out of those 2:) There's actually a bunch of methods in common, so one possibility is to create a new interface containing the common methods (say SSLBase for now for lack of a better name). Then you could change SSLEngine and SSLSocket to implement SSLBase (which should be a compatible change), and then have a single method on ApplicationProtocolSelector. Question is if there are enough common methods to do what you want? I don't know enough about ALPN to answer that question. --Sean From vincent.x.ryan at oracle.com Fri May 22 19:10:55 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 22 May 2015 20:10:55 +0100 Subject: [8u] request for review: 8062552 Support keystore type detection for JKS and PKCS12 keystores In-Reply-To: <555F4AE6.7070809@oracle.com> References: <033093D0-42E0-462F-A071-4EA5420541C0@oracle.com> <555F4AE6.7070809@oracle.com> Message-ID: <13F80CA0-3F67-4CC6-A2B5-3602DC861B82@oracle.com> Thanks Thomas and Sean for your review comments. KeyStoreDelegator matches the JDK 9 version. I?ve moved it to the sun.security.package and modified it as suggested. I also made JavaKeyStore package-private but DualFormatJKS needs to remain public. The cert in trusted.pem is an arbitrary X.509 cert and I?ve added a comment in the TestKeystoreCompat test. A new webrev is available at: http://cr.openjdk.java.net/~vinnie/8062552/webrev.02/ > On 22 May 2015, at 16:27, Sean Mullan wrote: > > Just a couple of other comments: > > - Both JavaKeyStore and JavaKeyStore$DualFormatJKS can be package-private since they are only referenced from SunEntries which is in the same package. I would also move KeyStoreDelegator into sun.security.provider and make it package-private. > > - Can you add a comment describing the contents of the trusted.pem cert in case we need to re-create it at some point in the future? > > - In KeyStoreDelegator, I think most/all of the fields can be made final. > > --Sean > > On 05/21/2015 11:44 AM, Vincent Ryan wrote: >> Please review this enhancement to JDK 8u that addresses a compatibility risk for certain applications that access >> keystores across JDK 8 and JDK 9 releases. The issue arises because the default keystore type is now PKCS12 in >> JDK 9 but is JKS in earlier releases. The problem can occur when a keystore is created on JDK 9 using the default >> keystore type but accessed on JDK 8 also using the default keystore type. This keystore type mismatch results in >> an error. >> >> The change introduces a keystore compatibility mode for JKS keystores where both JKS and PKCS12 file formats are >> understood. Similar behaviour is already present in JDK 9 (JEP-229). The keystore.type.compat security property >> controls whether the mode is enabled or not. By default it is enabled. >> >> This enhancement enables at risk applications to continue to function across JDK 8 and JDK 9 without requiring any >> application code changes. >> >> Thanks. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8062552 >> Webrev: http://cr.openjdk.java.net/~vinnie/8062552/webrev.01/ >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Fri May 22 19:14:03 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 22 May 2015 21:14:03 +0200 Subject: TLS ALPN Proposal In-Reply-To: References: <555E7E98.9050208@oracle.com> Message-ID: <20150522211403.000078cf.ecki@zusammenkunft.net> > > There was also some internal discussion about whether the values > > should be Strings or byte arrays. The ALPN RFC only discusses > > bytes, and a String.toBytes("US-ASCII") would limit the API to > > ASCII strings. > > > > Lastly, we could also add some convenience values for well-known > > values. e.g.: > > > > public static final AP_HTTP_1.1 = "http/1.1"; > > > > or in byte form: > > > > public static final AP_H2 = "h2".getBytes(""US-ASCII"); > > > > I refrained from including SPDY/*, since they are on their way out > > now, and NAT/STUN since there hasn't been any call for it so far. > > I agree that only http/1.1 and h2 deserve a constant. I would suggest to make this encoded in latin1 instead. This is supposed to be a 8bit clean encoding (and will be compatible to all ASCII only strings). It is still ugly and needs to be documanted cleanly that the string you get back might not be a string at all. Gruss Bernd From simone.bordet at gmail.com Fri May 22 19:16:54 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Fri, 22 May 2015 21:16:54 +0200 Subject: TLS ALPN Proposal In-Reply-To: <555F7B4C.5060709@oracle.com> References: <555E7E98.9050208@oracle.com> <555F7B4C.5060709@oracle.com> Message-ID: Hi, On Fri, May 22, 2015 at 8:54 PM, Sean Mullan wrote: > There's actually a bunch of methods in common, so one possibility is to > create a new interface containing the common methods (say SSLBase for now > for lack of a better name). Then you could change SSLEngine and SSLSocket to > implement SSLBase (which should be a compatible change), and then have a > single method on ApplicationProtocolSelector. Question is if there are > enough common methods to do what you want? I don't know enough about ALPN to > answer that question. There are 2 things that conflate here: one is to provide the mechanism to support ALPN, and the second is to make sure that it is possible to support HTTP/2. ALPN per se, for example, does not need any information about SSLEngine or TLS protocol versions or ciphers. It just needs the protocol strings, so the ApplicationProtocolSelector would just need select(List). For HTTP/2, however, the choice of the protocol will depend on the TLS version and the cipher, so we will need a way to obtain that information. Typically, in the code where you pass the ApplicationProtocolSelector you have the SSLEngine available, e.g.: sslEngine.getSSLParameters().setApplicationProtocolSelector(new ApplicationProtocolSelector() { public String select(List clientProtocols) { // Here sslEngine will be in lexical scope } }); In this way, ApplicationProtocolSelector won't depend on SSLEngine or SSLSocket, and can be reduced to a FunctionalInterface. -- 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 simone.bordet at gmail.com Fri May 22 19:20:59 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Fri, 22 May 2015 21:20:59 +0200 Subject: TLS ALPN Proposal In-Reply-To: <20150522211403.000078cf.ecki@zusammenkunft.net> References: <555E7E98.9050208@oracle.com> <20150522211403.000078cf.ecki@zusammenkunft.net> Message-ID: Hi, On Fri, May 22, 2015 at 9:14 PM, Bernd Eckenfels wrote: > I would suggest to make this encoded in latin1 instead. This is > supposed to be a 8bit clean encoding (and will be compatible to all > ASCII only strings). It is still ugly and needs to be documanted > cleanly that the string you get back might not be a string at all. RFC 7301 hints that protocol string could be UTF-8 encoded: http://tools.ietf.org/html/rfc7301#section-6 -- 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 Fri May 22 20:01:37 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 22 May 2015 16:01:37 -0400 Subject: [8u] request for review: 8062552 Support keystore type detection for JKS and PKCS12 keystores In-Reply-To: <13F80CA0-3F67-4CC6-A2B5-3602DC861B82@oracle.com> References: <033093D0-42E0-462F-A071-4EA5420541C0@oracle.com> <555F4AE6.7070809@oracle.com> <13F80CA0-3F67-4CC6-A2B5-3602DC861B82@oracle.com> Message-ID: <555F8B21.3050608@oracle.com> Looks fine to me. --Sean On 05/22/2015 03:10 PM, Vincent Ryan wrote: > Thanks Thomas and Sean for your review comments. > > KeyStoreDelegator matches the JDK 9 version. I?ve moved it to the > sun.security.package and modified it as suggested. > I also made JavaKeyStore package-private but DualFormatJKS needs to > remain public. > The cert in trusted.pem is an arbitrary X.509 cert and I?ve added a > comment in the TestKeystoreCompat test. > > A new webrev is available at: > http://cr.openjdk.java.net/~vinnie/8062552/webrev.02/ > > > >> On 22 May 2015, at 16:27, Sean Mullan > > wrote: >> >> Just a couple of other comments: >> >> - Both JavaKeyStore and JavaKeyStore$DualFormatJKS can be >> package-private since they are only referenced from SunEntries which >> is in the same package. I would also move KeyStoreDelegator into >> sun.security.provider and make it package-private. >> >> - Can you add a comment describing the contents of the trusted.pem >> cert in case we need to re-create it at some point in the future? >> >> - In KeyStoreDelegator, I think most/all of the fields can be made final. >> >> --Sean >> >> On 05/21/2015 11:44 AM, Vincent Ryan wrote: >>> Please review this enhancement to JDK 8u that addresses a >>> compatibility risk for certain applications that access >>> keystores across JDK 8 and JDK 9 releases. The issue arises because >>> the default keystore type is now PKCS12 in >>> JDK 9 but is JKS in earlier releases. The problem can occur when a >>> keystore is created on JDK 9 using the default >>> keystore type but accessed on JDK 8 also using the default keystore >>> type. This keystore type mismatch results in >>> an error. >>> >>> The change introduces a keystore compatibility mode for JKS keystores >>> where both JKS and PKCS12 file formats are >>> understood. Similar behaviour is already present in JDK 9 (JEP-229). >>> The keystore.type.compat security property >>> controls whether the mode is enabled or not. By default it is enabled. >>> >>> This enhancement enables at risk applications to continue to function >>> across JDK 8 and JDK 9 without requiring any >>> application code changes. >>> >>> Thanks. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8062552 >>> Webrev: http://cr.openjdk.java.net/~vinnie/8062552/webrev.01/ >>> > From ecki at zusammenkunft.net Fri May 22 21:34:35 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 22 May 2015 23:34:35 +0200 Subject: disabledAlgorithms "DHE keySize < 1024" support? Message-ID: <20150522233435.000040e2.ecki@zusammenkunft.net> Hello, does jdk.tls.disabledAlgorithms support to disable DHE based on the prime size (similiar to RSA keySize)? I have tried it, but I can only disable DHE completely, but I cannot get a Java TLS client to enforce higher standards (i.e. at least 768, better 1024) bit. I tried Oracle 8u40. Is there another way to do that? Gruss Bernd From weijun.wang at oracle.com Sat May 23 00:00:02 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 23 May 2015 08:00:02 +0800 Subject: RFR: 8065233: Remove Policy provider code that synchronizes on identityPolicyEntries List In-Reply-To: <555F6CC8.1050803@oracle.com> References: <555F3C5F.4000909@oracle.com> <555F3E39.2070403@oracle.com> <555F4023.7010008@oracle.com> <555F6CC8.1050803@oracle.com> Message-ID: <555FC302.6080700@oracle.com> On 5/23/2015 1:52 AM, Sean Mullan wrote: > After further thought, I think it makes sense to leave the property in > for now. > > The one change I will make is to add a sentence to the java.security > file that the default JDK policy provider does not support this > property. This is just documenting existing behavior since JDK 7, so a > CCC is not required. > > Are you ok with that? OK. --Max From weijun.wang at oracle.com Sat May 23 00:05:15 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 23 May 2015 08:05:15 +0800 Subject: TLS ALPN Proposal In-Reply-To: References: <555E7E98.9050208@oracle.com> <20150522211403.000078cf.ecki@zusammenkunft.net> Message-ID: <555FC43B.6070007@oracle.com> On 5/23/2015 3:20 AM, Simone Bordet wrote: > Hi, > > On Fri, May 22, 2015 at 9:14 PM, Bernd Eckenfels wrote: >> I would suggest to make this encoded in latin1 instead. This is >> supposed to be a 8bit clean encoding (and will be compatible to all >> ASCII only strings). It is still ugly and needs to be documanted >> cleanly that the string you get back might not be a string at all. > > RFC 7301 hints that protocol string could be UTF-8 encoded: > http://tools.ietf.org/html/rfc7301#section-6 But in the RFC the name is in uppercase and chars in string are all lowercases. So maybe the preferred impl will be like this? - Fields use String - on the wire UTF-8 - Compare with equalsIgnoreCase() --Max > From xuelei.fan at oracle.com Sat May 23 00:30:26 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 23 May 2015 08:30:26 +0800 Subject: disabledAlgorithms "DHE keySize < 1024" support? In-Reply-To: <20150522233435.000040e2.ecki@zusammenkunft.net> References: <20150522233435.000040e2.ecki@zusammenkunft.net> Message-ID: <555FCA22.20201@oracle.com> Please refer to the "Customizing Size of Ephemeral Diffie-Hellman Keys" section of JSSE Reference Guide. http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html Xuelei On 5/23/2015 5:34 AM, Bernd Eckenfels wrote: > Hello, > > does jdk.tls.disabledAlgorithms support to disable DHE based on the > prime size (similiar to RSA keySize)? I have tried it, but I can only > disable DHE completely, but I cannot get a Java TLS client to enforce > higher standards (i.e. at least 768, better 1024) bit. I tried > Oracle 8u40. Is there another way to do that? > > Gruss > Bernd > From bradford.wetmore at oracle.com Sat May 23 01:13:37 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 22 May 2015 18:13:37 -0700 Subject: TLS ALPN Proposal In-Reply-To: References: <555E7E98.9050208@oracle.com> Message-ID: <555FD441.4070204@oracle.com> Thanks for the thorough reviews and comments, I really appreciate it and always learn something. FunctionalInterface (@since 1.8) is something I haven't really explored yet, so off to the books. I'm glad this ALPN approach seems worth pursing. I have several different comments I'll combine into this single message. On 5/22/2015 9:12 AM, Simone Bordet wrote: >> ExtendedSSLSession: >> ------------------- >> gets the negotiated protocol String > > If I understand correctly, SSLParameters will have methods that can > only be used by one side of the TLS protocol (e.g. client or server, > but not both). > It's already like this for other things (e.g. SNI) so it will work, > but I had hoped for some kind of reworking in this area too, but I'm > digressing. I don't have a better idea/suggestion for this, protocol advertisement and selection are two very different things. At this point, I am thinking it should remain in SSLParameters. I considered putting the selector into the SSLContext initialization: sslContext.init(KeyManager, TrustManager, SecureRandom, Selector); but that means 1 selector for all SSLSockets/SSLEngines that get generated from that SSLContext. That is constricting if the selector wanted to keep any connection-specific values. It could go into SSLSocket/SSLEngine, but starting in JDK 6, we've been lumping all set* configuration parameters into SSLParameters, so that once configured, devs can reuse one SSLParameters object without having to reconstruct it (source code or at runtime) from scratch. BTW, there was a previous question about when to use SSLSocket.set*() and sslSocket.setSSLParameters(params). I gave a partial answer in: http://mail.openjdk.java.net/pipermail/security-dev/2014-November/011430.html I recently filed: https://bugs.openjdk.java.net/browse/JDK-8080799 Provide guidance on repeated configuration parameter APIs to address this. I don't think we need to deprecate the set() methods, but having a note here will alleviate confusion. >> /* >> * A callback class on the server side that is responsible for >> * choosing which Application Protocol should be used in a SSL/TLS >> * connection. >> */ >> public abstract class ApplicationProtocolSelector { >> >> /* >> * SSLSocket callback to choose which Application Protocol value >> * to return to a SSL/TLS client >> * >> * @param sslSocket the SSLSocket for this connection >> * @param protocols the list of protocols advertised by the client >> * @param protocolVersion the negotiated protocol version Egads, this is confusing. protocols is the ALPN protocols, protocolVersion is the TLS version number. I'll fix this. >> * @param ciphersuite the negotiated ciphersuite >> * @return a non-empty protocol String to send to the client, >> * or null if no protocol value (i.e. extension) should be sent. >> * @throws SSLProtocolException if the connection should be aborted >> * because the the server supports none of the protocols that >> * the client advertised. Whoops, I put exactly the Exception I didn't want to use! I was originally thinking SSLHandshakeException. See below for more comments. >> */ >> public String select(SSLSocket sslSocket, String[] protocols, >> String protocolVersion, String ciphersuite) >> throws SSLProtocolException; > > We are currently getting the protocolVersion and the cipherSuite via: > > [sslSocket|sslEngine].getHandshakeSession().get[Protocol|CipherSuite]() > > If this is correct, perhaps there is no need to pass those 2 > parameters to select() ? Good point. Yes, those are no longer needed. There was a suggestion to have access to the clientHello information in order to guide ciphersuite/protocol selection, however, there isn't a way to control that part of the internals at this time, so I didn't include it. As an aside, if we do develop the Handshake API (other mail) and allow for handshake message modification (not currently proposed, but hinted at), the protocols/ciphersuites values could be adjusted before they are handled. e.g. INBOUND callbacks would be triggered after the message has been parsed and added to the handshake hash calculation, but before clientHello() is actually called. > I would suggest that if SSLParameters.setApplicationProtocols() takes > a List, then also select() should take a List, rather > than a String[]. > Since it's the server picking the protocols, would be handy to have > the client protocols in a List in order to call contains(), > etc. on it. Good points. > I would suggest to throw SSLException rather than the too specific > SSLProtocolException (which may also be misleading, since its javadoc > hints at a "flaw in one of the protocol implementations", while in > this case it is just a failure to negotiate an *application* protocol > - perfectly fine from the point of view of the TLS protocol). See above. I'll change it to SSLException for now, but I think it probably should be SSLHandshakeException. > Would be great if we could make this class a FunctionalInterface, but > I guess it's not easy due to lack of commonality between SSLSocket and > SSLEngine. > Unless there is a way to abstract something out of those 2 :) I'll look into Sean's suggest of SSLBase. >> public class ExtendedSSLSession implements SSLSession { >> >> ...deleted... >> >> /** >> * Gets the application protocol negotiated for this connection. >> * >> * @returns the application protocol name or null if none was >> * negotiated. >> */ >> public String getApplicationProtocol() { }; >> } > > How would this case be covered: > > * client sends protocol list "foo","bar" > * server sends back "bax". > * client has to decide what to do. Are you positive this was a valid mode of operation? From RFC 7301: With ALPN, the client sends the list of supported application protocols as part of the TLS ClientHello message. The server chooses a protocol and sends the selected protocol as part of the TLS ServerHello message. This says to me that it needs to be one of the offered protocols. Granted, it's not explictly stated "it must be one of the offered", but allowing for that doesn't make sense to me. Should the server really be allowed to select a protocol that the client didn't offer, and then realistically expect the client to support it? If the server supported it, the client should have offered in the first place. I was originally thinking that we should throw an Exception if the negotiated protocol is not one of those sent, but maybe that's better left to the application when it looks at the ALPN value after handshaking is completed. > The only chance to call ExtendedSSLSession.getApplicationProtocol() > would be *after* the handshake is completed, right ? I think this point is moot, but to answer your question. For SSLEngine, it could be done at any time. For SSLSocket, if the connection needed to use the KeyManager(client auth)/TrustManager(server cert verification), then it could call during that point. > Do you plan to hardcode the abort of the handshake with an alert_120, > or give the application a chance (just asking) ? Originally, yes. To support what you suggest, we would need to add a level/description to the SSLException class. I'd been debating that anyway, but this RFC was pretty clear that only 120 is needed. >> There was also some internal discussion about whether the values should be >> Strings or byte arrays. The ALPN RFC only discusses bytes, and a >> String.toBytes("US-ASCII") would limit the API to ASCII strings. >> >> Lastly, we could also add some convenience values for well-known values. >> e.g.: >> >> public static final AP_HTTP_1.1 = "http/1.1"; >> >> or in byte form: >> >> public static final AP_H2 = "h2".getBytes(""US-ASCII"); >> >> I refrained from including SPDY/*, since they are on their way out now, and >> NAT/STUN since there hasn't been any call for it so far. > > I agree that only http/1.1 and h2 deserve a constant. Ok. Sean wrote: > There's actually a bunch of methods in common, so one possibility is > to create a new interface containing the common methods (say SSLBase > for now for lack of a better name). Then you could change SSLEngine > and SSLSocket to implement SSLBase (which should be a compatible > change), and then have a single method on ApplicationProtocolSelector. Worth looking into. Thanks for the suggestion. Simon wrote: > For HTTP/2, however, the choice of the protocol will depend on the TLS > version and the cipher, so we will need a way to obtain that > information. Yes, that's why I originally included the negotiated protocol/ciphersuite (er...soon to be sslBase.getHandshakeSession()). HTTP/2 must be TLSv1.2 and the ciphersuite must not be on the blacklist. > Typically, in the code where you pass the ApplicationProtocolSelector > you have the SSLEngine available, e.g.: > > sslEngine.getSSLParameters().setApplicationProtocolSelector(new > ApplicationProtocolSelector() > { > public String select(List clientProtocols) > { > // Here sslEngine will be in lexical scope > } > }); > > In this way, ApplicationProtocolSelector won't depend on SSLEngine or > SSLSocket, and can be reduced to a FunctionalInterface. But during the callback, does the application have access to the SSLEngine? Unless I've haven't grasped how FunctionalInterfaces would have access to SSLEngine/SSLSocket objects here (admittedly I'm flying a little blind here), the application might want to make the protocol decision based on other factors such as network origin. Our original X509TrustManager didn't have access to the Socket/Engine, and it was commonly requested. > RFC 7301 hints that protocol string could be UTF-8 encoded: > http://tools.ietf.org/html/rfc7301#section-6 Thanks for the pointer. We could add to the javadoc that it will be handled as UTF-8? Weijun wrote: > But in the RFC the name is in uppercase and chars in string are all > lowercases. > ...deleted... > - Compare with equalsIgnoreCase() Not following here, the spec is specific about the over-the-wire byte values, and http/1.1 != Http/1.1. The conversion inside SSLParameters could be done as: String s = new String(ba, "UTF-8"); byte[] ba = s.getBytes("UTF-8"); I would love any thoughts on the Handshake API approach, but understand it's a lot to parse, and ALPN should take priority for the immediate future. I should have an update out early next week, and hopefully can move this JEP to "Proposed to Target" if there are no other major comments. Thanks again, Brad From weijun.wang at oracle.com Sat May 23 03:28:50 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 23 May 2015 11:28:50 +0800 Subject: TLS ALPN Proposal In-Reply-To: <555FD441.4070204@oracle.com> References: <555E7E98.9050208@oracle.com> <555FD441.4070204@oracle.com> Message-ID: <555FF3F2.1000201@oracle.com> On 5/23/2015 9:13 AM, Bradford Wetmore wrote: > Weijun wrote: > > > But in the RFC the name is in uppercase and chars in string are all > > lowercases. > > ...deleted... > > - Compare with equalsIgnoreCase() > > Not following here, the spec is specific about the over-the-wire byte > values, and http/1.1 != Http/1.1. Because the spec says o Identification Sequence: The precise set of octet values that identifies the protocol. This could be the UTF-8 encoding [RFC3629] of the protocol name. and the name is uppercase. What if someone really sends "HTTP/1.1".getBytes("UTF-8")? --Max From openjdk at suche.org Sat May 23 08:42:17 2015 From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Sat, 23 May 2015 10:42:17 +0200 Subject: [8u] request for review: 8062552 Support keystore type detection for JKS and PKCS12 keystores In-Reply-To: <555F8B21.3050608@oracle.com> References: <033093D0-42E0-462F-A071-4EA5420541C0@oracle.com> <555F4AE6.7070809@oracle.com> <13F80CA0-3F67-4CC6-A2B5-3602DC861B82@oracle.com> <555F8B21.3050608@oracle.com> Message-ID: <55603D69.7020101@suche.org> Hi, 1) Would it not be an good idea to check the first bytes of the message so that the dual class already know what type the stream is and there is no unnecessary instanciation of exceptions and engine class? 2) If we add an "smart" keystore why we limit it to two types? I do not see any reason why it should not be possible to add other store types to: - JCEKS - PKCS11 It could be extended via securit property java.security.smartKeystore..type = PKCS11 java.security.smartKeystore..magic = (Optional for Performance) java.security.smartKeystore..engineClass = CanonicalEngine Class Name This would be only an small code change but an usefull improvement. Gru? Thomas On 22.05.2015 22:01, Sean Mullan wrote: > Looks fine to me. > > --Sean > > On 05/22/2015 03:10 PM, Vincent Ryan wrote: >> Thanks Thomas and Sean for your review comments. >> >> KeyStoreDelegator matches the JDK 9 version. I?ve moved it to the >> sun.security.package and modified it as suggested. >> I also made JavaKeyStore package-private but DualFormatJKS needs to >> remain public. >> The cert in trusted.pem is an arbitrary X.509 cert and I?ve added a >> comment in the TestKeystoreCompat test. >> >> A new webrev is available at: >> http://cr.openjdk.java.net/~vinnie/8062552/webrev.02/ From vincent.x.ryan at oracle.com Sat May 23 08:59:11 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Sat, 23 May 2015 09:59:11 +0100 Subject: [8u] request for review: 8062552 Support keystore type detection for JKS and PKCS12 keystores In-Reply-To: <55603D69.7020101@suche.org> References: <033093D0-42E0-462F-A071-4EA5420541C0@oracle.com> <555F4AE6.7070809@oracle.com> <13F80CA0-3F67-4CC6-A2B5-3602DC861B82@oracle.com> <555F8B21.3050608@oracle.com> <55603D69.7020101@suche.org> Message-ID: The aim of this enhancement is to address a specific compatibility risk for JKS and not to offer a general purpose mechanism for loading any keystore type. In general, the keystore type should match the keystore file format. In JDK 9 there is a new probe mechanism for keystores that is more similar to what you are proposing. The advantage of that mechanism is that the keystore type will exactly match the keystore file format. > On 23 May 2015, at 09:42, Thomas Lu?nig wrote: > > Hi, > > 1) Would it not be an good idea to check the first bytes of the message > so that the dual class already know what type the stream is > and there is no unnecessary instanciation of exceptions and engine class? > 2) If we add an "smart" keystore why we limit it to two types? I do not > see any reason why it should not be possible to add other store types to: > - JCEKS > - PKCS11 > It could be extended via securit property > java.security.smartKeystore..type = PKCS11 > java.security.smartKeystore..magic = (Optional for > Performance) > java.security.smartKeystore..engineClass = CanonicalEngine Class Name > > This would be only an small code change but an usefull improvement. > > Gru? Thomas > > > On 22.05.2015 22:01, Sean Mullan wrote: >> Looks fine to me. >> >> --Sean >> >> On 05/22/2015 03:10 PM, Vincent Ryan wrote: >>> Thanks Thomas and Sean for your review comments. >>> >>> KeyStoreDelegator matches the JDK 9 version. I?ve moved it to the >>> sun.security.package and modified it as suggested. >>> I also made JavaKeyStore package-private but DualFormatJKS needs to >>> remain public. >>> The cert in trusted.pem is an arbitrary X.509 cert and I?ve added a >>> comment in the TestKeystoreCompat test. >>> >>> A new webrev is available at: >>> http://cr.openjdk.java.net/~vinnie/8062552/webrev.02/ From simone.bordet at gmail.com Sat May 23 13:45:45 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Sat, 23 May 2015 15:45:45 +0200 Subject: TLS ALPN Proposal In-Reply-To: <555FD441.4070204@oracle.com> References: <555E7E98.9050208@oracle.com> <555FD441.4070204@oracle.com> Message-ID: Hi, On Sat, May 23, 2015 at 3:13 AM, Bradford Wetmore wrote: > Thanks for the thorough reviews and comments, I really appreciate it and > always learn something. FunctionalInterface (@since 1.8) is something I > haven't really explored yet, so off to the books. Just to be clear, this is what I am proposing: class SSLParameters { ... List getApplicationProtocols(); void setApplicationProtocols(List protocols); void setApplicationProtocolSelector(ApplicationProtocolSelector selector); ApplicationProtocolSelector getApplicationProtocolSelector(); } @FunctionalInterface interface ApplicationProtocolSelector { String select(List protocols) throws SSLException; } In this way, there is no need for a SSLBase to converge SSLSocket and SSLEngine, the ApplicationProtocolSelector can be specified as a lambda expression on SSLParameters, and everything is much simpler. -- 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 ecki at zusammenkunft.net Sat May 23 13:50:06 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sat, 23 May 2015 15:50:06 +0200 Subject: disabledAlgorithms "DHE keySize < 1024" support? In-Reply-To: <555FCA22.20201@oracle.com> References: <20150522233435.000040e2.ecki@zusammenkunft.net> <555FCA22.20201@oracle.com> Message-ID: <20150523155006.000037eb.ecki@zusammenkunft.net> Am Sat, 23 May 2015 08:30:26 +0800 schrieb Xuelei Fan : > Please refer to the "Customizing Size of Ephemeral Diffie-Hellman > Keys" section of JSSE Reference Guide. > > http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html Thanks Xulei, but I think this does not address the minimum accepted size of an client SSLSocket (at least I could not see that in the description). It only allows to configure the server generated groups in the ServerKeyExchange. When setting jdk.tls.ephemeralDHKeySize=2048 I still can connect to https://dhe512.zmap.io/ Gruss Bernd BTW in Regards to the Server side: That document should mention that the parameter group is generated randomly on first use (matching DSA restrictions). It is a good thing there are no standard primes used, it would be better if they are constructed not specifically for DSA (as mentioned in the Logjam paper). I can imagine that in the future for higher security mutual agreed parameter groups become more important, so let me point to http://bugs.java.com/view_bug.do?bug_id=4641806 as well. From xuelei.fan at oracle.com Sat May 23 14:16:16 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 23 May 2015 22:16:16 +0800 Subject: disabledAlgorithms "DHE keySize < 1024" support? In-Reply-To: <20150523155006.000037eb.ecki@zusammenkunft.net> References: <20150522233435.000040e2.ecki@zusammenkunft.net> <555FCA22.20201@oracle.com> <20150523155006.000037eb.ecki@zusammenkunft.net> Message-ID: <55608BB0.7040208@oracle.com> On 5/23/2015 9:50 PM, Bernd Eckenfels wrote: > Am Sat, 23 May 2015 08:30:26 +0800 > schrieb Xuelei Fan : > >> Please refer to the "Customizing Size of Ephemeral Diffie-Hellman >> Keys" section of JSSE Reference Guide. >> >> http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html > > Thanks Xulei, but I think this does not address the minimum accepted > size of an client SSLSocket (at least I could not see that in the > description). It only allows to configure the server generated groups > in the ServerKeyExchange. > > When setting jdk.tls.ephemeralDHKeySize=2048 I still can connect to > https://dhe512.zmap.io/ > Right, it is impact the generation of DH keys. I did not get your ideas in the previous mail. "jdk.tls.disabledAlgorithms" is expected to work to disable weak DH keys (for example, ""DHE keySize < 768"). Can you describe your concern more? Thanks, Xuelei > Gruss > Bernd > > BTW in Regards to the Server side: > > That document should mention that the parameter group is generated > randomly on first use (matching DSA restrictions). It is a good thing > there are no standard primes used, it would be better if they are > constructed not specifically for DSA (as mentioned in the Logjam > paper). > > I can imagine that in the future for higher security mutual agreed > parameter groups become more important, so let me point to > http://bugs.java.com/view_bug.do?bug_id=4641806 as well. > From ecki at zusammenkunft.net Sat May 23 15:18:07 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sat, 23 May 2015 17:18:07 +0200 Subject: disabledAlgorithms "DHE keySize < 1024" support? In-Reply-To: <55608BB0.7040208@oracle.com> References: <20150522233435.000040e2.ecki@zusammenkunft.net> <555FCA22.20201@oracle.com> <20150523155006.000037eb.ecki@zusammenkunft.net> <55608BB0.7040208@oracle.com> Message-ID: <20150523171807.00000ea6.ecki@zusammenkunft.net> Am Sat, 23 May 2015 22:16:16 +0800 schrieb Xuelei Fan : > I did not get your ideas in the previous mail. > "jdk.tls.disabledAlgorithms" is expected to work to disable weak DH > keys (for example, ""DHE keySize < 768"). Can you describe your > concern more? This is exactly what I want to do. In order for a client to protect against a Logjam attack it has to reject DHE groups with a prime smaller than a safe size. This is at least 768 bit but more security sensitive installation might want to restrict >1024 or even >2048 bit as well. Unfortiunatelly Java Clients accept 512bit (even when they do not offer export grade ciphers). So a minimum fix would be to only accept 512bit if it was offering export crypto. However making the minimum configurable would be even better. The current mechanism to restrict ciphers by key length does however not work, it seems. I suspect it only works for explicitely geenrated DH parameters but not received DHE groups. I searched the ClientHandshaker for usages of algorithmConstraints, and it does not use it for the DHE part. It only question KEY_AGREEMENT for cipher suite selection. (But I am not so famiiar with the code, maybe you can point me to a place where the DHE size would be validated). Thinking about it, it might be possible to register an own DiffieHellmann provider to enforce a limit, hm. Gruss Bernd From xuelei.fan at oracle.com Sat May 23 15:35:36 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 23 May 2015 23:35:36 +0800 Subject: disabledAlgorithms "DHE keySize < 1024" support? In-Reply-To: <20150523171807.00000ea6.ecki@zusammenkunft.net> References: <20150522233435.000040e2.ecki@zusammenkunft.net> <555FCA22.20201@oracle.com> <20150523155006.000037eb.ecki@zusammenkunft.net> <55608BB0.7040208@oracle.com> <20150523171807.00000ea6.ecki@zusammenkunft.net> Message-ID: <55609E48.60204@oracle.com> On 5/23/2015 11:18 PM, Bernd Eckenfels wrote: > Am Sat, 23 May 2015 22:16:16 +0800 > schrieb Xuelei Fan : > >> I did not get your ideas in the previous mail. >> "jdk.tls.disabledAlgorithms" is expected to work to disable weak DH >> keys (for example, ""DHE keySize < 768"). Can you describe your >> concern more? > > This is exactly what I want to do. In order for a client to protect > against a Logjam attack it has to reject DHE groups with a prime > smaller than a safe size. This is at least 768 bit but more security > sensitive installation might want to restrict >1024 or even >2048 bit as > well. > > Unfortiunatelly Java Clients accept 512bit (even when they do not offer > export grade ciphers). So a minimum fix would be to only accept 512bit > if it was offering export crypto. However making the minimum > configurable would be even better. > > The current mechanism to restrict ciphers by key length does however > not work, it seems. I suspect it only works for explicitely geenrated > DH parameters but not received DHE groups. > I see your point. Thanks, Xuelei > I searched the ClientHandshaker for usages of algorithmConstraints, and > it does not use it for the DHE part. It only question KEY_AGREEMENT for > cipher suite selection. (But I am not so famiiar with the code, maybe > you can point me to a place where the DHE size would be validated). > > Thinking about it, it might be possible to register an own > DiffieHellmann provider to enforce a limit, hm. > > Gruss > Bernd > From ecki at zusammenkunft.net Sat May 23 15:48:25 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sat, 23 May 2015 17:48:25 +0200 Subject: disabledAlgorithms "DHE keySize < 1024" support? In-Reply-To: <20150523171807.00000ea6.ecki@zusammenkunft.net> References: <20150522233435.000040e2.ecki@zusammenkunft.net> <555FCA22.20201@oracle.com> <20150523155006.000037eb.ecki@zusammenkunft.net> <55608BB0.7040208@oracle.com> <20150523171807.00000ea6.ecki@zusammenkunft.net> Message-ID: <20150523174825.00007ee8.ecki@zusammenkunft.net> Am Sat, 23 May 2015 17:18:07 +0200 schrieb Bernd Eckenfels : > I searched the ClientHandshaker for usages of algorithmConstraints, > and it does not use it for the DHE part. It only question > KEY_AGREEMENT for cipher suite selection. (But I am not so famiiar > with the code, maybe you can point me to a place where the DHE size > would be validated). I also run some connection test, it asks for the following permissions on the user set AC of SSLParameters: prim [KEY_AGREEMENT] TLSv1 with null prim [KEY_AGREEMENT] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with null prim [KEY_AGREEMENT] TLSv1.1 with null prim [KEY_AGREEMENT] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with null prim [KEY_AGREEMENT] TLSv1.2 with null prim [KEY_AGREEMENT] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 with null prim [KEY_AGREEMENT] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 with null prim [KEY_AGREEMENT] TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 with null prim [KEY_AGREEMENT] TLS_RSA_WITH_AES_128_CBC_SHA256 with null prim [KEY_AGREEMENT] TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 with null prim [KEY_AGREEMENT] TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 with null prim [KEY_AGREEMENT] TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 with null prim [KEY_AGREEMENT] TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 with null ... prim [KEY_AGREEMENT] SSL_RSA_WITH_RC4_128_MD5 with null prim [KEY_AGREEMENT] TLS_EMPTY_RENEGOTIATION_INFO_SCSV with null prim [SIGNATURE] SHA512withECDSA with null prim [SIGNATURE] SHA512withRSA with null ... prim [SIGNATURE] MD5withRSA with null prim [SIGNATURE] SHA384withRSA with null prim [SIGNATURE] Sun RSA public key, 4096 bits, modulus: 59... prim [SIGNATURE] SHA384withRSA with null prim [SIGNATURE] Sun RSA public key, 2048 bits prim [SIGNATURE] SHA384withRSA on Sun RSA public key prim [SIGNATURE] SHA256withRSA with prim [SIGNATURE] SHA256withRSA on Sun RSA Cipher used TLSv1.2 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 I do see some code which might be responsible for checking DHE restrictions, but I cant get it to work. Neither with above user algortihm constraints nor with the following disables line: jdk.tls.disabledAlgorithms=MD5, RC4, SSLv3, DSA, RSA keySize < 2048, DHE keySize < 1024, DiffieHellman keySize < 1024, DH keySize < 1024 So my guess, it cannot be controled currently. Gruss Bernd From ecki at zusammenkunft.net Sat May 23 16:09:20 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sat, 23 May 2015 18:09:20 +0200 Subject: disabledAlgorithms "DHE keySize < 1024" support? In-Reply-To: <20150523174825.00007ee8.ecki@zusammenkunft.net> References: <20150522233435.000040e2.ecki@zusammenkunft.net> <555FCA22.20201@oracle.com> <20150523155006.000037eb.ecki@zusammenkunft.net> <55608BB0.7040208@oracle.com> <20150523171807.00000ea6.ecki@zusammenkunft.net> <20150523174825.00007ee8.ecki@zusammenkunft.net> Message-ID: <20150523180920.000034c3.ecki@zusammenkunft.net> Am Sat, 23 May 2015 17:48:25 +0200 schrieb Bernd Eckenfels : > I also run some connection test In case somebody wonders, the test code is here: https://github.com/ecki/JavaCryptoTest#simple-weakdh-logjam-test-client Gruss Bernd From openjdk at suche.org Sat May 23 21:57:17 2015 From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Sat, 23 May 2015 23:57:17 +0200 Subject: [8u] request for review: 8062552 Support keystore type detection for JKS and PKCS12 keystores In-Reply-To: References: <033093D0-42E0-462F-A071-4EA5420541C0@oracle.com> <555F4AE6.7070809@oracle.com> <13F80CA0-3F67-4CC6-A2B5-3602DC861B82@oracle.com> <555F8B21.3050608@oracle.com> <55603D69.7020101@suche.org> Message-ID: <5560F7BD.5070400@suche.org> On 23.05.2015 10:59, Vincent Ryan wrote: > The aim of this enhancement is to address a specific compatibility risk for JKS and > not to offer a general purpose mechanism for loading any keystore type. In general, > the keystore type should match the keystore file format. > > In JDK 9 there is a new probe mechanism for keystores that is more similar to > what you are proposing. The advantage of that mechanism is that the keystore > type will exactly match the keystore file format. When there is already an new probe mechanism for keystore detetion, why do not backport/use it ? Why build this limited version for one single usecase instead of using the more gerneral solution ? > >> On 23 May 2015, at 09:42, Thomas Lu?nig wrote: >> >> Hi, >> >> 1) Would it not be an good idea to check the first bytes of the message >> so that the dual class already know what type the stream is >> and there is no unnecessary instanciation of exceptions and engine class? >> 2) If we add an "smart" keystore why we limit it to two types? I do not >> see any reason why it should not be possible to add other store types to: >> - JCEKS >> - PKCS11 >> It could be extended via securit property >> java.security.smartKeystore..type = PKCS11 >> java.security.smartKeystore..magic = (Optional for >> Performance) >> java.security.smartKeystore..engineClass = CanonicalEngine Class Name >> >> This would be only an small code change but an usefull improvement. >> >> Gru? Thomas >> >> >> On 22.05.2015 22:01, Sean Mullan wrote: >>> Looks fine to me. >>> >>> --Sean >>> >>> On 05/22/2015 03:10 PM, Vincent Ryan wrote: >>>> Thanks Thomas and Sean for your review comments. >>>> >>>> KeyStoreDelegator matches the JDK 9 version. I?ve moved it to the >>>> sun.security.package and modified it as suggested. >>>> I also made JavaKeyStore package-private but DualFormatJKS needs to >>>> remain public. >>>> The cert in trusted.pem is an arbitrary X.509 cert and I?ve added a >>>> comment in the TestKeystoreCompat test. >>>> >>>> A new webrev is available at: >>>> http://cr.openjdk.java.net/~vinnie/8062552/webrev.02/ From ecki at zusammenkunft.net Sat May 23 23:58:17 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sun, 24 May 2015 01:58:17 +0200 Subject: configurable DHE key size In-Reply-To: <20150523155006.000037eb.ecki@zusammenkunft.net> References: <20150522233435.000040e2.ecki@zusammenkunft.net> <555FCA22.20201@oracle.com> <20150523155006.000037eb.ecki@zusammenkunft.net> Message-ID: <20150524015817.000045fd.ecki@zusammenkunft.net> Hello, I need to correct a statement: Am Sat, 23 May 2015 15:50:06 +0200 schrieb Bernd Eckenfels : > BTW in Regards to the Server side: > > That document should mention that the parameter group is generated > randomly on first use (matching DSA restrictions). It is a good thing > there are no standard primes used This is actually wrong. I missed the fact that the Parameter Cache is pre-populated with primes for some sizes. Theoretically one can pick a different bit size and it should be randomly generated. However this has a problem: - ServerHandshaker restricts custom sizes between 1024 and 2048 Exception in thread "main" java.lang.ExceptionInInitializerError at sun.security.ssl.SSLSocketImpl.initHandshaker(SSLSocketImpl.java:1310) at sun.security.ssl.SSLSocketImpl.doneConnect(SSLSocketImpl.java:678) at sun.security.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:349) at net.eckenfels.test.ssl.JSSESocketServer.main(JSSESocketServer.java:104) Caused by: java.lang.IllegalArgumentException: Customized DH key size should be positive integer between 1024 and 2048 bits, inclusive at sun.security.ssl.ServerHandshaker.(ServerHandshaker.java:131) - DHParameterGenerator on the other hand allows custom sizes only between 512 and 1024: Exception in thread "main" javax.net.ssl.SSLException: java.security.InvalidParameterException: Keysize must be multiple of 64 ranging from 512 to 1024 (inclusive), or 2048 at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1937) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1894) at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1877) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1398) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375) at net.eckenfels.test.ssl.JSSESocketServer.main(JSSESocketServer.java:118) Caused by: java.security.InvalidParameterException: Keysize must be multiple of 64 ranging from 512 to 1024 (inclusive), or 2048 at com.sun.crypto.provider.DHParameterGenerator.engineInit(DHParameterGenerator.java:84) at java.security.AlgorithmParameterGenerator.init(AlgorithmParameterGenerator.java:296) at sun.security.provider.ParameterCache.getDHParameterSpec(ParameterCache.java:130) at com.sun.crypto.provider.DHKeyPairGenerator.generateKeyPair(DHKeyPairGenerator.java:148) at java.security.KeyPairGenerator$Delegate.generateKeyPair(KeyPairGenerator.java:697) at sun.security.ssl.DHCrypt.generateDHPublicKeySpec(DHCrypt.java:226) at sun.security.ssl.DHCrypt.(DHCrypt.java:101) at sun.security.ssl.ServerHandshaker.setupEphemeralDHKeys(ServerHandshaker.java:1357) ... So you can effectively only set 1024 or 2048, and both are precomputed. It would be good to allow a wider range to be set and generated (asuming it can generate safe primes) and even better to specify the parameters on the SSLParameters. Gruss Bernd From sebastian at 2007.org Sun May 24 14:38:18 2015 From: sebastian at 2007.org (Sebastian Boschert) Date: Sun, 24 May 2015 16:38:18 +0200 Subject: PBKDF2KeyImpl should offer a way to clear plaintext password from memory Message-ID: <9B3284DF-2155-4A4E-BC7E-3EEF9FCCD792@2007.org> Hello, I am currently working on a project that uses JDK's crypto libs to encrypt passwords using PBKDF2. During development I noticed that the PBKDF2KeyImpl class (which implements the SecretKey interface) retains a copy of the plaintext password char[] array. It seems to be impossible to clear the plaintext password after use. In my opinion, this is a security issue as an attacker could easily retrieve plaintext passwords that have not yet been garbage-collected, e.g. by analyzing a heap dump. I would have expected PBKDF2KeyImpl's destroy() method to overwrite the passwd char[], but instead PBKDF2KeyImpl does not override the default implementation from the Destroyable interface. This results in DestroyFailedExceptions being thrown whenever the destroy() method is called. In my opinion, JDK should probably include a way to clear the plaintext password. My suggestion would be to just provide an implementation of destroy(). This has the advantage of not having to add any new API. However, PBKDF2KeyImpl's getPassword() method would probably stop working as expected. I am new to JDK development (in fact this e-mail is my first involvement in it), but I have been using Java and the JDK for well over a decade. Therefore, I'd be happy to help in finding a solution and to offer my time in helping to implement it. Since I'm sure there's some process involved, I could probably use some guidance on how I could contribute to this issue. Here's the code that I currently have that made me aware of the issue. When debugging this code, it's obvious that secretKey's passwd field still contains the plaintext password, even after the DestroyFailedException is thrown. -------------------------------------------------------------------- SecretKeyFactory secretKeyFactory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA512"); PBEKeySpec spec = null; SecretKey secretKey = null; try { spec = new PBEKeySpec(plaintext, salt, iterations, keySizeBits); secretKey = secretKeyFactory.generateSecret(spec); return secretKey.getEncoded(); } catch (InvalidKeySpecException e) { throw new Error("Could not create valid key spec.", e); } finally { // Destroy the secret key because it might still contain the // plaintext password. if (secretKey != null && !secretKey.isDestroyed()) { try { secretKey.destroy(); } catch (DestroyFailedException e) { throw new Error("Could not destroy secret key after use.", e); } } // Clear the password from the key spec. if (spec != null) { spec.clearPassword(); } } -------------------------------------------------------------------- Kind regards, Sebastian Boschert From erik.joelsson at oracle.com Mon May 25 08:42:20 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 25 May 2015 10:42:20 +0200 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: <555F5F05.503@oracle.com> References: <555D5D32.9010908@oracle.com> <69BD6B3C-3C85-419F-A7F0-27D1DD9078C6@oracle.com> <555E5623.3020900@oracle.com> <555ED385.80508@oracle.com> <555F273E.9010203@oracle.com> <555F46A4.8040704@oracle.com> <555F5F05.503@oracle.com> Message-ID: <5562E06C.105@oracle.com> On 2015-05-22 18:53, Mandy Chung wrote: > > > On 05/22/2015 08:09 AM, Alan Bateman wrote: >> >> On 22/05/2015 13:55, Chris Hegarty wrote: >>> : >>> I think it could be done either way. >> >> Valerie - have you considered not pushing the services configuration >> files with this change? With the change then the java.security >> configuration is still class names, not provider names, so the >> fallback should just work. This is what we've done in a few other >> areas (like JNDI for example). > > I wasn't aware of the other areas that move to service provider but > remain being loaded with the fallback Class.forName. > > I would prefer java.security should convert to use the provider names > as an example and also exercise the code path using service > providers. If this causes much work to workaround it temporarily, I > won't object the security providers are not truly service providers > (no META-INF/services and java.security lists class name instead) > > Another option to workaround this: > > we only need to merge the service config files for generating the > image. Can we have do the concatenation of > jdk/modules/*/META-INF/services file and output to > supports/image_gensrc before the images target and have the image > builder to exclude all jdk/modules/*/META-INF/services files and take > the supports/image_gensrc instead? > > This will remove the process-provider logic from Gensrc-*.gmk files. > Would this be a better alternative? > Maybe, I'm not sure. I still think solving this in java code in the ImageBuilder is the right thing to do. /Erik From chris.hegarty at oracle.com Mon May 25 08:53:07 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 25 May 2015 09:53:07 +0100 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: <5562E06C.105@oracle.com> References: <555D5D32.9010908@oracle.com> <69BD6B3C-3C85-419F-A7F0-27D1DD9078C6@oracle.com> <555E5623.3020900@oracle.com> <555ED385.80508@oracle.com> <555F273E.9010203@oracle.com> <555F46A4.8040704@oracle.com> <555F5F05.503@oracle.com> <5562E06C.105@oracle.com> Message-ID: <5562E2F3.1040307@oracle.com> On 25/05/15 09:42, Erik Joelsson wrote: > > On 2015-05-22 18:53, Mandy Chung wrote: >> >> >> On 05/22/2015 08:09 AM, Alan Bateman wrote: >>> >>> On 22/05/2015 13:55, Chris Hegarty wrote: >>>> : >>>> I think it could be done either way. >>> >>> Valerie - have you considered not pushing the services configuration >>> files with this change? With the change then the java.security >>> configuration is still class names, not provider names, so the >>> fallback should just work. This is what we've done in a few other >>> areas (like JNDI for example). >> >> I wasn't aware of the other areas that move to service provider but >> remain being loaded with the fallback Class.forName. URL protocol handlers, and JDNI initial context, fall back to Class.forName for built-in handlers/implementations, and do not expose the implementation as services. >> I would prefer java.security should convert to use the provider names >> as an example and also exercise the code path using service I think URL protocol handlers works well as an example too. It is a minimal new service type, easy to understand. You can write your own Foo handler in a few lines of code. >> providers. If this causes much work to workaround it temporarily, I >> won't object the security providers are not truly service providers >> (no META-INF/services and java.security lists class name instead) >> >> Another option to workaround this: >> >> we only need to merge the service config files for generating the >> image. Can we have do the concatenation of >> jdk/modules/*/META-INF/services file and output to >> supports/image_gensrc before the images target and have the image >> builder to exclude all jdk/modules/*/META-INF/services files and take >> the supports/image_gensrc instead? >> >> This will remove the process-provider logic from Gensrc-*.gmk files. >> Would this be a better alternative? >> > Maybe, I'm not sure. I still think solving this in java code in the > ImageBuilder is the right thing to do. If it is agreed that these files are needed, then I can look at expanding the ImageBuilder to do concatenate them. -Chris. > /Erik From vincent.x.ryan at oracle.com Mon May 25 09:47:59 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 25 May 2015 10:47:59 +0100 Subject: [8u] request for review: 8062552 Support keystore type detection for JKS and PKCS12 keystores In-Reply-To: <5560F7BD.5070400@suche.org> References: <033093D0-42E0-462F-A071-4EA5420541C0@oracle.com> <555F4AE6.7070809@oracle.com> <13F80CA0-3F67-4CC6-A2B5-3602DC861B82@oracle.com> <555F8B21.3050608@oracle.com> <55603D69.7020101@suche.org> <5560F7BD.5070400@suche.org> Message-ID: Unfortunately we cannot modify a Java SE API in an update release so there is no opportunity to backport the keystore probe mechanism to JDK 8u. > On 23 May 2015, at 22:57, Thomas Lu?nig wrote: > > On 23.05.2015 10:59, Vincent Ryan wrote: >> The aim of this enhancement is to address a specific compatibility risk for JKS and >> not to offer a general purpose mechanism for loading any keystore type. In general, >> the keystore type should match the keystore file format. >> >> In JDK 9 there is a new probe mechanism for keystores that is more similar to >> what you are proposing. The advantage of that mechanism is that the keystore >> type will exactly match the keystore file format. > When there is already an new probe mechanism for keystore detetion, why > do not backport/use it ? > Why build this limited version for one single usecase instead of using > the more gerneral solution ? >> >>> On 23 May 2015, at 09:42, Thomas Lu?nig wrote: >>> >>> Hi, >>> >>> 1) Would it not be an good idea to check the first bytes of the message >>> so that the dual class already know what type the stream is >>> and there is no unnecessary instanciation of exceptions and engine class? >>> 2) If we add an "smart" keystore why we limit it to two types? I do not >>> see any reason why it should not be possible to add other store types to: >>> - JCEKS >>> - PKCS11 >>> It could be extended via securit property >>> java.security.smartKeystore..type = PKCS11 >>> java.security.smartKeystore..magic = (Optional for >>> Performance) >>> java.security.smartKeystore..engineClass = CanonicalEngine Class Name >>> >>> This would be only an small code change but an usefull improvement. >>> >>> Gru? Thomas >>> >>> >>> On 22.05.2015 22:01, Sean Mullan wrote: >>>> Looks fine to me. >>>> >>>> --Sean >>>> >>>> On 05/22/2015 03:10 PM, Vincent Ryan wrote: >>>>> Thanks Thomas and Sean for your review comments. >>>>> >>>>> KeyStoreDelegator matches the JDK 9 version. I?ve moved it to the >>>>> sun.security.package and modified it as suggested. >>>>> I also made JavaKeyStore package-private but DualFormatJKS needs to >>>>> remain public. >>>>> The cert in trusted.pem is an arbitrary X.509 cert and I?ve added a >>>>> comment in the TestKeystoreCompat test. >>>>> >>>>> A new webrev is available at: >>>>> http://cr.openjdk.java.net/~vinnie/8062552/webrev.02/ > From Alan.Bateman at oracle.com Mon May 25 10:00:49 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 May 2015 11:00:49 +0100 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: <5562E2F3.1040307@oracle.com> References: <555D5D32.9010908@oracle.com> <69BD6B3C-3C85-419F-A7F0-27D1DD9078C6@oracle.com> <555E5623.3020900@oracle.com> <555ED385.80508@oracle.com> <555F273E.9010203@oracle.com> <555F46A4.8040704@oracle.com> <555F5F05.503@oracle.com> <5562E06C.105@oracle.com> <5562E2F3.1040307@oracle.com> Message-ID: <5562F2D1.5080103@oracle.com> On 25/05/2015 09:53, Chris Hegarty wrote: > > If it is agreed that these files are needed, then I can look at > expanding the ImageBuilder to do concatenate them. I agree with Mandy's point that java.security should be change to list the provider name rather than the class name. If that happens then it means that the service configuration files will be required. I don't have a strong view on whether the concatenation is done via make files or the image builder as it's all just temporary and will go away once resources are keyed by a module. One thing about rev'ing the image builder is that we should probably let the jimage refresh get into jdk9/dev first. I don't think we want to delay that due to merge conflicts. -Alan From michael.x.mcmahon at oracle.com Mon May 25 10:08:10 2015 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 25 May 2015 11:08:10 +0100 Subject: TLS ALPN Proposal In-Reply-To: <555E7E98.9050208@oracle.com> References: <555E7E98.9050208@oracle.com> Message-ID: <5562F48A.5010405@oracle.com> Hi Brad, A couple of initial comments/questions. 1) Certificate selection is one feature envisaged by ALPN. ie a client or a server ought to be able to choose a different certificate depending on the application name that gets negotiated. Is that possible with this API? 2) The notion of client preference needs to be made explicit. This could just be a matter of javadoc given that List is ordered. So, it could be enough to say the same order is used in the protocol. 3) It's a shame that the RFC didn't mandate UTF8 encoded byte sequences for the protocol name, because it's theoretically possible that non UTF8 byte sequences could get registered, but that's not a concern for HTTP/2 at least. Thanks, Michael On 22/05/15 01:55, Bradford Wetmore wrote: > This is a fork of the previous thread: > > Subject: TLS Handshake Message Proposal > (Was: Re: JEP 244: TLS Application-Layer Protocol > Negotiation Extension) > > I broke this thread off to keep this proposal discussion together, but > if you're interested in the history, please see the previous thread. > > This approach combines different suggestions from security-dev in a > new way, and simplifies the ALPN selection process quite a bit. I > think it addresses most of the concerns about selection that were raised. > > This approach can be completely separated from the Handshake mechanism > I discussed in the previous message, so I'm thinking of this approach > for JDK 9 and targeting the more general handshake approach for JDK 10. > > Here's the summary of API additions: > > > SSLParameters: > -------------- > Client-side: gets/sets the list of protocol names to send. > Server-side: gets/sets a ApplicationProtocolSelector which is a > user-defined callback mechanism. > > ApplicationProtocolSelector: > ---------------------------- > Server-side: callback methods for SSLSocket/SSLEngine which > are provided with handshake information for making > the selection > > ExtendedSSLSession: > ------------------- > gets the negotiated protocol String > > > > Specifics below. The javadoc obviously needs work. > > class SSLParameters { > > ...deleted... > > /** > * Gets the list of application protocols that will sent by > * the client. > * > * The list could be empty, in which case no protocols will be > * sent. > * > * @returns a list of application protocol names. > */ > public List getApplicationProtocols() { }; > > /** > * Sets the list of application protocols that will sent by > * the client. > * > * protocols could be empty, in which case no protocols will be > * sent. > * > * @param protocols a list of application protocol names > * @throws IllegalArgumentException if protocols is null. > */ > public void setApplicationProtocols(List protocols); > > /** > * Gets the current server-side application layer protocol selector. > * > * @param the selector mechanism. > * @return the current application protocol selector, or null if > * there is not one. > */ > public ApplicationProtocolSelector > getApplicationProtocolSelector() {}; > > /** > * Sets the server-side application layer protocol selector. > * > * @param the selector mechanism, or null if protocol selection > * should not be done. > */ > public void setApplicationProtocolSelector( > ApplicationProtocolSelector selector) {}; > } > > > /* > * A callback class on the server side that is responsible for > * choosing which Application Protocol should be used in a SSL/TLS > * connection. > */ > public abstract class ApplicationProtocolSelector { > > /* > * SSLSocket callback to choose which Application Protocol value > * to return to a SSL/TLS client > * > * @param sslSocket the SSLSocket for this connection > * @param protocols the list of protocols advertised by the client > * @param protocolVersion the negotiated protocol version > * @param ciphersuite the negotiated ciphersuite > * @return a non-empty protocol String to send to the client, > * or null if no protocol value (i.e. extension) should be sent. > * @throws SSLProtocolException if the connection should be aborted > * because the the server supports none of the protocols that > * the client advertised. > */ > public String select(SSLSocket sslSocket, String[] protocols, > String protocolVersion, String ciphersuite) > throws SSLProtocolException; > > /* > * SSLEngine callback to choose which Application Protocol to return > * to a SSL/TLS client. > * > * @param sslEngine the SSLEngine for this connection > * @param protocols the list of protocols advertised by the client > * @param protocolVersion the negotiated protocol version > * @param ciphersuite the negotiated ciphersuite > * @return a non-empty protocol String to send to the client, > * or null if no protocol value should be sent. > * @throws SSLProtocolException if the connection should be aborted > * because the the server supports none of the protocols that > * the client advertised. > */ > public String select(SSLEngine sslEngine, String[] protocols, > String protocolVersion, String ciphersuite) > throws SSLProtocolException; > } > > If need be, we could include the received extensions or in a future > version of this class. > > > public class ExtendedSSLSession implements SSLSession { > > ...deleted... > > /** > * Gets the application protocol negotiated for this connection. > * > * @returns the application protocol name or null if none was > * negotiated. > */ > public String getApplicationProtocol() { }; > } > > There was also some internal discussion about whether the values > should be Strings or byte arrays. The ALPN RFC only discusses bytes, > and a String.toBytes("US-ASCII") would limit the API to ASCII strings. > > Lastly, we could also add some convenience values for well-known > values. e.g.: > > public static final AP_HTTP_1.1 = "http/1.1"; > > or in byte form: > > public static final AP_H2 = "h2".getBytes(""US-ASCII"); > > I refrained from including SPDY/*, since they are on their way out > now, and NAT/STUN since there hasn't been any call for it so far. > > Thanks, > > Brad From simone.bordet at gmail.com Mon May 25 11:34:50 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 25 May 2015 13:34:50 +0200 Subject: TLS ALPN Proposal In-Reply-To: <5562F48A.5010405@oracle.com> References: <555E7E98.9050208@oracle.com> <5562F48A.5010405@oracle.com> Message-ID: Hi, On Mon, May 25, 2015 at 12:08 PM, Michael McMahon wrote: > Hi Brad, > > A couple of initial comments/questions. > > 1) Certificate selection is one feature envisaged by ALPN. ie a client or a > server > ought to be able to choose a different certificate depending on the > application name > that gets negotiated. Is that possible with this API? Interesting. I can definitely see choosing the ALPN protocol based on the SNI name sent by the client. For example, a server able to speak http/1.1 and h2 receiving a request for http1.domain.com wants to force http/1.1. This would be possible, IIUC, using sslEngine.getHandshakeSession().getRequestedServerNames() in the ApplicationProtocolSelector implementation. I see less common choosing the certificate given the application protocol, but I understand it's mentioned in RFC 7301. ALPN definitely needs the cipher to be negotiated to support HTTP/2, so I hope it's not a chicken-egg problem. -- 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 michael.x.mcmahon at oracle.com Mon May 25 13:57:42 2015 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 25 May 2015 14:57:42 +0100 Subject: TLS ALPN Proposal In-Reply-To: References: <555E7E98.9050208@oracle.com> <5562F48A.5010405@oracle.com> Message-ID: <55632A56.3020507@oracle.com> On 25/05/15 12:34, Simone Bordet wrote: > Hi, > > On Mon, May 25, 2015 at 12:08 PM, Michael McMahon > wrote: >> Hi Brad, >> >> A couple of initial comments/questions. >> >> 1) Certificate selection is one feature envisaged by ALPN. ie a client or a >> server >> ought to be able to choose a different certificate depending on the >> application name >> that gets negotiated. Is that possible with this API? > Interesting. > > I can definitely see choosing the ALPN protocol based on the SNI name > sent by the client. > For example, a server able to speak http/1.1 and h2 receiving a > request for http1.domain.com wants to force http/1.1. > This would be possible, IIUC, using > sslEngine.getHandshakeSession().getRequestedServerNames() in the > ApplicationProtocolSelector implementation. Perhaps, though it seems there are specific ALPNs for HTTP/1.1 ("http/1.1") and for HTTP/2 ("h2"). So, I think you would use ALPN itself to do that negotiation. An incoming TLS connection without the ALPN extension is just assumed to be HTTP/1.1 > I see less common choosing the certificate given the application > protocol, but I understand it's mentioned in RFC 7301. There aren't very many different "applications" envisaged yet. There are a couple of NAT related protocols registered. But, actually having thought about it again, client certificate selection happens in the X509ExtendedKeyManager class and that implementation could presumably call sslEngine.getHandshakeSession().getApplicationProtocol() and select the client cert using that information. It doesn't do that now obviously but I think it could in future if necessary. > ALPN definitely needs the cipher to be negotiated to support HTTP/2, > so I hope it's not a chicken-egg problem. > I've been assuming that (by default) we just need to avoid using the black-listed ciphers and make sure to propose at least the one mandatory cipher; then we shouldn't have any problem. HTTP/2 apps can still create their own SSLContexts and configure them any way they want. - Michael. From simone.bordet at gmail.com Mon May 25 14:09:23 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 25 May 2015 16:09:23 +0200 Subject: TLS ALPN Proposal In-Reply-To: <55632A56.3020507@oracle.com> References: <555E7E98.9050208@oracle.com> <5562F48A.5010405@oracle.com> <55632A56.3020507@oracle.com> Message-ID: Hi, On Mon, May 25, 2015 at 3:57 PM, Michael McMahon wrote: > Perhaps, though it seems there are specific ALPNs for HTTP/1.1 ("http/1.1") > and for HTTP/2 ("h2"). So, I think you would use ALPN itself to do that > negotiation. > An incoming TLS connection without the ALPN extension is just assumed to be > HTTP/1.1 Sure, but I can see a client looping over a list of domain names (e.g. to check whether the sites support HTTP/2) and therefore not having any knowledge of whether it should or not add the ALPN extension. This client will always add it, but the server must force http/1.1 for http1.domain.com. > There aren't very many different "applications" envisaged yet. There are > a couple of NAT related protocols registered. But, actually having thought > about it > again, client certificate selection happens in the X509ExtendedKeyManager > class > and that implementation could presumably call > sslEngine.getHandshakeSession().getApplicationProtocol() > and select the client cert using that information. It doesn't do that now > obviously > but I think it could in future if necessary. Sure, unless the protocol is not available because ALPN code has not run yet. For what I understand, currently cipher selection and certificate selection happen at the same time, please correct me if I am wrong. If that's the case, then we have a chicken-egg problem: you can't call ALPN code before the cipher is selected, but you need ALPN to select the certificate. If those two steps can be split, then ALPN code could be put in between and all is solved. -- 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 weijun.wang at oracle.com Mon May 25 14:16:35 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 25 May 2015 22:16:35 +0800 Subject: RFR 8080911: sun/security/krb5/auto/UseCacheAndStoreKey.java timed out intermittently Message-ID: <55632EC3.4050702@oracle.com> Hi All Please review a code change at http://cr.openjdk.java.net/~weijun/8080911/webrev.00/ I've limit the synchronized block to Config creation only and therefore won't deadlock with EType's class initialization. Noreg-hard. The EType call is at class initialization and only run once in a VM session, which is extremely difficult to catch. Thanks Max From bhanu.prakash.gopularam at oracle.com Mon May 25 15:13:00 2015 From: bhanu.prakash.gopularam at oracle.com (Bhanu Prakash Gopularam) Date: Mon, 25 May 2015 08:13:00 -0700 (PDT) Subject: RFR: 8048830 - Implement tests for new functionality provided in JEP 166 Message-ID: <1b1a0975-c522-4b92-8339-76a6d2a274c5@default> 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 mandy.chung at oracle.com Mon May 25 15:33:45 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 25 May 2015 08:33:45 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: <5562F2D1.5080103@oracle.com> References: <555D5D32.9010908@oracle.com> <69BD6B3C-3C85-419F-A7F0-27D1DD9078C6@oracle.com> <555E5623.3020900@oracle.com> <555ED385.80508@oracle.com> <555F273E.9010203@oracle.com> <555F46A4.8040704@oracle.com> <555F5F05.503@oracle.com> <5562E06C.105@oracle.com> <5562E2F3.1040307@oracle.com> <5562F2D1.5080103@oracle.com> Message-ID: > On May 25, 2015, at 3:00 AM, Alan Bateman wrote: > > On 25/05/2015 09:53, Chris Hegarty wrote: >> >> If it is agreed that these files are needed, then I can look at expanding the ImageBuilder to do concatenate them. > I agree with Mandy's point that java.security should be change to list the provider name rather than the class name. If that happens then it means that the service configuration files will be required. > > I don't have a strong view on whether the concatenation is done via make files or the image builder as it's all just temporary and will go away once resources are keyed by a module. One thing about rev'ing the image builder is that we should probably let the jimage refresh get into jdk9/dev first. I don't think we want to delay that due to merge conflicts. Right this is all temporary. One benefit of having the concatenation done by image builder will get the makefile cleaned up and get ready for the resources keyed for a module as long as the work required is small. Good point about image refresh and any image builder change should come after jimage refresh to avoid causing any merge conflict. Depending on when the image refresh and this security provider change are ready to push to jdk9/dev, I can work with Valerie to determine whether to wait or phase it. thanks Mandy From org.openjdk at io7m.com Mon May 25 15:41:48 2015 From: org.openjdk at io7m.com (org.openjdk at io7m.com) Date: Mon, 25 May 2015 15:41:48 -0000 Subject: Run-time configurable sandboxes Message-ID: Hello! I am a security-conscious Java developer and am interested in using the JVMs built-in security features to run code in separated and run-time configured sandboxes. I'm writing to the list to explain some of the issues I've come up against and am hoping to either elicit suggestions or at least provoke some discussion about how the JVM might better support this. I've been working on a small experimental system for sandboxing due to dissatisfaction with the existing sandboxing packages. The existing sandboxing packages appear to be overly complicated, fragile, and unmaintained. They almost all implement a complicated and error-prone custom security manager and seem to more or less ignore everything else the JVM has in terms of security features. I'm hoping that I can do better! My own use case will be running code that is sandbox-aware and that only uses a few classes from java.lang and talks to an API that I provide to each sandbox. I would expect to restrict arbitrary file I/O (with sandboxed code persisting state via provided key/value interface), restrict network I/O, restrict access to native code, restrict access to reflection, restrict thread creation, and restrict exiting the VM. About the only thing I cannot protect against is heap exhaustion (but the JVM does a decent job of enforcing a global limit anyway, so it's not as if malicious code would end up killing the user's machine or running afoul of operating system limits). It seems that others have somewhat similar use cases, often using some sort of sandbox to provide security to embedded languages that have been compiled to JVM bytecode at run-time. I won't bore anyone here with the details of how the JVM applies security policy because I'd assume everyone on this list already understands it. My basic approach has been to use a custom implementation of java.security.Policy[0] and a custom classloader. The program creates one classloader C per application sandbox S and assigns all classes loaded by C a protection domain P. My assumption is that for a particular sandbox, we no longer care about fine-grained per-CodeSource control of classes inside the sandbox as we're more likely to be applying a coarse sandbox-wide set of restrictions. This then means that that the custom Policy implementation can assign permissions on a per-sandbox basis by simply checking the CodeSource URL and returning any permissions defined for that URL. As a concrete example, I create a sandbox that I then assign a URL of http://sandbox.io7m.com/1. The classloader for that sandbox assigns every loaded class a CodeSource with location http://sandbox.io7m.com/1. Now, whenever the AccessController consults the policy's checkPermission function, the policy simply uses the set of permissions defined for http://sandbox.io7m.com/1. As an aside, I do use a custom SecurityManager but only to add a couple of extra checks for Thread and ThreadGroup creation/modification, because the default SecurityManager is not strict enough. This appears to work well. I've been unable to subvert the sandbox and am reasonably confident in its security simply due to the fact that it does absolutely nothing clever whatsoever and uses the basic provided JVM security features to achieve it. The code is less than 150 lines and is not exciting in any way. The bulk of a real implementation would be providing a pleasant API and a nice way to configure policies at run-time. My main gripes: 1. The ClassLoader and SecureClassLoader classes are not very nice. It seems that I cannot take an existing classloader and preserve all of the semantics with regards to mapping names to byte arrays (such as looking through the classpath for class files, contacting remote servers for classes, etc) if I want to maintain my own control over the resulting ProtectionDomains of those classes. It is likely that ProtectionDomains and CodeSources were never intended to be used in the slightly abusive way I'm using them in the above system. I'm guessing also that the implementations carry a ton of historical baggage and would likely not have their interfaces presented in the way they currently are if they were written/designed today! There is a tempting package-private method in java.lang.Class called setProtectionDomain that I'm not allowed to call. Having access to this would allow me use any existing class loader and simply overwrite the protection domains of the resulting classes without having to modify any code. 2. I feel like I should not have to do any of the things I have done! I realize this sounds silly, but if it were possible to label classes with a simple immutable opaque tag indicating their confinement, and the Policy could refer to this tag... I'd already be done. I would assume that setting a confinement label on a class would require security checks and that it could only be set once. This seems almost too good/simple an approach to be true - would it require an unlimited amount of bureaucracy to get something like this into the standard library? It obviously exists to support a specific use case, but I could see how the same approach could be used to provide a generalized sandbox for anything compiled to JVM bytecode running inside a scripting engine, for example. I'm open to flames and/or suggestions on better approaches. Mark -- [0] Not essential for sandboxing, but essential for run-time configuration, because the default Policy is obviously loaded from a file on JVM startup, can't be easily/pleasantly updated, and likely references a policy file that contains system-specific defaults that I'd like to ignore! From artem.smotrakov at oracle.com Mon May 25 15:58:43 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 25 May 2015 18:58:43 +0300 Subject: [9] RFR: 8078823: javax/net/ssl/ciphersuites/DisabledAlgorithms.java fails intermittently Message-ID: <556346B3.3070806@oracle.com> Hello, Please review this fix for javax/net/ssl/ciphersuites/DisabledAlgorithms.java test. It fails very rarely with SocketException. The test runs clients in main thread, but a server runs in a separate thread. In checkFailure() method, clients expect a SSLHandshakeException, and when it occurs, they stop the server by calling SSLServer.stop() method which makes the server close its server socket. The server usually throws an expected SSLHandshakeException, then server socket is closed. But it seems that sometimes the server closes the server socket before handshake failure is processed. As a result, IOException happens instead of SSLHandshakeException. The server should stop if any exception occurs, and clients shouldn't stop the server by themselves. Bug: https://bugs.openjdk.java.net/browse/JDK-8078823 Webrev: http://cr.openjdk.java.net/~asmotrak/8078823/webrev.00/ Artem From bradford.wetmore at oracle.com Mon May 25 20:37:56 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 25 May 2015 13:37:56 -0700 Subject: TLS ALPN Proposal In-Reply-To: <555FF3F2.1000201@oracle.com> References: <555E7E98.9050208@oracle.com> <555FD441.4070204@oracle.com> <555FF3F2.1000201@oracle.com> Message-ID: <55638824.8070607@oracle.com> On 5/22/2015 8:28 PM, Weijun Wang wrote: > > > On 5/23/2015 9:13 AM, Bradford Wetmore wrote: >> Weijun wrote: >> >> > But in the RFC the name is in uppercase and chars in string are all >> > lowercases. >> > ...deleted... >> > - Compare with equalsIgnoreCase() >> >> Not following here, the spec is specific about the over-the-wire byte >> values, and http/1.1 != Http/1.1. > > Because the spec says > > o Identification Sequence: The precise set of octet values that > identifies the protocol. This could be the UTF-8 encoding > [RFC3629] of the protocol name. > > and the name is uppercase. What if someone really sends > "HTTP/1.1".getBytes("UTF-8")? I'm sorry, but I'm still not understanding your point. Looking at an existing ALPN directory entry: Protocol: HTTP/1.1 Identification Sequence: 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 ("http/1.1") Reference: [RFC7230] The name of the "Protocol" is HTTP/1.1, but the "Identification Sequence" is "0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 ("http/1.1")". I am proposing that the List be the values of the Identification Sequence, not the IANA Protocol Names. Is your opinion that the ALPN API String "Protocol" be the "Protocol:" and that we should internally map from HTTP/1.1 to http/1.1 before sending? Or that Identification Sequence "HTTP/1.1" SHOULD BE treated the same as "http/1.1"? I think that's what you're saying, since I think you want to compare it using equalsIgnoreCase(). That will make future ALPN protocol name addition challenging. > What if someone really sends "HTTP/1.1".getBytes("UTF-8")? In my proposal, then they should send "HTTP/1.1" instead of "http/1.1". I'm really sorry if I'm still missing something. Brad From xuelei.fan at oracle.com Mon May 25 23:59:33 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 26 May 2015 07:59:33 +0800 Subject: RFR 8080911: sun/security/krb5/auto/UseCacheAndStoreKey.java timed out intermittently In-Reply-To: <55632EC3.4050702@oracle.com> References: <55632EC3.4050702@oracle.com> Message-ID: <5563B765.2070404@oracle.com> synchronized on class looks a little bit unsafe to me. As singleton is a static variable, creating the instance during initialization looks safer. - private static Config singleton = null; + private static Config singleton = new Config(); Xuelei On 5/25/2015 10:16 PM, Weijun Wang wrote: > Hi All > > Please review a code change at > > http://cr.openjdk.java.net/~weijun/8080911/webrev.00/ > > I've limit the synchronized block to Config creation only and therefore > won't deadlock with EType's class initialization. > > Noreg-hard. The EType call is at class initialization and only run once > in a VM session, which is extremely difficult to catch. > > Thanks > Max From xuelei.fan at oracle.com Tue May 26 00:02:35 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 26 May 2015 08:02:35 +0800 Subject: [9] RFR: 8078823: javax/net/ssl/ciphersuites/DisabledAlgorithms.java fails intermittently In-Reply-To: <556346B3.3070806@oracle.com> References: <556346B3.3070806@oracle.com> Message-ID: <5563B81B.7030609@oracle.com> Looks fine to me. Thanks, Xuelei On 5/25/2015 11:58 PM, Artem Smotrakov wrote: > Hello, > > Please review this fix for > javax/net/ssl/ciphersuites/DisabledAlgorithms.java test. > > It fails very rarely with SocketException. The test runs clients in main > thread, but a server runs in a separate thread. In checkFailure() > method, clients expect a SSLHandshakeException, and when it occurs, they > stop the server by calling SSLServer.stop() method which makes the > server close its server socket. The server usually throws an expected > SSLHandshakeException, then server socket is closed. But it seems that > sometimes the server closes the server socket before handshake failure > is processed. As a result, IOException happens instead of > SSLHandshakeException. > > The server should stop if any exception occurs, and clients shouldn't > stop the server by themselves. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8078823 > Webrev: http://cr.openjdk.java.net/~asmotrak/8078823/webrev.00/ > > Artem From bradford.wetmore at oracle.com Tue May 26 00:30:44 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 25 May 2015 17:30:44 -0700 Subject: TLS ALPN Proposal In-Reply-To: <5562F48A.5010405@oracle.com> References: <555E7E98.9050208@oracle.com> <5562F48A.5010405@oracle.com> Message-ID: <5563BEB4.1040501@oracle.com> Darn those Chicken/Eggs [1]! Yes, you are correct. The steps for the current server code: 1. The ClientHello is parsed, and the SNI matcher callback is called. It does not return which value was matched in the ServerHello, just whether a SNI name was matched or not: The "extension_data" field of this extension SHALL be empty. 2. Begin generating the ServerHello, choose the Protocol Version. 3. Iterate through the list of client's ciphersuites and call the Server's KeyManager (KM) callback until the KM returns key material we can use. A return string selects the proposed ciphersuite. So we currently don't know the selected ciphersuite until the KM has been called (possibly multiple times). If we choose the ALPN before the ciphersuite, the ciphersuite selection may end up being inappropriate (HTTP/2 blacklist). If we choose the ciphersuite first, then the ALPN value wasn't used to drive the certificate selection. Two suggestions in preferred order below. In each of these cases, unfortunately there is currently no indication of the proposed Ciphersuite, so we need to modify the behavior of getHandshakeSession().getCipherSuite() to fill in the proposed CipherSuite before the call to the KM. This seems ok with the current wording, but we'd need to make that explicit. This value will change for each ciphersuite/KM choice attempt. Each suggestion below is followed by our previously proposed ALPN callback to make the actual ALPN value selection: 1a. Add a parallel method to ExtendedSSLSession: public List getRequestedApplicationProtocolNames(); along with the previously proposed selected name: public String getApplicationProtocol() (I'll be changing these names. I'm open to suggestions). When the KM is called, the TLS protocol (e.g. TLSv1.2) has already been selected. Both of the major selection parameters (protocol/proposed ciphersuite) are now available, and applications have access to the ordered ALPN list to see what the client's requested values were. -or- 1b. Keep API as is, and make two callbacks. This first is an advisory value, the TLS protocol version and proposed ciphersuite will be available in getHandshakeSession(). The second callback sets the final value that will be sent. I think 1.a is my preference. To answer some of the other questions. On 5/25/2015 3:08 AM, Michael McMahon wrote: > 2) The notion of client preference needs to be made explicit. This could > just be a matter > of javadoc given that List is ordered. So, it could be > enough to say the same > order is used in the protocol. Yes, I'll add that. > 3) It's a shame that the RFC didn't mandate UTF8 encoded byte sequences > for the > protocol name, because it's theoretically possible that non UTF8 > byte sequences > could get registered, but that's not a concern for HTTP/2 at least. No. Not sure what we can do about that, short of going back to the byte[] option. Given that IANA operates mainly in English, I would expect the namespaces will probably be ASCII, but that is just conjecture. > This would be possible, IIUC, using > sslEngine.getHandshakeSession().getRequestedServerNames() in the > ApplicationProtocolSelector implementation. Yes. > but I understand it's mentioned in RFC 7301. Yes, see the last sentence section 1. Brad [1] https://www.youtube.com/watch?v=ixgf5SlvOB4&feature=youtu.be&t=27 From weijun.wang at oracle.com Tue May 26 01:06:02 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 26 May 2015 09:06:02 +0800 Subject: RFR 8080911: sun/security/krb5/auto/UseCacheAndStoreKey.java timed out intermittently In-Reply-To: <5563B765.2070404@oracle.com> References: <55632EC3.4050702@oracle.com> <5563B765.2070404@oracle.com> Message-ID: <5563C6FA.9010509@oracle.com> On 5/26/2015 7:59 AM, Xuelei Fan wrote: > synchronized on class looks a little bit unsafe to me. Why? Isn't it the same as making a static method synchronized? [1] > As singleton is > a static variable, creating the instance during initialization looks safer. > > - private static Config singleton = null; > + private static Config singleton = new Config(); This line might throw an exception. Also, do you intend to make getInstance() simply returning singleton? This means if the first call to new Config() throws an exception, getInstance() will not try to reconstruct it. This might not be common in production, but I don't want to make any behavior change. --Max [1] https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.3.6 > > Xuelei > > On 5/25/2015 10:16 PM, Weijun Wang wrote: >> Hi All >> >> Please review a code change at >> >> http://cr.openjdk.java.net/~weijun/8080911/webrev.00/ >> >> I've limit the synchronized block to Config creation only and therefore >> won't deadlock with EType's class initialization. >> >> Noreg-hard. The EType call is at class initialization and only run once >> in a VM session, which is extremely difficult to catch. >> >> Thanks >> Max > From xuelei.fan at oracle.com Tue May 26 01:22:00 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 26 May 2015 09:22:00 +0800 Subject: RFR 8080911: sun/security/krb5/auto/UseCacheAndStoreKey.java timed out intermittently In-Reply-To: <5563C6FA.9010509@oracle.com> References: <55632EC3.4050702@oracle.com> <5563B765.2070404@oracle.com> <5563C6FA.9010509@oracle.com> Message-ID: <5563CAB8.8080706@oracle.com> On 5/26/2015 9:06 AM, Weijun Wang wrote: > On 5/26/2015 7:59 AM, Xuelei Fan wrote: >> synchronized on class looks a little bit unsafe to me. > > Why? Isn't it the same as making a static method synchronized? [1] > Other code may be also able to lock on class. Code 1: lock on MyClass.class Code 2: lock on MyClass.class Code 1 and 2 know nothing about each other. The behavior may be weird. I don't think it is a good practice. >> As singleton is >> a static variable, creating the instance during initialization looks >> safer. >> >> - private static Config singleton = null; >> + private static Config singleton = new Config(); > > This line might throw an exception. Also, do you intend to make > getInstance() simply returning singleton? This means if the first call > to new Config() throws an exception, getInstance() will not try to > reconstruct it. This might not be common in production, but I don't want > to make any behavior change. > I see you point. Maybe, you can lock on a object. Xuelei > --Max > > [1] > https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.3.6 > >> >> Xuelei >> >> On 5/25/2015 10:16 PM, Weijun Wang wrote: >>> Hi All >>> >>> Please review a code change at >>> >>> http://cr.openjdk.java.net/~weijun/8080911/webrev.00/ >>> >>> I've limit the synchronized block to Config creation only and therefore >>> won't deadlock with EType's class initialization. >>> >>> Noreg-hard. The EType call is at class initialization and only run once >>> in a VM session, which is extremely difficult to catch. >>> >>> Thanks >>> Max >> From weijun.wang at oracle.com Tue May 26 02:40:21 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 26 May 2015 10:40:21 +0800 Subject: RFR 8080911: sun/security/krb5/auto/UseCacheAndStoreKey.java timed out intermittently In-Reply-To: <5563CAB8.8080706@oracle.com> References: <55632EC3.4050702@oracle.com> <5563B765.2070404@oracle.com> <5563C6FA.9010509@oracle.com> <5563CAB8.8080706@oracle.com> Message-ID: <5563DD15.5020003@oracle.com> On 5/26/2015 9:22 AM, Xuelei Fan wrote: > On 5/26/2015 9:06 AM, Weijun Wang wrote: >> On 5/26/2015 7:59 AM, Xuelei Fan wrote: >>> synchronized on class looks a little bit unsafe to me. >> >> Why? Isn't it the same as making a static method synchronized? [1] >> > Other code may be also able to lock on class. > > Code 1: > lock on MyClass.class > > Code 2: > lock on MyClass.class > > Code 1 and 2 know nothing about each other. The behavior may be weird. > I don't think it is a good practice. So you are not a fan of all synchronized methods? :-) I thought it's quite common to use synchronized static methods to prevent simultaneous access to a static field. While a method in another class can lock on thisClass.class (in this case the class is internal), I don't see why it wants to do this. This is not casual, it's just evil. > >>> As singleton is >>> a static variable, creating the instance during initialization looks >>> safer. >>> >>> - private static Config singleton = null; >>> + private static Config singleton = new Config(); >> >> This line might throw an exception. Also, do you intend to make >> getInstance() simply returning singleton? This means if the first call >> to new Config() throws an exception, getInstance() will not try to >> reconstruct it. This might not be common in production, but I don't want >> to make any behavior change. >> > I see you point. Maybe, you can lock on a object. A private static final Object? Yes I can, but is it worth doing? Thanks Max > > Xuelei > >> --Max >> >> [1] >> https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.3.6 >> >>> >>> Xuelei >>> >>> On 5/25/2015 10:16 PM, Weijun Wang wrote: >>>> Hi All >>>> >>>> Please review a code change at >>>> >>>> http://cr.openjdk.java.net/~weijun/8080911/webrev.00/ >>>> >>>> I've limit the synchronized block to Config creation only and therefore >>>> won't deadlock with EType's class initialization. >>>> >>>> Noreg-hard. The EType call is at class initialization and only run once >>>> in a VM session, which is extremely difficult to catch. >>>> >>>> Thanks >>>> Max >>> > From weijun.wang at oracle.com Tue May 26 03:32:42 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 26 May 2015 11:32:42 +0800 Subject: RFR 8038089: TLS optional support for Kerberos cipher suites needs to be re-examine In-Reply-To: <61B179BE-E775-4A32-9660-D5FFBB4CC150@oracle.com> References: <61B179BE-E775-4A32-9660-D5FFBB4CC150@oracle.com> Message-ID: <5563E95A.2080704@oracle.com> This is the latest webrev of this bug http://cr.openjdk.java.net/~weijun/8038089/webrev.06/ No significant change from the previous one, mainly rebase. There are some issues which need changes inside JSSE. I'd like to file another bug for them. 1. JsseJce.java still uses core reflection to detect whether Kerberos support is available. It cannot call ClientKeyExchangeService.find() because there is a circular initialization problem between it and CipherSuite. 2. CipherSuite.java still contains hard coded krb5-related KeyExchange and CipherSuite values. These should be moved into plugin. Finally, a lot of you speak out that RFC 2712 is dead and we needn't support them. Thanks for the advice. However, this code change is mainly a refactoring of existing codes because in jdk9 we will have to separate TLS and Kerberos into different modules, and we cannot simply drop the feature. Thanks Max On 9/16/2014 9:31 AM, Wang Weijun wrote: > Hi Xuelei > > Please review the latest code change at > > http://cr.openjdk.java.net/~weijun/8038089/webrev.04/ > > Compared with webrev.03, only the way the provider is loaded is changed, which is the static block on lines 50-71 of Krb5Helper.java. > > Thanks > Max > From xuelei.fan at oracle.com Tue May 26 04:50:31 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 26 May 2015 12:50:31 +0800 Subject: RFR 8080911: sun/security/krb5/auto/UseCacheAndStoreKey.java timed out intermittently In-Reply-To: <5563DD15.5020003@oracle.com> References: <55632EC3.4050702@oracle.com> <5563B765.2070404@oracle.com> <5563C6FA.9010509@oracle.com> <5563CAB8.8080706@oracle.com> <5563DD15.5020003@oracle.com> Message-ID: <5563FB97.2040609@oracle.com> I do not like class level synchronization because it may not work as expected, especially if the synchronization can be used by other codes. However, your update does not change this behavior. The fix looks fine to me. Please go ahead if you don't want to use object level synchronization. Xuelei On 5/26/2015 10:40 AM, Weijun Wang wrote: > > > On 5/26/2015 9:22 AM, Xuelei Fan wrote: >> On 5/26/2015 9:06 AM, Weijun Wang wrote: >>> On 5/26/2015 7:59 AM, Xuelei Fan wrote: >>>> synchronized on class looks a little bit unsafe to me. >>> >>> Why? Isn't it the same as making a static method synchronized? [1] >>> >> Other code may be also able to lock on class. >> >> Code 1: >> lock on MyClass.class >> >> Code 2: >> lock on MyClass.class >> >> Code 1 and 2 know nothing about each other. The behavior may be weird. >> I don't think it is a good practice. > > So you are not a fan of all synchronized methods? :-) > > I thought it's quite common to use synchronized static methods to > prevent simultaneous access to a static field. While a method in another > class can lock on thisClass.class (in this case the class is internal), > I don't see why it wants to do this. This is not casual, it's just evil. > >> >>>> As singleton is >>>> a static variable, creating the instance during initialization looks >>>> safer. >>>> >>>> - private static Config singleton = null; >>>> + private static Config singleton = new Config(); >>> >>> This line might throw an exception. Also, do you intend to make >>> getInstance() simply returning singleton? This means if the first call >>> to new Config() throws an exception, getInstance() will not try to >>> reconstruct it. This might not be common in production, but I don't want >>> to make any behavior change. >>> >> I see you point. Maybe, you can lock on a object. > > A private static final Object? Yes I can, but is it worth doing? > > Thanks > Max > >> >> Xuelei >> >>> --Max >>> >>> [1] >>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.3.6 >>> >>>> >>>> Xuelei >>>> >>>> On 5/25/2015 10:16 PM, Weijun Wang wrote: >>>>> Hi All >>>>> >>>>> Please review a code change at >>>>> >>>>> http://cr.openjdk.java.net/~weijun/8080911/webrev.00/ >>>>> >>>>> I've limit the synchronized block to Config creation only and >>>>> therefore >>>>> won't deadlock with EType's class initialization. >>>>> >>>>> Noreg-hard. The EType call is at class initialization and only run >>>>> once >>>>> in a VM session, which is extremely difficult to catch. >>>>> >>>>> Thanks >>>>> Max >>>> >> From simone.bordet at gmail.com Tue May 26 08:00:09 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Tue, 26 May 2015 10:00:09 +0200 Subject: TLS ALPN Proposal In-Reply-To: <5563BEB4.1040501@oracle.com> References: <555E7E98.9050208@oracle.com> <5562F48A.5010405@oracle.com> <5563BEB4.1040501@oracle.com> Message-ID: Hi, On Tue, May 26, 2015 at 2:30 AM, Bradford Wetmore wrote: > Darn those Chicken/Eggs [1]! > > Yes, you are correct. The steps for the current server code: > > 1. The ClientHello is parsed, and the SNI matcher callback is called. It > does not return which value was matched in the ServerHello, just whether a > SNI name was matched or not: > > The "extension_data" field of this extension SHALL be > empty. > > 2. Begin generating the ServerHello, choose the Protocol Version. > > 3. Iterate through the list of client's ciphersuites and call the Server's > KeyManager (KM) callback until the KM returns key material we can use. A > return string selects the proposed ciphersuite. > > So we currently don't know the selected ciphersuite until the KM has been > called (possibly multiple times). > > If we choose the ALPN before the ciphersuite, the ciphersuite selection may > end up being inappropriate (HTTP/2 blacklist). If we choose the ciphersuite > first, then the ALPN value wasn't used to drive the certificate selection. > > Two suggestions in preferred order below. > > In each of these cases, unfortunately there is currently no indication of > the proposed Ciphersuite, so we need to modify the behavior of > getHandshakeSession().getCipherSuite() to fill in the proposed CipherSuite > before the call to the KM. This seems ok with the current wording, but we'd > need to make that explicit. This value will change for each ciphersuite/KM > choice attempt. > > Each suggestion below is followed by our previously proposed ALPN callback > to make the actual ALPN value selection: > > > 1a. Add a parallel method to ExtendedSSLSession: > > public List getRequestedApplicationProtocolNames(); > > along with the previously proposed selected name: > > public String getApplicationProtocol() > > (I'll be changing these names. I'm open to suggestions). > > When the KM is called, the TLS protocol (e.g. TLSv1.2) has already been > selected. > > Both of the major selection parameters (protocol/proposed ciphersuite) are > now available, and applications have access to the ordered ALPN list to see > what the client's requested values were. > > -or- > > 1b. Keep API as is, and make two callbacks. This first is an advisory > value, the TLS protocol version and proposed ciphersuite will be available > in getHandshakeSession(). The second callback sets the final value that > will be sent. > > > I think 1.a is my preference. I am not sure I follow this. Can you please sketch the steps/algorithm that will be done in your proposed solution ? -- 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 Tue May 26 12:51:11 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 26 May 2015 08:51:11 -0400 Subject: RFR 8080911: sun/security/krb5/auto/UseCacheAndStoreKey.java timed out intermittently In-Reply-To: <5563FB97.2040609@oracle.com> References: <55632EC3.4050702@oracle.com> <5563B765.2070404@oracle.com> <5563C6FA.9010509@oracle.com> <5563CAB8.8080706@oracle.com> <5563DD15.5020003@oracle.com> <5563FB97.2040609@oracle.com> Message-ID: <55646C3F.5040401@oracle.com> I would use the Initialization-on-demand holder idiom [1] instead, ex: private static class SingletonHolder { private static final Config singleton = new Config(); } public static Config getInstance() throws KrbException { return SingletonHolder.singleton; } This way you avoid synchronized altogether. --Sean [1] http://en.wikipedia.org/wiki/Initialization-on-demand_holder_idiom On 05/26/2015 12:50 AM, Xuelei Fan wrote: > I do not like class level synchronization because it may not work as > expected, especially if the synchronization can be used by other codes. > However, your update does not change this behavior. The fix looks fine > to me. Please go ahead if you don't want to use object level > synchronization. > > Xuelei > > On 5/26/2015 10:40 AM, Weijun Wang wrote: >> >> >> On 5/26/2015 9:22 AM, Xuelei Fan wrote: >>> On 5/26/2015 9:06 AM, Weijun Wang wrote: >>>> On 5/26/2015 7:59 AM, Xuelei Fan wrote: >>>>> synchronized on class looks a little bit unsafe to me. >>>> >>>> Why? Isn't it the same as making a static method synchronized? [1] >>>> >>> Other code may be also able to lock on class. >>> >>> Code 1: >>> lock on MyClass.class >>> >>> Code 2: >>> lock on MyClass.class >>> >>> Code 1 and 2 know nothing about each other. The behavior may be weird. >>> I don't think it is a good practice. >> >> So you are not a fan of all synchronized methods? :-) >> >> I thought it's quite common to use synchronized static methods to >> prevent simultaneous access to a static field. While a method in another >> class can lock on thisClass.class (in this case the class is internal), >> I don't see why it wants to do this. This is not casual, it's just evil. >> >>> >>>>> As singleton is >>>>> a static variable, creating the instance during initialization looks >>>>> safer. >>>>> >>>>> - private static Config singleton = null; >>>>> + private static Config singleton = new Config(); >>>> >>>> This line might throw an exception. Also, do you intend to make >>>> getInstance() simply returning singleton? This means if the first call >>>> to new Config() throws an exception, getInstance() will not try to >>>> reconstruct it. This might not be common in production, but I don't want >>>> to make any behavior change. >>>> >>> I see you point. Maybe, you can lock on a object. >> >> A private static final Object? Yes I can, but is it worth doing? >> >> Thanks >> Max >> >>> >>> Xuelei >>> >>>> --Max >>>> >>>> [1] >>>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.3.6 >>>> >>>>> >>>>> Xuelei >>>>> >>>>> On 5/25/2015 10:16 PM, Weijun Wang wrote: >>>>>> Hi All >>>>>> >>>>>> Please review a code change at >>>>>> >>>>>> http://cr.openjdk.java.net/~weijun/8080911/webrev.00/ >>>>>> >>>>>> I've limit the synchronized block to Config creation only and >>>>>> therefore >>>>>> won't deadlock with EType's class initialization. >>>>>> >>>>>> Noreg-hard. The EType call is at class initialization and only run >>>>>> once >>>>>> in a VM session, which is extremely difficult to catch. >>>>>> >>>>>> Thanks >>>>>> Max >>>>> >>> > From weijun.wang at oracle.com Tue May 26 13:45:28 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 26 May 2015 21:45:28 +0800 Subject: RFR 8080911: sun/security/krb5/auto/UseCacheAndStoreKey.java timed out intermittently In-Reply-To: <55646C3F.5040401@oracle.com> References: <55632EC3.4050702@oracle.com> <5563B765.2070404@oracle.com> <5563C6FA.9010509@oracle.com> <5563CAB8.8080706@oracle.com> <5563DD15.5020003@oracle.com> <5563FB97.2040609@oracle.com> <55646C3F.5040401@oracle.com> Message-ID: <556478F8.8000009@oracle.com> But here it's not a real singleton (not final), the refresh() method can reassign an instance to it. --Max On 5/26/2015 8:51 PM, Sean Mullan wrote: > I would use the Initialization-on-demand holder idiom [1] instead, ex: > > private static class SingletonHolder { > private static final Config singleton = new Config(); > } > > public static Config getInstance() throws KrbException { > return SingletonHolder.singleton; > } > > This way you avoid synchronized altogether. > > --Sean > > [1] http://en.wikipedia.org/wiki/Initialization-on-demand_holder_idiom > > > On 05/26/2015 12:50 AM, Xuelei Fan wrote: >> I do not like class level synchronization because it may not work as >> expected, especially if the synchronization can be used by other codes. >> However, your update does not change this behavior. The fix looks fine >> to me. Please go ahead if you don't want to use object level >> synchronization. >> >> Xuelei >> >> On 5/26/2015 10:40 AM, Weijun Wang wrote: >>> >>> >>> On 5/26/2015 9:22 AM, Xuelei Fan wrote: >>>> On 5/26/2015 9:06 AM, Weijun Wang wrote: >>>>> On 5/26/2015 7:59 AM, Xuelei Fan wrote: >>>>>> synchronized on class looks a little bit unsafe to me. >>>>> >>>>> Why? Isn't it the same as making a static method synchronized? [1] >>>>> >>>> Other code may be also able to lock on class. >>>> >>>> Code 1: >>>> lock on MyClass.class >>>> >>>> Code 2: >>>> lock on MyClass.class >>>> >>>> Code 1 and 2 know nothing about each other. The behavior may be weird. >>>> I don't think it is a good practice. >>> >>> So you are not a fan of all synchronized methods? :-) >>> >>> I thought it's quite common to use synchronized static methods to >>> prevent simultaneous access to a static field. While a method in another >>> class can lock on thisClass.class (in this case the class is internal), >>> I don't see why it wants to do this. This is not casual, it's just evil. >>> >>>> >>>>>> As singleton is >>>>>> a static variable, creating the instance during initialization looks >>>>>> safer. >>>>>> >>>>>> - private static Config singleton = null; >>>>>> + private static Config singleton = new Config(); >>>>> >>>>> This line might throw an exception. Also, do you intend to make >>>>> getInstance() simply returning singleton? This means if the first call >>>>> to new Config() throws an exception, getInstance() will not try to >>>>> reconstruct it. This might not be common in production, but I don't >>>>> want >>>>> to make any behavior change. >>>>> >>>> I see you point. Maybe, you can lock on a object. >>> >>> A private static final Object? Yes I can, but is it worth doing? >>> >>> Thanks >>> Max >>> >>>> >>>> Xuelei >>>> >>>>> --Max >>>>> >>>>> [1] >>>>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.3.6 >>>>> >>>>> >>>>>> >>>>>> Xuelei >>>>>> >>>>>> On 5/25/2015 10:16 PM, Weijun Wang wrote: >>>>>>> Hi All >>>>>>> >>>>>>> Please review a code change at >>>>>>> >>>>>>> http://cr.openjdk.java.net/~weijun/8080911/webrev.00/ >>>>>>> >>>>>>> I've limit the synchronized block to Config creation only and >>>>>>> therefore >>>>>>> won't deadlock with EType's class initialization. >>>>>>> >>>>>>> Noreg-hard. The EType call is at class initialization and only run >>>>>>> once >>>>>>> in a VM session, which is extremely difficult to catch. >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>> >>>> >> From sean.mullan at oracle.com Tue May 26 14:00:07 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 26 May 2015 10:00:07 -0400 Subject: RFR 8080911: sun/security/krb5/auto/UseCacheAndStoreKey.java timed out intermittently In-Reply-To: <556478F8.8000009@oracle.com> References: <55632EC3.4050702@oracle.com> <5563B765.2070404@oracle.com> <5563C6FA.9010509@oracle.com> <5563CAB8.8080706@oracle.com> <5563DD15.5020003@oracle.com> <5563FB97.2040609@oracle.com> <55646C3F.5040401@oracle.com> <556478F8.8000009@oracle.com> Message-ID: <55647C67.80400@oracle.com> On 05/26/2015 09:45 AM, Weijun Wang wrote: > But here it's not a real singleton (not final), the refresh() method can > reassign an instance to it. Oh. I missed that. Forget my suggestion then. --Sean > > --Max > > On 5/26/2015 8:51 PM, Sean Mullan wrote: >> I would use the Initialization-on-demand holder idiom [1] instead, ex: >> >> private static class SingletonHolder { >> private static final Config singleton = new Config(); >> } >> >> public static Config getInstance() throws KrbException { >> return SingletonHolder.singleton; >> } >> >> This way you avoid synchronized altogether. >> >> --Sean >> >> [1] http://en.wikipedia.org/wiki/Initialization-on-demand_holder_idiom >> >> >> On 05/26/2015 12:50 AM, Xuelei Fan wrote: >>> I do not like class level synchronization because it may not work as >>> expected, especially if the synchronization can be used by other codes. >>> However, your update does not change this behavior. The fix looks >>> fine >>> to me. Please go ahead if you don't want to use object level >>> synchronization. >>> >>> Xuelei >>> >>> On 5/26/2015 10:40 AM, Weijun Wang wrote: >>>> >>>> >>>> On 5/26/2015 9:22 AM, Xuelei Fan wrote: >>>>> On 5/26/2015 9:06 AM, Weijun Wang wrote: >>>>>> On 5/26/2015 7:59 AM, Xuelei Fan wrote: >>>>>>> synchronized on class looks a little bit unsafe to me. >>>>>> >>>>>> Why? Isn't it the same as making a static method synchronized? [1] >>>>>> >>>>> Other code may be also able to lock on class. >>>>> >>>>> Code 1: >>>>> lock on MyClass.class >>>>> >>>>> Code 2: >>>>> lock on MyClass.class >>>>> >>>>> Code 1 and 2 know nothing about each other. The behavior may be >>>>> weird. >>>>> I don't think it is a good practice. >>>> >>>> So you are not a fan of all synchronized methods? :-) >>>> >>>> I thought it's quite common to use synchronized static methods to >>>> prevent simultaneous access to a static field. While a method in >>>> another >>>> class can lock on thisClass.class (in this case the class is internal), >>>> I don't see why it wants to do this. This is not casual, it's just >>>> evil. >>>> >>>>> >>>>>>> As singleton is >>>>>>> a static variable, creating the instance during initialization looks >>>>>>> safer. >>>>>>> >>>>>>> - private static Config singleton = null; >>>>>>> + private static Config singleton = new Config(); >>>>>> >>>>>> This line might throw an exception. Also, do you intend to make >>>>>> getInstance() simply returning singleton? This means if the first >>>>>> call >>>>>> to new Config() throws an exception, getInstance() will not try to >>>>>> reconstruct it. This might not be common in production, but I don't >>>>>> want >>>>>> to make any behavior change. >>>>>> >>>>> I see you point. Maybe, you can lock on a object. >>>> >>>> A private static final Object? Yes I can, but is it worth doing? >>>> >>>> Thanks >>>> Max >>>> >>>>> >>>>> Xuelei >>>>> >>>>>> --Max >>>>>> >>>>>> [1] >>>>>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.3.6 >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Xuelei >>>>>>> >>>>>>> On 5/25/2015 10:16 PM, Weijun Wang wrote: >>>>>>>> Hi All >>>>>>>> >>>>>>>> Please review a code change at >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~weijun/8080911/webrev.00/ >>>>>>>> >>>>>>>> I've limit the synchronized block to Config creation only and >>>>>>>> therefore >>>>>>>> won't deadlock with EType's class initialization. >>>>>>>> >>>>>>>> Noreg-hard. The EType call is at class initialization and only run >>>>>>>> once >>>>>>>> in a VM session, which is extremely difficult to catch. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>> >>>>> >>> From bradford.wetmore at oracle.com Tue May 26 18:46:34 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 26 May 2015 11:46:34 -0700 Subject: TLS ALPN Proposal In-Reply-To: References: <555E7E98.9050208@oracle.com> <5562F48A.5010405@oracle.com> <5563BEB4.1040501@oracle.com> Message-ID: <5564BF8A.90709@oracle.com> > I am not sure I follow this. Can you please sketch the steps/algorithm > that will be done in your proposed solution ? I'm assuming you are talking about 1a and not 1b. Sure, most of the heavy lifting takes place in ServerHandshaker. ServerHandshaker.java ===================== In the SunJSSE code: // currently line 330. private void clientHello(ClientHello mesg) throws IOException { // Was an ALPNExtension received? ALPNExtension alpnExt = (ALPNExtension) mesg.extensions.get(ExtensionTyp.EXT_ALPN); ... // Currently line 706 in JDK9. session = new SSLSessionImpl(protocolVersion, CipherSuite.C_NULL, getLocalSupportedSignAlgs(), sslContext.getSecureRandom(), getHostAddressSE(), getPortSE()); ... session.setALPNNames(alpnExt.getNames()); ... // choose cipher suite and corresponding private key // This function is at 987 currently. chooseCipherSuite(mesg); ... // Only adds an ALPN extension if non-empty. m1.extensions.add(applicationProtocolSelector.select(...)); ... Above, chooseCipherSuite() iterates through the collection of suites. Inside that, trySetCipherSuite() attempts to verify that the suite is acceptable to use. Inside that, setupPrivateKeyAndChain() does the actual KeyManager calls. if (conn != null) { alias = km.chooseServerAlias(algorithm, null, conn); } else { alias = km.chooseEngineServerAlias(algorithm, null, engine); } Now in the Application's Code: If you want the KeyManager to take this info into account, you need to create your own customer KM. public String chooseEngineServerAlias(String keyType, Principal[] issuers, SSLEngine engine) { ExtendedSSLSession session = engine.getHandshakeSession(); String protocol = session.getProtocol(); String ciphersuite = session.getCipherSuite(); List alpns = session.getRequestedApplicationProtocolNames(); // Some logic for which key to use... return choose(protocol, ciphersuite, alpns); } And then your actual ALPN selector: public String select(...) throws SSLProtocolException { ExtendedSSLSession session = engine.getHandshakeSession() String ciphersuite = session.getCipherSuite(); List alpns = session.getRequestedApplicationProtocolNames(); // Some logic for which key to use... return choose(protocol, ciphersuite, alpns); } Hopefully that is clear. Brad On 5/26/2015 1:00 AM, Simone Bordet wrote: > Hi, > > On Tue, May 26, 2015 at 2:30 AM, Bradford Wetmore > wrote: >> Darn those Chicken/Eggs [1]! >> >> Yes, you are correct. The steps for the current server code: >> >> 1. The ClientHello is parsed, and the SNI matcher callback is called. It >> does not return which value was matched in the ServerHello, just whether a >> SNI name was matched or not: >> >> The "extension_data" field of this extension SHALL be >> empty. >> >> 2. Begin generating the ServerHello, choose the Protocol Version. >> >> 3. Iterate through the list of client's ciphersuites and call the Server's >> KeyManager (KM) callback until the KM returns key material we can use. A >> return string selects the proposed ciphersuite. >> >> So we currently don't know the selected ciphersuite until the KM has been >> called (possibly multiple times). >> >> If we choose the ALPN before the ciphersuite, the ciphersuite selection may >> end up being inappropriate (HTTP/2 blacklist). If we choose the ciphersuite >> first, then the ALPN value wasn't used to drive the certificate selection. >> >> Two suggestions in preferred order below. >> >> In each of these cases, unfortunately there is currently no indication of >> the proposed Ciphersuite, so we need to modify the behavior of >> getHandshakeSession().getCipherSuite() to fill in the proposed CipherSuite >> before the call to the KM. This seems ok with the current wording, but we'd >> need to make that explicit. This value will change for each ciphersuite/KM >> choice attempt. >> >> Each suggestion below is followed by our previously proposed ALPN callback >> to make the actual ALPN value selection: >> >> >> 1a. Add a parallel method to ExtendedSSLSession: >> >> public List getRequestedApplicationProtocolNames(); >> >> along with the previously proposed selected name: >> >> public String getApplicationProtocol() >> >> (I'll be changing these names. I'm open to suggestions). >> >> When the KM is called, the TLS protocol (e.g. TLSv1.2) has already been >> selected. >> >> Both of the major selection parameters (protocol/proposed ciphersuite) are >> now available, and applications have access to the ordered ALPN list to see >> what the client's requested values were. >> >> -or- >> >> 1b. Keep API as is, and make two callbacks. This first is an advisory >> value, the TLS protocol version and proposed ciphersuite will be available >> in getHandshakeSession(). The second callback sets the final value that >> will be sent. >> >> >> I think 1.a is my preference. > > I am not sure I follow this. Can you please sketch the steps/algorithm > that will be done in your proposed solution ? > From mmaass at andrew.cmu.edu Tue May 26 20:19:59 2015 From: mmaass at andrew.cmu.edu (Michael Maass) Date: Tue, 26 May 2015 16:19:59 -0400 Subject: Run-time configurable sandboxes In-Reply-To: References: Message-ID: <5564D56F.1000201@andrew.cmu.edu> I've been working on addressing similar issues as part of my PhD thesis and have noted many of the same challenges, although I've taken a different approach. Some points I can add from a recent but currently unpublished study of actual usage of the Java sandbox (I can send a draft to individuals on request): 1. Almost no one uses the Java sandbox, and out of those that do, quite a few are using it for reasons that have nothing to do with security. We factored out applets because applets are dead (see builtwith stats on applets) and did not directly use the sandbox themselves. While we did look at web start applications, in practice, vendors seem to always sign them and request all permissions. I personally believe the latter is common because it's currently too hard to figure out what permissions a non-trivial set of Java code needs. 2. Almost everyone using the Java sandbox that cares about security is using it incorrectly, often in ways that ensure using the sandbox is entirely ineffective. The most common issue is completely misunderstanding the permission model (i.e. believing it's a blacklist instead of a whitelist). This often leads people to accidentally use one of several Java permissions that are so powerful you might as well not use the sandbox if you grant them. 3. Common security reasons to use the sandbox: (a) using a third party library that isn't fully trusted (convenience often trumps security) and (b) frameworks loading third party plugins. My solution has been to create tooling to let software deal with the complexity while letting the user deal with higher level concerns. I have a full prototype tool suite that let's users pick a specific set of classes and JAR's in an application to sandbox. The tools then use static and dynamic analysis to develop a starter policy for the selected subset that contains all of the permissions required by every execution of the subset. Finally, the tools let the user review the policy and edit it in a little IDE that warns them if they do something dangerous to establish the final policy. The tools then impose the final policy on the application by re-writing the bytecode. The basic approach the bytecode re-writing implements is very similar to what you described and for the same reasons. I went with a tooling approach in acknowledgment of the fact that the Java sandbox is hard to use because it's quite flexible in many ways. Instead of losing that flexibility, I feel it is better to separate complexity a human must deal with from that a machine can deal with and let each deal with their own concerns. Tooling also has the advantage that it can be adopted without the potentially lengthy process required to change the sandbox in the JVM itself. What I've learned is that the Java sandbox is, for most practical intents and purposes, impossible to use manually without causing problems, but that it's extremely handy when tools do most of the heavy lifting for you. Michael On 05/25/2015 11:41 AM, org.openjdk at io7m.com wrote: > Hello! > > I am a security-conscious Java developer and am interested in using the > JVMs built-in security features to run code in separated and run-time > configured sandboxes. I'm writing to the list to explain some of the > issues I've come up against and am hoping to either elicit suggestions > or at least provoke some discussion about how the JVM might better > support this. > > I've been working on a small experimental system for sandboxing > due to dissatisfaction with the existing sandboxing packages. > The existing sandboxing packages appear to be overly complicated, > fragile, and unmaintained. They almost all implement a complicated > and error-prone custom security manager and seem to more or less > ignore everything else the JVM has in terms of security features. > I'm hoping that I can do better! > > My own use case will be running code that is sandbox-aware and that > only uses a few classes from java.lang and talks to an API that I > provide to each sandbox. I would expect to restrict arbitrary file > I/O (with sandboxed code persisting state via provided key/value > interface), restrict network I/O, restrict access to native code, > restrict access to reflection, restrict thread creation, and restrict > exiting the VM. About the only thing I cannot protect against is > heap exhaustion (but the JVM does a decent job of enforcing a global > limit anyway, so it's not as if malicious code would end up killing > the user's machine or running afoul of operating system limits). > > It seems that others have somewhat similar use cases, often using > some sort of sandbox to provide security to embedded languages that > have been compiled to JVM bytecode at run-time. > > I won't bore anyone here with the details of how the JVM applies > security policy because I'd assume everyone on this list already > understands it. > > My basic approach has been to use a custom implementation of > java.security.Policy[0] and a custom classloader. The program > creates one classloader C per application sandbox S and assigns > all classes loaded by C a protection domain P. My assumption is > that for a particular sandbox, we no longer care about fine-grained > per-CodeSource control of classes inside the sandbox as we're more > likely to be applying a coarse sandbox-wide set of restrictions. This > then means that that the custom Policy implementation can assign > permissions on a per-sandbox basis by simply checking the CodeSource > URL and returning any permissions defined for that URL. > > As a concrete example, I create a sandbox that I then assign > a URL of http://sandbox.io7m.com/1. The classloader for that > sandbox assigns every loaded class a CodeSource with location > http://sandbox.io7m.com/1. Now, whenever the AccessController consults > the policy's checkPermission function, the policy simply uses the > set of permissions defined for http://sandbox.io7m.com/1. > > As an aside, I do use a custom SecurityManager but only to add a couple > of extra checks for Thread and ThreadGroup creation/modification, > because the default SecurityManager is not strict enough. > > This appears to work well. I've been unable to subvert the sandbox and > am reasonably confident in its security simply due to the fact that it > does absolutely nothing clever whatsoever and uses the basic provided > JVM security features to achieve it. The code is less than 150 lines > and is not exciting in any way. The bulk of a real implementation > would be providing a pleasant API and a nice way to configure policies > at run-time. > > My main gripes: > > 1. The ClassLoader and SecureClassLoader classes are not very nice. It > seems that I cannot take an existing classloader and preserve all > of the semantics with regards to mapping names to byte arrays (such > as looking through the classpath for class files, contacting remote > servers for classes, etc) if I want to maintain my own control over > the resulting ProtectionDomains of those classes. It is likely that > ProtectionDomains and CodeSources were never intended to be used in > the slightly abusive way I'm using them in the above system. I'm > guessing also that the implementations carry a ton of historical > baggage and would likely not have their interfaces presented in the > way they currently are if they were written/designed today! > > There is a tempting package-private method in java.lang.Class called > setProtectionDomain that I'm not allowed to call. Having access to this > would allow me use any existing class loader and simply overwrite the > protection domains of the resulting classes without having to modify > any code. > > 2. I feel like I should not have to do any of the things I have done! > I realize this sounds silly, but if it were possible to label classes > with a simple immutable opaque tag indicating their confinement, and > the Policy could refer to this tag... I'd already be done. I would > assume that setting a confinement label on a class would require > security checks and that it could only be set once. This seems > almost too good/simple an approach to be true - would it require > an unlimited amount of bureaucracy to get something like this into > the standard library? It obviously exists to support a specific use > case, but I could see how the same approach could be used to provide > a generalized sandbox for anything compiled to JVM bytecode running > inside a scripting engine, for example. > > I'm open to flames and/or suggestions on better approaches. > > Mark > > -- > > [0] Not essential for sandboxing, but essential for run-time > configuration, because the default Policy is obviously loaded from a > file on JVM startup, can't be easily/pleasantly updated, and likely > references a policy file that contains system-specific defaults that > I'd like to ignore! > > From ecki at zusammenkunft.net Tue May 26 20:40:23 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 26 May 2015 22:40:23 +0200 Subject: Run-time configurable sandboxes In-Reply-To: <5564D56F.1000201@andrew.cmu.edu> References: <5564D56F.1000201@andrew.cmu.edu> Message-ID: <20150526224023.00003f3e.ecki@zusammenkunft.net> Hello, partial quote as I want to add to a point: Am Tue, 26 May 2015 16:19:59 -0400 schrieb Michael Maass : > 3. Common security reasons to use the sandbox: (a) using a third > party library that isn't fully trusted (convenience often trumps > security) and (b) frameworks loading third party plugins. From looking at CVEs it looks like the only other common reason not mentioned here is multi tenancy for Web Application Servers (i.e. seperate WAR deployments). And I am quite sure by now (i.e. contains and other PaaS technolgies) nobody considers that anymore. So the biggest user might as well be Google App Engine (not sure how far their special platform relies on the security manager). Gruss Bernd PS: Michael I would be interested in your paper for my personal education. From sean.mullan at oracle.com Tue May 26 20:57:02 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 26 May 2015 16:57:02 -0400 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: <555D5D32.9010908@oracle.com> References: <555D5D32.9010908@oracle.com> Message-ID: <5564DE1E.1060601@oracle.com> This all looks fine to me (except for the Makefile stuff which I'll leave to others). --Sean On 05/21/2015 12:21 AM, Valerie Peng wrote: > Sean, > > Could you please review this change? The changes are mostly the same as > the prototype in Jake, but I have to make some modification due to the > difference in ServiceLoader lookup in OpenJDK (corresponding > META-INF/services/java.security.Provider files in each module) and the > related makefile change (merge their content into one for the final > image build). Then, I adjusted the Provider.configure() method to take a > single String argument to be consistent with the "providerarg" option > that keytool defined. > > In addition, I also made some misc changes, such as configuring the > providers inside ProviderConfig instead of ProviderLoader, add back the > doPrivileged block to all the provider constructors. I also have second > thought on making the switch to privider name (instead of provider class > name) in java.security file, so I reverted the changes on that - that > SunPKCS11 provider has its name specified in its configuration file, so > when ServiceLoader loads the PKCS11 provider, the configuration file has > not been passed to it, so the name is not known at that time. Thus, > using the class name for the provider list entry seems to fit the flow > better. I also updated the default policy for SunPKCS11 provider given > its recent change of using sun.misc. > > Webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.00/ > CCC: http://ccc.us.oracle.com/7191662 > > Thanks, > Valerie > From valerie.peng at oracle.com Tue May 26 21:02:29 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 26 May 2015 14:02:29 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: <5564DE1E.1060601@oracle.com> References: <555D5D32.9010908@oracle.com> <5564DE1E.1060601@oracle.com> Message-ID: <5564DF65.4080203@oracle.com> Thanks, I will sort out the Makefile stuff with Mandy and other build experts... Valerie On 5/26/2015 1:57 PM, Sean Mullan wrote: > This all looks fine to me (except for the Makefile stuff which I'll > leave to others). > > --Sean > > On 05/21/2015 12:21 AM, Valerie Peng wrote: >> Sean, >> >> Could you please review this change? The changes are mostly the same as >> the prototype in Jake, but I have to make some modification due to the >> difference in ServiceLoader lookup in OpenJDK (corresponding >> META-INF/services/java.security.Provider files in each module) and the >> related makefile change (merge their content into one for the final >> image build). Then, I adjusted the Provider.configure() method to take a >> single String argument to be consistent with the "providerarg" option >> that keytool defined. >> >> In addition, I also made some misc changes, such as configuring the >> providers inside ProviderConfig instead of ProviderLoader, add back the >> doPrivileged block to all the provider constructors. I also have second >> thought on making the switch to privider name (instead of provider class >> name) in java.security file, so I reverted the changes on that - that >> SunPKCS11 provider has its name specified in its configuration file, so >> when ServiceLoader loads the PKCS11 provider, the configuration file has >> not been passed to it, so the name is not known at that time. Thus, >> using the class name for the provider list entry seems to fit the flow >> better. I also updated the default policy for SunPKCS11 provider given >> its recent change of using sun.misc. >> >> Webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.00/ >> CCC: http://ccc.us.oracle.com/7191662 >> >> Thanks, >> Valerie >> From mandy.chung at oracle.com Tue May 26 22:27:55 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 26 May 2015 15:27:55 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: <5564DE1E.1060601@oracle.com> References: <555D5D32.9010908@oracle.com> <5564DE1E.1060601@oracle.com> Message-ID: <5564F36B.6060102@oracle.com> sun/security/jca/ProviderConfig.java 287 /** 288 * Loads the provider with the specified class name. 289 * 290 * @param name the name of the provider class 291 * @return the Provider, or null if it cannot be found or loaded 292 * @throws ProviderException all other exceptions are ignored 293 */ 294 public Provider load(String classname) { : 305 if (p.getClass().getName().equals(classname)) { 306 return p; 307 } Is this load method supposed to take the provider name instead of the classname? line 305 should check against p.getName() instead? The legacyLoad method is for the fallback to the class name. java.security now uses classname. Did you decide to use security provider name instead? Even so, the legacyLoader method should be able to find them and the load method looks to me should check the provider name instead. test/java/lang/SecurityManager/CheckSecurityProvider.java you add this test to run with security manager. I wonder if you want to run with and without security manager through @run othervm. Now each security provider has a name. Should this test verify the provider name as well? test/tools/launcher/MiscTests.java - does this test need to call sun.security.pkcs11 internal API? Can this be changed to call public API? I didn't review other files. Mandy On 05/26/2015 01:57 PM, Sean Mullan wrote: > This all looks fine to me (except for the Makefile stuff which I'll > leave to others). > > --Sean > > On 05/21/2015 12:21 AM, Valerie Peng wrote: >> Sean, >> >> Could you please review this change? The changes are mostly the same as >> the prototype in Jake, but I have to make some modification due to the >> difference in ServiceLoader lookup in OpenJDK (corresponding >> META-INF/services/java.security.Provider files in each module) and the >> related makefile change (merge their content into one for the final >> image build). Then, I adjusted the Provider.configure() method to take a >> single String argument to be consistent with the "providerarg" option >> that keytool defined. >> >> In addition, I also made some misc changes, such as configuring the >> providers inside ProviderConfig instead of ProviderLoader, add back the >> doPrivileged block to all the provider constructors. I also have second >> thought on making the switch to privider name (instead of provider class >> name) in java.security file, so I reverted the changes on that - that >> SunPKCS11 provider has its name specified in its configuration file, so >> when ServiceLoader loads the PKCS11 provider, the configuration file has >> not been passed to it, so the name is not known at that time. Thus, >> using the class name for the provider list entry seems to fit the flow >> better. I also updated the default policy for SunPKCS11 provider given >> its recent change of using sun.misc. >> >> Webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.00/ >> CCC: http://ccc.us.oracle.com/7191662 >> >> Thanks, >> Valerie >> From weijun.wang at oracle.com Wed May 27 04:45:05 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 27 May 2015 12:45:05 +0800 Subject: RFR 8038089: TLS optional support for Kerberos cipher suites needs to be re-examine In-Reply-To: <5563E95A.2080704@oracle.com> References: <61B179BE-E775-4A32-9660-D5FFBB4CC150@oracle.com> <5563E95A.2080704@oracle.com> Message-ID: <55654BD1.8050707@oracle.com> Oh, not the last one. Here is a new one that uses String instead of CipherSuite.KeyExchange in the service interface. 1) below is thus resolved. http://cr.openjdk.java.net/~weijun/8038089/webrev.07/ Thanks Max On 5/26/2015 11:32 AM, Weijun Wang wrote: > This is the latest webrev of this bug > > http://cr.openjdk.java.net/~weijun/8038089/webrev.06/ > > No significant change from the previous one, mainly rebase. > > There are some issues which need changes inside JSSE. I'd like to file > another bug for them. > > 1. JsseJce.java still uses core reflection to detect whether Kerberos > support is available. It cannot call ClientKeyExchangeService.find() > because there is a circular initialization problem between it and > CipherSuite. > > 2. CipherSuite.java still contains hard coded krb5-related KeyExchange > and CipherSuite values. These should be moved into plugin. > > Finally, a lot of you speak out that RFC 2712 is dead and we needn't > support them. Thanks for the advice. However, this code change is mainly > a refactoring of existing codes because in jdk9 we will have to separate > TLS and Kerberos into different modules, and we cannot simply drop the > feature. > > Thanks > Max > > On 9/16/2014 9:31 AM, Wang Weijun wrote: >> Hi Xuelei >> >> Please review the latest code change at >> >> http://cr.openjdk.java.net/~weijun/8038089/webrev.04/ >> >> Compared with webrev.03, only the way the provider is loaded is >> changed, which is the static block on lines 50-71 of Krb5Helper.java. >> >> Thanks >> Max >> From xuelei.fan at oracle.com Wed May 27 08:50:31 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 27 May 2015 16:50:31 +0800 Subject: RFR 8038089: TLS optional support for Kerberos cipher suites needs to be re-examine In-Reply-To: <55654BD1.8050707@oracle.com> References: <61B179BE-E775-4A32-9660-D5FFBB4CC150@oracle.com> <5563E95A.2080704@oracle.com> <55654BD1.8050707@oracle.com> Message-ID: <55658557.7060007@oracle.com> src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java ---------------------- - } else if (keyExchange == K_KRB5 || keyExchange == K_KRB5_EXPORT) { + } else if (ClientKeyExchangeService.find(keyExchange.name) != null) { ClientKeyExchangeService is a pretty common name. "ClientKeyExchangeService.find(keyExchange.name)" does not sound like it is for KRB5 only at present. For some similar update in this fix, the code reader may be confusing if he/she does not know the history of this fix. Would you mind add a comment like "For external KRB5 cipher suite at present"? src/java.base/share/classes/sun/security/ssl/JsseJce.java ----------------- - kerberosAvailable = p != null; + kerberosAvailable = (p != null); Easier to read. Otherwise, looks fine to me. Xuelei On 5/27/2015 12:45 PM, Weijun Wang wrote: > Oh, not the last one. Here is a new one that uses String instead of > CipherSuite.KeyExchange in the service interface. 1) below is thus > resolved. > > http://cr.openjdk.java.net/~weijun/8038089/webrev.07/ > > Thanks > Max > > On 5/26/2015 11:32 AM, Weijun Wang wrote: >> This is the latest webrev of this bug >> >> http://cr.openjdk.java.net/~weijun/8038089/webrev.06/ >> >> No significant change from the previous one, mainly rebase. >> >> There are some issues which need changes inside JSSE. I'd like to file >> another bug for them. >> >> 1. JsseJce.java still uses core reflection to detect whether Kerberos >> support is available. It cannot call ClientKeyExchangeService.find() >> because there is a circular initialization problem between it and >> CipherSuite. >> >> 2. CipherSuite.java still contains hard coded krb5-related KeyExchange >> and CipherSuite values. These should be moved into plugin. >> >> Finally, a lot of you speak out that RFC 2712 is dead and we needn't >> support them. Thanks for the advice. However, this code change is mainly >> a refactoring of existing codes because in jdk9 we will have to separate >> TLS and Kerberos into different modules, and we cannot simply drop the >> feature. >> >> Thanks >> Max >> >> On 9/16/2014 9:31 AM, Wang Weijun wrote: >>> Hi Xuelei >>> >>> Please review the latest code change at >>> >>> http://cr.openjdk.java.net/~weijun/8038089/webrev.04/ >>> >>> Compared with webrev.03, only the way the provider is loaded is >>> changed, which is the static block on lines 50-71 of Krb5Helper.java. >>> >>> Thanks >>> Max >>> From weijun.wang at oracle.com Wed May 27 10:46:29 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 27 May 2015 18:46:29 +0800 Subject: [JEP-219/JDK-8043758] Code Review Request: Datagram Transport Layer Security (DTLS) In-Reply-To: <555D341F.3050906@oracle.com> References: <555D341F.3050906@oracle.com> Message-ID: <5565A085.6050507@oracle.com> There are several places you write // DTLS bans stream ciphers. if (suite.cipher.cipherType == CipherType.STREAM_CIPHER) { return true; } According to rfc6347 4.1.2.5. New Cipher Suites Upon registration, new TLS cipher suites MUST indicate whether they are suitable for DTLS usage and what, if any, adaptations must be made (see Section 7 for IANA considerations). Is it better to add a suitableForDTLS() method to CipherSuite? You can choose a better name. In CipherSuite.java, there are // obsoleted since protocol version final int obsoleted; // supported since protocol version final int supported; You might want to add a comment that the version must uses TLS versions (not DTLS versions). --Max On 5/21/2015 9:25 AM, Xuelei Fan wrote: > Hi, > > Please review DTLS implementation [JEP-219/JDK-8043758]: > > webrev: http://cr.openjdk.java.net/~xuelei/8043758/webrev.latest/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8043758 > > I would greatly appreciate it if you could send me feedback on or before > May 28, 2015. > > Thanks & Regards, > Xuelei Fan > From simone.bordet at gmail.com Wed May 27 11:47:52 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Wed, 27 May 2015 13:47:52 +0200 Subject: TLS ALPN Proposal In-Reply-To: <5564BF8A.90709@oracle.com> References: <555E7E98.9050208@oracle.com> <5562F48A.5010405@oracle.com> <5563BEB4.1040501@oracle.com> <5564BF8A.90709@oracle.com> Message-ID: Hi, On Tue, May 26, 2015 at 8:46 PM, Bradford Wetmore wrote: >> I am not sure I follow this. Can you please sketch the steps/algorithm >> that will be done in your proposed solution ? > > I'm assuming you are talking about 1a and not 1b. > > Sure, most of the heavy lifting takes place in ServerHandshaker. > > ServerHandshaker.java > ===================== > > In the SunJSSE code: > > // currently line 330. > private void clientHello(ClientHello mesg) throws IOException { > > // Was an ALPNExtension received? > ALPNExtension alpnExt = (ALPNExtension) > mesg.extensions.get(ExtensionTyp.EXT_ALPN); > ... > // Currently line 706 in JDK9. > session = new SSLSessionImpl(protocolVersion, > CipherSuite.C_NULL, > getLocalSupportedSignAlgs(), > sslContext.getSecureRandom(), > getHostAddressSE(), getPortSE()); > ... > session.setALPNNames(alpnExt.getNames()); > ... > // choose cipher suite and corresponding private key > // This function is at 987 currently. > chooseCipherSuite(mesg); > ... > // Only adds an ALPN extension if non-empty. > m1.extensions.add(applicationProtocolSelector.select(...)); > ... > > Above, chooseCipherSuite() iterates through the collection of suites. Inside > that, trySetCipherSuite() attempts to verify that the suite is acceptable to > use. Inside that, setupPrivateKeyAndChain() does the actual KeyManager > calls. > > if (conn != null) { > alias = km.chooseServerAlias(algorithm, null, conn); > } else { > alias = km.chooseEngineServerAlias(algorithm, null, engine); > } > > Now in the Application's Code: > > If you want the KeyManager to take this info into account, you need to > create your own customer KM. > > public String chooseEngineServerAlias(String keyType, > Principal[] issuers, > SSLEngine engine) { > > ExtendedSSLSession session = engine.getHandshakeSession(); > String protocol = session.getProtocol(); > String ciphersuite = session.getCipherSuite(); > List alpns = > session.getRequestedApplicationProtocolNames(); > > // Some logic for which key to use... > return choose(protocol, ciphersuite, alpns); > } > > And then your actual ALPN selector: > > public String select(...) throws SSLProtocolException { > ExtendedSSLSession session = engine.getHandshakeSession() > String ciphersuite = session.getCipherSuite(); > List alpns = > session.getRequestedApplicationProtocolNames(); > > // Some logic for which key to use... > return choose(protocol, ciphersuite, alpns); > } > > Hopefully that is clear. Let me see if I understand correctly. In chooseEngineServerAlias() I will have a proposed cipher and the list of app protos from the client. The goal would be to choose the alias based on the app proto, as stated by 7301. However, the app proto is not yet chosen here. If I don't have other constraints to choose the app proto (e.g. SNI), the usual algorithm applies: pick the first server app proto that is in common with the client. Let's assume this is h2; but looking at the cipher, it's not good, so we have to pick another app proto, say http/1.1. Now the cipher is good and we return the alias. This is similar to what happens now with Jetty's ALPN: the cipher will be chosen, then the ALPN callback invoked and there, by looking at the cipher, we know we have to use http/1.1. Let's assume now I have the constraint to choose h2 (e.g. I have a SNI of http2.domain.com). In chooseEngineServerAlias() I will look at SNI, and therefore choose h2, then look at the proposed cipher, which is not good, so return null. Method chooseEngineServerAlias() will be called repeatedly for other ciphers, until a cipher good for h2 is found, otherwise it's an alert 120. Are you proposing to call select(...) from chooseEngineServerAlias(), and give the ALPN callback a semantic that it may be called multiple times, each time with a different cipher, and give access to the ALPN callback implementation to SNI to choose the right protocol based on that ? 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 xuelei.fan at oracle.com Wed May 27 12:12:04 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 27 May 2015 20:12:04 +0800 Subject: [JEP-219/JDK-8043758] Code Review Request: Datagram Transport Layer Security (DTLS) In-Reply-To: <5565A085.6050507@oracle.com> References: <555D341F.3050906@oracle.com> <5565A085.6050507@oracle.com> Message-ID: <5565B494.2040201@oracle.com> On 5/27/2015 6:46 PM, Weijun Wang wrote: > There are several places you write > > // DTLS bans stream ciphers. > if (suite.cipher.cipherType == CipherType.STREAM_CIPHER) { > return true; > } > > According to rfc6347 > > 4.1.2.5. New Cipher Suites > > Upon registration, new TLS cipher suites MUST indicate whether they > are suitable for DTLS usage and what, if any, adaptations must be > made (see Section 7 for IANA considerations). > > Is it better to add a suitableForDTLS() method to CipherSuite? You can > choose a better name. > At present, only stream cipher suites are not suitable for DTLS usage. I will use the suggestion if new cipher suites are not suitable for DTLS in the future. > In CipherSuite.java, there are > > // obsoleted since protocol version > final int obsoleted; > > // supported since protocol version > final int supported; > > You might want to add a comment that the version must uses TLS versions > (not DTLS versions). > Good! I made the update as: // obsoleted since protocol version // // TLS version is used. If checking DTLS versions, please map to // TLS version firstly. See ProtocolVersion.mapToTLSProtocol(). final int obsoleted; // supported since protocol version (TLS version is used) // // TLS version is used. If checking DTLS versions, please map to // TLS version firstly. See ProtocolVersion.mapToTLSProtocol(). final int supported; Thanks, Xuelei > --Max > > On 5/21/2015 9:25 AM, Xuelei Fan wrote: >> Hi, >> >> Please review DTLS implementation [JEP-219/JDK-8043758]: >> >> webrev: http://cr.openjdk.java.net/~xuelei/8043758/webrev.latest/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8043758 >> >> I would greatly appreciate it if you could send me feedback on or before >> May 28, 2015. >> >> Thanks & Regards, >> Xuelei Fan >> From mmaass at andrew.cmu.edu Wed May 27 12:32:45 2015 From: mmaass at andrew.cmu.edu (Michael Maass) Date: Wed, 27 May 2015 08:32:45 -0400 Subject: Run-time configurable sandboxes In-Reply-To: <20150526224023.00003f3e.ecki@zusammenkunft.net> References: <5564D56F.1000201@andrew.cmu.edu> <20150526224023.00003f3e.ecki@zusammenkunft.net> Message-ID: <5565B96D.9060908@andrew.cmu.edu> Good point! The Web Application Servers use case also seems to have been the impetus behind JSR 121: Application Isolation API Specification (https://jcp.org/en/jsr/detail?id=121). Mark, note the dates on this spec. Specification started in 2001 and ended in 2006. Security Explorations released a report last year on GAE with some decent discussion of the architecture: http://www.security-explorations.com/materials/se-2014-02-report.pdf. Most of the serious vulnerabilities are in class loaders. Bernd, I'll send you a copy of the paper shortly. Michael On 05/26/2015 04:40 PM, Bernd Eckenfels wrote: > Hello, > > partial quote as I want to add to a point: > > Am Tue, 26 May 2015 16:19:59 -0400 > schrieb Michael Maass : > >> 3. Common security reasons to use the sandbox: (a) using a third >> party library that isn't fully trusted (convenience often trumps >> security) and (b) frameworks loading third party plugins. > From looking at CVEs it looks like the only other common reason not > mentioned here is multi tenancy for Web Application Servers (i.e. > seperate WAR deployments). > > And I am quite sure by now (i.e. contains and other PaaS technolgies) > nobody considers that anymore. So the biggest user might as well be > Google App Engine (not sure how far their special platform relies on > the security manager). > > Gruss > Bernd > > PS: Michael I would be interested in your paper for my personal > education. From weijun.wang at oracle.com Wed May 27 15:08:19 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 27 May 2015 23:08:19 +0800 Subject: RFR 8081278: Typo in Exception Message Message-ID: <5565DDE3.2050006@oracle.com> Please review the fix below: diff --git a/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java b/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java --- a/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java +++ b/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java @@ -85,7 +85,7 @@ if (creds == null) throw new GSSException(GSSException.NO_CRED, -1, - "Failed to find any Kerberos credentails"); + "Failed to find any Kerberos credentials"); if (name == null) { String fullName = creds.getName(); No webrev, noreg-trivial. Thanks Max From sean.mullan at oracle.com Wed May 27 15:26:10 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 27 May 2015 11:26:10 -0400 Subject: RFR 8081278: Typo in Exception Message In-Reply-To: <5565DDE3.2050006@oracle.com> References: <5565DDE3.2050006@oracle.com> Message-ID: <5565E212.6000405@oracle.com> Looks good! --Sean On 05/27/2015 11:08 AM, Weijun Wang wrote: > Please review the fix below: > > diff --git > a/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java > b/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java > > --- > a/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java > > +++ > b/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java > > @@ -85,7 +85,7 @@ > > if (creds == null) > throw new GSSException(GSSException.NO_CRED, -1, > - "Failed to find any Kerberos > credentails"); > + "Failed to find any Kerberos > credentials"); > > if (name == null) { > String fullName = creds.getName(); > > No webrev, noreg-trivial. > > Thanks > Max > From aph at redhat.com Wed May 27 17:17:40 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 May 2015 18:17:40 +0100 Subject: RSA and Diffie-Hellman performance [Was: RFR(L): 8069539: RSA acceleration] In-Reply-To: <555708BE.8090100@redhat.com> References: <02FCFB8477C4EF43A2AD8E0C60F3DA2B63321E33@FMSMSX112.amr.corp.intel.com> <5502E67C.8080208@oracle.com> <02FCFB8477C4EF43A2AD8E0C60F3DA2B63322AB0@FMSMSX112.amr.corp.intel.com> <02FCFB8477C4EF43A2AD8E0C60F3DA2B63323E86@FMSMSX112.amr.corp.intel.com> <550C004D.1060501@redhat.com> <02FCFB8477C4EF43A2AD8E0C60F3DA2B633245C8@FMSMSX112.amr.corp.intel.com> <55101C52.1090506@redhat.com> <5548193E.7060803@oracle.com> <55488803.4020802@redhat.com> <554CDD48.8080500@redhat.com> <1CCF381D-1C55-4392-A905-AD8CD457980B@oracle.com> <555708BE.8090100@redhat.com> Message-ID: <5565FC34.3020908@redhat.com> [I'm sorry, I didn't send this to the correct list. I forgot that there was a separate security list.] An update: I'm still working on this. Following last week's revelations [1] it seems to me that a faster implementation of (integer) D-H is even more important. I've spent a couple of days tracking down an extremely odd feature (bug?) in MutableBigInteger which was breaking everything, but I'm past that now. I'm trying to produce an intrinsic implementation of the core modular exponentiation which is as fast as any state-of-the- art implementation while disrupting the common code as little as possible; this is not easy. I hope to have something which is faster on all processors, not just those for which we have hand-coded assembly-language implementations. I don't think that my work should be any impediment to Sadya's patch for squareToLen at http://cr.openjdk.java.net/~kvn/8069539/webrev.01/ being committed. It'll still be useful. Andrew. [1] Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice https://weakdh.org/imperfect-forward-secrecy.pdf From anthony.scarpino at oracle.com Wed May 27 20:35:07 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 27 May 2015 13:35:07 -0700 Subject: RSA and Diffie-Hellman performance [Was: RFR(L): 8069539: RSA acceleration] In-Reply-To: <5565FC34.3020908@redhat.com> References: <02FCFB8477C4EF43A2AD8E0C60F3DA2B63321E33@FMSMSX112.amr.corp.intel.com> <5502E67C.8080208@oracle.com> <02FCFB8477C4EF43A2AD8E0C60F3DA2B63322AB0@FMSMSX112.amr.corp.intel.com> <02FCFB8477C4EF43A2AD8E0C60F3DA2B63323E86@FMSMSX112.amr.corp.intel.com> <550C004D.1060501@redhat.com> <02FCFB8477C4EF43A2AD8E0C60F3DA2B633245C8@FMSMSX112.amr.corp.intel.com> <55101C52.1090506@redhat.com> <5548193E.7060803@oracle.com> <55488803.4020802@redhat.com> <554CDD48.8080500@redhat.com> <1CCF381D-1C55-4392-A905-AD8CD457980B@oracle.com> <555708BE.8090100@redhat.com> <5565FC34.3020908@redhat.com> Message-ID: <55662A7B.8010103@oracle.com> On 05/27/2015 10:17 AM, Andrew Haley wrote: > [I'm sorry, I didn't send this to the correct list. I forgot that > there was a separate security list.] > > An update: > > I'm still working on this. Following last week's revelations [1] it > seems to me that a faster implementation of (integer) D-H is even more > important. > > I've spent a couple of days tracking down an extremely odd feature > (bug?) in MutableBigInteger which was breaking everything, but I'm > past that now. I'm trying to produce an intrinsic implementation of > the core modular exponentiation which is as fast as any state-of-the- > art implementation while disrupting the common code as little as > possible; this is not easy. > > I hope to have something which is faster on all processors, not just > those for which we have hand-coded assembly-language implementations. > > I don't think that my work should be any impediment to Sadya's patch > for squareToLen at http://cr.openjdk.java.net/~kvn/8069539/webrev.01/ > being committed. It'll still be useful. > > Andrew. > > > [1] Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice > https://weakdh.org/imperfect-forward-secrecy.pdf > I had been following your work off and on as I was on the hotspot-compiler-dev thread for a while, but then fell off. Intrinsifying montgomery multiply & square would be a good thing. I was prototyping montgomery multiple & square around SPARC instructions about the same time you posted your webrev a few weeks ago and we had similarities. I've been pulled into other parts of my JEP 246, so I look forward to see what you come up. Please keep me in the loop on how things are progressing. How much of the montgomery multiply and sqaure are you planning to intrinsify? Are you doing the whole thing or just portions of the operations similar to multiplyToLen and squareToLen? Sandhya's patch is going to proceed. Tony From valerie.peng at oracle.com Wed May 27 22:35:46 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 27 May 2015 15:35:46 -0700 Subject: Fwd: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <55664547.7050002@oracle.com> References: <55664547.7050002@oracle.com> Message-ID: <556646C2.2080003@oracle.com> Sean, FYI, I have asked the build team to review the makefile changes. BTW, I changed java.security.Provider file to use @implSpec as Joe has suggested. In addition, I changed the getArgument() impl in OracleUcrypto provider + SunPKCS11 provider to only return the value if the caller has read permission to the file. I feel this is probably safer as we don't want to reveal the path (potential info leak) to untrusted callers. If the callers don't have the right permission, then "" is returned. If you prefer SecurityException be thrown, please let me know. I will need to update the CCC and the webrev. Thanks, Valerie -------- Original Message -------- Subject: RFR 7191662: JCE providers should be located via ServiceLoader Date: Wed, 27 May 2015 15:29:27 -0700 From: Valerie Peng Organization: Oracle Corporation To: build-dev at openjdk.java.net, Mandy Chung Hi, build experts, Can you please review the make file related change, i.e. the new file || *make/gensrc/Gensrc-java.naming.gmk*, in the following webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. The rest of source code changes are reviewed by my team already. Thanks, Valerie (Java Security Team) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Wed May 27 22:42:27 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 27 May 2015 15:42:27 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <55664547.7050002@oracle.com> References: <55664547.7050002@oracle.com> Message-ID: Valerie, Did you see my comment yesterday? http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html Since you have reverted the java.security to keep the classname, to avoid causing merge conflict to jimage refresh, let?s remove the META-INF files in the first push and the build change. The security providers will be loaded via the fallback mechanism (i.e. ProviderLoader.legacyLoad method). You should keep the ProviderLoader.load method to take the provider name instead of classname. I?ll file a bug to follow up to change java.security to list the provider name. This will wait after the jimage refresh goes into jdk9/dev. Mandy > On May 27, 2015, at 3:29 PM, Valerie Peng wrote: > > Hi, build experts, > > Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: > http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ > > This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. > > The rest of source code changes are reviewed by my team already. > Thanks, > Valerie > (Java Security Team) From sean.mullan at oracle.com Wed May 27 23:05:49 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 27 May 2015 19:05:49 -0400 Subject: Fwd: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <556646C2.2080003@oracle.com> References: <55664547.7050002@oracle.com> <556646C2.2080003@oracle.com> Message-ID: <55664DCD.8040808@oracle.com> On 05/27/2015 06:35 PM, Valerie Peng wrote: > In addition, I changed the getArgument() impl in OracleUcrypto provider > + SunPKCS11 provider to only return the value if the caller has read > permission to the file. I feel this is probably safer as we don't want > to reveal the path (potential info leak) to untrusted callers. If the > callers don't have the right permission, then "" is returned. If you > prefer SecurityException be thrown, please let me know. Better yet, maybe we don't need the getArgument method. The argument is really only needed for Provider implementations, which get it via the constructor. This way we can just have the constructor and not expose potentially sensitive info through a public method. --Sean From sean.mullan at oracle.com Wed May 27 23:06:41 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 27 May 2015 19:06:41 -0400 Subject: Fwd: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <55664DCD.8040808@oracle.com> References: <55664547.7050002@oracle.com> <556646C2.2080003@oracle.com> <55664DCD.8040808@oracle.com> Message-ID: <55664E01.5090206@oracle.com> On 05/27/2015 07:05 PM, Sean Mullan wrote: > On 05/27/2015 06:35 PM, Valerie Peng wrote: >> In addition, I changed the getArgument() impl in OracleUcrypto provider >> + SunPKCS11 provider to only return the value if the caller has read >> permission to the file. I feel this is probably safer as we don't want >> to reveal the path (potential info leak) to untrusted callers. If the >> callers don't have the right permission, then "" is returned. If you >> prefer SecurityException be thrown, please let me know. > > Better yet, maybe we don't need the getArgument method. The argument is > really only needed for Provider implementations, which get it via the > constructor. I mean via the configure method ... --Sean > This way we can just have the constructor and not expose > potentially sensitive info through a public method. > > --Sean From valerie.peng at oracle.com Wed May 27 23:17:51 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 27 May 2015 16:17:51 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: <5564F36B.6060102@oracle.com> References: <555D5D32.9010908@oracle.com> <5564DE1E.1060601@oracle.com> <5564F36B.6060102@oracle.com> Message-ID: <5566509F.1070105@oracle.com> Hi, Mandy, I have second thought on using the provider name for the java.security file... There are a few things that I want to discuss/brainstorm internally to make sure that there is no "surprise" later. Thus, I had not made the switch in this webrev. It doesn't affect the overall functionality. The legacyLoad() is for finding providers the old-fashioned way, e.g. through reflection, instead of ServiceLoader. The legacyLoad can only work using class name. Running test/java/lang/SecurityManager/CheckSecurityProvider.java with a security manager should cover more than without. I don't see much value in adding provider name verification? Verifying class name seems enough in making sure that the providers are present as expected. As for test/tools/launcher/MiscTests.java, it's for verifying a bug in launcher, so I have stick with the internal API as I am not sure if switching to public API may be too great of a change as the call path changed significantly... Thanks, Valerie On 5/26/2015 3:27 PM, Mandy Chung wrote: > sun/security/jca/ProviderConfig.java > > 287 /** > 288 * Loads the provider with the specified class name. > 289 * > 290 * @param name the name of the provider class > 291 * @return the Provider, or null if it cannot be found or > loaded > 292 * @throws ProviderException all other exceptions are > ignored > 293 */ > 294 public Provider load(String classname) { > : > > 305 if (p.getClass().getName().equals(classname)) { > 306 return p; > 307 } > > Is this load method supposed to take the provider name instead of the > classname? > line 305 should check against p.getName() instead? The legacyLoad > method is > for the fallback to the class name. > > java.security now uses classname. Did you decide to use security > provider name instead? > Even so, the legacyLoader method should be able to find them and the > load method > looks to me should check the provider name instead. > > test/java/lang/SecurityManager/CheckSecurityProvider.java > you add this test to run with security manager. I wonder if you want > to run with and without security manager through @run othervm. > > Now each security provider has a name. Should this test verify the > provider > name as well? > > test/tools/launcher/MiscTests.java > - does this test need to call sun.security.pkcs11 internal API? Can > this be > changed to call public API? > > I didn't review other files. > Mandy > > On 05/26/2015 01:57 PM, Sean Mullan wrote: >> This all looks fine to me (except for the Makefile stuff which I'll >> leave to others). >> >> --Sean >> >> On 05/21/2015 12:21 AM, Valerie Peng wrote: >>> Sean, >>> >>> Could you please review this change? The changes are mostly the same as >>> the prototype in Jake, but I have to make some modification due to the >>> difference in ServiceLoader lookup in OpenJDK (corresponding >>> META-INF/services/java.security.Provider files in each module) and the >>> related makefile change (merge their content into one for the final >>> image build). Then, I adjusted the Provider.configure() method to >>> take a >>> single String argument to be consistent with the "providerarg" option >>> that keytool defined. >>> >>> In addition, I also made some misc changes, such as configuring the >>> providers inside ProviderConfig instead of ProviderLoader, add back the >>> doPrivileged block to all the provider constructors. I also have second >>> thought on making the switch to privider name (instead of provider >>> class >>> name) in java.security file, so I reverted the changes on that - that >>> SunPKCS11 provider has its name specified in its configuration file, so >>> when ServiceLoader loads the PKCS11 provider, the configuration file >>> has >>> not been passed to it, so the name is not known at that time. Thus, >>> using the class name for the provider list entry seems to fit the flow >>> better. I also updated the default policy for SunPKCS11 provider given >>> its recent change of using sun.misc. >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.00/ >>> CCC: http://ccc.us.oracle.com/7191662 >>> >>> Thanks, >>> Valerie >>> > From mandy.chung at oracle.com Wed May 27 23:40:56 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 27 May 2015 16:40:56 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: <5566509F.1070105@oracle.com> References: <555D5D32.9010908@oracle.com> <5564DE1E.1060601@oracle.com> <5564F36B.6060102@oracle.com> <5566509F.1070105@oracle.com> Message-ID: <5FE0E92E-EE62-49CF-AC3F-59D31B6BD987@oracle.com> > On May 27, 2015, at 4:17 PM, Valerie Peng wrote: > > Hi, Mandy, > > I have second thought on using the provider name for the java.security file... > There are a few things that I want to discuss/brainstorm internally to make sure that there is no "surprise" later. > Thus, I had not made the switch in this webrev. It doesn't affect the overall functionality. > What is the issue you concern about with ServiceLoader to load providers when it matches its provider name rather than the classname? SPI allows you to move away from using the classname in the configuration and separate implementation from interfaces. > The legacyLoad() is for finding providers the old-fashioned way, e.g. through reflection, instead of ServiceLoader. > The legacyLoad can only work using class name. > For the first push, it?s okay to leave them loaded by the legacy mechanism via reflection until you sort out the provider name issue before you make them true service providers. But I still think ProviderLoader.load should not tie with the classname unless there is a strong reason to. > Running test/java/lang/SecurityManager/CheckSecurityProvider.java with a security manager should cover more than without. Ok with me. > I don't see much value in adding provider name verification? Verifying class name seems enough in making sure that the providers are present as expected. > If you are using the provider name to load service providers, this adds additional verification. I?m surprised that your webrev was changed as I didn?t see any mail about your concern that leads to the change. > As for test/tools/launcher/MiscTests.java, it's for verifying a bug in launcher, so I have stick with the internal API as I am not sure if switching to public API may be too great of a change as the call path changed significantly? This test verifies 6856415 that needs to use sun.* API and ensures that the right Exception is thrown. Ok - it?s okay to leave it then. Mandy > > Thanks, > Valerie > > On 5/26/2015 3:27 PM, Mandy Chung wrote: >> sun/security/jca/ProviderConfig.java >> >> 287 /** >> 288 * Loads the provider with the specified class name. >> 289 * >> 290 * @param name the name of the provider class >> 291 * @return the Provider, or null if it cannot be found or loaded >> 292 * @throws ProviderException all other exceptions are ignored >> 293 */ >> 294 public Provider load(String classname) { >> : >> >> 305 if (p.getClass().getName().equals(classname)) { >> 306 return p; >> 307 } >> >> Is this load method supposed to take the provider name instead of the classname? >> line 305 should check against p.getName() instead? The legacyLoad method is >> for the fallback to the class name. >> >> java.security now uses classname. Did you decide to use security provider name instead? >> Even so, the legacyLoader method should be able to find them and the load method >> looks to me should check the provider name instead. >> >> test/java/lang/SecurityManager/CheckSecurityProvider.java >> you add this test to run with security manager. I wonder if you want >> to run with and without security manager through @run othervm. >> >> Now each security provider has a name. Should this test verify the provider >> name as well? >> >> test/tools/launcher/MiscTests.java >> - does this test need to call sun.security.pkcs11 internal API? Can this be >> changed to call public API? >> >> I didn't review other files. >> Mandy >> >> On 05/26/2015 01:57 PM, Sean Mullan wrote: >>> This all looks fine to me (except for the Makefile stuff which I'll leave to others). >>> >>> --Sean >>> >>> On 05/21/2015 12:21 AM, Valerie Peng wrote: >>>> Sean, >>>> >>>> Could you please review this change? The changes are mostly the same as >>>> the prototype in Jake, but I have to make some modification due to the >>>> difference in ServiceLoader lookup in OpenJDK (corresponding >>>> META-INF/services/java.security.Provider files in each module) and the >>>> related makefile change (merge their content into one for the final >>>> image build). Then, I adjusted the Provider.configure() method to take a >>>> single String argument to be consistent with the "providerarg" option >>>> that keytool defined. >>>> >>>> In addition, I also made some misc changes, such as configuring the >>>> providers inside ProviderConfig instead of ProviderLoader, add back the >>>> doPrivileged block to all the provider constructors. I also have second >>>> thought on making the switch to privider name (instead of provider class >>>> name) in java.security file, so I reverted the changes on that - that >>>> SunPKCS11 provider has its name specified in its configuration file, so >>>> when ServiceLoader loads the PKCS11 provider, the configuration file has >>>> not been passed to it, so the name is not known at that time. Thus, >>>> using the class name for the provider list entry seems to fit the flow >>>> better. I also updated the default policy for SunPKCS11 provider given >>>> its recent change of using sun.misc. >>>> >>>> Webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.00/ >>>> CCC: http://ccc.us.oracle.com/7191662 >>>> >>>> Thanks, >>>> Valerie >>>> >> From weijun.wang at oracle.com Thu May 28 01:02:44 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 28 May 2015 09:02:44 +0800 Subject: Fwd: 8078439: 8048194: possible bug in commit for these two fixes In-Reply-To: <555D9020.50903@oracle.com> References: <1432164509.64528.BPMail_high_carrier@web162905.mail.bf1.yahoo.com> <555D9020.50903@oracle.com> Message-ID: <55666934.4050003@oracle.com> Hi Darwin Thanks for looking into this file. Most of your words are correct, but I'd like to explain what was behind those changesets. See comments below. On 5/21/2015 3:58 PM, Se?n Coffey wrote: > FYI, > > concerns from Darwin on the 8078439: 8048194 fixes. > > regards, > Sean. > > -------- Forwarded Message -------- > Subject: 8078439: 8048194: possible bug in commit for these two fixes > Date: Wed, 20 May 2015 16:28:29 -0700 > From: Darwin Felix > To: jdk8u-dev at openjdk.java.net > CC: darwinfelix at users.sourceforge.net > > > > 8078439: 8048194: possible bug in commit for these two fixes > > It appears that this commit has a bug: > > http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/d777e2918a77/src/share/classes/sun/security/jgss/spnego/SpNegoContext.java > Fundamentally, it appears that this commit desires to honor the initiator/client's preferred mechanism - first one in the list of mechanisms the client is offering to the target/server. > However, the commit does not allow for the condition where the server can only support a different mechanism from the client's offering/list (server not able to support mechList[0] but is able to support mechList[N]). In SPNEGO, the client always sends a mechToken using mechList[0]. Before this change for JDK-8048194, even if the server does not support mechList[0] and prefer mechList[n], it blindly calls GSS_acceptSecContext() on the mechToken as if it's for mechList[n], which will fail immediately. After the fix, server will not touch mechToken anymore. It sends its own preferred mech (mech_wanted, which is mechList[n]) back to client and wait for the client to send a mechToken for this mech in the 2nd round. > > In my humble opinion, based on my quick glance of the code, this commit is broken because the server is no longer allowed to select from one of the other mechanisms from the client's list. The server does select one (line 532) and inform the client about it (line 591). > > > This next commit also appears to have a bug: > > http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/9ab9f20e9bdd/src/share/classes/sun/security/jgss/spnego/SpNegoContext.java > It appears that this commit also desires to honor the initiator/client's preferred mechanism. > However, this commit also appears to suffer from the condition where the server can only support a different mechanism from the client's offering/list (server not able to support mechList[0] but is able to support mechList[N]). As I described in the bug comment for JDK-8078439, client sends Microsoft's krb5 OID as mechList[0] but Java only understands the standard krb5 OID. After the *previous* fix, it sends back the standard OID and wait for the client to send a mechToken for it. It will be something like c: Here is a mechToken for MS krb5 OID s: Sorry, I don't know that. Please send a token for standard krb5 OID c: Sure, here it is s: Good, here is my response token However, we are seeing clients that only expect one round of communication and when it cannot see a response token as the 1st reply it just fails. Thus the 2nd fix: c: Here is a mechToken for MS krb5 OID s: Wow, MS krb5 OID, I understand now. Here is my response token [A happy c] BTW, before these 2 fixes, it was c: Here is a mechToken for MS krb5 OID. I also know standard krb5 s: I know about standard krb5. Here is my response token [A happy c] > > > > Perhaps the above two (2) commits should be reverted? > > An alternative approach to supporting/honoring the initiator/client's preferred mechanism: > > Prior to the above two (2) commits, SpNegoContext.java suffered from the condition where it did not make an attempt/consider to use the initiator/client's preferred mechanism. Instead, the code would find a mechanism from the client's list that the server can support. Meaning, the server's supported/preferred mechanisms is the outer loop and the client's supported/preferred mechanism is the inner loop (preference specified by its order in the list). Exactly, and this is not correct. The reason I didn't touch this is that Java only supports krb5 now, so whichever is outer or inner loop does not really make a difference. We will fix it once we support a new mech. > > Here's what the code looked like prior to the above two (2) commits: > > http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/1a3de3cdc684/src/share/classes/sun/security/jgss/spnego/SpNegoContext.java > Perhaps, if we simply place the client's list as the outer loop and the server's list as the inner loop, we might be able to honor the client's preferred mechanism while ensuring that the chosen mechanism is one that the server can support. > > For example, have a look at the implementation of the method named > > SpNegoContext.negotiate_mech_type(supported_mechSet, mechList) > > Notice that the server's list is chosen as being the outer loop. It might make more sense to have the client's list be the outer loop. > > > If possible, I would like to discuss the possibility of reverting the above two commits and instead implement my proposed change (mechList as the outer loop and supported_mechSet as the inner loop) to the method named negotiate_mech_type. But what JDK-8048194 describes still exists: c: Here is a mechToken for XYZ mech. BTW, I also support krb5 s: Aha, I also support krb5, let me accept your mechToken... bang... token not parseable... fail... [ c still waiting ] Thanks Max > > > thanks, > -darwin > > > From valerie.peng at oracle.com Thu May 28 01:47:30 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 27 May 2015 18:47:30 -0700 Subject: Fwd: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <55664DCD.8040808@oracle.com> References: <55664547.7050002@oracle.com> <556646C2.2080003@oracle.com> <55664DCD.8040808@oracle.com> Message-ID: <556673B2.3050309@oracle.com> Sounds good to me. I suppose we can add it later if really needed. I will update the webrev and CCC. Thanks, Valerie On 5/27/2015 4:05 PM, Sean Mullan wrote: > On 05/27/2015 06:35 PM, Valerie Peng wrote: >> In addition, I changed the getArgument() impl in OracleUcrypto provider >> + SunPKCS11 provider to only return the value if the caller has read >> permission to the file. I feel this is probably safer as we don't want >> to reveal the path (potential info leak) to untrusted callers. If the >> callers don't have the right permission, then "" is returned. If you >> prefer SecurityException be thrown, please let me know. > > Better yet, maybe we don't need the getArgument method. The argument > is really only needed for Provider implementations, which get it via > the constructor. This way we can just have the constructor and not > expose potentially sensitive info through a public method. > > --Sean From aph at redhat.com Thu May 28 07:51:52 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 28 May 2015 08:51:52 +0100 Subject: RSA and Diffie-Hellman performance [Was: RFR(L): 8069539: RSA acceleration] In-Reply-To: <55662A7B.8010103@oracle.com> References: <02FCFB8477C4EF43A2AD8E0C60F3DA2B63321E33@FMSMSX112.amr.corp.intel.com> <5502E67C.8080208@oracle.com> <02FCFB8477C4EF43A2AD8E0C60F3DA2B63322AB0@FMSMSX112.amr.corp.intel.com> <02FCFB8477C4EF43A2AD8E0C60F3DA2B63323E86@FMSMSX112.amr.corp.intel.com> <550C004D.1060501@redhat.com> <02FCFB8477C4EF43A2AD8E0C60F3DA2B633245C8@FMSMSX112.amr.corp.intel.com> <55101C52.1090506@redhat.com> <5548193E.7060803@oracle.com> <55488803.4020802@redhat.com> <554CDD48.8080500@redhat.com> <1CCF381D-1C55-4392-A905-AD8CD457980B@oracle.com> <555708BE.8090100@redhat.com> <5565FC34.3020908@redhat.com> <55662A7B.8010103@oracle.com> Message-ID: <5566C918.5070202@redhat.com> On 27/05/15 21:35, Anthony Scarpino wrote: > How much of the montgomery multiply and sqaure are you planning to > intrinsify? Are you doing the whole thing or just portions of the > operations similar to multiplyToLen and squareToLen? I'm doing the whole montgomery multiply and square operation in a routine which interleaves multiplication and reduction so that the intermediate product is never written into memory. Andrew. From aph at redhat.com Thu May 28 09:25:38 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 28 May 2015 10:25:38 +0100 Subject: RSA and Diffie-Hellman performance [Was: RFR(L): 8069539: RSA acceleration] In-Reply-To: <5566C918.5070202@redhat.com> References: <02FCFB8477C4EF43A2AD8E0C60F3DA2B63321E33@FMSMSX112.amr.corp.intel.com> <5502E67C.8080208@oracle.com> <02FCFB8477C4EF43A2AD8E0C60F3DA2B63322AB0@FMSMSX112.amr.corp.intel.com> <02FCFB8477C4EF43A2AD8E0C60F3DA2B63323E86@FMSMSX112.amr.corp.intel.com> <550C004D.1060501@redhat.com> <02FCFB8477C4EF43A2AD8E0C60F3DA2B633245C8@FMSMSX112.amr.corp.intel.com> <55101C52.1090506@redhat.com> <5548193E.7060803@oracle.com> <55488803.4020802@redhat.com> <554CDD48.8080500@redhat.com> <1CCF381D-1C55-4392-A905-AD8CD457980B@oracle.com> <555708BE.8090100@redhat.com> <5565FC34.3020908@redhat.com> <55662A7B.8010103@oracle.com> <5566C918.5070202@redhat.com> Message-ID: <5566DF12.7080205@redhat.com> On 05/28/2015 08:51 AM, Andrew Haley wrote: > On 27/05/15 21:35, Anthony Scarpino wrote: > >> How much of the montgomery multiply and sqaure are you planning to >> intrinsify? Are you doing the whole thing or just portions of the >> operations similar to multiplyToLen and squareToLen? > > I'm doing the whole montgomery multiply and square operation in a > routine which interleaves multiplication and reduction so that the > intermediate product is never written into memory. For a bit more information, here's the algorithm in C: Andrew. // Multiply (unsigned) Long A by Long B, accumulating the double- // length result into the accumulator formed of T0, T1, and T2. #define MACC(A, B, T0, T1, T2) \ do { \ unsigned long hi, lo; \ __asm__ ("mul %5; add %%rax, %2; adc %%rdx, %3; adc $0, %4" \ : "=&d"(hi), "=a"(lo), "+r"(T0), "+r"(T1), "+g"(T2) \ : "r"(A), "a"(B)); \ } while(0) // Fast Montgomery multiplication. The derivation of the algorithm is // in A Cryptographic Library for the Motorola DSP56000, // Dusse and Kaliski, Proc. EUROCRYPT 90, pp. 230-237. static void __attribute__((noinline)) montgomery_multiply(unsigned long a[], unsigned long b[], unsigned long n[], unsigned long m[], unsigned long inv, int len) { unsigned long t0 = 0, t1 = 0, t2 = 0; // Triple-precision accumulator int i; assert(inv * n[0] == -1UL); for (i = 0; i < len; i++) { int j; for (j = 0; j < i; j++) { MACC(a[j], b[i-j], t0, t1, t2); MACC(m[j], n[i-j], t0, t1, t2); } MACC(a[i], b[0], t0, t1, t2); m[i] = t0 * inv; MACC(m[i], n[0], t0, t1, t2); assert(t0 == 0); t0 = t1; t1 = t2; t2 = 0; } for (i = len; i < 2*len; i++) { int j; for (j = i-len+1; j < len; j++) { MACC(a[j], b[i-j], t0, t1, t2); MACC(m[j], n[i-j], t0, t1, t2); } m[i-len] = t0; t0 = t1; t1 = t2; t2 = 0; } m[len] = t0; while(cmp(m, n, len+1) > 0) sub(m, n, len+1); } From Alan.Bateman at oracle.com Thu May 28 11:35:06 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 May 2015 12:35:06 +0100 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: References: <55664547.7050002@oracle.com> Message-ID: <5566FD6A.5040201@oracle.com> On 27/05/2015 23:42, Mandy Chung wrote: > Valerie, > > Did you see my comment yesterday? > http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html > > Since you have reverted the java.security to keep the classname, to avoid causing merge conflict to jimage refresh, let?s remove the META-INF files in the first push and the build change. > > The security providers will be loaded via the fallback mechanism (i.e. ProviderLoader.legacyLoad method). You should keep the ProviderLoader.load method to take the provider name instead of classname. > > I?ll file a bug to follow up to change java.security to list the provider name. This will wait after the jimage refresh goes into jdk9/dev. > I think that's the best approach and this will also allow the temporary image build tool to be updated to merge the configuration files. -Alan From bhanu.prakash.gopularam at oracle.com Thu May 28 16:29:09 2015 From: bhanu.prakash.gopularam at oracle.com (Bhanu Prakash Gopularam) Date: Thu, 28 May 2015 09:29:09 -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: <7ceffa29-f629-41f0-8228-fa1b2556001b@default> Please review the changes for JEP 166: In this webrev, I have updated test certificate fields to reflect proper test data. http://cr.openjdk.java.net/~asmotrak/bhanu/8048830/webrev.01/ 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 May 28 20:17:04 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 28 May 2015 16:17:04 -0400 Subject: [JEP-219/JDK-8043758] Code Review Request: Datagram Transport Layer Security (DTLS) In-Reply-To: <555F5C50.40701@oracle.com> References: <555D341F.3050906@oracle.com> <555DAE74.8070708@oracle.com> <555DBF52.104@oracle.com> <555DC1FF.9060904@oracle.com> <555DC2C4.8070206@oracle.com> <555F5C50.40701@oracle.com> Message-ID: <556777C0.3010103@oracle.com> On 05/22/2015 12:41 PM, Xuelei Fan wrote: > webrev:http://cr.openjdk.java.net/~xuelei/8043758/webrev.latest/ > > Updates: > 1. Update to discard invalid records, rather than use an alert message, > per the requirements in section 4.1.2.7, RFC 6374. > 2. Update to use a base test class, simplify the test case a lot. I think it would be useful to add some comments to each of the new tests to describe what they are testing. Most of them don't have any comments. --Sean From valerie.peng at oracle.com Thu May 28 22:10:19 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 28 May 2015 15:10:19 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: References: <55664547.7050002@oracle.com> Message-ID: <5567924B.5030604@oracle.com> Please find comments in line... On 5/27/2015 3:42 PM, Mandy Chung wrote: > Valerie, > > Did you see my comment yesterday? > http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html Yes, we exchanged emails after this above one. I will follow up your latest one later today. > > Since you have reverted the java.security to keep the classname, to avoid causing merge conflict to jimage refresh, let?s remove the META-INF files in the first push and the build change. > > The security providers will be loaded via the fallback mechanism (i.e. ProviderLoader.legacyLoad method). You should keep the ProviderLoader.load method to take the provider name instead of classname. Sure, I can remove the META-INF files so the providers are loaded through the legacyLoad(). Hmm, the ProviderLoader.load() method is used by java.security file provider loading. Since the current list still uses class name, it should take class name when checking for matches while iterating through the list returned by ServiceLoader. This way, when changes are sync'ed into Jake, no extra change required and the providers will be loaded through ProviderLoader.load() automatically with the current list. > I?ll file a bug to follow up to change java.security to list the provider name. This will wait after the jimage refresh goes into jdk9/dev Ok. Thanks, Valerie > . > > Mandy > >> On May 27, 2015, at 3:29 PM, Valerie Peng wrote: >> >> Hi, build experts, >> >> Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ >> >> This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. >> >> The rest of source code changes are reviewed by my team already. >> Thanks, >> Valerie >> (Java Security Team) From xuelei.fan at oracle.com Fri May 29 00:55:52 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 29 May 2015 08:55:52 +0800 Subject: [JEP-219/JDK-8043758] Code Review Request: Datagram Transport Layer Security (DTLS) In-Reply-To: <556777C0.3010103@oracle.com> References: <555D341F.3050906@oracle.com> <555DAE74.8070708@oracle.com> <555DBF52.104@oracle.com> <555DC1FF.9060904@oracle.com> <555DC2C4.8070206@oracle.com> <555F5C50.40701@oracle.com> <556777C0.3010103@oracle.com> Message-ID: <5567B918.2080705@oracle.com> On 5/29/2015 4:17 AM, Sean Mullan wrote: > On 05/22/2015 12:41 PM, Xuelei Fan wrote: >> webrev:http://cr.openjdk.java.net/~xuelei/8043758/webrev.latest/ >> >> Updates: >> 1. Update to discard invalid records, rather than use an alert message, >> per the requirements in section 4.1.2.7, RFC 6374. >> 2. Update to use a base test class, simplify the test case a lot. > > I think it would be useful to add some comments to each of the new tests > to describe what they are testing. Most of them don't have any comments. > Updated in webrev.latest. Thanks, Xuelei From valerie.peng at oracle.com Fri May 29 01:05:40 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 28 May 2015 18:05:40 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: <5FE0E92E-EE62-49CF-AC3F-59D31B6BD987@oracle.com> References: <555D5D32.9010908@oracle.com> <5564DE1E.1060601@oracle.com> <5564F36B.6060102@oracle.com> <5566509F.1070105@oracle.com> <5FE0E92E-EE62-49CF-AC3F-59D31B6BD987@oracle.com> Message-ID: <5567BB64.7060805@oracle.com> Please find comments in line. On 5/27/2015 4:40 PM, Mandy Chung wrote: >> On May 27, 2015, at 4:17 PM, Valerie Peng wrote: >> >> Hi, Mandy, >> >> I have second thought on using the provider name for the java.security file... >> There are a few things that I want to discuss/brainstorm internally to make sure that there is no "surprise" later. >> Thus, I had not made the switch in this webrev. It doesn't affect the overall functionality. >> > What is the issue you concern about with ServiceLoader to load providers when it matches its provider name rather than the classname? SPI allows you to move away from using the classname in the configuration and separate implementation from interfaces. There are several things...or questions that I'd like to clarify before making the switch. Not all of them are related to this switch though, but still, I don't want to complicate things further by adding new changes into this mix. First, provider name seems "looser" than provider class name. With just a name, what happens when there is a name collision? Is there an ordering on how ServiceLoader loads/looks up services? If yes/no, does it affect provider validation? Second, it's a bit awkward in the SunPKCS11 provider case. For SunPKCS11 provider, its name is set in the configuration file which is passed to the provider object upon the configure call. When ServiceLoader loads the SunPKCS11 provider object, you can't use the provider name to look for a match as the provider itself doesn't have that info yet. Sure, we can always do special handling for SunPKCS11 to make this work. But this special handling isn't needed for the class name setting. Lastly, this overlaps with Tony's JEP and his current proposal fits better with class name setting (this may just be my personal opinion). So, I feel it's better to clarify all these questions before making the switch. I did mention about this (not using provider name in java.security) when sending out my webrev to security alias but didn't not notify Alan and you separately. Sorry~ Valerie > > >> The legacyLoad() is for finding providers the old-fashioned way, e.g. through reflection, instead of ServiceLoader. >> The legacyLoad can only work using class name. >> > For the first push, it?s okay to leave them loaded by the legacy mechanism via reflection until you sort out the provider name issue before you make them true service providers. But I still think ProviderLoader.load should not tie with the classname unless there is a strong reason to. > > >> Running test/java/lang/SecurityManager/CheckSecurityProvider.java with a security manager should cover more than without. > Ok with me. > >> I don't see much value in adding provider name verification? Verifying class name seems enough in making sure that the providers are present as expected. >> > If you are using the provider name to load service providers, this adds additional verification. I?m surprised that your webrev was changed as I didn?t see any mail about your concern that leads to the change. > >> As for test/tools/launcher/MiscTests.java, it's for verifying a bug in launcher, so I have stick with the internal API as I am not sure if switching to public API may be too great of a change as the call path changed significantly? > This test verifies 6856415 that needs to use sun.* API and ensures that the right Exception is thrown. Ok - it?s okay to leave it then. > > Mandy > >> Thanks, >> Valerie >> >> On 5/26/2015 3:27 PM, Mandy Chung wrote: >>> sun/security/jca/ProviderConfig.java >>> >>> 287 /** >>> 288 * Loads the provider with the specified class name. >>> 289 * >>> 290 * @param name the name of the provider class >>> 291 * @return the Provider, or null if it cannot be found or loaded >>> 292 * @throws ProviderException all other exceptions are ignored >>> 293 */ >>> 294 public Provider load(String classname) { >>> : >>> >>> 305 if (p.getClass().getName().equals(classname)) { >>> 306 return p; >>> 307 } >>> >>> Is this load method supposed to take the provider name instead of the classname? >>> line 305 should check against p.getName() instead? The legacyLoad method is >>> for the fallback to the class name. >>> >>> java.security now uses classname. Did you decide to use security provider name instead? >>> Even so, the legacyLoader method should be able to find them and the load method >>> looks to me should check the provider name instead. >>> >>> test/java/lang/SecurityManager/CheckSecurityProvider.java >>> you add this test to run with security manager. I wonder if you want >>> to run with and without security manager through @run othervm. >>> >>> Now each security provider has a name. Should this test verify the provider >>> name as well? >>> >>> test/tools/launcher/MiscTests.java >>> - does this test need to call sun.security.pkcs11 internal API? Can this be >>> changed to call public API? >>> >>> I didn't review other files. >>> Mandy >>> >>> On 05/26/2015 01:57 PM, Sean Mullan wrote: >>>> This all looks fine to me (except for the Makefile stuff which I'll leave to others). >>>> >>>> --Sean >>>> >>>> On 05/21/2015 12:21 AM, Valerie Peng wrote: >>>>> Sean, >>>>> >>>>> Could you please review this change? The changes are mostly the same as >>>>> the prototype in Jake, but I have to make some modification due to the >>>>> difference in ServiceLoader lookup in OpenJDK (corresponding >>>>> META-INF/services/java.security.Provider files in each module) and the >>>>> related makefile change (merge their content into one for the final >>>>> image build). Then, I adjusted the Provider.configure() method to take a >>>>> single String argument to be consistent with the "providerarg" option >>>>> that keytool defined. >>>>> >>>>> In addition, I also made some misc changes, such as configuring the >>>>> providers inside ProviderConfig instead of ProviderLoader, add back the >>>>> doPrivileged block to all the provider constructors. I also have second >>>>> thought on making the switch to privider name (instead of provider class >>>>> name) in java.security file, so I reverted the changes on that - that >>>>> SunPKCS11 provider has its name specified in its configuration file, so >>>>> when ServiceLoader loads the PKCS11 provider, the configuration file has >>>>> not been passed to it, so the name is not known at that time. Thus, >>>>> using the class name for the provider list entry seems to fit the flow >>>>> better. I also updated the default policy for SunPKCS11 provider given >>>>> its recent change of using sun.misc. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.00/ >>>>> CCC: http://ccc.us.oracle.com/7191662 >>>>> >>>>> Thanks, >>>>> Valerie >>>>> From bradford.wetmore at oracle.com Sat May 30 00:26:41 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 29 May 2015 17:26:41 -0700 Subject: TLS ALPN Proposal In-Reply-To: References: <555E7E98.9050208@oracle.com> <5562F48A.5010405@oracle.com> <5563BEB4.1040501@oracle.com> <5564BF8A.90709@oracle.com> Message-ID: <556903C1.5090304@oracle.com> Simone, I'm sorry for the delay in responding, I've been getting familiar with lambdas the last couple days, and how we might be able to apply it to the ALPNSelector code. Interesting stuff. To the question in this email. I'll leave the previous discussion for context. See my responses inline. On 5/27/2015 4:47 AM, Simone Bordet wrote: > Hi, > > On Tue, May 26, 2015 at 8:46 PM, Bradford Wetmore > wrote: >>> I am not sure I follow this. Can you please sketch the steps/algorithm >>> that will be done in your proposed solution ? >> >> I'm assuming you are talking about 1a and not 1b. >> >> Sure, most of the heavy lifting takes place in ServerHandshaker. >> >> ServerHandshaker.java >> ===================== >> >> In the SunJSSE code: >> >> // currently line 330. >> private void clientHello(ClientHello mesg) throws IOException { >> >> // Was an ALPNExtension received? >> ALPNExtension alpnExt = (ALPNExtension) >> mesg.extensions.get(ExtensionTyp.EXT_ALPN); >> ... >> // Currently line 706 in JDK9. >> session = new SSLSessionImpl(protocolVersion, >> CipherSuite.C_NULL, >> getLocalSupportedSignAlgs(), >> sslContext.getSecureRandom(), >> getHostAddressSE(), getPortSE()); >> ... >> session.setALPNNames(alpnExt.getNames()); >> ... >> // choose cipher suite and corresponding private key >> // This function is at 987 currently. >> chooseCipherSuite(mesg); >> ... >> // Only adds an ALPN extension if non-empty. >> m1.extensions.add(applicationProtocolSelector.select(...)); >> ... >> >> Above, chooseCipherSuite() iterates through the collection of suites. Inside >> that, trySetCipherSuite() attempts to verify that the suite is acceptable to >> use. Inside that, setupPrivateKeyAndChain() does the actual KeyManager >> calls. >> >> if (conn != null) { >> alias = km.chooseServerAlias(algorithm, null, conn); >> } else { >> alias = km.chooseEngineServerAlias(algorithm, null, engine); >> } >> >> Now in the Application's Code: >> >> If you want the KeyManager to take this info into account, you need to >> create your own customer KM. >> >> public String chooseEngineServerAlias(String keyType, >> Principal[] issuers, >> SSLEngine engine) { >> >> ExtendedSSLSession session = engine.getHandshakeSession(); >> String protocol = session.getProtocol(); >> String ciphersuite = session.getCipherSuite(); >> List alpns = >> session.getRequestedApplicationProtocolNames(); >> >> // Some logic for which key to use... >> return choose(protocol, ciphersuite, alpns); >> } >> >> And then your actual ALPN selector: >> >> public String select(...) throws SSLProtocolException { >> ExtendedSSLSession session = engine.getHandshakeSession() >> String ciphersuite = session.getCipherSuite(); >> List alpns = >> session.getRequestedApplicationProtocolNames(); >> >> // Some logic for which key to use... >> return choose(protocol, ciphersuite, alpns); >> } >> >> Hopefully that is clear. > > Let me see if I understand correctly. > > In chooseEngineServerAlias() I will have a proposed cipher and the > list of app protos from the client. > The goal would be to choose the alias based on the app proto, as stated by 7301. > > However, the app proto is not yet chosen here. If I don't have other > constraints to choose the app proto (e.g. SNI), the usual algorithm > applies: pick the first server app proto that is in common with the > client. > Let's assume this is h2; but looking at the cipher, it's not good, so > we have to pick another app proto, say http/1.1. Now the cipher is > good and we return the alias. > This is similar to what happens now with Jetty's ALPN: the cipher will > be chosen, then the ALPN callback invoked and there, by looking at the > cipher, we know we have to use http/1.1. > > Let's assume now I have the constraint to choose h2 (e.g. I have a SNI > of http2.domain.com). > In chooseEngineServerAlias() I will look at SNI, and therefore choose > h2, then look at the proposed cipher, which is not good, so return > null. > Method chooseEngineServerAlias() will be called repeatedly for other > ciphers, until a cipher good for h2 is found, otherwise it's an alert > 120. Correct. To expand a bit... You will have the SSLSocket/SSLEngine which will give you access to the Socket's attributes (e.g. local/remote IP address/ports), along with the handshakeSession which is being negotiated. The handshakeSession will give access to the selected TLS protocol version number plus the received SNI and ALPN names. With my change to the ciphersuites, it will now give you to the "proposed" ciphersuite, the one being probed for valid key material. If your custom KeyManager don't like this combination of protocol/ciphersuite/sni/alpn/Socket attributes, the KeyManager can report back no valid key material is available, thus meeting that constraint. > Are you proposing to call select(...) from chooseEngineServerAlias(), > and give the ALPN callback a semantic that it may be called multiple > times, each time with a different cipher, and give access to the ALPN > callback implementation to SNI to choose the right protocol based on > that ? That's another approach, add an SSLSocket/SSLEngine API to set the selected value from the KM callback. But that won't work for KM-less ciphersuites (anonymous). I was planning on calling select() after the KM has returned to make the final selection once the ciphersuite has been officially selected, rather than requiring the KM to make the call. Brad