From zaiyao.liu at oracle.com Mon Sep 1 01:37:42 2014 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Mon, 01 Sep 2014 09:37:42 +0800 Subject: RFR 8048619: Implement tests for converting PKCS12 keystores Message-ID: <5403CDE6.6070006@oracle.com> Hi Max, Please review the code change,the purpose of this fix is implement tests that convert PKCS12 keystores to other formats. Webrev: http://cr.openjdk.java.net/~tyan/kevin/JDK-8048619/webrev01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8048619 Thanks Kevin From weijun.wang at oracle.com Mon Sep 1 05:25:04 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 1 Sep 2014 13:25:04 +0800 Subject: RFR 8048619: Implement tests for converting PKCS12 keystores In-Reply-To: <5403CDE6.6070006@oracle.com> References: <5403CDE6.6070006@oracle.com> Message-ID: On vacation now. Can you look for someone else? I will be back in Sep 17 if you are not in a hurry. --Max On Sep 1, 2014, at 9:37, zaiyao liu wrote: > Hi Max, > > Please review the code change,the purpose of this fix is implement tests that convert PKCS12 keystores to other formats. > > Webrev: http://cr.openjdk.java.net/~tyan/kevin/JDK-8048619/webrev01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8048619 > > Thanks > > Kevin From zaiyao.liu at oracle.com Mon Sep 1 07:14:34 2014 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Mon, 01 Sep 2014 15:14:34 +0800 Subject: RFR 8048621: Implement basic keystore tests In-Reply-To: <53FE89B1.3080502@oracle.com> References: <53FE89B1.3080502@oracle.com> Message-ID: <54041CDA.5080506@oracle.com> Hi Xuelei, Can you help to review those tests? Thanks Kevin ? 2014/8/28 9:45, zaiyao liu ??: > Hi All, > > Please review the code change,the purpose of this fix is implement > basic tests for keystore types supported by JDK. > > Webrev: http://cr.openjdk.java.net/~tyan/kevin/JDK-8048621/webrev01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8048621 > > Thanks > > Kevin From xuelei.fan at oracle.com Mon Sep 1 09:42:11 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 01 Sep 2014 17:42:11 +0800 Subject: RFR 8048621: Implement basic keystore tests In-Reply-To: <54041CDA.5080506@oracle.com> References: <53FE89B1.3080502@oracle.com> <54041CDA.5080506@oracle.com> Message-ID: <54043F73.8060301@oracle.com> Providers.java --------------- May be not necessary to define Providers.SUN_JCE, Providers.SUNPKCS11_SOLARIS. As add unnecessary dependencies among tests, and slow down the test performance. TestKeyStoreBasic.java ---------------------- Better to throw exception, rather than return false so that the cause of failure is exposed in the exception stacks. TestKeyStoreEntry.java ---------------------- See above. A question: in which case PKCS11 keystore is disabled? Xuelei On 9/1/2014 3:14 PM, zaiyao liu wrote: > Hi Xuelei, > > Can you help to review those tests? > > Thanks > > Kevin > ? 2014/8/28 9:45, zaiyao liu ??: >> Hi All, >> >> Please review the code change,the purpose of this fix is implement >> basic tests for keystore types supported by JDK. >> >> Webrev: http://cr.openjdk.java.net/~tyan/kevin/JDK-8048621/webrev01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8048621 >> >> Thanks >> >> Kevin > From raghu.k.nair at oracle.com Tue Sep 2 01:14:57 2014 From: raghu.k.nair at oracle.com (raghu k.nair) Date: Tue, 02 Sep 2014 06:44:57 +0530 Subject: Please review CR 8049429 tests for java client server communications with various TLS/SSL combinations. In-Reply-To: <53FEC332.6060301@oracle.com> References: <53F70D3F.6030703@oracle.com> <53FEBDC7.8020304@oracle.com> <53FEC332.6060301@oracle.com> Message-ID: <54051A11.1080000@oracle.com> Hi Xuelie, Could you please review the updated code. I have removed the dependency on binary files. http://cr.openjdk.java.net/~tyan/raghu/8049429/webrev02/ Thanks, Raghu Nair On 8/28/2014 11:20 AM, Xuelei Fan wrote: > Remove Drew from the CC list. > > I have not read too much about the test code. I think, binary files are > not preferred in mercurial workspace. Would you mind convert the PKCS12 > binary file to nested stream in the test code? > > Here is an example about how to avoid the use of binary key store file. > test/javax/net/ssl/TLSv12/ShortRSAKey512.java > > Xuelei > > On 8/28/2014 1:27 PM, raghu k.nair wrote: >> Hi Andrew, >> >> Could you please help in me in reviewing the following tests. >> >> Thanks, >> Raghu Nair >> >> On 8/22/2014 2:58 PM, raghu k.nair wrote: >>> Hello, >>> >>> Please help to review the tests for java client server >>> communications with various TLS/SSL combinations. >>> >>> Bug - https://bugs.openjdk.java.net/browse/JDK-8049429 >>> webrev- http://cr.openjdk.java.net/~tyan/raghu/8049429/webrev01/ >>> >>> >>> Thanks >>> Raghu Nair -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue Sep 2 03:15:02 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 02 Sep 2014 11:15:02 +0800 Subject: Please review CR 8049429 tests for java client server communications with various TLS/SSL combinations. In-Reply-To: <54051A11.1080000@oracle.com> References: <53F70D3F.6030703@oracle.com> <53FEBDC7.8020304@oracle.com> <53FEC332.6060301@oracle.com> <54051A11.1080000@oracle.com> Message-ID: <54053636.70501@oracle.com> Looks fine to me. Nice test. Xuelei On 9/2/2014 9:14 AM, raghu k.nair wrote: > Hi Xuelie, > Could you please review the updated code. I have removed the > dependency on binary files. > http://cr.openjdk.java.net/~tyan/raghu/8049429/webrev02/ > > > Thanks, > Raghu Nair > On 8/28/2014 11:20 AM, Xuelei Fan wrote: >> Remove Drew from the CC list. >> >> I have not read too much about the test code. I think, binary files are >> not preferred in mercurial workspace. Would you mind convert the PKCS12 >> binary file to nested stream in the test code? >> >> Here is an example about how to avoid the use of binary key store file. >> test/javax/net/ssl/TLSv12/ShortRSAKey512.java >> >> Xuelei >> >> On 8/28/2014 1:27 PM, raghu k.nair wrote: >>> Hi Andrew, >>> >>> Could you please help in me in reviewing the following tests. >>> >>> Thanks, >>> Raghu Nair >>> >>> On 8/22/2014 2:58 PM, raghu k.nair wrote: >>>> Hello, >>>> >>>> Please help to review the tests for java client server >>>> communications with various TLS/SSL combinations. >>>> >>>> Bug - https://bugs.openjdk.java.net/browse/JDK-8049429 >>>> webrev- http://cr.openjdk.java.net/~tyan/raghu/8049429/webrev01/ >>>> >>>> >>>> Thanks >>>> Raghu Nair > From simone.bordet at gmail.com Tue Sep 2 08:15:14 2014 From: simone.bordet at gmail.com (Simone Bordet) Date: Tue, 2 Sep 2014 10:15:14 +0200 Subject: TLS extensions API, ALPN and HTTP 2.0 In-Reply-To: References: Message-ID: Hi, On Wed, Aug 20, 2014 at 1:03 PM, Simone Bordet wrote: > On Tue, Aug 19, 2014 at 4:11 PM, Vincent Ryan wrote: >> Finally, please confirm that you have already signed the OCA [1] > > I have not yet, it's running through legals ATM. > I'll notify when this is done. I emailed the signed OCA. Does it need to be processed before we can talk about the design, or ... ? 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 vincent.x.ryan at oracle.com Tue Sep 2 09:11:59 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 2 Sep 2014 10:11:59 +0100 Subject: TLS extensions API, ALPN and HTTP 2.0 In-Reply-To: References: Message-ID: Your OCA is still being processed. When that has completed your name will be listed at: http://www.oracle.com/technetwork/community/oca-486395.html#b Until then, we can discuss these TLS/HTTP issues but we cannot include your APIs or source code. Thanks. On 2 Sep 2014, at 09:15, Simone Bordet wrote: > Hi, > > On Wed, Aug 20, 2014 at 1:03 PM, Simone Bordet wrote: >> On Tue, Aug 19, 2014 at 4:11 PM, Vincent Ryan wrote: >>> Finally, please confirm that you have already signed the OCA [1] >> >> I have not yet, it's running through legals ATM. >> I'll notify when this is done. > > I emailed the signed OCA. Does it need to be processed before we can > talk about the design, or ... ? > > 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 mala.bankal at oracle.com Tue Sep 2 09:55:26 2014 From: mala.bankal at oracle.com (mala bankal) Date: Tue, 02 Sep 2014 15:25:26 +0530 Subject: Request for review : 8054817: File ccache only recognizes Linux and Solaris defaults Message-ID: <5405940E.7060205@oracle.com> HI Max, All, Request to review the changes for the backport of 8054817 to jdk7u-dev. webrev : http://cr.openjdk.java.net/~mbankal/8054817/webrev.00/ JDK9 changeset : http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ec98f141c757 JDK8 changeset : http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ec98f141c757 The backport has been derived from JDK8 changes. Thanks. rgds mala From sean.mullan at oracle.com Tue Sep 2 11:43:55 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 02 Sep 2014 07:43:55 -0400 Subject: Request for review : 8054817: File ccache only recognizes Linux and Solaris defaults In-Reply-To: <5405940E.7060205@oracle.com> References: <5405940E.7060205@oracle.com> Message-ID: <5405AD7B.209@oracle.com> Looks fine to me. --Sean On 09/02/2014 05:55 AM, mala bankal wrote: > HI Max, All, > > Request to review the changes for the backport of 8054817 to jdk7u-dev. > > webrev : > http://cr.openjdk.java.net/~mbankal/8054817/webrev.00/ > > JDK9 changeset : > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ec98f141c757 > JDK8 changeset : > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ec98f141c757 > > The backport has been derived from JDK8 changes. > Thanks. > > rgds > mala From sean.coffey at oracle.com Tue Sep 2 15:52:28 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 02 Sep 2014 16:52:28 +0100 Subject: RFR : 8054019 Keytool Error publicKey's is not X.509, but X509 Message-ID: <5405E7BC.5070405@oracle.com> I'd like to bring this change into 7u only. The 7u40 7109096 fix introduced tighter conditions around Key.getFormat(). Some interoperability issues have been seen for key generators that mightn't strictly honour the ASN.1 data format of X509 keys. As a result, I don't think the restriction was suitable for an update release and we should relax it : https://bugs.openjdk.java.net/browse/JDK-8054019 > diff --git a/src/share/classes/sun/security/x509/CertAndKeyGen.java > b/src/share/classes/sun/security/x509/CertAndKeyGen.java > --- a/src/share/classes/sun/security/x509/CertAndKeyGen.java > +++ b/src/share/classes/sun/security/x509/CertAndKeyGen.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1996, 2009, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1996, 2014, 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 > @@ -156,7 +156,9 @@ > > // publicKey's format must be X.509 otherwise > // the whole CertGen part of this class is broken. > - if (!"X.509".equalsIgnoreCase(publicKey.getFormat())) { > + // Allow "X509" in 7u for backwards compatibility. > + if (!"X.509".equalsIgnoreCase(publicKey.getFormat()) && > + !"X509".equalsIgnoreCase(publicKey.getFormat())) { > throw new IllegalArgumentException("publicKey's is not > X.509, but " > + publicKey.getFormat()); > } Regards, Sean. From sean.mullan at oracle.com Tue Sep 2 16:17:18 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 02 Sep 2014 12:17:18 -0400 Subject: RFR : 8054019 Keytool Error publicKey's is not X.509, but X509 In-Reply-To: <5405E7BC.5070405@oracle.com> References: <5405E7BC.5070405@oracle.com> Message-ID: <5405ED8E.9030307@oracle.com> That seems fine to me. While you are in there, it would also be nice to fix the grammar of the exception message, ex: "public key format is " + publicKey.getFormat() + ", must be X.509/X509"); and open another bug to correct that in JDK 9. Thanks, Sean On 09/02/2014 11:52 AM, Se?n Coffey wrote: > I'd like to bring this change into 7u only. The 7u40 7109096 fix introduced > tighter conditions around Key.getFormat(). Some interoperability issues > have been seen for key generators that mightn't strictly honour the > ASN.1 data format of X509 keys. > > As a result, I don't think the restriction was suitable for an update > release > and we should relax it : > > https://bugs.openjdk.java.net/browse/JDK-8054019 >> diff --git a/src/share/classes/sun/security/x509/CertAndKeyGen.java >> b/src/share/classes/sun/security/x509/CertAndKeyGen.java >> --- a/src/share/classes/sun/security/x509/CertAndKeyGen.java >> +++ b/src/share/classes/sun/security/x509/CertAndKeyGen.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1996, 2009, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 1996, 2014, 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 >> @@ -156,7 +156,9 @@ >> >> // publicKey's format must be X.509 otherwise >> // the whole CertGen part of this class is broken. >> - if (!"X.509".equalsIgnoreCase(publicKey.getFormat())) { >> + // Allow "X509" in 7u for backwards compatibility. >> + if (!"X.509".equalsIgnoreCase(publicKey.getFormat()) && >> + !"X509".equalsIgnoreCase(publicKey.getFormat())) { >> throw new IllegalArgumentException("publicKey's is not >> X.509, but " >> + publicKey.getFormat()); >> } > > Regards, > Sean. > From sean.coffey at oracle.com Tue Sep 2 16:41:51 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Tue, 02 Sep 2014 17:41:51 +0100 Subject: RFR : 8054019 Keytool Error publicKey's is not X.509, but X509 In-Reply-To: <5405ED8E.9030307@oracle.com> References: <5405E7BC.5070405@oracle.com> <5405ED8E.9030307@oracle.com> Message-ID: <5405F34F.2020704@oracle.com> On 02/09/2014 17:17, Sean Mullan wrote: > That seems fine to me. While you are in there, it would also be nice > to fix the grammar of the exception message, ex: > > "public key format is " + publicKey.getFormat() + ", must be > X.509/X509"); Will do. Thought about adding X.509 to message that but the correct format is "X.509" only. I think it's best for an exception message to promote the correct format : "Public key format is " + publicKey.getFormat() + ", must be X.509"); I'll go ahead with that unless I hear otherwise. Will log a bug 8u/9 also. regards, Sean. > > and open another bug to correct that in JDK 9. > > Thanks, > Sean > > On 09/02/2014 11:52 AM, Se?n Coffey wrote: >> I'd like to bring this change into 7u only. The 7u40 7109096 fix >> introduced >> tighter conditions around Key.getFormat(). Some interoperability issues >> have been seen for key generators that mightn't strictly honour the >> ASN.1 data format of X509 keys. >> >> As a result, I don't think the restriction was suitable for an update >> release >> and we should relax it : >> >> https://bugs.openjdk.java.net/browse/JDK-8054019 >>> diff --git a/src/share/classes/sun/security/x509/CertAndKeyGen.java >>> b/src/share/classes/sun/security/x509/CertAndKeyGen.java >>> --- a/src/share/classes/sun/security/x509/CertAndKeyGen.java >>> +++ b/src/share/classes/sun/security/x509/CertAndKeyGen.java >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 1996, 2009, Oracle and/or its affiliates. All rights >>> reserved. >>> + * Copyright (c) 1996, 2014, 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 >>> @@ -156,7 +156,9 @@ >>> >>> // publicKey's format must be X.509 otherwise >>> // the whole CertGen part of this class is broken. >>> - if (!"X.509".equalsIgnoreCase(publicKey.getFormat())) { >>> + // Allow "X509" in 7u for backwards compatibility. >>> + if (!"X.509".equalsIgnoreCase(publicKey.getFormat()) && >>> + !"X509".equalsIgnoreCase(publicKey.getFormat())) { >>> throw new IllegalArgumentException("publicKey's is not >>> X.509, but " >>> + publicKey.getFormat()); >>> } >> >> Regards, >> Sean. >> From sean.coffey at oracle.com Tue Sep 2 18:47:26 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 02 Sep 2014 19:47:26 +0100 Subject: RFR (XS) : 8057076 : Correct exception message in CertAndKeyGen.java Message-ID: <540610BE.6080201@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8057076 As per earlier discussion today, a simple update to the exception message used in JDK 9. diff --git a/src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java b/src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java --- a/src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java +++ b/src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1996, 2014, 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 @@ -158,8 +158,8 @@ // publicKey's format must be X.509 otherwise // the whole CertGen part of this class is broken. if (!"X.509".equalsIgnoreCase(publicKey.getFormat())) { - throw new IllegalArgumentException("publicKey's is not X.509, but " - + publicKey.getFormat()); + throw new IllegalArgumentException("Public key format is " + + publicKey.getFormat() + ", must be X.509"); } } regards, Sean. From sean.mullan at oracle.com Tue Sep 2 18:56:34 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 02 Sep 2014 14:56:34 -0400 Subject: RFR (XS) : 8057076 : Correct exception message in CertAndKeyGen.java In-Reply-To: <540610BE.6080201@oracle.com> References: <540610BE.6080201@oracle.com> Message-ID: <540612E2.1040302@oracle.com> Looks good. --Sean On 09/02/2014 02:47 PM, Se?n Coffey wrote: > https://bugs.openjdk.java.net/browse/JDK-8057076 > > As per earlier discussion today, a simple update to the exception > message used in JDK 9. > > diff --git > a/src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java > b/src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java > --- > a/src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java > +++ > b/src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1996, 2014, 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 > @@ -158,8 +158,8 @@ > // publicKey's format must be X.509 otherwise > // the whole CertGen part of this class is broken. > if (!"X.509".equalsIgnoreCase(publicKey.getFormat())) { > - throw new IllegalArgumentException("publicKey's is not > X.509, but " > - + publicKey.getFormat()); > + throw new IllegalArgumentException("Public key format is " > + + publicKey.getFormat() + ", must be X.509"); > } > } > > regards, > Sean. From jason.uh at oracle.com Tue Sep 2 19:17:04 2014 From: jason.uh at oracle.com (Jason Uh) Date: Tue, 02 Sep 2014 12:17:04 -0700 Subject: Review request for CR 8049039 Need new tests for sun.securiy.x509 classes In-Reply-To: <53FDFA94.6050607@oracle.com> References: <53E99EF2.8010900@oracle.com> <53FAECEE.3010007@oracle.com> <53FCCCE6.3080701@oracle.com> <53FD5B06.2020607@oracle.com> <53FDFA94.6050607@oracle.com> Message-ID: <540617B0.7010801@oracle.com> On 8/27/14 8:34 AM, raghu k.nair wrote: > Hi Vincent / Jason, > Please review the updated webrev based on Jason's comments. > webrev: http://cr.openjdk.java.net/~tyan/raghu/8049039/webrev02/ > > > Thanks, > Raghu Nair > On 8/27/2014 9:43 AM, raghu k.nair wrote: >> Hi Jason, >> Thanks for your review comments. >> On 8/26/2014 11:37 PM, Jason Uh wrote: >>> Hi Raghu, >>> >>> I'm not an official Reviewer, but I have some comments, mostly about >>> X509Test.java. >>> >>> 1. I'm not sure if this matters, but the formatting of your copyright >>> header is a little strange. The text appears to be correct, but the >>> line breaks occur at non-standard places. If you look at any other >>> file, the first couple lines would look like this: >>> >>> /* >>> * Copyright (c) 2014, Oracle and/or its affiliates. All rights >>> reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> >>> Again, not sure how important this is, but it applies to every file >>> in the webrev. I'd suggest changing them. >>> >> This happened due to default formatting by Netbeans . I will correct it. I was actually showing the issue with the entire copyright header by quoting just the beginning. Sorry if I wasn't clear, but it looks like you only corrected the formatting on the first two lines. Could you please redo the entire copyright header for all of these files? (You can look at any existing test for reference and you'll see the difference.) >>> 2. checkMethod(): >>> Doesn't appear to be used anywhere. Do you want to keep this? If you >>> do, could you add a comment to explain the parameters? >>> >>> Also, in general for the rest of the methods, there are a lot of >>> parameters noted with the @param tag. If you want to leave those >>> javadoc style comments in, could you please describe the params? >>> >> X509Test is used by many other tests ( appart from these tests as part >> of the webrev). I will add comment and description for the params. >> Minor detail, but there is an extra space in line 53 and 55 of X509Test. Could you please remove them? Otherwise, looks good to me, but you'll still need an official Reviewer. Thanks, Jason >>> 3. equals() and assertByteArray() both seem to be >>> "assertEquals()"-style methods, but they are named a bit differently. >>> could you make the naming consistent? For example, maybe assertEquals >>> / assertByteArrayEquals. >>> >> Yes it make sense. I will make the necessary changes . >> >> 4. getElementesTest() should probably read getElementsTest(). You use >> this method in IssuerAlternativeNameExtensionTest.java, by the way. >> >> typo needs to be fixed. >> >> Thanks, >> Raghu >>> Otherwise, I think the tests look good to me, but again, I'm not a >>> Reviewer, so you still need an official review. >>> >>> Thanks, >>> Jason >>> >>> >>> >>> On 08/25/2014 03:59 AM, raghu k.nair wrote: >>>> Hi Vincent / Jason, >>>> Could you please help in reviewing the following test. >>>> >>>> Thanks, >>>> Raghu Nair >>>> >>>> On 8/12/2014 10:28 AM, raghu k.nair wrote: >>>>> Hello, >>>>> Please review the tests for sun.security.x509 classes. >>>>> These cover tests for GeneralName, GeneralNames, GeneralSubtree, >>>>> GeneralSubtrees, IPAddressName and IssuerAlternativeNameExtension. >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~rhalade/8049039/webrev.00/ >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8049039 >>>>> >>>>> Thanks, >>>>> Raghu Nair >>>> >> > From jamil.j.nimeh at oracle.com Tue Sep 2 21:15:45 2014 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 02 Sep 2014 14:15:45 -0700 Subject: JEP Review Request: OCSP Stapling for TLS Message-ID: <54063381.4020306@oracle.com> Hello all, The draft JEP "OCSP Stapling for TLS" has been opened up for community review. This is an update to the original call for comments back in mid-March this year[*]. Like some of the other early JEPs this year, this has been brought under the JEP 2.0 process. https://bugs.openjdk.java.net/browse/JDK-8046321 Thank you, --Jamil * http://mail.openjdk.java.net/pipermail/security-dev/2014-March/010327.html From zhong.j.yu at gmail.com Tue Sep 2 23:39:21 2014 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Tue, 2 Sep 2014 18:39:21 -0500 Subject: Wildcard in subjectAltName/dNSName Message-ID: The following command would fail, rejecting the wildcard in dNSName keytool -genkeypair -ext SAN=DNS:*.example.com ..... keytool error: java.lang.RuntimeException: java.io.IOException: DNSName components must begin with a letter RFC5280 $4.2.1.6. contains a paragraph vaguely talking about wildcards Finally, the semantics of subject alternative names that include wildcard characters (e.g., as a placeholder for a set of names) are not addressed by this specification. Applications with specific requirements MAY use such names, but they must define the semantics. And in practice, CAs, browsers, servers all seems to support wildcards in dNSName. Thoughts? Zhong Yu bayou.io From ecki at zusammenkunft.net Wed Sep 3 00:47:04 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 3 Sep 2014 02:47:04 +0200 Subject: JEP Review Request: OCSP Stapling for TLS In-Reply-To: <54063381.4020306@oracle.com> References: <54063381.4020306@oracle.com> Message-ID: <20140903024704.000038c7.ecki@zusammenkunft.net> hello, this is good news! jut a quick question before I prepare a full response. There is a "tunables" section mentioned in the JIRA which is not very concrete, is there a draft somewhere for it? Because, I would add as a sample/recommended tunable the option to deny for ServerSockets to respond to requests with nonces, as this is a major DOS risk and most of the good properties of OCSP stapling wont be present if a client requests it. Instead of denying it might also be OK to ignore it, as the per RFC6066 passing request_extension(ocsp-nonce) is a SHOULD in 6961 an "conditional MUST". I guess the responderID will not be honored by the server implementation? (and it is a shame that 6066 and 6961 do not mention the most typical use case with no responderid, no nonce and a single OCSP response provided by the CA issuing the intermediate as well, therefore no multiple-response is needed. I guess the client will not sent a nonce by default (or not at all?)). Also I can understand the restriction to not require API changes I wonder if this is a good idea. I will come back to that later, but just a prelimiary question: will a TrustManager (or HostnameVerifier) be able to actually see and work on the OCSP response - maybe via getHandshakeSession()? In the case I have to connect to a larger number of remote servers it would be good for me to turn the request of on a destination base. With a security/system property thats not so easy. In case of SNI I could work around by constructing the client socket with no hostname, but I really wish both features could be controlled dynamically. Greetings Bernd Am Tue, 02 Sep 2014 14:15:45 -0700 schrieb Jamil Nimeh : > Hello all, > > The draft JEP "OCSP Stapling for TLS" has been opened up for > community review. This is an update to the original call for > comments back in mid-March this year[*]. Like some of the other > early JEPs this year, this has been brought under the JEP 2.0 process. > > https://bugs.openjdk.java.net/browse/JDK-8046321 > > Thank you, > --Jamil > > * > http://mail.openjdk.java.net/pipermail/security-dev/2014-March/010327.html From zaiyao.liu at oracle.com Wed Sep 3 02:57:15 2014 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Wed, 03 Sep 2014 10:57:15 +0800 Subject: RFR 8048621: Implement basic keystore tests In-Reply-To: <54043F73.8060301@oracle.com> References: <53FE89B1.3080502@oracle.com> <54041CDA.5080506@oracle.com> <54043F73.8060301@oracle.com> Message-ID: <5406838B.7060609@oracle.com> Hi Xuelei, Thanks for review, please review the update: http://cr.openjdk.java.net/~tyan/kevin/JDK-8048621/webrev02/ Thanks Kevin ? 2014/9/1 17:42, Xuelei Fan ??: > Providers.java > --------------- > May be not necessary to define Providers.SUN_JCE, > Providers.SUNPKCS11_SOLARIS. As add unnecessary dependencies among > tests, and slow down the test performance. > > TestKeyStoreBasic.java > ---------------------- > Better to throw exception, rather than return false so that the cause of > failure is exposed in the exception stacks. > > TestKeyStoreEntry.java > ---------------------- > See above. > > A question: in which case PKCS11 keystore is disabled? > > Xuelei > > > On 9/1/2014 3:14 PM, zaiyao liu wrote: >> Hi Xuelei, >> >> Can you help to review those tests? >> >> Thanks >> >> Kevin >> ? 2014/8/28 9:45, zaiyao liu ??: >>> Hi All, >>> >>> Please review the code change,the purpose of this fix is implement >>> basic tests for keystore types supported by JDK. >>> >>> Webrev: http://cr.openjdk.java.net/~tyan/kevin/JDK-8048621/webrev01/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048621 >>> >>> Thanks >>> >>> Kevin From xuelei.fan at oracle.com Wed Sep 3 04:36:12 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 03 Sep 2014 12:36:12 +0800 Subject: RFR 8048621: Implement basic keystore tests In-Reply-To: <5406838B.7060609@oracle.com> References: <53FE89B1.3080502@oracle.com> <54041CDA.5080506@oracle.com> <54043F73.8060301@oracle.com> <5406838B.7060609@oracle.com> Message-ID: <54069ABC.80105@oracle.com> Looks fine to me. Thanks, Xuelei On 9/3/2014 10:57 AM, zaiyao liu wrote: > Hi Xuelei, > > Thanks for review, please review the update: > http://cr.openjdk.java.net/~tyan/kevin/JDK-8048621/webrev02/ > > Thanks > > Kevin > ? 2014/9/1 17:42, Xuelei Fan ??: >> Providers.java >> --------------- >> May be not necessary to define Providers.SUN_JCE, >> Providers.SUNPKCS11_SOLARIS. As add unnecessary dependencies among >> tests, and slow down the test performance. >> >> TestKeyStoreBasic.java >> ---------------------- >> Better to throw exception, rather than return false so that the cause of >> failure is exposed in the exception stacks. >> >> TestKeyStoreEntry.java >> ---------------------- >> See above. >> >> A question: in which case PKCS11 keystore is disabled? >> >> Xuelei >> >> >> On 9/1/2014 3:14 PM, zaiyao liu wrote: >>> Hi Xuelei, >>> >>> Can you help to review those tests? >>> >>> Thanks >>> >>> Kevin >>> ? 2014/8/28 9:45, zaiyao liu ??: >>>> Hi All, >>>> >>>> Please review the code change,the purpose of this fix is implement >>>> basic tests for keystore types supported by JDK. >>>> >>>> Webrev: http://cr.openjdk.java.net/~tyan/kevin/JDK-8048621/webrev01/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048621 >>>> >>>> Thanks >>>> >>>> Kevin > From zaiyao.liu at oracle.com Wed Sep 3 05:10:28 2014 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Wed, 03 Sep 2014 13:10:28 +0800 Subject: RFR 8048621: Implement basic keystore tests In-Reply-To: <54069ABC.80105@oracle.com> References: <53FE89B1.3080502@oracle.com> <54041CDA.5080506@oracle.com> <54043F73.8060301@oracle.com> <5406838B.7060609@oracle.com> <54069ABC.80105@oracle.com> Message-ID: <5406A2C4.7070609@oracle.com> Hi Xuelei, Can you help to push this code for me? Full comments: 8048621: Implement basic keystore tests Reviewed-by: Xuelei Fan Contributed-by: Zaiyao Liu Thanks Kevin ? 2014/9/3 12:36, Xuelei Fan ??: > Looks fine to me. > > Thanks, > Xuelei > > On 9/3/2014 10:57 AM, zaiyao liu wrote: >> Hi Xuelei, >> >> Thanks for review, please review the update: >> http://cr.openjdk.java.net/~tyan/kevin/JDK-8048621/webrev02/ >> >> Thanks >> >> Kevin >> ? 2014/9/1 17:42, Xuelei Fan ??: >>> Providers.java >>> --------------- >>> May be not necessary to define Providers.SUN_JCE, >>> Providers.SUNPKCS11_SOLARIS. As add unnecessary dependencies among >>> tests, and slow down the test performance. >>> >>> TestKeyStoreBasic.java >>> ---------------------- >>> Better to throw exception, rather than return false so that the cause of >>> failure is exposed in the exception stacks. >>> >>> TestKeyStoreEntry.java >>> ---------------------- >>> See above. >>> >>> A question: in which case PKCS11 keystore is disabled? >>> >>> Xuelei >>> >>> >>> On 9/1/2014 3:14 PM, zaiyao liu wrote: >>>> Hi Xuelei, >>>> >>>> Can you help to review those tests? >>>> >>>> Thanks >>>> >>>> Kevin >>>> ? 2014/8/28 9:45, zaiyao liu ??: >>>>> Hi All, >>>>> >>>>> Please review the code change,the purpose of this fix is implement >>>>> basic tests for keystore types supported by JDK. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~tyan/kevin/JDK-8048621/webrev01/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048621 >>>>> >>>>> Thanks >>>>> >>>>> Kevin From raghu.k.nair at oracle.com Wed Sep 3 07:42:14 2014 From: raghu.k.nair at oracle.com (raghu k.nair) Date: Wed, 03 Sep 2014 13:12:14 +0530 Subject: Please review CR 8050462 JAAS login tests for different LoginModule Message-ID: <5406C656.4050403@oracle.com> Hi Max/ Andrew, Could you please help me in reviewing the tests to check for JAAS login module with different combinations of JAAS LoginModule methods (REQUIRED, REQUISITE, SUFFICIENT and OPTIONAL). webrev: http://cr.openjdk.java.net/~tyan/raghu/8050462/webrev01/ Bug Id : JDK-8050462 Thanks, Raghu From raghu.k.nair at oracle.com Wed Sep 3 08:03:25 2014 From: raghu.k.nair at oracle.com (raghu k.nair) Date: Wed, 03 Sep 2014 13:33:25 +0530 Subject: Please review CR 8048363 Implement Provider tests Message-ID: <5406CB4D.1020409@oracle.com> Hi Brad, Could you please help me in reviewing the tests for CustomProvider and tests for various algorithms from the SUN and SunJCE providers. webrev: http://cr.openjdk.java.net/~tyan/raghu/8048363/webrev01/ Bug Id: JDK-8048363 Thanks, Raghu Nair From valerie.peng at oracle.com Wed Sep 3 21:41:30 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 03 Sep 2014 14:41:30 -0700 Subject: RFR 8042900: Allow com.sun.security.jgss to be in different module than org.ietf.jgss In-Reply-To: <5402818F.5030405@oracle.com> References: <53FEEE2C.7000308@oracle.com> <5402818F.5030405@oracle.com> Message-ID: <54078B0A.40103@oracle.com> I will take a look, hope it be done before Friday, but maybe early next week. Valerie On 8/30/2014 6:59 PM, Weijun Wang wrote: > Webrev updated at > > http://cr.openjdk.java.net/~weijun/8042900/webrev.01/ > > as per Alan's suggestions. > > Can anyone in the security team take a look? > > Thanks > Max > From jamil.j.nimeh at oracle.com Wed Sep 3 21:52:24 2014 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 03 Sep 2014 14:52:24 -0700 Subject: JEP Review Request: OCSP Stapling for TLS In-Reply-To: <20140903024704.000038c7.ecki@zusammenkunft.net> References: <54063381.4020306@oracle.com> <20140903024704.000038c7.ecki@zusammenkunft.net> Message-ID: <54078D98.1010806@oracle.com> Hello Bernd, thanks for the quick feedback! I don't have concrete answers to all your questions at this point, but I'll address what I can in-line. On 09/02/2014 05:47 PM, Bernd Eckenfels wrote: > hello, > > this is good news! > > jut a quick question before I prepare a full response. > > There is a "tunables" section mentioned in the JIRA which is not very > concrete, is there a draft somewhere for it? JJN: We don't have a draft for all the tunables yet. Right now I'm collecting all the items that we'd want to be able to tweak, so suggestions are certainly welcome. Your note below about an option to deny or ignore incoming requests with nonces is an interesting one that I had not considered. Most of the TLS clients I've seen that even do status_request don't bother with nonces or extensions of any type, I would assume for the performance reasons you hinted at below. To be fair, all the clients I've looked at that make status requests have been browsers and openssl s_client. Perhaps there are other TLS clients that make use of ResponderIds and/or extensions that I have yet to see. > > Because, I would add as a sample/recommended tunable the option to deny > for ServerSockets to respond to requests with nonces, as this is a > major DOS risk and most of the good properties of OCSP stapling wont be > present if a client requests it. Instead of denying it might also be OK > to ignore it, as the per RFC6066 passing request_extension(ocsp-nonce) > is a SHOULD in 6961 an "conditional MUST". > > I guess the responderID will not be honored by the server > implementation? JJN: I'd like to have the server honor it if possible, though I don't think I called it out in the description portion of the JEP. In my prototyping so far with Apache 2.4 I haven't populated a request with a ResponderId yet, though I have the hooks to do so. It would be interesting to see how they handle it. > > (and it is a shame that 6066 and 6961 do not mention the most typical > use case with no responderid, no nonce and a single OCSP response > provided by the CA issuing the intermediate as well, therefore no > multiple-response is needed. I guess the client will not sent a nonce > by default (or not at all?)). > > Also I can understand the restriction to not require API changes I > wonder if this is a good idea. I will come back to that later, but just > a prelimiary question: will a TrustManager (or HostnameVerifier) be > able to actually see and work on the OCSP response - maybe via > getHandshakeSession()? JJN: I'm also rethinking this, though I don't want to say more than that right now only because I don't have a clear picture yet of what any programmatic interface would look like. Up to now I've been thinking properties, but I'd like to avoid a case where we make too many of those. Also you brought up a very good point about being able to turn it on/off on a per-destination basis. Thanks once again for sharing your thoughts on this, and I welcome further comments on the topic. --Jamil > > In the case I have to connect to a larger number of remote servers it > would be good for me to turn the request of on a destination base. With > a security/system property thats not so easy. In case of SNI I could > work around by constructing the client socket with no hostname, but I > really wish both features could be controlled dynamically. > > Greetings > Bernd > > > Am Tue, 02 Sep 2014 14:15:45 -0700 schrieb Jamil Nimeh > : > >> Hello all, >> >> The draft JEP "OCSP Stapling for TLS" has been opened up for >> community review. This is an update to the original call for >> comments back in mid-March this year[*]. Like some of the other >> early JEPs this year, this has been brought under the JEP 2.0 process. >> >> https://bugs.openjdk.java.net/browse/JDK-8046321 >> >> Thank you, >> --Jamil >> >> * >> http://mail.openjdk.java.net/pipermail/security-dev/2014-March/010327.html From raghu.k.nair at oracle.com Thu Sep 4 13:54:38 2014 From: raghu.k.nair at oracle.com (raghu k.nair) Date: Thu, 04 Sep 2014 19:24:38 +0530 Subject: Review request for CR 8049039 Need new tests for sun.securiy.x509 classes In-Reply-To: <540617B0.7010801@oracle.com> References: <53E99EF2.8010900@oracle.com> <53FAECEE.3010007@oracle.com> <53FCCCE6.3080701@oracle.com> <53FD5B06.2020607@oracle.com> <53FDFA94.6050607@oracle.com> <540617B0.7010801@oracle.com> Message-ID: <54086F1E.6010603@oracle.com> Hi Jason, Please review the updated webrev . I have addressed your comments. http://cr.openjdk.java.net/~tyan/raghu/8049039/webrev03/ Thanks, Raghu On 9/3/2014 12:47 AM, Jason Uh wrote: > On 8/27/14 8:34 AM, raghu k.nair wrote: >> Hi Vincent / Jason, >> Please review the updated webrev based on Jason's comments. >> webrev: http://cr.openjdk.java.net/~tyan/raghu/8049039/webrev02/ >> >> >> Thanks, >> Raghu Nair >> On 8/27/2014 9:43 AM, raghu k.nair wrote: >>> Hi Jason, >>> Thanks for your review comments. >>> On 8/26/2014 11:37 PM, Jason Uh wrote: >>>> Hi Raghu, >>>> >>>> I'm not an official Reviewer, but I have some comments, mostly about >>>> X509Test.java. >>>> >>>> 1. I'm not sure if this matters, but the formatting of your copyright >>>> header is a little strange. The text appears to be correct, but the >>>> line breaks occur at non-standard places. If you look at any other >>>> file, the first couple lines would look like this: >>>> >>>> /* >>>> * Copyright (c) 2014, Oracle and/or its affiliates. All rights >>>> reserved. >>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>> >>>> Again, not sure how important this is, but it applies to every file >>>> in the webrev. I'd suggest changing them. >>>> >>> This happened due to default formatting by Netbeans . I will correct >>> it. > > I was actually showing the issue with the entire copyright header by > quoting just the beginning. Sorry if I wasn't clear, but it looks like > you only corrected the formatting on the first two lines. Could you > please redo the entire copyright header for all of these files? (You > can look at any existing test for reference and you'll see the > difference.) > >>>> 2. checkMethod(): >>>> Doesn't appear to be used anywhere. Do you want to keep this? If you >>>> do, could you add a comment to explain the parameters? >>>> >>>> Also, in general for the rest of the methods, there are a lot of >>>> parameters noted with the @param tag. If you want to leave those >>>> javadoc style comments in, could you please describe the params? >>>> >>> X509Test is used by many other tests ( appart from these tests as part >>> of the webrev). I will add comment and description for the params. >>> > > Minor detail, but there is an extra space in line 53 and 55 of > X509Test. Could you please remove them? > > Otherwise, looks good to me, but you'll still need an official Reviewer. > > Thanks, > Jason > >>>> 3. equals() and assertByteArray() both seem to be >>>> "assertEquals()"-style methods, but they are named a bit differently. >>>> could you make the naming consistent? For example, maybe assertEquals >>>> / assertByteArrayEquals. >>>> >>> Yes it make sense. I will make the necessary changes . >>> >>> 4. getElementesTest() should probably read getElementsTest(). You use >>> this method in IssuerAlternativeNameExtensionTest.java, by the way. >>> >>> typo needs to be fixed. >>> >>> Thanks, >>> Raghu >>>> Otherwise, I think the tests look good to me, but again, I'm not a >>>> Reviewer, so you still need an official review. >>>> >>>> Thanks, >>>> Jason >>>> >>>> >>>> >>>> On 08/25/2014 03:59 AM, raghu k.nair wrote: >>>>> Hi Vincent / Jason, >>>>> Could you please help in reviewing the following test. >>>>> >>>>> Thanks, >>>>> Raghu Nair >>>>> >>>>> On 8/12/2014 10:28 AM, raghu k.nair wrote: >>>>>> Hello, >>>>>> Please review the tests for sun.security.x509 classes. >>>>>> These cover tests for GeneralName, GeneralNames, GeneralSubtree, >>>>>> GeneralSubtrees, IPAddressName and IssuerAlternativeNameExtension. >>>>>> >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~rhalade/8049039/webrev.00/ >>>>>> >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8049039 >>>>>> >>>>>> Thanks, >>>>>> Raghu Nair >>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Fri Sep 5 01:21:16 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 05 Sep 2014 09:21:16 +0800 Subject: JEP Review Request: OCSP Stapling for TLS In-Reply-To: <20140903024704.000038c7.ecki@zusammenkunft.net> References: <54063381.4020306@oracle.com> <20140903024704.000038c7.ecki@zusammenkunft.net> Message-ID: <5409100C.8090203@oracle.com> On 9/3/2014 8:47 AM, Bernd Eckenfels wrote: > Also I can understand the restriction to not require API changes I > wonder if this is a good idea. I will come back to that later, but just > a prelimiary question: will a TrustManager (or HostnameVerifier) be > able to actually see and work on the OCSP response - maybe via > getHandshakeSession()? The configuration and validation of OCSP should be delegated to PKIX cert path building and validation processes. Customized the PKIXRevocationChecker and PKIXParameters would impact the behavior of JSSE. TrustManager would also honor the PKIX configurations. Xuelei From Alan.Bateman at oracle.com Fri Sep 5 13:58:17 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 05 Sep 2014 14:58:17 +0100 Subject: RFR 8042900: Allow com.sun.security.jgss to be in different module than org.ietf.jgss In-Reply-To: <1B57A59A-C6B8-402E-B02A-B4D81B257ECB@oracle.com> References: <53FEEE2C.7000308@oracle.com> <1B57A59A-C6B8-402E-B02A-B4D81B257ECB@oracle.com> Message-ID: <5409C179.4070607@oracle.com> On 28/08/2014 10:36, Wang Weijun wrote: > Hi Alan > > Thanks for the review. All suggestions accepted. > > Change for S4U2selfGSS is not related and can be reverted. > I've looked through webrev.01 and you've addressed all my comments. A small item but the new JgssExtender.java needs a copyright header before you push it. -Alan. From jason.uh at oracle.com Fri Sep 5 20:28:24 2014 From: jason.uh at oracle.com (Jason Uh) Date: Fri, 05 Sep 2014 13:28:24 -0700 Subject: Review request for CR 8049039 Need new tests for sun.securiy.x509 classes In-Reply-To: <54086F1E.6010603@oracle.com> References: <53E99EF2.8010900@oracle.com> <53FAECEE.3010007@oracle.com> <53FCCCE6.3080701@oracle.com> <53FD5B06.2020607@oracle.com> <53FDFA94.6050607@oracle.com> <540617B0.7010801@oracle.com> <54086F1E.6010603@oracle.com> Message-ID: <540A1CE8.4060905@oracle.com> Hi Raghu, Formatting looks good, but one last thing about the copyright headers. I noticed that in lines 7-9, you have the lines * ... Oracle designates this * particular file as subject to the "Classpath" exception as provided * by Oracle in the LICENSE file that accompanied this code. Can you remove that sentence? In general, I think the license that includes those lines is meant for source files, not for test files. If you look at other tests, you'll see that this final sentence isn't there. Thanks, Jason On 9/4/14 6:54 AM, raghu k.nair wrote: > Hi Jason, > Please review the updated webrev . I have addressed your comments. > http://cr.openjdk.java.net/~tyan/raghu/8049039/webrev03/ > > > Thanks, > Raghu > On 9/3/2014 12:47 AM, Jason Uh wrote: >> On 8/27/14 8:34 AM, raghu k.nair wrote: >>> Hi Vincent / Jason, >>> Please review the updated webrev based on Jason's comments. >>> webrev: http://cr.openjdk.java.net/~tyan/raghu/8049039/webrev02/ >>> >>> >>> Thanks, >>> Raghu Nair >>> On 8/27/2014 9:43 AM, raghu k.nair wrote: >>>> Hi Jason, >>>> Thanks for your review comments. >>>> On 8/26/2014 11:37 PM, Jason Uh wrote: >>>>> Hi Raghu, >>>>> >>>>> I'm not an official Reviewer, but I have some comments, mostly about >>>>> X509Test.java. >>>>> >>>>> 1. I'm not sure if this matters, but the formatting of your copyright >>>>> header is a little strange. The text appears to be correct, but the >>>>> line breaks occur at non-standard places. If you look at any other >>>>> file, the first couple lines would look like this: >>>>> >>>>> /* >>>>> * Copyright (c) 2014, Oracle and/or its affiliates. All rights >>>>> reserved. >>>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>> >>>>> Again, not sure how important this is, but it applies to every file >>>>> in the webrev. I'd suggest changing them. >>>>> >>>> This happened due to default formatting by Netbeans . I will correct >>>> it. >> >> I was actually showing the issue with the entire copyright header by >> quoting just the beginning. Sorry if I wasn't clear, but it looks like >> you only corrected the formatting on the first two lines. Could you >> please redo the entire copyright header for all of these files? (You >> can look at any existing test for reference and you'll see the >> difference.) >> >>>>> 2. checkMethod(): >>>>> Doesn't appear to be used anywhere. Do you want to keep this? If you >>>>> do, could you add a comment to explain the parameters? >>>>> >>>>> Also, in general for the rest of the methods, there are a lot of >>>>> parameters noted with the @param tag. If you want to leave those >>>>> javadoc style comments in, could you please describe the params? >>>>> >>>> X509Test is used by many other tests ( appart from these tests as part >>>> of the webrev). I will add comment and description for the params. >>>> >> >> Minor detail, but there is an extra space in line 53 and 55 of >> X509Test. Could you please remove them? >> >> Otherwise, looks good to me, but you'll still need an official Reviewer. >> >> Thanks, >> Jason >> >>>>> 3. equals() and assertByteArray() both seem to be >>>>> "assertEquals()"-style methods, but they are named a bit differently. >>>>> could you make the naming consistent? For example, maybe assertEquals >>>>> / assertByteArrayEquals. >>>>> >>>> Yes it make sense. I will make the necessary changes . >>>> >>>> 4. getElementesTest() should probably read getElementsTest(). You use >>>> this method in IssuerAlternativeNameExtensionTest.java, by the way. >>>> >>>> typo needs to be fixed. >>>> >>>> Thanks, >>>> Raghu >>>>> Otherwise, I think the tests look good to me, but again, I'm not a >>>>> Reviewer, so you still need an official review. >>>>> >>>>> Thanks, >>>>> Jason >>>>> >>>>> >>>>> >>>>> On 08/25/2014 03:59 AM, raghu k.nair wrote: >>>>>> Hi Vincent / Jason, >>>>>> Could you please help in reviewing the following test. >>>>>> >>>>>> Thanks, >>>>>> Raghu Nair >>>>>> >>>>>> On 8/12/2014 10:28 AM, raghu k.nair wrote: >>>>>>> Hello, >>>>>>> Please review the tests for sun.security.x509 classes. >>>>>>> These cover tests for GeneralName, GeneralNames, GeneralSubtree, >>>>>>> GeneralSubtrees, IPAddressName and IssuerAlternativeNameExtension. >>>>>>> >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~rhalade/8049039/webrev.00/ >>>>>>> >>>>>>> Bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049039 >>>>>>> >>>>>>> Thanks, >>>>>>> Raghu Nair >>>>>> >>>> >>> >> > From raghu.k.nair at oracle.com Sat Sep 6 04:05:52 2014 From: raghu.k.nair at oracle.com (raghu k.nair) Date: Sat, 06 Sep 2014 09:35:52 +0530 Subject: Review request for CR 8049039 Need new tests for sun.securiy.x509 classes In-Reply-To: <540A1CE8.4060905@oracle.com> References: <53E99EF2.8010900@oracle.com> <53FAECEE.3010007@oracle.com> <53FCCCE6.3080701@oracle.com> <53FD5B06.2020607@oracle.com> <53FDFA94.6050607@oracle.com> <540617B0.7010801@oracle.com> <54086F1E.6010603@oracle.com> <540A1CE8.4060905@oracle.com> Message-ID: <540A8820.5080301@oracle.com> Hi Jason, Yes you are right. I will remove those lines from the code. Vincent, Could you please give an official node to commit these changes ? Thanks, Raghu On 9/6/2014 1:58 AM, Jason Uh wrote: > Hi Raghu, > > Formatting looks good, but one last thing about the copyright headers. > I noticed that in lines 7-9, you have the lines > > * ... Oracle designates this > * particular file as subject to the "Classpath" exception as provided > * by Oracle in the LICENSE file that accompanied this code. > > Can you remove that sentence? In general, I think the license that > includes those lines is meant for source files, not for test files. If > you look at other tests, you'll see that this final sentence isn't there. > > Thanks, > Jason > > On 9/4/14 6:54 AM, raghu k.nair wrote: >> Hi Jason, >> Please review the updated webrev . I have addressed your comments. >> http://cr.openjdk.java.net/~tyan/raghu/8049039/webrev03/ >> >> >> Thanks, >> Raghu >> On 9/3/2014 12:47 AM, Jason Uh wrote: >>> On 8/27/14 8:34 AM, raghu k.nair wrote: >>>> Hi Vincent / Jason, >>>> Please review the updated webrev based on Jason's comments. >>>> webrev: http://cr.openjdk.java.net/~tyan/raghu/8049039/webrev02/ >>>> >>>> >>>> Thanks, >>>> Raghu Nair >>>> On 8/27/2014 9:43 AM, raghu k.nair wrote: >>>>> Hi Jason, >>>>> Thanks for your review comments. >>>>> On 8/26/2014 11:37 PM, Jason Uh wrote: >>>>>> Hi Raghu, >>>>>> >>>>>> I'm not an official Reviewer, but I have some comments, mostly about >>>>>> X509Test.java. >>>>>> >>>>>> 1. I'm not sure if this matters, but the formatting of your >>>>>> copyright >>>>>> header is a little strange. The text appears to be correct, but the >>>>>> line breaks occur at non-standard places. If you look at any other >>>>>> file, the first couple lines would look like this: >>>>>> >>>>>> /* >>>>>> * Copyright (c) 2014, Oracle and/or its affiliates. All rights >>>>>> reserved. >>>>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>>> >>>>>> Again, not sure how important this is, but it applies to every file >>>>>> in the webrev. I'd suggest changing them. >>>>>> >>>>> This happened due to default formatting by Netbeans . I will correct >>>>> it. >>> >>> I was actually showing the issue with the entire copyright header by >>> quoting just the beginning. Sorry if I wasn't clear, but it looks like >>> you only corrected the formatting on the first two lines. Could you >>> please redo the entire copyright header for all of these files? (You >>> can look at any existing test for reference and you'll see the >>> difference.) >>> >>>>>> 2. checkMethod(): >>>>>> Doesn't appear to be used anywhere. Do you want to keep this? If you >>>>>> do, could you add a comment to explain the parameters? >>>>>> >>>>>> Also, in general for the rest of the methods, there are a lot of >>>>>> parameters noted with the @param tag. If you want to leave those >>>>>> javadoc style comments in, could you please describe the params? >>>>>> >>>>> X509Test is used by many other tests ( appart from these tests as >>>>> part >>>>> of the webrev). I will add comment and description for the params. >>>>> >>> >>> Minor detail, but there is an extra space in line 53 and 55 of >>> X509Test. Could you please remove them? >>> >>> Otherwise, looks good to me, but you'll still need an official >>> Reviewer. >>> >>> Thanks, >>> Jason >>> >>>>>> 3. equals() and assertByteArray() both seem to be >>>>>> "assertEquals()"-style methods, but they are named a bit >>>>>> differently. >>>>>> could you make the naming consistent? For example, maybe >>>>>> assertEquals >>>>>> / assertByteArrayEquals. >>>>>> >>>>> Yes it make sense. I will make the necessary changes . >>>>> >>>>> 4. getElementesTest() should probably read getElementsTest(). You use >>>>> this method in IssuerAlternativeNameExtensionTest.java, by the way. >>>>> >>>>> typo needs to be fixed. >>>>> >>>>> Thanks, >>>>> Raghu >>>>>> Otherwise, I think the tests look good to me, but again, I'm not a >>>>>> Reviewer, so you still need an official review. >>>>>> >>>>>> Thanks, >>>>>> Jason >>>>>> >>>>>> >>>>>> >>>>>> On 08/25/2014 03:59 AM, raghu k.nair wrote: >>>>>>> Hi Vincent / Jason, >>>>>>> Could you please help in reviewing the following test. >>>>>>> >>>>>>> Thanks, >>>>>>> Raghu Nair >>>>>>> >>>>>>> On 8/12/2014 10:28 AM, raghu k.nair wrote: >>>>>>>> Hello, >>>>>>>> Please review the tests for sun.security.x509 classes. >>>>>>>> These cover tests for GeneralName, GeneralNames, GeneralSubtree, >>>>>>>> GeneralSubtrees, IPAddressName and IssuerAlternativeNameExtension. >>>>>>>> >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~rhalade/8049039/webrev.00/ >>>>>>>> >>>>>>>> Bug: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049039 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Raghu Nair >>>>>>> >>>>> >>>> >>> >> > From valerie.peng at oracle.com Mon Sep 8 22:25:17 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 08 Sep 2014 15:25:17 -0700 Subject: RFR 8042900: Allow com.sun.security.jgss to be in different module than org.ietf.jgss In-Reply-To: <5402818F.5030405@oracle.com> References: <53FEEE2C.7000308@oracle.com> <5402818F.5030405@oracle.com> Message-ID: <540E2CCD.7070509@oracle.com> Max, Mostly look fine. Just some comments, questions (see below): 1) line 71 - 76 was done in Krb5Context.java. Is it really necessary to move it here? I don't see a reason to. 1) line 1435, the cloning is removed? I didn't see a corresponding clone being done in the caller, e.g. ExtendedGSSContext. 1) the class description mentioned the registration process is hardcoded in GSSManagerImpl. But it looks to me that it's actually done by the com.sun.security.jgss.Extender class? 2) do you think we should require permissions for calls to set/getExtender()? 1) line 364: move it inside the if-block? Seems no value calling xstatus() when x is null. 2) line 401: move it inside the if-block? Since if x is null, then there is no output following this println() call. Thanks, Valerie On 8/30/2014 6:59 PM, Weijun Wang wrote: > Webrev updated at > > http://cr.openjdk.java.net/~weijun/8042900/webrev.01/ > > as per Alan's suggestions. > > Can anyone in the security team take a look? > > Thanks > Max > From zaiyao.liu at oracle.com Tue Sep 9 02:47:19 2014 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Tue, 09 Sep 2014 10:47:19 +0800 Subject: [JDK-9] RFR: 8048607: Implement key generation tests In-Reply-To: <53F6F9B4.6040206@oracle.com> References: <53D5F8AD.2060804@oracle.com> <53DB0509.3000109@oracle.com> <53F6F9B4.6040206@oracle.com> Message-ID: <540E6A37.3070607@oracle.com> Hi Xuelei, Can you help to review this test? JDK Issue: https://bugs.openjdk.java.net/browse/JDK-8048607 Webrev: http://cr.openjdk.java.net/~tyan/kevin/JDK-8048607/webrev01/ Thanks Kevin ? 2014/8/22 16:05, zaiyao liu ??: > May I request you to review 1 new test to be added forkey generation algorithms. New test are added to address following: > - Generate a secret key using key generator for specified algorithm, > retrieve its value, then verify the parity of that key. > > JDK Issue: https://bugs.openjdk.java.net/browse/JDK-8048607 > Webrev: http://cr.openjdk.java.net/~tyan/kevin/JDK-8048607/webrev01/ > > Thanks, > > Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Sep 9 10:45:25 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 9 Sep 2014 18:45:25 +0800 Subject: RFR 8042900: Allow com.sun.security.jgss to be in different module than org.ietf.jgss In-Reply-To: <540E2CCD.7070509@oracle.com> References: <53FEEE2C.7000308@oracle.com> <5402818F.5030405@oracle.com> <540E2CCD.7070509@oracle.com> Message-ID: On Sep 9, 2014, at 6:25, Valerie Peng wrote: > Max, > > Mostly look fine. Just some comments, questions (see below): > > > 1) line 71 - 76 was done in Krb5Context.java. Is it really necessary to move it here? I don't see a reason to. You are right. I thought KerberosCredMessage is a com.sun.security.jgss class but actually it's in javax.security.auth.kerberos. > > > 1) line 1435, the cloning is removed? I didn't see a corresponding clone being done in the caller, e.g. ExtendedGSSContext. Will add it back. > > > 1) the class description mentioned the registration process is hardcoded in GSSManagerImpl. But it looks to me that it's actually done by the com.sun.security.jgss.Extender class? It is done inside Extender. I meant the registration is triggered in GSSManagerImpl using Class.forName(). Will change the words. > 2) do you think we should require permissions for calls to set/getExtender()? The method is defined in a sun.security.jgss class so I guess we don't need a permission. > > > 1) line 364: move it inside the if-block? Seems no value calling xstatus() when x is null. Correct. > 2) line 401: move it inside the if-block? Since if x is null, then there is no output following this println() call. No block needed if I move line 364 into if-block. Thanks Max > > Thanks, > Valerie > > On 8/30/2014 6:59 PM, Weijun Wang wrote: >> Webrev updated at >> >> http://cr.openjdk.java.net/~weijun/8042900/webrev.01/ >> >> as per Alan's suggestions. >> >> Can anyone in the security team take a look? >> >> Thanks >> Max >> From weijun.wang at oracle.com Tue Sep 9 10:53:39 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 9 Sep 2014 18:53:39 +0800 Subject: RFR 8042900: Allow com.sun.security.jgss to be in different module than org.ietf.jgss In-Reply-To: References: <53FEEE2C.7000308@oracle.com> <5402818F.5030405@oracle.com> <540E2CCD.7070509@oracle.com> Message-ID: <575B9AD5-C656-4DE0-8133-5D1406A39F68@oracle.com> On Sep 9, 2014, at 18:45, Wang Weijun wrote: >> >> 1) line 364: move it inside the if-block? Seems no value calling xstatus() when x is null. > > Correct. > >> 2) line 401: move it inside the if-block? Since if x is null, then there is no output following this println() call. > > No block needed if I move line 364 into if-block. Answered too quickly. The xstatus() method is for both ExtendedGSSContext and ExtendedGSSCredential (although no useless info for the latter now). I think I would keep my current code but pull the "if (cred != null)" block out of the "if (x != null)" one. Is that OK? Thanks Max From sean.coffey at oracle.com Tue Sep 9 17:10:18 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 09 Sep 2014 18:10:18 +0100 Subject: RFR(XXS) : 8057813: Alterations to jdk_security3 test target Message-ID: <540F347A.4060207@oracle.com> On some recent JPRT test jobs, I've noticed that the jdk_security3 test target is taking 40+ mins on some systems. Looking closer at test times, I see that sun/security/krb5 tests alone can take ~15-16 mins to run. I'd like to separate those tests out into their own test target (jdk_security4) so that we can better utilize idle clients during JPRT test runs. bug : https://bugs.openjdk.java.net/browse/JDK-8057813 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8057813.jdk9/webrev/ regards, Sean. From sean.mullan at oracle.com Tue Sep 9 18:45:19 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 09 Sep 2014 14:45:19 -0400 Subject: RFR(XXS) : 8057813: Alterations to jdk_security3 test target In-Reply-To: <540F347A.4060207@oracle.com> References: <540F347A.4060207@oracle.com> Message-ID: <540F4ABF.8060100@oracle.com> This seems like a good idea to me. Looks ok to me. --Sean On 09/09/2014 01:10 PM, Se?n Coffey wrote: > On some recent JPRT test jobs, I've noticed that the jdk_security3 test > target is taking 40+ mins on some systems. Looking closer at test times, > I see that sun/security/krb5 tests alone can take ~15-16 mins to run. > I'd like to separate those tests out into their own test target > (jdk_security4) so that we can better utilize idle clients during JPRT > test runs. > > bug : https://bugs.openjdk.java.net/browse/JDK-8057813 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8057813.jdk9/webrev/ > > regards, > Sean. > From valerie.peng at oracle.com Tue Sep 9 22:25:17 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 09 Sep 2014 15:25:17 -0700 Subject: RFR 8042900: Allow com.sun.security.jgss to be in different module than org.ietf.jgss In-Reply-To: <575B9AD5-C656-4DE0-8133-5D1406A39F68@oracle.com> References: <53FEEE2C.7000308@oracle.com> <5402818F.5030405@oracle.com> <540E2CCD.7070509@oracle.com> <575B9AD5-C656-4DE0-8133-5D1406A39F68@oracle.com> Message-ID: <540F7E4D.3070208@oracle.com> Sure, fine with me. Thanks, Valerie On 9/9/2014 3:53 AM, Wang Weijun wrote: > On Sep 9, 2014, at 18:45, Wang Weijun wrote: > >>> >>> 1) line 364: move it inside the if-block? Seems no value calling xstatus() when x is null. >> Correct. >> >>> 2) line 401: move it inside the if-block? Since if x is null, then there is no output following this println() call. >> No block needed if I move line 364 into if-block. > Answered too quickly. > > The xstatus() method is for both ExtendedGSSContext and ExtendedGSSCredential (although no useless info for the latter now). I think I would keep my current code but pull the "if (cred != null)" block out of the "if (x != null)" one. Is that OK? > > Thanks > Max > From bradford.wetmore at oracle.com Tue Sep 9 23:36:18 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 09 Sep 2014 16:36:18 -0700 Subject: RFR(XXS) : 8057813: Alterations to jdk_security3 test target In-Reply-To: <540F4ABF.8060100@oracle.com> References: <540F347A.4060207@oracle.com> <540F4ABF.8060100@oracle.com> Message-ID: <540F8EF2.8030106@oracle.com> I'm not an expert in the JPRT/makefiles for test, but looks good. Brad On 9/9/2014 11:45 AM, Sean Mullan wrote: > This seems like a good idea to me. Looks ok to me. > > --Sean > > On 09/09/2014 01:10 PM, Se?n Coffey wrote: >> On some recent JPRT test jobs, I've noticed that the jdk_security3 test >> target is taking 40+ mins on some systems. Looking closer at test times, >> I see that sun/security/krb5 tests alone can take ~15-16 mins to run. >> I'd like to separate those tests out into their own test target >> (jdk_security4) so that we can better utilize idle clients during JPRT >> test runs. >> >> bug : https://bugs.openjdk.java.net/browse/JDK-8057813 >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8057813.jdk9/webrev/ >> >> regards, >> Sean. >> From amanda.jiang at oracle.com Wed Sep 10 00:52:59 2014 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Tue, 09 Sep 2014 17:52:59 -0700 Subject: Please review CR 8049021 Add smartcardio tests with APDU buffer Message-ID: <540FA0EB.2090105@oracle.com> Hello, Please help to review the changeset below, new tests are added for javax.smartcardio.CommandAPDU, javax.smartcardio.ResponseAPDU and javax.smartcardio.TerminalFactorySpi. Bug - https://bugs.openjdk.java.net/browse/JDK-8049021 Webrev - http://cr.openjdk.java.net/~tyan/amandaj/8049021/webrev00/ Thanks, Amanda From xuelei.fan at oracle.com Wed Sep 10 01:28:55 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 10 Sep 2014 09:28:55 +0800 Subject: RFR(XXS) : 8057813: Alterations to jdk_security3 test target In-Reply-To: <540F347A.4060207@oracle.com> References: <540F347A.4060207@oracle.com> Message-ID: <540FA957.5000102@oracle.com> Good idea and look fine to me. Thanks, Xuelei On 9/10/2014 1:10 AM, Se?n Coffey wrote: > On some recent JPRT test jobs, I've noticed that the jdk_security3 test > target is taking 40+ mins on some systems. Looking closer at test times, > I see that sun/security/krb5 tests alone can take ~15-16 mins to run. > I'd like to separate those tests out into their own test target > (jdk_security4) so that we can better utilize idle clients during JPRT > test runs. > > bug : https://bugs.openjdk.java.net/browse/JDK-8057813 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8057813.jdk9/webrev/ > > regards, > Sean. > From zaiyao.liu at oracle.com Wed Sep 10 02:29:33 2014 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Wed, 10 Sep 2014 10:29:33 +0800 Subject: RFR JDK-8049432: Need new tests for testing TLS property jdk.tls.client.protocols with various protocols and values Message-ID: <540FB78D.2070101@oracle.com> Hi All, Please review the code change,the purpose of this fix is to address following: -Sets the property jdk.tls.client.protocols to one of this protocols:SSLv3,TLSv1,TLSv1,TLSv1.1,TLSv1.2 and TLSV(invalid) or removes this property (if any),then validates the default, supported and current protocols in the SSLContext. Webrev: http://cr.openjdk.java.net/~tyan/kevin/JDK-8049432/webrev01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8049432 Thanks Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Sep 10 02:53:19 2014 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 10 Sep 2014 10:53:19 +0800 Subject: RFR(XXS) : 8057813: Alterations to jdk_security3 test target In-Reply-To: <540F347A.4060207@oracle.com> References: <540F347A.4060207@oracle.com> Message-ID: <540FBD1F.5000308@oracle.com> I'd like other jgss/krb5-related tests also there: test/sun/security/krb5 \ test/sun/security/jgss \ test/com/sun/security/jgss \ test/javax/security/auth/kerberos \ Is that OK? Thanks Max On 9/10/2014 1:10, Se?n Coffey wrote: > On some recent JPRT test jobs, I've noticed that the jdk_security3 test > target is taking 40+ mins on some systems. Looking closer at test times, > I see that sun/security/krb5 tests alone can take ~15-16 mins to run. > I'd like to separate those tests out into their own test target > (jdk_security4) so that we can better utilize idle clients during JPRT > test runs. > > bug : https://bugs.openjdk.java.net/browse/JDK-8057813 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8057813.jdk9/webrev/ > > regards, > Sean. > From sean.coffey at oracle.com Wed Sep 10 12:02:25 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Wed, 10 Sep 2014 13:02:25 +0100 Subject: RFR(XXS) : 8057813: Alterations to jdk_security3 test target In-Reply-To: <540FBD1F.5000308@oracle.com> References: <540F347A.4060207@oracle.com> <540FBD1F.5000308@oracle.com> Message-ID: <54103DD1.2070101@oracle.com> Sounds reasonable Max. I've made those changes and sec3 and sec4 test groups seem to be averaging out to ~15 mins each now. http://cr.openjdk.java.net/~coffeys/webrev.8057813.jdk9.v2/webrev/ Regards, Sean. On 10/09/14 03:53, Weijun Wang wrote: > I'd like other jgss/krb5-related tests also there: > > test/sun/security/krb5 \ > test/sun/security/jgss \ > test/com/sun/security/jgss \ > test/javax/security/auth/kerberos \ > > Is that OK? > > Thanks > Max > > On 9/10/2014 1:10, Se?n Coffey wrote: >> On some recent JPRT test jobs, I've noticed that the jdk_security3 test >> target is taking 40+ mins on some systems. Looking closer at test times, >> I see that sun/security/krb5 tests alone can take ~15-16 mins to run. >> I'd like to separate those tests out into their own test target >> (jdk_security4) so that we can better utilize idle clients during JPRT >> test runs. >> >> bug : https://bugs.openjdk.java.net/browse/JDK-8057813 >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8057813.jdk9/webrev/ >> >> regards, >> Sean. >> From weijun.wang at oracle.com Wed Sep 10 15:09:11 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 10 Sep 2014 23:09:11 +0800 Subject: RFR(XXS) : 8057813: Alterations to jdk_security3 test target In-Reply-To: <54103DD1.2070101@oracle.com> References: <540F347A.4060207@oracle.com> <540FBD1F.5000308@oracle.com> <54103DD1.2070101@oracle.com> Message-ID: The change looks good. Thanks Max On Sep 10, 2014, at 20:02, Se?n Coffey wrote: > Sounds reasonable Max. I've made those changes and sec3 and sec4 test groups seem to be averaging out to ~15 mins each now. > > http://cr.openjdk.java.net/~coffeys/webrev.8057813.jdk9.v2/webrev/ > > Regards, > Sean. From sean.mullan at oracle.com Wed Sep 10 15:19:26 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 10 Sep 2014 11:19:26 -0400 Subject: RFR(XXS) : 8057813: Alterations to jdk_security3 test target In-Reply-To: References: <540F347A.4060207@oracle.com> <540FBD1F.5000308@oracle.com> <54103DD1.2070101@oracle.com> Message-ID: <54106BFE.4010508@oracle.com> On 09/10/2014 11:09 AM, Wang Weijun wrote: > The change looks good. Ditto. --Sean > > Thanks > Max > > On Sep 10, 2014, at 20:02, Se?n Coffey wrote: > >> Sounds reasonable Max. I've made those changes and sec3 and sec4 test groups seem to be averaging out to ~15 mins each now. >> >> http://cr.openjdk.java.net/~coffeys/webrev.8057813.jdk9.v2/webrev/ >> >> Regards, >> Sean. > From valerie.peng at oracle.com Wed Sep 10 16:28:19 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 10 Sep 2014 09:28:19 -0700 Subject: RFR 8039898: sunpkcs11-solaris.cfg should be in solaris specific directory Message-ID: <54107C23.2010809@oracle.com> Could someone please review this build related change for moving sunpkcs11-solaris.cfg file to the pkcs11 module? Webrev: http://cr.openjdk.java.net/~valeriep/8039898/webrev.00/ Thanks, Valerie From sean.coffey at oracle.com Wed Sep 10 17:06:41 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Wed, 10 Sep 2014 18:06:41 +0100 Subject: RFR : 8052406: SSLv2Hello protocol may be filter out unexpectedly and 8057813: Alterations to jdk_security3 test target Message-ID: <54108521.90506@oracle.com> looking to push two fixes to jdk8u : 8052406: SSLv2Hello protocol may be filter out unexpectedly This is a straight forward backport of the JDK 9. The testcase did require one minor config adjustment : pathToStores value updated to : "../../../../sun/security/ssl/etc"; 8057813: Alterations to jdk_security3 test target Continuation of the JDK 9 fix. I noticed that javax/net tests are not part of the jdk_security groups and have added them to jdk_security3 like that seen in JDK 9. webrev: http://cr.openjdk.java.net/~coffeys/webrev.8057813.8u/webrev/ regards, Sean. From jason.uh at oracle.com Wed Sep 10 23:14:11 2014 From: jason.uh at oracle.com (Jason Uh) Date: Wed, 10 Sep 2014 16:14:11 -0700 Subject: [9] RFR: 8047223: Add algorithm parameter to EncodedKeySpec class and its two subclasses Message-ID: <5410DB43.9040306@oracle.com> Please review this change, which adds a constructor taking an algorithm name parameter to EncodedKeySpec and its subclasses. This allows the algorithm name to be retrieved in subsequent calls to the EncodedKeySpec. webrev: http://cr.openjdk.java.net/~juh/8047223/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8047223 Thanks, Jason From erik.joelsson at oracle.com Thu Sep 11 08:51:56 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 11 Sep 2014 10:51:56 +0200 Subject: RFR 8039898: sunpkcs11-solaris.cfg should be in solaris specific directory In-Reply-To: <54107C23.2010809@oracle.com> References: <54107C23.2010809@oracle.com> Message-ID: <541162AC.2020609@oracle.com> Change looks good to me. /Erik On 2014-09-10 18:28, Valerie Peng wrote: > > Could someone please review this build related change for moving > sunpkcs11-solaris.cfg file to the pkcs11 module? > > Webrev: http://cr.openjdk.java.net/~valeriep/8039898/webrev.00/ > > Thanks, > Valerie From magnus.ihse.bursie at oracle.com Thu Sep 11 09:38:07 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 11 Sep 2014 11:38:07 +0200 Subject: RFR 8039898: sunpkcs11-solaris.cfg should be in solaris specific directory In-Reply-To: <54107C23.2010809@oracle.com> References: <54107C23.2010809@oracle.com> Message-ID: <54116D7F.4010503@oracle.com> On 2014-09-10 18:28, Valerie Peng wrote: > > Could someone please review this build related change for moving > sunpkcs11-solaris.cfg file to the pkcs11 module? > > Webrev: http://cr.openjdk.java.net/~valeriep/8039898/webrev.00/ Looks good. However, I'll give the same feedback to you as I just recently did to Phil: The webrev shows the file as being moved outside the control of mercurial. That is, if you do "hg mv" to move the file, the history of the file will be kept intact. Otherwise it will look like a new file in the repo. (Sometimes this doesn't show up properly in the webrev, apologies if you already did this.) /Magnus From Alan.Bateman at oracle.com Thu Sep 11 09:51:12 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 Sep 2014 10:51:12 +0100 Subject: RFR 8039898: sunpkcs11-solaris.cfg should be in solaris specific directory In-Reply-To: <54116D7F.4010503@oracle.com> References: <54107C23.2010809@oracle.com> <54116D7F.4010503@oracle.com> Message-ID: <54117090.9020102@oracle.com> On 11/09/2014 10:38, Magnus Ihse Bursie wrote: > On 2014-09-10 18:28, Valerie Peng wrote: >> >> Could someone please review this build related change for moving >> sunpkcs11-solaris.cfg file to the pkcs11 module? >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8039898/webrev.00/ > > Looks good. However, I'll give the same feedback to you as I just > recently did to Phil: > > The webrev shows the file as being moved outside the control of > mercurial. That is, if you do "hg mv" to move the file, the history of > the file will be kept intact. Otherwise it will look like a new file > in the repo. (Sometimes this doesn't show up properly in the webrev, > apologies if you already did this.) For webrev then I think it depends on whether the changes have been committed or not. If you do a hg mv and then webrev -N before committing then it will show as a move. If you commit and then generate the webrev then it looks like a delete + new file. Maybe there is an opportunity for someone to see if webrev can be made a bit smarter. -Alan From magnus.ihse.bursie at oracle.com Thu Sep 11 10:42:42 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 11 Sep 2014 12:42:42 +0200 Subject: RFR 8039898: sunpkcs11-solaris.cfg should be in solaris specific directory In-Reply-To: <54117090.9020102@oracle.com> References: <54107C23.2010809@oracle.com> <54116D7F.4010503@oracle.com> <54117090.9020102@oracle.com> Message-ID: <54117CA2.6020603@oracle.com> On 2014-09-11 11:51, Alan Bateman wrote: > On 11/09/2014 10:38, Magnus Ihse Bursie wrote: >> The webrev shows the file as being moved outside the control of >> mercurial. That is, if you do "hg mv" to move the file, the history >> of the file will be kept intact. Otherwise it will look like a new >> file in the repo. (Sometimes this doesn't show up properly in the >> webrev, apologies if you already did this.) > For webrev then I think it depends on whether the changes have been > committed or not. If you do a hg mv and then webrev -N before > committing then it will show as a move. If you commit and then > generate the webrev then it looks like a delete + new file. Maybe > there is an opportunity for someone to see if webrev can be made a bit > smarter. Aha, that's the reason. I know it "usually" work but not always, but I have not seen the pattern. (I usually create pre-checkin webrevs.) /Magnus From darran.lofthouse at jboss.com Thu Sep 11 15:48:04 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 11 Sep 2014 16:48:04 +0100 Subject: Kerberos Enc Type Expectations for delegated credential within AP_REQ message. Message-ID: <5411C434.6010301@jboss.com> Hello there, I am currently attempting to get to the bottom of some interoperability issues regarding the handling of Kerberos AP_REQ messages that contain a delegated credential. Before I start raising bug reports I wanted to pass it through you guys first in case there is a strong opposition to this being raised as a Java bug. The kind of error messages I am seeing are: - http://fpaste.org/132824/ http://fpaste.org/132825/ In short the class 'sun.security.jgss.krb5.InitialToken' is making an assumption as to if the enc type for the delegated credential is NULL based on the enc type of the session key. If I follow through the call to the constructor in 'sun.security.krb5.KrbCred' there is even a comment saying the key will always be NULL even though that is no longer true so it looks like this block of code has been modified at some point to start to support an EncryptionKey. The reason this is a problem is that I have Mac OS clients that will always use NULL regardless of the algorithm for the session key, I also have Linux clients that will use the session key regardless of the algorithm. After researching this I am yet to find anything that tells me the algorithm for the session key should affect if the credential is encrypted which is why I am questioning if that is a valid approach. My proposal would be to update the code within InitialToken to skip trying to decide to use EncryptionKey.NULL_KEY, instead just keep the try / catch block for the key and sub-key. Within sun.security.krb5.KrbCred just before decrypt is called it would be possible to check the encType and check for the NULL type and substitute in the NULL_KEY at that point. Where the delegated credential is encrypted the existing checks would still apply to identify any encType mis-match - so overall this change would be to use the EncryptionKey.NULL_KEY only when absolutely confirmed it is required. I am happy to create a Jira issue and e-mail over a proposed patch but as I say I just wanted to run this by you guys before I start down that patch. Regards, Darran Lofthouse. From valerie.peng at oracle.com Thu Sep 11 16:45:29 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 11 Sep 2014 09:45:29 -0700 Subject: RFR 8039898: sunpkcs11-solaris.cfg should be in solaris specific directory In-Reply-To: <54117CA2.6020603@oracle.com> References: <54107C23.2010809@oracle.com> <54116D7F.4010503@oracle.com> <54117090.9020102@oracle.com> <54117CA2.6020603@oracle.com> Message-ID: <5411D1A9.8070609@oracle.com> Thanks all for the review and tips on webrev. I have re-generated the webrev following all the tips... Thanks again, Valerie On 9/11/2014 3:42 AM, Magnus Ihse Bursie wrote: > On 2014-09-11 11:51, Alan Bateman wrote: >> On 11/09/2014 10:38, Magnus Ihse Bursie wrote: >>> The webrev shows the file as being moved outside the control of >>> mercurial. That is, if you do "hg mv" to move the file, the history >>> of the file will be kept intact. Otherwise it will look like a new >>> file in the repo. (Sometimes this doesn't show up properly in the >>> webrev, apologies if you already did this.) >> For webrev then I think it depends on whether the changes have been >> committed or not. If you do a hg mv and then webrev -N before >> committing then it will show as a move. If you commit and then >> generate the webrev then it looks like a delete + new file. Maybe >> there is an opportunity for someone to see if webrev can be made a >> bit smarter. > Aha, that's the reason. I know it "usually" work but not always, but I > have not seen the pattern. (I usually create pre-checkin webrevs.) > > /Magnus From raghu.k.nair at oracle.com Thu Sep 11 16:58:10 2014 From: raghu.k.nair at oracle.com (raghu k.nair) Date: Thu, 11 Sep 2014 22:28:10 +0530 Subject: Review request for CR 8049039 Need new tests for sun.securiy.x509 classes In-Reply-To: <540A1CE8.4060905@oracle.com> References: <53E99EF2.8010900@oracle.com> <53FAECEE.3010007@oracle.com> <53FCCCE6.3080701@oracle.com> <53FD5B06.2020607@oracle.com> <53FDFA94.6050607@oracle.com> <540617B0.7010801@oracle.com> <54086F1E.6010603@oracle.com> <540A1CE8.4060905@oracle.com> Message-ID: <5411D4A2.9050709@oracle.com> Hi Jason, I have removed those lines from copyright headers. Here is the updated webrev. http://cr.openjdk.java.net/~rhalade/8049039/webrev.04/ Thanks, Raghu Nair On 9/6/2014 1:58 AM, Jason Uh wrote: > Hi Raghu, > > Formatting looks good, but one last thing about the copyright headers. > I noticed that in lines 7-9, you have the lines > > * ... Oracle designates this > * particular file as subject to the "Classpath" exception as provided > * by Oracle in the LICENSE file that accompanied this code. > > Can you remove that sentence? In general, I think the license that > includes those lines is meant for source files, not for test files. If > you look at other tests, you'll see that this final sentence isn't there. > > Thanks, > Jason > > On 9/4/14 6:54 AM, raghu k.nair wrote: >> Hi Jason, >> Please review the updated webrev . I have addressed your comments. >> http://cr.openjdk.java.net/~tyan/raghu/8049039/webrev03/ >> >> >> Thanks, >> Raghu >> On 9/3/2014 12:47 AM, Jason Uh wrote: >>> On 8/27/14 8:34 AM, raghu k.nair wrote: >>>> Hi Vincent / Jason, >>>> Please review the updated webrev based on Jason's comments. >>>> webrev: http://cr.openjdk.java.net/~tyan/raghu/8049039/webrev02/ >>>> >>>> >>>> Thanks, >>>> Raghu Nair >>>> On 8/27/2014 9:43 AM, raghu k.nair wrote: >>>>> Hi Jason, >>>>> Thanks for your review comments. >>>>> On 8/26/2014 11:37 PM, Jason Uh wrote: >>>>>> Hi Raghu, >>>>>> >>>>>> I'm not an official Reviewer, but I have some comments, mostly about >>>>>> X509Test.java. >>>>>> >>>>>> 1. I'm not sure if this matters, but the formatting of your >>>>>> copyright >>>>>> header is a little strange. The text appears to be correct, but the >>>>>> line breaks occur at non-standard places. If you look at any other >>>>>> file, the first couple lines would look like this: >>>>>> >>>>>> /* >>>>>> * Copyright (c) 2014, Oracle and/or its affiliates. All rights >>>>>> reserved. >>>>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>>> >>>>>> Again, not sure how important this is, but it applies to every file >>>>>> in the webrev. I'd suggest changing them. >>>>>> >>>>> This happened due to default formatting by Netbeans . I will correct >>>>> it. >>> >>> I was actually showing the issue with the entire copyright header by >>> quoting just the beginning. Sorry if I wasn't clear, but it looks like >>> you only corrected the formatting on the first two lines. Could you >>> please redo the entire copyright header for all of these files? (You >>> can look at any existing test for reference and you'll see the >>> difference.) >>> >>>>>> 2. checkMethod(): >>>>>> Doesn't appear to be used anywhere. Do you want to keep this? If you >>>>>> do, could you add a comment to explain the parameters? >>>>>> >>>>>> Also, in general for the rest of the methods, there are a lot of >>>>>> parameters noted with the @param tag. If you want to leave those >>>>>> javadoc style comments in, could you please describe the params? >>>>>> >>>>> X509Test is used by many other tests ( appart from these tests as >>>>> part >>>>> of the webrev). I will add comment and description for the params. >>>>> >>> >>> Minor detail, but there is an extra space in line 53 and 55 of >>> X509Test. Could you please remove them? >>> >>> Otherwise, looks good to me, but you'll still need an official >>> Reviewer. >>> >>> Thanks, >>> Jason >>> >>>>>> 3. equals() and assertByteArray() both seem to be >>>>>> "assertEquals()"-style methods, but they are named a bit >>>>>> differently. >>>>>> could you make the naming consistent? For example, maybe >>>>>> assertEquals >>>>>> / assertByteArrayEquals. >>>>>> >>>>> Yes it make sense. I will make the necessary changes . >>>>> >>>>> 4. getElementesTest() should probably read getElementsTest(). You use >>>>> this method in IssuerAlternativeNameExtensionTest.java, by the way. >>>>> >>>>> typo needs to be fixed. >>>>> >>>>> Thanks, >>>>> Raghu >>>>>> Otherwise, I think the tests look good to me, but again, I'm not a >>>>>> Reviewer, so you still need an official review. >>>>>> >>>>>> Thanks, >>>>>> Jason >>>>>> >>>>>> >>>>>> >>>>>> On 08/25/2014 03:59 AM, raghu k.nair wrote: >>>>>>> Hi Vincent / Jason, >>>>>>> Could you please help in reviewing the following test. >>>>>>> >>>>>>> Thanks, >>>>>>> Raghu Nair >>>>>>> >>>>>>> On 8/12/2014 10:28 AM, raghu k.nair wrote: >>>>>>>> Hello, >>>>>>>> Please review the tests for sun.security.x509 classes. >>>>>>>> These cover tests for GeneralName, GeneralNames, GeneralSubtree, >>>>>>>> GeneralSubtrees, IPAddressName and IssuerAlternativeNameExtension. >>>>>>>> >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~rhalade/8049039/webrev.00/ >>>>>>>> >>>>>>>> Bug: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049039 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Raghu Nair >>>>>>> >>>>> >>>> >>> >> > From sean.mullan at oracle.com Thu Sep 11 23:41:28 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 11 Sep 2014 19:41:28 -0400 Subject: [9] RFR: 8047223: Add algorithm parameter to EncodedKeySpec class and its two subclasses In-Reply-To: <5410DB43.9040306@oracle.com> References: <5410DB43.9040306@oracle.com> Message-ID: <54123328.6050305@oracle.com> On line 83 of EncodedKeySpec, call algorithm.isEmpty() instead. Looks good otherwise. --Sean On 09/10/2014 07:14 PM, Jason Uh wrote: > Please review this change, which adds a constructor taking an algorithm > name parameter to EncodedKeySpec and its subclasses. This allows the > algorithm name to be retrieved in subsequent calls to the EncodedKeySpec. > > webrev: http://cr.openjdk.java.net/~juh/8047223/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8047223 > > Thanks, > Jason From vincent.x.ryan at oracle.com Fri Sep 12 15:11:22 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 12 Sep 2014 16:11:22 +0100 Subject: [9] RFR 8056026 Debug security logging should print Provider used for each crypto operation Message-ID: Please review this change to display the JCE provider that has been selected for common crypto operations. This aids troubleshooting crypto applications when a given crypto algorithm is supported by several JCE providers. Some crypto operations delay selecting a provider until they examine the key supplied in the init() method. This fix also accommodates that behaviour. The following crypto operations are supported: Cipher, KeyAgreement, KeyGenerator, KeyPairGenerator, Mac and Signature. To see these new messages, activate JCE provider debugging as normal. For example, % java -Djava.security.debug=provider MySSLClientApp : Provider: Signature.SHA256withRSA verification from: SunRsaSign Provider: Signature.SHA256withRSA verification from: SunRsaSign Provider: Signature.SHA256withRSA verification from: SunRsaSign Provider: Signature.SHA1withDSA verification from: SunPKCS11-Solaris Provider: Signature.SHA1withDSA verification from: SunPKCS11-Solaris Provider: Signature.MD5withRSA verification from: SunPKCS11-Solaris Provider: Signature.MD5withRSA verification from: SunPKCS11-Solaris Provider: Signature.SHA256withRSA verification from: SunRsaSign Provider: Signature.SHA256withRSA verification from: SunRsaSign Provider: KeyPairGenerator.EC from: SunPKCS11-Solaris Provider: Signature.SHA256withRSA verification from: SunRsaSign Provider: Signature.SHA256withRSA verification from: SunRsaSign Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE Provider: KeyGenerator.SunTls12RsaPremasterSecret from: SunJCE Provider: Cipher.RSA/ECB/PKCS1Padding key wrapping from: SunPKCS11-Solaris Provider: KeyGenerator.SunTls12MasterSecret from: SunJCE Provider: KeyGenerator.SunTls12KeyMaterial from: SunJCE Provider: Signature.SHA512withRSA signing from: SunPKCS11-Solaris Provider: KeyGenerator.SunTls12Prf from: SunJCE Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE Provider: KeyGenerator.SunTls12Prf from: SunJCE Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE Provider: KeyGenerator.SunTls12KeyMaterial from: SunJCE Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE Provider: KeyGenerator.SunTls12Prf from: SunJCE Provider: KeyGenerator.SunTls12Prf from: SunJCE Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE : Thanks. Bug: https://bugs.openjdk.java.net/browse/JDK-8056026 Webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Fri Sep 12 16:00:56 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 13 Sep 2014 00:00:56 +0800 Subject: RFR : 8052406: SSLv2Hello protocol may be filter out unexpectedly and 8057813: Alterations to jdk_security3 test target In-Reply-To: <54108521.90506@oracle.com> References: <54108521.90506@oracle.com> Message-ID: <541318B8.3020101@oracle.com> Looks fine to me. Thanks, Xuelei On 9/11/2014 1:06 AM, Se?n Coffey wrote: > looking to push two fixes to jdk8u : > > 8052406: SSLv2Hello protocol may be filter out unexpectedly > > This is a straight forward backport of the JDK 9. The testcase did require > one minor config adjustment : > pathToStores value updated to : "../../../../sun/security/ssl/etc"; > > 8057813: Alterations to jdk_security3 test target > > Continuation of the JDK 9 fix. I noticed that javax/net > tests are not part of the jdk_security groups and have > added them to jdk_security3 like that seen in JDK 9. > > webrev: http://cr.openjdk.java.net/~coffeys/webrev.8057813.8u/webrev/ > > regards, > Sean. From magnus.k.karlsson at msc.se Fri Sep 12 18:59:32 2014 From: magnus.k.karlsson at msc.se (Magnus K Karlsson) Date: Fri, 12 Sep 2014 20:59:32 +0200 Subject: Fwd: RE: Cannot view reference issue JDK-8042756 In-Reply-To: <1f42f1e4-3766-4e8e-aab6-100b7caca866@default> References: <1f42f1e4-3766-4e8e-aab6-100b7caca866@default> Message-ID: Hi, Cannot browse JDK-8042756. Please help, we have this bug in production. So wee need all information we can get. Is there a workaround? Should we switch jdk version? Etc Best Regards, Magnus K Karlsson ---------- Forwarded message ---------- From: "Iris Clark" Date: 12 Sep 2014 20:07 Subject: RE: Cannot view reference issue JDK-8042756 To: "Magnus K Karlsson" , Cc: Hi, Magnus. I see from bug JDK-8049839 that the "Component" is "security-libs". I recommend that you contact security-dev at openjdk.java.net [1] where you'll find the bug's owner and other experts in that area. Thanks, Iris Clark [1]: http://mail.openjdk.java.net/mailman/listinfo/security-dev *From:* Magnus K Karlsson [mailto:magnus.k.karlsson at msc.se] *Sent:* Friday, September 12, 2014 10:59 AM *To:* help at openjdk.java.net *Subject:* Cannot view reference issue JDK-8042756 Hi We have the problem JDK-8049839 ( https://bugs.openjdk.java.net/browse/JDK-8049839) in production and this bug has been closed due to it is a duplicate of JDK-8042756. But I cannot browse JDK-8042756 via https://bugs.openjdk.java.net/browse/ JDK-8042756. Please help, we need information about this bug. -- Best Regards, Magnus K Karlsson Software Architect RHC{E, SA, JA} SC{EA, WCD, JD, JP} Mobile: +46 (0)70 218 00 84 Email: magnus.k.karlsson at msc.se Blog: magnus-k-karlsson.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Sep 15 15:12:57 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 15 Sep 2014 11:12:57 -0400 Subject: [9] RFR 8056026 Debug security logging should print Provider used for each crypto operation In-Reply-To: References: Message-ID: <541701F9.8000609@oracle.com> Can you also add similar log messages for MessageDigest, SecureRandom, and KeyStore? Otherwise looks good. Please add a noreg label. Also the fix is helpful to any platform and not just solaris/sparc so you should change those fields to be generic. --Sean On 09/12/2014 11:11 AM, Vincent Ryan wrote: > > Please review this change to display the JCE provider that has been > selected for common crypto operations. > This aids troubleshooting crypto applications when a given crypto > algorithm is supported by several JCE providers. > Some crypto operations delay selecting a provider until they examine the > key supplied in the init() method. > This fix also accommodates that behaviour. > > The following crypto operations are supported: Cipher, KeyAgreement, > KeyGenerator, KeyPairGenerator, Mac and Signature. > To see these new messages, activate JCE provider debugging as normal. > For example, > > % java -Djava.security.debug=provider MySSLClientApp > : > Provider: Signature.SHA256withRSA verification from: SunRsaSign > Provider: Signature.SHA256withRSA verification from: SunRsaSign > Provider: Signature.SHA256withRSA verification from: SunRsaSign > Provider: Signature.SHA1withDSA verification from: SunPKCS11-Solaris > Provider: Signature.SHA1withDSA verification from: SunPKCS11-Solaris > Provider: Signature.MD5withRSA verification from: SunPKCS11-Solaris > Provider: Signature.MD5withRSA verification from: SunPKCS11-Solaris > Provider: Signature.SHA256withRSA verification from: SunRsaSign > Provider: Signature.SHA256withRSA verification from: SunRsaSign > Provider: KeyPairGenerator.EC from: SunPKCS11-Solaris > Provider: Signature.SHA256withRSA verification from: SunRsaSign > Provider: Signature.SHA256withRSA verification from: SunRsaSign > Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE > Provider: KeyGenerator.SunTls12RsaPremasterSecret from: SunJCE > Provider: Cipher.RSA/ECB/PKCS1Padding key wrapping from: SunPKCS11-Solaris > Provider: KeyGenerator.SunTls12MasterSecret from: SunJCE > Provider: KeyGenerator.SunTls12KeyMaterial from: SunJCE > Provider: Signature.SHA512withRSA signing from: SunPKCS11-Solaris > Provider: KeyGenerator.SunTls12Prf from: SunJCE > Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE > Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE > Provider: KeyGenerator.SunTls12Prf from: SunJCE > Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE > Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE > Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE > Provider: KeyGenerator.SunTls12KeyMaterial from: SunJCE > Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE > Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE > Provider: KeyGenerator.SunTls12Prf from: SunJCE > Provider: KeyGenerator.SunTls12Prf from: SunJCE > Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE > Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE > Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE > Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE > Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE > Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE > : > > > Thanks. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8056026 > Webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.00/ From vincent.x.ryan at oracle.com Mon Sep 15 15:34:13 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 15 Sep 2014 16:34:13 +0100 Subject: [9] RFR 8056026 Debug security logging should print Provider used for each crypto operation In-Reply-To: <541701F9.8000609@oracle.com> References: <541701F9.8000609@oracle.com> Message-ID: Originally I did support tracing for MessageDigest but removed it because of the huge quantity of log messages that were generated. Hashes are very widely used before an application even starts. SecureRandom is similar. Also I omitted KeyStore log messages because there is usually only a single implementation for a given keystore type so the JCE provider which has been selected is obvious. I?ll add support for KeyStore. On 15 Sep 2014, at 16:12, Sean Mullan wrote: > Can you also add similar log messages for MessageDigest, SecureRandom, and KeyStore? > > Otherwise looks good. Please add a noreg label. Also the fix is helpful to any platform and not just solaris/sparc so you should change those fields to be generic. > > --Sean > > On 09/12/2014 11:11 AM, Vincent Ryan wrote: >> >> Please review this change to display the JCE provider that has been >> selected for common crypto operations. >> This aids troubleshooting crypto applications when a given crypto >> algorithm is supported by several JCE providers. >> Some crypto operations delay selecting a provider until they examine the >> key supplied in the init() method. >> This fix also accommodates that behaviour. >> >> The following crypto operations are supported: Cipher, KeyAgreement, >> KeyGenerator, KeyPairGenerator, Mac and Signature. >> To see these new messages, activate JCE provider debugging as normal. >> For example, >> >> % java -Djava.security.debug=provider MySSLClientApp >> : >> Provider: Signature.SHA256withRSA verification from: SunRsaSign >> Provider: Signature.SHA256withRSA verification from: SunRsaSign >> Provider: Signature.SHA256withRSA verification from: SunRsaSign >> Provider: Signature.SHA1withDSA verification from: SunPKCS11-Solaris >> Provider: Signature.SHA1withDSA verification from: SunPKCS11-Solaris >> Provider: Signature.MD5withRSA verification from: SunPKCS11-Solaris >> Provider: Signature.MD5withRSA verification from: SunPKCS11-Solaris >> Provider: Signature.SHA256withRSA verification from: SunRsaSign >> Provider: Signature.SHA256withRSA verification from: SunRsaSign >> Provider: KeyPairGenerator.EC from: SunPKCS11-Solaris >> Provider: Signature.SHA256withRSA verification from: SunRsaSign >> Provider: Signature.SHA256withRSA verification from: SunRsaSign >> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >> Provider: KeyGenerator.SunTls12RsaPremasterSecret from: SunJCE >> Provider: Cipher.RSA/ECB/PKCS1Padding key wrapping from: SunPKCS11-Solaris >> Provider: KeyGenerator.SunTls12MasterSecret from: SunJCE >> Provider: KeyGenerator.SunTls12KeyMaterial from: SunJCE >> Provider: Signature.SHA512withRSA signing from: SunPKCS11-Solaris >> Provider: KeyGenerator.SunTls12Prf from: SunJCE >> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >> Provider: KeyGenerator.SunTls12Prf from: SunJCE >> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >> Provider: KeyGenerator.SunTls12KeyMaterial from: SunJCE >> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >> Provider: KeyGenerator.SunTls12Prf from: SunJCE >> Provider: KeyGenerator.SunTls12Prf from: SunJCE >> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >> : >> >> >> Thanks. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8056026 >> Webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.00/ From sean.mullan at oracle.com Mon Sep 15 15:50:37 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 15 Sep 2014 11:50:37 -0400 Subject: [9] RFR 8056026 Debug security logging should print Provider used for each crypto operation In-Reply-To: References: <541701F9.8000609@oracle.com> Message-ID: <54170ACD.9020005@oracle.com> On 09/15/2014 11:34 AM, Vincent Ryan wrote: > Originally I did support tracing for MessageDigest but removed it because of the huge quantity of log messages that were generated. > Hashes are very widely used before an application even starts. SecureRandom is similar. Hmm, it would be nice to specify the engine classes you want to see. Maybe that's too much work right now, but something like: java -Djava.security.debug="provider engine=MessageDigest,Signature" ... > Also I omitted KeyStore log messages because there is usually only a single implementation for a given keystore type so the > JCE provider which has been selected is obvious. I?ll add support for KeyStore. Ok. I think it would be primarily useful to see the KeyStore when PKCS11 is used with unextractable keys to help debug any subsequent delayed provider selection. --Sean > > > On 15 Sep 2014, at 16:12, Sean Mullan wrote: > >> Can you also add similar log messages for MessageDigest, SecureRandom, and KeyStore? >> >> Otherwise looks good. Please add a noreg label. Also the fix is helpful to any platform and not just solaris/sparc so you should change those fields to be generic. >> >> --Sean >> >> On 09/12/2014 11:11 AM, Vincent Ryan wrote: >>> >>> Please review this change to display the JCE provider that has been >>> selected for common crypto operations. >>> This aids troubleshooting crypto applications when a given crypto >>> algorithm is supported by several JCE providers. >>> Some crypto operations delay selecting a provider until they examine the >>> key supplied in the init() method. >>> This fix also accommodates that behaviour. >>> >>> The following crypto operations are supported: Cipher, KeyAgreement, >>> KeyGenerator, KeyPairGenerator, Mac and Signature. >>> To see these new messages, activate JCE provider debugging as normal. >>> For example, >>> >>> % java -Djava.security.debug=provider MySSLClientApp >>> : >>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>> Provider: Signature.SHA1withDSA verification from: SunPKCS11-Solaris >>> Provider: Signature.SHA1withDSA verification from: SunPKCS11-Solaris >>> Provider: Signature.MD5withRSA verification from: SunPKCS11-Solaris >>> Provider: Signature.MD5withRSA verification from: SunPKCS11-Solaris >>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>> Provider: KeyPairGenerator.EC from: SunPKCS11-Solaris >>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>> Provider: KeyGenerator.SunTls12RsaPremasterSecret from: SunJCE >>> Provider: Cipher.RSA/ECB/PKCS1Padding key wrapping from: SunPKCS11-Solaris >>> Provider: KeyGenerator.SunTls12MasterSecret from: SunJCE >>> Provider: KeyGenerator.SunTls12KeyMaterial from: SunJCE >>> Provider: Signature.SHA512withRSA signing from: SunPKCS11-Solaris >>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>> Provider: KeyGenerator.SunTls12KeyMaterial from: SunJCE >>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>> : >>> >>> >>> Thanks. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8056026 >>> Webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.00/ > From vincent.x.ryan at oracle.com Mon Sep 15 15:57:22 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 15 Sep 2014 16:57:22 +0100 Subject: [9] RFR 8056026 Debug security logging should print Provider used for each crypto operation In-Reply-To: <54170ACD.9020005@oracle.com> References: <541701F9.8000609@oracle.com> <54170ACD.9020005@oracle.com> Message-ID: <241BE800-B528-4D72-865A-2F55C311283B@oracle.com> On 15 Sep 2014, at 16:50, Sean Mullan wrote: > On 09/15/2014 11:34 AM, Vincent Ryan wrote: >> Originally I did support tracing for MessageDigest but removed it because of the huge quantity of log messages that were generated. >> Hashes are very widely used before an application even starts. SecureRandom is similar. > > Hmm, it would be nice to specify the engine classes you want to see. Maybe that's too much work right now, but something like: > > java -Djava.security.debug="provider engine=MessageDigest,Signature" ? We can log the JCE provider for all engine classes by default and also support a filtering mechanism using the ?engine' sub-option as you suggest above. > >> Also I omitted KeyStore log messages because there is usually only a single implementation for a given keystore type so the >> JCE provider which has been selected is obvious. I?ll add support for KeyStore. > > Ok. I think it would be primarily useful to see the KeyStore when PKCS11 is used with unextractable keys to help debug any subsequent delayed provider selection. > > --Sean > >> >> >> On 15 Sep 2014, at 16:12, Sean Mullan wrote: >> >>> Can you also add similar log messages for MessageDigest, SecureRandom, and KeyStore? >>> >>> Otherwise looks good. Please add a noreg label. Also the fix is helpful to any platform and not just solaris/sparc so you should change those fields to be generic. >>> >>> --Sean >>> >>> On 09/12/2014 11:11 AM, Vincent Ryan wrote: >>>> >>>> Please review this change to display the JCE provider that has been >>>> selected for common crypto operations. >>>> This aids troubleshooting crypto applications when a given crypto >>>> algorithm is supported by several JCE providers. >>>> Some crypto operations delay selecting a provider until they examine the >>>> key supplied in the init() method. >>>> This fix also accommodates that behaviour. >>>> >>>> The following crypto operations are supported: Cipher, KeyAgreement, >>>> KeyGenerator, KeyPairGenerator, Mac and Signature. >>>> To see these new messages, activate JCE provider debugging as normal. >>>> For example, >>>> >>>> % java -Djava.security.debug=provider MySSLClientApp >>>> : >>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>> Provider: Signature.SHA1withDSA verification from: SunPKCS11-Solaris >>>> Provider: Signature.SHA1withDSA verification from: SunPKCS11-Solaris >>>> Provider: Signature.MD5withRSA verification from: SunPKCS11-Solaris >>>> Provider: Signature.MD5withRSA verification from: SunPKCS11-Solaris >>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>> Provider: KeyPairGenerator.EC from: SunPKCS11-Solaris >>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>> Provider: KeyGenerator.SunTls12RsaPremasterSecret from: SunJCE >>>> Provider: Cipher.RSA/ECB/PKCS1Padding key wrapping from: SunPKCS11-Solaris >>>> Provider: KeyGenerator.SunTls12MasterSecret from: SunJCE >>>> Provider: KeyGenerator.SunTls12KeyMaterial from: SunJCE >>>> Provider: Signature.SHA512withRSA signing from: SunPKCS11-Solaris >>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>> Provider: KeyGenerator.SunTls12KeyMaterial from: SunJCE >>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>> : >>>> >>>> >>>> Thanks. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8056026 >>>> Webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.00/ >> From weijun.wang at oracle.com Tue Sep 16 01:31:40 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 16 Sep 2014 09:31:40 +0800 Subject: RFR 8038089: TLS optional support for Kerberos cipher suites needs to be re-examine Message-ID: <61B179BE-E775-4A32-9660-D5FFBB4CC150@oracle.com> 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 vincent.x.ryan at oracle.com Tue Sep 16 15:27:24 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 16 Sep 2014 16:27:24 +0100 Subject: [9] RFR 8056026 Debug security logging should print Provider used for each crypto operation In-Reply-To: <241BE800-B528-4D72-865A-2F55C311283B@oracle.com> References: <541701F9.8000609@oracle.com> <54170ACD.9020005@oracle.com> <241BE800-B528-4D72-865A-2F55C311283B@oracle.com> Message-ID: <541856DC.1040108@oracle.com> Here's an updated webrev that supports including/excluding specific JCA engines: Webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.01/ For example, use the following to trace only MessageDigest and Signature engines: -Djava.security.debug=provider:engine=MessageDigest,Signature and use the following to trace all supported engines: -Djava.security.debug=provider or -Djava.security.debug=all On 15/09/2014 16:57, Vincent Ryan wrote: > > On 15 Sep 2014, at 16:50, Sean Mullan wrote: > >> On 09/15/2014 11:34 AM, Vincent Ryan wrote: >>> Originally I did support tracing for MessageDigest but removed it because of the huge quantity of log messages that were generated. >>> Hashes are very widely used before an application even starts. SecureRandom is similar. >> >> Hmm, it would be nice to specify the engine classes you want to see. Maybe that's too much work right now, but something like: >> >> java -Djava.security.debug="provider engine=MessageDigest,Signature" ? > > We can log the JCE provider for all engine classes by default and also support a filtering mechanism using the ?engine' sub-option as you suggest above. > > >> >>> Also I omitted KeyStore log messages because there is usually only a single implementation for a given keystore type so the >>> JCE provider which has been selected is obvious. I?ll add support for KeyStore. >> >> Ok. I think it would be primarily useful to see the KeyStore when PKCS11 is used with unextractable keys to help debug any subsequent delayed provider selection. >> >> --Sean >> >>> >>> >>> On 15 Sep 2014, at 16:12, Sean Mullan wrote: >>> >>>> Can you also add similar log messages for MessageDigest, SecureRandom, and KeyStore? >>>> >>>> Otherwise looks good. Please add a noreg label. Also the fix is helpful to any platform and not just solaris/sparc so you should change those fields to be generic. >>>> >>>> --Sean >>>> >>>> On 09/12/2014 11:11 AM, Vincent Ryan wrote: >>>>> >>>>> Please review this change to display the JCE provider that has been >>>>> selected for common crypto operations. >>>>> This aids troubleshooting crypto applications when a given crypto >>>>> algorithm is supported by several JCE providers. >>>>> Some crypto operations delay selecting a provider until they examine the >>>>> key supplied in the init() method. >>>>> This fix also accommodates that behaviour. >>>>> >>>>> The following crypto operations are supported: Cipher, KeyAgreement, >>>>> KeyGenerator, KeyPairGenerator, Mac and Signature. >>>>> To see these new messages, activate JCE provider debugging as normal. >>>>> For example, >>>>> >>>>> % java -Djava.security.debug=provider MySSLClientApp >>>>> : >>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>> Provider: Signature.SHA1withDSA verification from: SunPKCS11-Solaris >>>>> Provider: Signature.SHA1withDSA verification from: SunPKCS11-Solaris >>>>> Provider: Signature.MD5withRSA verification from: SunPKCS11-Solaris >>>>> Provider: Signature.MD5withRSA verification from: SunPKCS11-Solaris >>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>> Provider: KeyPairGenerator.EC from: SunPKCS11-Solaris >>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>> Provider: KeyGenerator.SunTls12RsaPremasterSecret from: SunJCE >>>>> Provider: Cipher.RSA/ECB/PKCS1Padding key wrapping from: SunPKCS11-Solaris >>>>> Provider: KeyGenerator.SunTls12MasterSecret from: SunJCE >>>>> Provider: KeyGenerator.SunTls12KeyMaterial from: SunJCE >>>>> Provider: Signature.SHA512withRSA signing from: SunPKCS11-Solaris >>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>> Provider: KeyGenerator.SunTls12KeyMaterial from: SunJCE >>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>> : >>>>> >>>>> >>>>> Thanks. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8056026 >>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.00/ >>> > From sean.mullan at oracle.com Tue Sep 16 21:07:20 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 16 Sep 2014 17:07:20 -0400 Subject: [9] RFR 8056026 Debug security logging should print Provider used for each crypto operation In-Reply-To: <541856DC.1040108@oracle.com> References: <541701F9.8000609@oracle.com> <54170ACD.9020005@oracle.com> <241BE800-B528-4D72-865A-2F55C311283B@oracle.com> <541856DC.1040108@oracle.com> Message-ID: <5418A688.5010500@oracle.com> On 09/16/2014 11:27 AM, Vincent Ryan wrote: > Here's an updated webrev that supports including/excluding specific > JCA engines: > > Webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.01/ Looks good, although the doDebug boolean is making my head spin, is there an easier way to specify that? Also, can you open a corresponding docs bug to update the troubleshooting guide: http://docs.oracle.com/javase/8/docs/technotes/guides/security/troubleshooting-security.html --Sean > > > For example, use the following to trace only MessageDigest and > Signature engines: > > -Djava.security.debug=provider:engine=MessageDigest,Signature > > and use the following to trace all supported engines: > > -Djava.security.debug=provider > or > -Djava.security.debug=all > > > > On 15/09/2014 16:57, Vincent Ryan wrote: >> >> On 15 Sep 2014, at 16:50, Sean Mullan wrote: >> >>> On 09/15/2014 11:34 AM, Vincent Ryan wrote: >>>> Originally I did support tracing for MessageDigest but removed it >>>> because of the huge quantity of log messages that were generated. >>>> Hashes are very widely used before an application even starts. >>>> SecureRandom is similar. >>> >>> Hmm, it would be nice to specify the engine classes you want to see. >>> Maybe that's too much work right now, but something like: >>> >>> java -Djava.security.debug="provider engine=MessageDigest,Signature" ? >> >> We can log the JCE provider for all engine classes by default and also >> support a filtering mechanism using the ?engine' sub-option as you >> suggest above. >> >> >>> >>>> Also I omitted KeyStore log messages because there is usually only a >>>> single implementation for a given keystore type so the >>>> JCE provider which has been selected is obvious. I?ll add support >>>> for KeyStore. >>> >>> Ok. I think it would be primarily useful to see the KeyStore when >>> PKCS11 is used with unextractable keys to help debug any subsequent >>> delayed provider selection. >>> >>> --Sean >>> >>>> >>>> >>>> On 15 Sep 2014, at 16:12, Sean Mullan wrote: >>>> >>>>> Can you also add similar log messages for MessageDigest, >>>>> SecureRandom, and KeyStore? >>>>> >>>>> Otherwise looks good. Please add a noreg label. Also the fix is >>>>> helpful to any platform and not just solaris/sparc so you should >>>>> change those fields to be generic. >>>>> >>>>> --Sean >>>>> >>>>> On 09/12/2014 11:11 AM, Vincent Ryan wrote: >>>>>> >>>>>> Please review this change to display the JCE provider that has been >>>>>> selected for common crypto operations. >>>>>> This aids troubleshooting crypto applications when a given crypto >>>>>> algorithm is supported by several JCE providers. >>>>>> Some crypto operations delay selecting a provider until they >>>>>> examine the >>>>>> key supplied in the init() method. >>>>>> This fix also accommodates that behaviour. >>>>>> >>>>>> The following crypto operations are supported: Cipher, KeyAgreement, >>>>>> KeyGenerator, KeyPairGenerator, Mac and Signature. >>>>>> To see these new messages, activate JCE provider debugging as normal. >>>>>> For example, >>>>>> >>>>>> % java -Djava.security.debug=provider MySSLClientApp >>>>>> : >>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>> Provider: Signature.SHA1withDSA verification from: SunPKCS11-Solaris >>>>>> Provider: Signature.SHA1withDSA verification from: SunPKCS11-Solaris >>>>>> Provider: Signature.MD5withRSA verification from: SunPKCS11-Solaris >>>>>> Provider: Signature.MD5withRSA verification from: SunPKCS11-Solaris >>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>> Provider: KeyPairGenerator.EC from: SunPKCS11-Solaris >>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>> Provider: KeyGenerator.SunTls12RsaPremasterSecret from: SunJCE >>>>>> Provider: Cipher.RSA/ECB/PKCS1Padding key wrapping from: >>>>>> SunPKCS11-Solaris >>>>>> Provider: KeyGenerator.SunTls12MasterSecret from: SunJCE >>>>>> Provider: KeyGenerator.SunTls12KeyMaterial from: SunJCE >>>>>> Provider: Signature.SHA512withRSA signing from: SunPKCS11-Solaris >>>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>> Provider: KeyGenerator.SunTls12KeyMaterial from: SunJCE >>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>> : >>>>>> >>>>>> >>>>>> Thanks. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8056026 >>>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.00/ >>>> >> From ecki at zusammenkunft.net Wed Sep 17 01:38:27 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 17 Sep 2014 03:38:27 +0200 Subject: NoSuchMethod in 9ea-b30 getRawHostnameSE Message-ID: <20140917033827.00002df6.ecki@zusammenkunft.net> Hello JDK security team, (cced the Undertow guys cause I mentioned this on the IRC channel) when trying to run the JBoss Undertow build tests with JDK9ea-b30 a lot of tests fail with the same "NosuchMethodError", and I am not sure why. It looks like an internal inconsitency in the JSSE? However I tries the simple SSLEngine demo code and that one compiles and runs. Undertow master 79daf29 https://github.com/undertow-io/undertow/tree/79daf29322940f93a42f736a2cd959f6d0a7a5de maven 3.2.3 Windows x64 7 this is using xnio-api and xnio-nio 3.3.0.Beta3 (from jboss-public-repository-group) One of the observed exceptions (but not related to SPDY IMHO): 03:26:29,211 ERROR (XNIO-1 I/O-2) [org.xnio.listener] XNIO001007: A channel event listener threw an exception: java.lang.NoSuchMethodError: sun.security.ssl.ClientHandshaker.getRawHostnameSE()Ljava/lang/String; at sun.security.ssl.ClientHandshaker.getKickstartMessage(ClientHandshaker.java:1294) at sun.security.ssl.Handshaker.kickstart(Handshaker.java:972) at sun.security.ssl.SSLEngineImpl.kickstartHandshake(SSLEngineImpl.java:728) at sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:750) at org.xnio.ssl.JsseSslConduitEngine.beginHandshake(JsseSslConduitEngine.java:177) at org.xnio.ssl.JsseSslStreamConnection.startHandshake(JsseSslStreamConnection.java:85) at io.undertow.client.spdy.SpdyClientProvider.handlePotentialSpdyConnection(SpdyClientProvider.java:222) at io.undertow.client.http.HttpClientProvider.handleConnected(HttpClientProvider.java:132) at io.undertow.client.http.HttpClientProvider.access$000(HttpClientProvider.java:49) at io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:123) at io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:120) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.ssl.JsseXnioSsl$StreamConnectionChannelListener.handleEvent(JsseXnioSsl.java:283) at org.xnio.ssl.JsseXnioSsl$StreamConnectionChannelListener.handleEvent(JsseXnioSsl.java:265) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:324) at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) As xnio (the NIO abstraction used by undertow) uses asm and some unsafe functions it might not be the cleanest test, however the stacktrace looks like the problem is all inside javax.ssl / JSSE? I am not sure where to look for the right JDK source version, is this before or after the modular split? The latest code does not seem to match the stacktrace: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/40c3a5ce8047/src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java Gruss Bernd From xuelei.fan at oracle.com Wed Sep 17 02:27:22 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 17 Sep 2014 10:27:22 +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: <5418F18A.9070109@oracle.com> I'm OK with the doPrivileged-with-permission mode. Generally speaking, we only need to define the authentication part of a cipher suite for KRB5 implementation. I was wondering, can we simplify the code more as follow: 1. define an private external authentication interface, which: a. generate key exchange message; b. read key exchange message; c. generate pre-master secret. 2. This interface can be implemented for key exchange/authentication as KRB5 (RFC 2712), SRP (RFC 5054), PSK (RFC 4279), etc. For this fix, we probably want to: 1. move KerberosClientKeyExchange.java to krb5 model. 2. update ExternalCipherSuiteProvider (rename to KeyExchangeService?) to support HandshakeMessage parser and generation, and the generation of pre-master secret. 3. don't need Krb5Helper any more, call the new interface directly. After the update, the SunJSSE provider would only known the algorithm name of the KRB5 key exchange. What do you think? Thanks, Xuelei 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 sdouglas at redhat.com Wed Sep 17 02:14:05 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 17 Sep 2014 12:14:05 +1000 Subject: [undertow-dev] NoSuchMethod in 9ea-b30 getRawHostnameSE In-Reply-To: <20140917033827.00002df6.ecki@zusammenkunft.net> References: <20140917033827.00002df6.ecki@zusammenkunft.net> Message-ID: <5418EE6D.6010004@redhat.com> This is because Undertow is testing SPDY and HTTP2, which use Jetty ALPN. This jar resides on the boot class path, and you need to use a specific version of it for a given JVM. Undertow uses profiles to select between JDK 7 and 8, however it looks like it will attempt to use the 8 jar if you test on 9. I will look at updating the build to just ignore these tests if the appropriate version of the ALPN jar is not available. Stuart Bernd Eckenfels wrote: > Hello JDK security team, > (cced the Undertow guys cause I mentioned this on the IRC channel) > > > when trying to run the JBoss Undertow build tests with JDK9ea-b30 a lot > of tests fail with the same "NosuchMethodError", and I am not sure why. > > It looks like an internal inconsitency in the JSSE? However I tries the simple SSLEngine demo code and that one compiles and runs. > > Undertow master 79daf29 > https://github.com/undertow-io/undertow/tree/79daf29322940f93a42f736a2cd959f6d0a7a5de > > maven 3.2.3 Windows x64 7 > this is using xnio-api and xnio-nio 3.3.0.Beta3 (from jboss-public-repository-group) > > > One of the observed exceptions (but not related to SPDY IMHO): > > 03:26:29,211 ERROR (XNIO-1 I/O-2) [org.xnio.listener] XNIO001007: A channel event listener threw an exception: > > java.lang.NoSuchMethodError: sun.security.ssl.ClientHandshaker.getRawHostnameSE()Ljava/lang/String; > at sun.security.ssl.ClientHandshaker.getKickstartMessage(ClientHandshaker.java:1294) > at sun.security.ssl.Handshaker.kickstart(Handshaker.java:972) > at sun.security.ssl.SSLEngineImpl.kickstartHandshake(SSLEngineImpl.java:728) > at sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:750) > > at org.xnio.ssl.JsseSslConduitEngine.beginHandshake(JsseSslConduitEngine.java:177) > at org.xnio.ssl.JsseSslStreamConnection.startHandshake(JsseSslStreamConnection.java:85) > at io.undertow.client.spdy.SpdyClientProvider.handlePotentialSpdyConnection(SpdyClientProvider.java:222) > at io.undertow.client.http.HttpClientProvider.handleConnected(HttpClientProvider.java:132) > at io.undertow.client.http.HttpClientProvider.access$000(HttpClientProvider.java:49) > at io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:123) > at io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:120) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.ssl.JsseXnioSsl$StreamConnectionChannelListener.handleEvent(JsseXnioSsl.java:283) > at org.xnio.ssl.JsseXnioSsl$StreamConnectionChannelListener.handleEvent(JsseXnioSsl.java:265) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:324) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) > > > As xnio (the NIO abstraction used by undertow) uses asm and some > unsafe functions it might not be the cleanest test, however the > stacktrace looks like the problem is all inside javax.ssl / JSSE? > > I am not sure where to look for the right JDK source version, is this before or after the modular split? The latest code does not seem to match the stacktrace: > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/40c3a5ce8047/src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java > > Gruss > Bernd > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From weijun.wang at oracle.com Wed Sep 17 03:32:58 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 17 Sep 2014 11:32:58 +0800 Subject: RFR 8038089: TLS optional support for Kerberos cipher suites needs to be re-examine In-Reply-To: <5418F18A.9070109@oracle.com> References: <61B179BE-E775-4A32-9660-D5FFBB4CC150@oracle.com> <5418F18A.9070109@oracle.com> Message-ID: Certainly it will be better to make the interface more generalized. But there are ExternalCipherSuiteProvider methods like getServiceCreds() and isRelated() and I don't know how they will be used for other key exchange services. Also it seems we still need to define an extended HandshakeMessage which is similar to KerberosClientKeyExchange that contains getPeerPrincipal() and getLocalPrincipal(). In this sense, it is more likely we rename KerberosClientKeyExchange to a better name instead of moving it out of SSL. Do you wish to do these inside this bug or a new one? I prefer the latter when we decide to support (or at least prototype) one of those other key exchange services. --Max On Sep 17, 2014, at 10:27, Xuelei Fan wrote: > I'm OK with the doPrivileged-with-permission mode. > > Generally speaking, we only need to define the authentication part of a > cipher suite for KRB5 implementation. I was wondering, can we simplify > the code more as follow: > 1. define an private external authentication interface, which: > a. generate key exchange message; > b. read key exchange message; > c. generate pre-master secret. > > 2. This interface can be implemented for key exchange/authentication as > KRB5 (RFC 2712), SRP (RFC 5054), PSK (RFC 4279), etc. > > For this fix, we probably want to: > 1. move KerberosClientKeyExchange.java to krb5 model. > 2. update ExternalCipherSuiteProvider (rename to KeyExchangeService?) to > support HandshakeMessage parser and generation, and the generation of > pre-master secret. > 3. don't need Krb5Helper any more, call the new interface directly. > > After the update, the SunJSSE provider would only known the algorithm > name of the KRB5 key exchange. > > What do you think? > > Thanks, > Xuelei > > 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 Sep 17 05:18:50 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 17 Sep 2014 13:18:50 +0800 Subject: RFR 8038089: TLS optional support for Kerberos cipher suites needs to be re-examine In-Reply-To: References: <61B179BE-E775-4A32-9660-D5FFBB4CC150@oracle.com> <5418F18A.9070109@oracle.com> Message-ID: <541919BA.1040601@oracle.com> On 9/17/2014 11:32 AM, Wang Weijun wrote: > > Certainly it will be better to make the interface more generalized. But there are ExternalCipherSuiteProvider methods like getServiceCreds() and isRelated() and I don't know how they will be used for other key exchange services. One of my motivation for a better design is the getServiceCreds() and the Exchanger.getResult() methods in the current webrev, which is more like a internal logic of krb5 key exchange. For the new design, no need to define the Exchanger.getResult() and getServiceCreds() any more. Correspondingly, these function might be able to implemented internally in the service provider. > Also it seems we still need to define an extended HandshakeMessage which is similar to KerberosClientKeyExchange that contains getPeerPrincipal() and getLocalPrincipal(). I think it could the function of the new ExternalCipherSuiteProvider. > In this sense, it is more likely we rename KerberosClientKeyExchange to a better name instead of moving it out of SSL. > > Do you wish to do these inside this bug or a new one? I prefer to hide the details of KRB5 in SunJSSE as if we want to move the implementation details to Krb5. If we do it later, it is likely we need to reorg most the of code in this update, I would prefer we do it now. If I did not miss something, the new design should be more simple and straightforward. Xuelei > I prefer the latter when we decide to support (or at least prototype) one of those other key exchange services. > > --Max > > On Sep 17, 2014, at 10:27, Xuelei Fan wrote: > >> I'm OK with the doPrivileged-with-permission mode. >> >> Generally speaking, we only need to define the authentication part of a >> cipher suite for KRB5 implementation. I was wondering, can we simplify >> the code more as follow: >> 1. define an private external authentication interface, which: >> a. generate key exchange message; >> b. read key exchange message; >> c. generate pre-master secret. >> >> 2. This interface can be implemented for key exchange/authentication as >> KRB5 (RFC 2712), SRP (RFC 5054), PSK (RFC 4279), etc. >> >> For this fix, we probably want to: >> 1. move KerberosClientKeyExchange.java to krb5 model. >> 2. update ExternalCipherSuiteProvider (rename to KeyExchangeService?) to >> support HandshakeMessage parser and generation, and the generation of >> pre-master secret. >> 3. don't need Krb5Helper any more, call the new interface directly. >> >> After the update, the SunJSSE provider would only known the algorithm >> name of the KRB5 key exchange. >> >> What do you think? >> >> Thanks, >> Xuelei >> >> 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 Sep 17 05:49:42 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 17 Sep 2014 13:49:42 +0800 Subject: RFR 8038089: TLS optional support for Kerberos cipher suites needs to be re-examine In-Reply-To: <541919BA.1040601@oracle.com> References: <61B179BE-E775-4A32-9660-D5FFBB4CC150@oracle.com> <5418F18A.9070109@oracle.com> <541919BA.1040601@oracle.com> Message-ID: <2823CD99-98C1-4349-82B7-1D0DD2400AAE@oracle.com> > I would prefer we do it now. If I did not miss something, the new design should be more simple > and straightforward. Maybe, but I am not sure since this would surely touch more TLS side codes. If you want to be totally separated, we also need to move the ciphersuites definitions outside CipherSuite.java. The TLS side can iterate through all providers to add them back and create something like a Map. Then we could use this map in all "switch (keyExchange)" blocks. Do you think it's easier to make these changes based on the current codes? Or based on my modified codes? Can you describe the KeyExchangeService interface you are thinking about? Currently I have to define a two-level interface -- ExternalCipherSuiteProvider and ExternalCipherSuiteProvider.Exchanger -- to model the service and the exchange instance. Thanks Max From xuelei.fan at oracle.com Wed Sep 17 05:58:29 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 17 Sep 2014 13:58:29 +0800 Subject: RFR 8038089: TLS optional support for Kerberos cipher suites needs to be re-examine In-Reply-To: <2823CD99-98C1-4349-82B7-1D0DD2400AAE@oracle.com> References: <61B179BE-E775-4A32-9660-D5FFBB4CC150@oracle.com> <5418F18A.9070109@oracle.com> <541919BA.1040601@oracle.com> <2823CD99-98C1-4349-82B7-1D0DD2400AAE@oracle.com> Message-ID: <54192305.2030905@oracle.com> On 9/17/2014 1:49 PM, Wang Weijun wrote: >> I would prefer we do it now. If I did not miss something, the new design should be more simple >> and straightforward. > > Maybe, but I am not sure since this would surely touch more TLS side codes. If you want to be totally separated, we also need to move the ciphersuites definitions outside CipherSuite.java. The TLS side can iterate through all providers to add them back and create something like a Map. Then we could use this map in all "switch (keyExchange)" blocks. > > Do you think it's easier to make these changes based on the current codes? Or based on my modified codes? > > Can you describe the KeyExchangeService interface you are thinking about? Currently I have to define a two-level interface -- ExternalCipherSuiteProvider and ExternalCipherSuiteProvider.Exchanger -- to model the service and the exchange instance. > OK, I will wrap up my ideas of the KeyExchangeService. But it may take a few more days. Wish I could get it ready by next Monday. Thanks, Xuelei From simone.bordet at gmail.com Wed Sep 17 10:02:40 2014 From: simone.bordet at gmail.com (Simone Bordet) Date: Wed, 17 Sep 2014 12:02:40 +0200 Subject: TLS extensions API, ALPN and HTTP 2.0 In-Reply-To: References: Message-ID: Hi, On Tue, Sep 2, 2014 at 11:11 AM, Vincent Ryan wrote: > Your OCA is still being processed. When that has completed your name will be listed at: > http://www.oracle.com/technetwork/community/oca-486395.html#b > > Until then, we can discuss these TLS/HTTP issues but we cannot include your APIs or source code. Just an update on this... While ALPN should offer mechanism independent from the protocol advertised or the cipher used in the TLS connection, it seems that the HTTP/2.0 spec has put some constraint that link the protocol advertised to the ciphers negotiated (http://tools.ietf.org/html/draft-ietf-httpbis-http2-14#section-9.2.2). Currently it seems that this HTTP/2 requirement is difficult, if not impossible, to implement in the JDK. I am following the HTTP/2 expert group to see if this issue is resolved, and working on the Jetty code to implement this feature. The idea being to wait a bit to define the ALPN APIs until this issue is resolved, to see if the resolution requires changes in the ALPN APIs. 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 vincent.x.ryan at oracle.com Wed Sep 17 10:33:58 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 17 Sep 2014 11:33:58 +0100 Subject: [9] RFR 8056026 Debug security logging should print Provider used for each crypto operation In-Reply-To: <5418A688.5010500@oracle.com> References: <541701F9.8000609@oracle.com> <54170ACD.9020005@oracle.com> <241BE800-B528-4D72-865A-2F55C311283B@oracle.com> <541856DC.1040108@oracle.com> <5418A688.5010500@oracle.com> Message-ID: <7C8A77B0-52D2-4C50-9A71-7B71EB49EEEE@oracle.com> I?ve renamed that boolean flag and inverted its logic: - private static final boolean doDebug = !(Debug.isOn("engine=") && !Debug.isOn(?XXX")); + private static final boolean skipDebug = Debug.isOn("engine=") && !Debug.isOn(?XXX?); Updated webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.02/ Docs bug: https://bugs.openjdk.java.net/browse/JDK-8058624 On 16 Sep 2014, at 22:07, Sean Mullan wrote: > On 09/16/2014 11:27 AM, Vincent Ryan wrote: >> Here's an updated webrev that supports including/excluding specific >> JCA engines: >> >> Webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.01/ > > Looks good, although the doDebug boolean is making my head spin, is there an easier way to specify that? > > Also, can you open a corresponding docs bug to update the troubleshooting guide: http://docs.oracle.com/javase/8/docs/technotes/guides/security/troubleshooting-security.html > > --Sean > >> >> >> For example, use the following to trace only MessageDigest and >> Signature engines: >> >> -Djava.security.debug=provider:engine=MessageDigest,Signature >> >> and use the following to trace all supported engines: >> >> -Djava.security.debug=provider >> or >> -Djava.security.debug=all >> >> >> >> On 15/09/2014 16:57, Vincent Ryan wrote: >>> >>> On 15 Sep 2014, at 16:50, Sean Mullan wrote: >>> >>>> On 09/15/2014 11:34 AM, Vincent Ryan wrote: >>>>> Originally I did support tracing for MessageDigest but removed it >>>>> because of the huge quantity of log messages that were generated. >>>>> Hashes are very widely used before an application even starts. >>>>> SecureRandom is similar. >>>> >>>> Hmm, it would be nice to specify the engine classes you want to see. >>>> Maybe that's too much work right now, but something like: >>>> >>>> java -Djava.security.debug="provider engine=MessageDigest,Signature" ? >>> >>> We can log the JCE provider for all engine classes by default and also >>> support a filtering mechanism using the ?engine' sub-option as you >>> suggest above. >>> >>> >>>> >>>>> Also I omitted KeyStore log messages because there is usually only a >>>>> single implementation for a given keystore type so the >>>>> JCE provider which has been selected is obvious. I?ll add support >>>>> for KeyStore. >>>> >>>> Ok. I think it would be primarily useful to see the KeyStore when >>>> PKCS11 is used with unextractable keys to help debug any subsequent >>>> delayed provider selection. >>>> >>>> --Sean >>>> >>>>> >>>>> >>>>> On 15 Sep 2014, at 16:12, Sean Mullan wrote: >>>>> >>>>>> Can you also add similar log messages for MessageDigest, >>>>>> SecureRandom, and KeyStore? >>>>>> >>>>>> Otherwise looks good. Please add a noreg label. Also the fix is >>>>>> helpful to any platform and not just solaris/sparc so you should >>>>>> change those fields to be generic. >>>>>> >>>>>> --Sean >>>>>> >>>>>> On 09/12/2014 11:11 AM, Vincent Ryan wrote: >>>>>>> >>>>>>> Please review this change to display the JCE provider that has been >>>>>>> selected for common crypto operations. >>>>>>> This aids troubleshooting crypto applications when a given crypto >>>>>>> algorithm is supported by several JCE providers. >>>>>>> Some crypto operations delay selecting a provider until they >>>>>>> examine the >>>>>>> key supplied in the init() method. >>>>>>> This fix also accommodates that behaviour. >>>>>>> >>>>>>> The following crypto operations are supported: Cipher, KeyAgreement, >>>>>>> KeyGenerator, KeyPairGenerator, Mac and Signature. >>>>>>> To see these new messages, activate JCE provider debugging as normal. >>>>>>> For example, >>>>>>> >>>>>>> % java -Djava.security.debug=provider MySSLClientApp >>>>>>> : >>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>> Provider: Signature.SHA1withDSA verification from: SunPKCS11-Solaris >>>>>>> Provider: Signature.SHA1withDSA verification from: SunPKCS11-Solaris >>>>>>> Provider: Signature.MD5withRSA verification from: SunPKCS11-Solaris >>>>>>> Provider: Signature.MD5withRSA verification from: SunPKCS11-Solaris >>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>> Provider: KeyPairGenerator.EC from: SunPKCS11-Solaris >>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>> Provider: KeyGenerator.SunTls12RsaPremasterSecret from: SunJCE >>>>>>> Provider: Cipher.RSA/ECB/PKCS1Padding key wrapping from: >>>>>>> SunPKCS11-Solaris >>>>>>> Provider: KeyGenerator.SunTls12MasterSecret from: SunJCE >>>>>>> Provider: KeyGenerator.SunTls12KeyMaterial from: SunJCE >>>>>>> Provider: Signature.SHA512withRSA signing from: SunPKCS11-Solaris >>>>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>> Provider: KeyGenerator.SunTls12KeyMaterial from: SunJCE >>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>> : >>>>>>> >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8056026 >>>>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.00/ >>>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.x.mcmahon at oracle.com Wed Sep 17 10:57:21 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 17 Sep 2014 11:57:21 +0100 Subject: TLS extensions API, ALPN and HTTP 2.0 In-Reply-To: References: Message-ID: <54196911.6050903@oracle.com> Hi Simone, I'm interested to understand why you think this Http 2 requirement is difficult or impossible to implement in the JDK currently. I thought, cipher suite selection would be independent of the ALPN mechanism. So, a Http 2 client implementation would ensure that allowed ciphers are in its list of proposed ciphers, and it's up to the server then to choose an allowed one. And presumably, a server implementation can do the same? - Michael. On 17/09/14 11:02, Simone Bordet wrote: > Hi, > > On Tue, Sep 2, 2014 at 11:11 AM, Vincent Ryan wrote: >> Your OCA is still being processed. When that has completed your name will be listed at: >> http://www.oracle.com/technetwork/community/oca-486395.html#b >> >> Until then, we can discuss these TLS/HTTP issues but we cannot include your APIs or source code. > Just an update on this... > > While ALPN should offer mechanism independent from the protocol > advertised or the cipher used in the TLS connection, it seems that the > HTTP/2.0 spec has put some constraint that link the protocol > advertised to the ciphers negotiated > (http://tools.ietf.org/html/draft-ietf-httpbis-http2-14#section-9.2.2). > Currently it seems that this HTTP/2 requirement is difficult, if not > impossible, to implement in the JDK. > I am following the HTTP/2 expert group to see if this issue is > resolved, and working on the Jetty code to implement this feature. > > The idea being to wait a bit to define the ALPN APIs until this issue > is resolved, to see if the resolution requires changes in the ALPN > APIs. > > Thanks ! > From darran.lofthouse at jboss.com Wed Sep 17 12:56:46 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 17 Sep 2014 13:56:46 +0100 Subject: Kerberos Enc Type Expectations for delegated credential within AP_REQ message. In-Reply-To: <5411C434.6010301@jboss.com> References: <5411C434.6010301@jboss.com> Message-ID: <5419850E.2090606@jboss.com> Ignore my ramblings, I have just checked the code at the tip for OpenJDK 9 and I find the changes I think need making to earlier versions have already been made for 9 ;-) From 9 the encryption type of the session key is no longer taken into account and instead the encryption type of the enc part is and a NULL_KEY used only when appropriate otherwise the session key is used. Regards, Darran Lofthouse. On 11/09/14 16:48, Darran Lofthouse wrote: > Hello there, I am currently attempting to get to the bottom of some > interoperability issues regarding the handling of Kerberos AP_REQ > messages that contain a delegated credential. > > Before I start raising bug reports I wanted to pass it through you guys > first in case there is a strong opposition to this being raised as a > Java bug. > > The kind of error messages I am seeing are: - > http://fpaste.org/132824/ > http://fpaste.org/132825/ > > In short the class 'sun.security.jgss.krb5.InitialToken' is making an > assumption as to if the enc type for the delegated credential is NULL > based on the enc type of the session key. > > If I follow through the call to the constructor in > 'sun.security.krb5.KrbCred' there is even a comment saying the key will > always be NULL even though that is no longer true so it looks like this > block of code has been modified at some point to start to support an > EncryptionKey. > > The reason this is a problem is that I have Mac OS clients that will > always use NULL regardless of the algorithm for the session key, I also > have Linux clients that will use the session key regardless of the > algorithm. > > After researching this I am yet to find anything that tells me the > algorithm for the session key should affect if the credential is > encrypted which is why I am questioning if that is a valid approach. > > My proposal would be to update the code within InitialToken to skip > trying to decide to use EncryptionKey.NULL_KEY, instead just keep the > try / catch block for the key and sub-key. Within > sun.security.krb5.KrbCred just before decrypt is called it would be > possible to check the encType and check for the NULL type and substitute > in the NULL_KEY at that point. > > Where the delegated credential is encrypted the existing checks would > still apply to identify any encType mis-match - so overall this change > would be to use the EncryptionKey.NULL_KEY only when absolutely > confirmed it is required. > > I am happy to create a Jira issue and e-mail over a proposed patch but > as I say I just wanted to run this by you guys before I start down that > patch. > > Regards, > Darran Lofthouse. > > From simone.bordet at gmail.com Wed Sep 17 13:17:40 2014 From: simone.bordet at gmail.com (Simone Bordet) Date: Wed, 17 Sep 2014 15:17:40 +0200 Subject: TLS extensions API, ALPN and HTTP 2.0 In-Reply-To: <54196911.6050903@oracle.com> References: <54196911.6050903@oracle.com> Message-ID: Hi, On Wed, Sep 17, 2014 at 12:57 PM, Michael McMahon wrote: > Hi Simone, > > I'm interested to understand why you think this Http 2 requirement > is difficult or impossible to implement in the JDK currently. > > I thought, cipher suite selection would be independent of the ALPN > mechanism. Indeed they should be independent, but section 9.2.2 poses constraint and links the h2 protocol with a particular subset of ciphers. The client can offer 2 ciphers, cipher1 that is valid per 9.2.2 and will work for h2, and cipher2 that is not valid for h2, but will work for http/1.1. At this point, the server has to have a knowledge about what ciphers are good for what protocol. Writing this code in a future-proof way is difficult. Even preferring client ciphers, which is only possible in JDK 8, is not enough, as we may choose the wrong one if the client sends them without a particular order. For example two browsers may send one (cipher1, cipher2), and another (cipher2, cipher1). Say that in future cipher FOO is discovered and found to be suitable for h2. An old h2 client is not aware of FOO, and won't accept it as valid for h2. But when the old h2 client is deployed in JDK 9, which does offer FOO, a server can select FOO because the client offered it, negotiate h2, but the client will close the connection because it won't recognize FOO as a valid cipher for h2. My statement about the difficulty of implementation went a bit beyond about strictly ALPN, but also taking in account server implementations of h2. We are trying to have section 9.2.2 modified so that it drops this linking and leaves everything to TLS (for example by just stating that a particular version (or greater) of TLS is mandatory for h2, without mentioning ciphers). For reference the discussion happens at http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2112.html. -- 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 Wed Sep 17 13:18:42 2014 From: simone.bordet at gmail.com (Simone Bordet) Date: Wed, 17 Sep 2014 15:18:42 +0200 Subject: TLS extensions API, ALPN and HTTP 2.0 In-Reply-To: References: <54196911.6050903@oracle.com> Message-ID: See also: https://github.com/http2/http2-spec/issues/612 On Wed, Sep 17, 2014 at 3:17 PM, Simone Bordet wrote: > Hi, > > On Wed, Sep 17, 2014 at 12:57 PM, Michael McMahon > wrote: >> Hi Simone, >> >> I'm interested to understand why you think this Http 2 requirement >> is difficult or impossible to implement in the JDK currently. >> >> I thought, cipher suite selection would be independent of the ALPN >> mechanism. > > Indeed they should be independent, but section 9.2.2 poses constraint > and links the h2 protocol with a particular subset of ciphers. > > The client can offer 2 ciphers, cipher1 that is valid per 9.2.2 and > will work for h2, and cipher2 that is not valid for h2, but will work > for http/1.1. > > At this point, the server has to have a knowledge about what ciphers > are good for what protocol. > Writing this code in a future-proof way is difficult. > > Even preferring client ciphers, which is only possible in JDK 8, is > not enough, as we may choose the wrong one if the client sends them > without a particular order. > For example two browsers may send one (cipher1, cipher2), and another > (cipher2, cipher1). > > Say that in future cipher FOO is discovered and found to be suitable for h2. > An old h2 client is not aware of FOO, and won't accept it as valid for h2. > But when the old h2 client is deployed in JDK 9, which does offer FOO, > a server can select FOO because the client offered it, negotiate h2, > but the client will close the connection because it won't recognize > FOO as a valid cipher for h2. > > My statement about the difficulty of implementation went a bit beyond > about strictly ALPN, but also taking in account server implementations > of h2. > > We are trying to have section 9.2.2 modified so that it drops this > linking and leaves everything to TLS (for example by just stating that > a particular version (or greater) of TLS is mandatory for h2, without > mentioning ciphers). > > For reference the discussion happens at > http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2112.html. > > -- > 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 -- 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 Wed Sep 17 14:11:06 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 17 Sep 2014 15:11:06 +0100 Subject: TLS extensions API, ALPN and HTTP 2.0 In-Reply-To: References: <54196911.6050903@oracle.com> Message-ID: <5419967A.9060500@oracle.com> Okay, I see the point you are making. It's more a question of whether the constraints themselves are appropriate. I've another question. In the work you've done so far, did you allow for the possibility of separate certificates to be selected per ALPN instance? I'm guessing that if multiple applications are to be supported over one TCP port (client or server) then different certificates might be needed for each application. Or is that not a reasonable assumption? Thanks, Michael On 17/09/14 14:18, Simone Bordet wrote: > See also: https://github.com/http2/http2-spec/issues/612 > > On Wed, Sep 17, 2014 at 3:17 PM, Simone Bordet wrote: >> Hi, >> >> On Wed, Sep 17, 2014 at 12:57 PM, Michael McMahon >> wrote: >>> Hi Simone, >>> >>> I'm interested to understand why you think this Http 2 requirement >>> is difficult or impossible to implement in the JDK currently. >>> >>> I thought, cipher suite selection would be independent of the ALPN >>> mechanism. >> Indeed they should be independent, but section 9.2.2 poses constraint >> and links the h2 protocol with a particular subset of ciphers. >> >> The client can offer 2 ciphers, cipher1 that is valid per 9.2.2 and >> will work for h2, and cipher2 that is not valid for h2, but will work >> for http/1.1. >> >> At this point, the server has to have a knowledge about what ciphers >> are good for what protocol. >> Writing this code in a future-proof way is difficult. >> >> Even preferring client ciphers, which is only possible in JDK 8, is >> not enough, as we may choose the wrong one if the client sends them >> without a particular order. >> For example two browsers may send one (cipher1, cipher2), and another >> (cipher2, cipher1). >> >> Say that in future cipher FOO is discovered and found to be suitable for h2. >> An old h2 client is not aware of FOO, and won't accept it as valid for h2. >> But when the old h2 client is deployed in JDK 9, which does offer FOO, >> a server can select FOO because the client offered it, negotiate h2, >> but the client will close the connection because it won't recognize >> FOO as a valid cipher for h2. >> >> My statement about the difficulty of implementation went a bit beyond >> about strictly ALPN, but also taking in account server implementations >> of h2. >> >> We are trying to have section 9.2.2 modified so that it drops this >> linking and leaves everything to TLS (for example by just stating that >> a particular version (or greater) of TLS is mandatory for h2, without >> mentioning ciphers). >> >> For reference the discussion happens at >> http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2112.html. >> >> -- >> 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.coffey at oracle.com Wed Sep 17 15:00:01 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Wed, 17 Sep 2014 16:00:01 +0100 Subject: [9] RFR 8056026 Debug security logging should print Provider used for each crypto operation In-Reply-To: <7C8A77B0-52D2-4C50-9A71-7B71EB49EEEE@oracle.com> References: <541701F9.8000609@oracle.com> <54170ACD.9020005@oracle.com> <241BE800-B528-4D72-865A-2F55C311283B@oracle.com> <541856DC.1040108@oracle.com> <5418A688.5010500@oracle.com> <7C8A77B0-52D2-4C50-9A71-7B71EB49EEEE@oracle.com> Message-ID: <5419A1F1.1070004@oracle.com> Thanks for tackling this one Vinnie. It'll certainly help better debug environments where several providers are available to perform similar crypto operations. One minor suggestion might be to use a simple boolean to control whether the engine provider info gets printed. i.e. change "private static final boolean skipDebug = Debug.isOn("engine=") && !Debug.isOn(?XXX?);" to "private static final boolean printProviderEngine = pdebug != null && Debug.isOn("engine=") && Debug.isOn(?XXX?); Might read better but minor like I say. regards, Sean. On 17/09/14 11:33, Vincent Ryan wrote: > I?ve renamed that boolean flag and inverted its logic: > > - privatestaticfinalbooleandoDebug = !(Debug.isOn("engine=") && > !Debug.isOn(?XXX")); > + privatestaticfinalbooleanskipDebug = Debug.isOn("engine=") && > !Debug.isOn(?XXX?); > > > Updated webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.02/ > > > Docs bug: https://bugs.openjdk.java.net/browse/JDK-8058624 > > > On 16 Sep 2014, at 22:07, Sean Mullan > wrote: > >> On 09/16/2014 11:27 AM, Vincent Ryan wrote: >>> Here's an updated webrev that supports including/excluding specific >>> JCA engines: >>> >>> Webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.01/ >>> >> >> Looks good, although the doDebug boolean is making my head spin, is >> there an easier way to specify that? >> >> Also, can you open a corresponding docs bug to update the >> troubleshooting guide: >> http://docs.oracle.com/javase/8/docs/technotes/guides/security/troubleshooting-security.html >> >> --Sean >> >>> >>> >>> For example, use the following to trace only MessageDigest and >>> Signature engines: >>> >>> -Djava.security.debug=provider:engine=MessageDigest,Signature >>> >>> and use the following to trace all supported engines: >>> >>> -Djava.security.debug=provider >>> or >>> -Djava.security.debug=all >>> >>> >>> >>> On 15/09/2014 16:57, Vincent Ryan wrote: >>>> >>>> On 15 Sep 2014, at 16:50, Sean Mullan >>> > wrote: >>>> >>>>> On 09/15/2014 11:34 AM, Vincent Ryan wrote: >>>>>> Originally I did support tracing for MessageDigest but removed it >>>>>> because of the huge quantity of log messages that were generated. >>>>>> Hashes are very widely used before an application even starts. >>>>>> SecureRandom is similar. >>>>> >>>>> Hmm, it would be nice to specify the engine classes you want to see. >>>>> Maybe that's too much work right now, but something like: >>>>> >>>>> java -Djava.security.debug="provider engine=MessageDigest,Signature" ? >>>> >>>> We can log the JCE provider for all engine classes by default and also >>>> support a filtering mechanism using the ?engine' sub-option as you >>>> suggest above. >>>> >>>> >>>>> >>>>>> Also I omitted KeyStore log messages because there is usually only a >>>>>> single implementation for a given keystore type so the >>>>>> JCE provider which has been selected is obvious. I?ll add support >>>>>> for KeyStore. >>>>> >>>>> Ok. I think it would be primarily useful to see the KeyStore when >>>>> PKCS11 is used with unextractable keys to help debug any subsequent >>>>> delayed provider selection. >>>>> >>>>> --Sean >>>>> >>>>>> >>>>>> >>>>>> On 15 Sep 2014, at 16:12, Sean Mullan >>>>> > wrote: >>>>>> >>>>>>> Can you also add similar log messages for MessageDigest, >>>>>>> SecureRandom, and KeyStore? >>>>>>> >>>>>>> Otherwise looks good. Please add a noreg label. Also the fix is >>>>>>> helpful to any platform and not just solaris/sparc so you should >>>>>>> change those fields to be generic. >>>>>>> >>>>>>> --Sean >>>>>>> >>>>>>> On 09/12/2014 11:11 AM, Vincent Ryan wrote: >>>>>>>> >>>>>>>> Please review this change to display the JCE provider that has been >>>>>>>> selected for common crypto operations. >>>>>>>> This aids troubleshooting crypto applications when a given crypto >>>>>>>> algorithm is supported by several JCE providers. >>>>>>>> Some crypto operations delay selecting a provider until they >>>>>>>> examine the >>>>>>>> key supplied in the init() method. >>>>>>>> This fix also accommodates that behaviour. >>>>>>>> >>>>>>>> The following crypto operations are supported: Cipher, >>>>>>>> KeyAgreement, >>>>>>>> KeyGenerator, KeyPairGenerator, Mac and Signature. >>>>>>>> To see these new messages, activate JCE provider debugging as >>>>>>>> normal. >>>>>>>> For example, >>>>>>>> >>>>>>>> % java -Djava.security.debug=provider MySSLClientApp >>>>>>>> : >>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>>> Provider: Signature.SHA1withDSA verification from: >>>>>>>> SunPKCS11-Solaris >>>>>>>> Provider: Signature.SHA1withDSA verification from: >>>>>>>> SunPKCS11-Solaris >>>>>>>> Provider: Signature.MD5withRSA verification from: SunPKCS11-Solaris >>>>>>>> Provider: Signature.MD5withRSA verification from: SunPKCS11-Solaris >>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>>> Provider: KeyPairGenerator.EC from: SunPKCS11-Solaris >>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>>> Provider: KeyGenerator.SunTls12RsaPremasterSecret from: SunJCE >>>>>>>> Provider: Cipher.RSA/ECB/PKCS1Padding key wrapping from: >>>>>>>> SunPKCS11-Solaris >>>>>>>> Provider: KeyGenerator.SunTls12MasterSecret from: SunJCE >>>>>>>> Provider: KeyGenerator.SunTls12KeyMaterial from: SunJCE >>>>>>>> Provider: Signature.SHA512withRSA signing from: SunPKCS11-Solaris >>>>>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>>> Provider: KeyGenerator.SunTls12KeyMaterial from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>>>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>>> : >>>>>>>> >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8056026 >>>>>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.00/ >>>>>>>> >>>>>> >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Wed Sep 17 15:04:34 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 17 Sep 2014 17:04:34 +0200 Subject: [undertow-dev] NoSuchMethod in 9ea-b30 getRawHostnameSE In-Reply-To: <5418EE6D.6010004@redhat.com> References: <20140917033827.00002df6.ecki@zusammenkunft.net> <5418EE6D.6010004@redhat.com> Message-ID: <20140917170434.00000e0e.ecki@zusammenkunft.net> Hello, thanks Stuart, I should have known to look for this. I mentioned before, that this is a quite important thing for JSSE to support (or actually the SSL API). But I did not expect that the JEtty workaround is already used. Hopefully Simone can influence the JDK to make stuff like this less painfull and keep Java as recent as protocol support as one would expect. (And sorry for the "false" alert, rory :) Gruss Bernd Am Wed, 17 Sep 2014 12:14:05 +1000 schrieb Stuart Douglas : > This is because Undertow is testing SPDY and HTTP2, which use Jetty > ALPN. This jar resides on the boot class path, and you need to use a > specific version of it for a given JVM. > > Undertow uses profiles to select between JDK 7 and 8, however it > looks like it will attempt to use the 8 jar if you test on 9. I will > look at updating the build to just ignore these tests if the > appropriate version of the ALPN jar is not available. > > Stuart > > Bernd Eckenfels wrote: > > Hello JDK security team, > > (cced the Undertow guys cause I mentioned this on the IRC channel) > > > > > > when trying to run the JBoss Undertow build tests with JDK9ea-b30 a > > lot of tests fail with the same "NosuchMethodError", and I am not > > sure why. > > > > It looks like an internal inconsitency in the JSSE? However I tries > > the simple SSLEngine demo code and that one compiles and runs. > > > > Undertow master 79daf29 > > https://github.com/undertow-io/undertow/tree/79daf29322940f93a42f736a2cd959f6d0a7a5de > > > > maven 3.2.3 Windows x64 7 > > this is using xnio-api and xnio-nio 3.3.0.Beta3 (from > > jboss-public-repository-group) > > > > > > One of the observed exceptions (but not related to SPDY IMHO): > > > > 03:26:29,211 ERROR (XNIO-1 I/O-2) > > [org.xnio.listener] XNIO001007: A > > channel event listener threw an exception: > > > > java.lang.NoSuchMethodError: > > sun.security.ssl.ClientHandshaker.getRawHostnameSE()Ljava/lang/String; > > at > > sun.security.ssl.ClientHandshaker.getKickstartMessage(ClientHandshaker.java:1294) > > at sun.security.ssl.Handshaker.kickstart(Handshaker.java:972) at > > sun.security.ssl.SSLEngineImpl.kickstartHandshake(SSLEngineImpl.java:728) > > at > > sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:750) > > > > at > > org.xnio.ssl.JsseSslConduitEngine.beginHandshake(JsseSslConduitEngine.java:177) > > at > > org.xnio.ssl.JsseSslStreamConnection.startHandshake(JsseSslStreamConnection.java:85) > > at > > io.undertow.client.spdy.SpdyClientProvider.handlePotentialSpdyConnection(SpdyClientProvider.java:222) > > at > > io.undertow.client.http.HttpClientProvider.handleConnected(HttpClientProvider.java:132) > > at > > io.undertow.client.http.HttpClientProvider.access$000(HttpClientProvider.java:49) > > at > > io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:123) > > at > > io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:120) > > at > > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > > at > > org.xnio.ssl.JsseXnioSsl$StreamConnectionChannelListener.handleEvent(JsseXnioSsl.java:283) > > at > > org.xnio.ssl.JsseXnioSsl$StreamConnectionChannelListener.handleEvent(JsseXnioSsl.java:265) > > at > > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > > at > > org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:324) > > at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) > > > > > > As xnio (the NIO abstraction used by undertow) uses asm and some > > unsafe functions it might not be the cleanest test, however the > > stacktrace looks like the problem is all inside javax.ssl / JSSE? > > > > I am not sure where to look for the right JDK source version, is > > this before or after the modular split? The latest code does not > > seem to match the stacktrace: > > > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/40c3a5ce8047/src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java > > > > Gruss > > Bernd > > > > > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev From simone.bordet at gmail.com Wed Sep 17 15:25:53 2014 From: simone.bordet at gmail.com (Simone Bordet) Date: Wed, 17 Sep 2014 17:25:53 +0200 Subject: TLS extensions API, ALPN and HTTP 2.0 In-Reply-To: <5419967A.9060500@oracle.com> References: <54196911.6050903@oracle.com> <5419967A.9060500@oracle.com> Message-ID: Hi, On Wed, Sep 17, 2014 at 4:11 PM, Michael McMahon wrote: > Okay, I see the point you are making. It's more a question of whether > the constraints themselves are appropriate. And convince the HTTP/2 editors :( > I've another question. In the work you've done so far, did you allow > for the possibility of separate certificates to be selected per ALPN > instance? > > I'm guessing that if multiple applications are to be supported > over one TCP port (client or server) then different certificates might be > needed for each application. Or is that not a reasonable assumption? If I understand you correctly, you are saying that you want a connection with SNI=foo.domain.com to *not* trigger ALPN, but a connection with SNI=bar.domain.com to trigger ALPN ? We don't support this right now in Jetty, but the current ALPN API probably does: at the moment of selecting the protocol, the application can retrieve the SNI and decide what protocol to select. See for example: http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/tree/jetty-alpn/jetty-alpn-server/src/main/java/org/eclipse/jetty/alpn/server/ALPNServerConnection.java#n49 There you can call getSSLEngine(), which will be able to return a number of information about the handshake (such as the cipher chosen). Makes sense ? -- 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 vincent.x.ryan at oracle.com Wed Sep 17 15:24:35 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 17 Sep 2014 16:24:35 +0100 Subject: [9] RFR 8056026 Debug security logging should print Provider used for each crypto operation In-Reply-To: <5419A1F1.1070004@oracle.com> References: <541701F9.8000609@oracle.com> <54170ACD.9020005@oracle.com> <241BE800-B528-4D72-865A-2F55C311283B@oracle.com> <541856DC.1040108@oracle.com> <5418A688.5010500@oracle.com> <7C8A77B0-52D2-4C50-9A71-7B71EB49EEEE@oracle.com> <5419A1F1.1070004@oracle.com> Message-ID: <73367543-783B-41B9-A6DA-B9DC8154BD1F@oracle.com> On 17 Sep 2014, at 16:00, Se?n Coffey wrote: > Thanks for tackling this one Vinnie. It'll certainly help better debug environments > where several providers are available to perform similar crypto operations. > > One minor suggestion might be to use a simple boolean to control whether > the engine provider info gets printed. > > i.e. change "private static final boolean skipDebug = Debug.isOn("engine=") && !Debug.isOn(?XXX?);" > to "private static final boolean printProviderEngine = > pdebug != null && Debug.isOn("engine=") && Debug.isOn(?XXX?); This requires an engine to be explicitly listed in order to get traced. I?d also like to support tracing for 'java.security.debug=all' and 'java.security.debug=provider'. > > Might read better but minor like I say. > > regards, > Sean. > > On 17/09/14 11:33, Vincent Ryan wrote: >> I?ve renamed that boolean flag and inverted its logic: >> >> - private static final boolean doDebug = !(Debug.isOn("engine=") && !Debug.isOn(?XXX")); >> + private static final boolean skipDebug = Debug.isOn("engine=") && !Debug.isOn(?XXX?); >> >> >> Updated webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.02/ >> >> Docs bug: https://bugs.openjdk.java.net/browse/JDK-8058624 >> >> >> On 16 Sep 2014, at 22:07, Sean Mullan wrote: >> >>> On 09/16/2014 11:27 AM, Vincent Ryan wrote: >>>> Here's an updated webrev that supports including/excluding specific >>>> JCA engines: >>>> >>>> Webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.01/ >>> >>> Looks good, although the doDebug boolean is making my head spin, is there an easier way to specify that? >>> >>> Also, can you open a corresponding docs bug to update the troubleshooting guide: http://docs.oracle.com/javase/8/docs/technotes/guides/security/troubleshooting-security.html >>> >>> --Sean >>> >>>> >>>> >>>> For example, use the following to trace only MessageDigest and >>>> Signature engines: >>>> >>>> -Djava.security.debug=provider:engine=MessageDigest,Signature >>>> >>>> and use the following to trace all supported engines: >>>> >>>> -Djava.security.debug=provider >>>> or >>>> -Djava.security.debug=all >>>> >>>> >>>> >>>> On 15/09/2014 16:57, Vincent Ryan wrote: >>>>> >>>>> On 15 Sep 2014, at 16:50, Sean Mullan wrote: >>>>> >>>>>> On 09/15/2014 11:34 AM, Vincent Ryan wrote: >>>>>>> Originally I did support tracing for MessageDigest but removed it >>>>>>> because of the huge quantity of log messages that were generated. >>>>>>> Hashes are very widely used before an application even starts. >>>>>>> SecureRandom is similar. >>>>>> >>>>>> Hmm, it would be nice to specify the engine classes you want to see. >>>>>> Maybe that's too much work right now, but something like: >>>>>> >>>>>> java -Djava.security.debug="provider engine=MessageDigest,Signature" ? >>>>> >>>>> We can log the JCE provider for all engine classes by default and also >>>>> support a filtering mechanism using the ?engine' sub-option as you >>>>> suggest above. >>>>> >>>>> >>>>>> >>>>>>> Also I omitted KeyStore log messages because there is usually only a >>>>>>> single implementation for a given keystore type so the >>>>>>> JCE provider which has been selected is obvious. I?ll add support >>>>>>> for KeyStore. >>>>>> >>>>>> Ok. I think it would be primarily useful to see the KeyStore when >>>>>> PKCS11 is used with unextractable keys to help debug any subsequent >>>>>> delayed provider selection. >>>>>> >>>>>> --Sean >>>>>> >>>>>>> >>>>>>> >>>>>>> On 15 Sep 2014, at 16:12, Sean Mullan wrote: >>>>>>> >>>>>>>> Can you also add similar log messages for MessageDigest, >>>>>>>> SecureRandom, and KeyStore? >>>>>>>> >>>>>>>> Otherwise looks good. Please add a noreg label. Also the fix is >>>>>>>> helpful to any platform and not just solaris/sparc so you should >>>>>>>> change those fields to be generic. >>>>>>>> >>>>>>>> --Sean >>>>>>>> >>>>>>>> On 09/12/2014 11:11 AM, Vincent Ryan wrote: >>>>>>>>> >>>>>>>>> Please review this change to display the JCE provider that has been >>>>>>>>> selected for common crypto operations. >>>>>>>>> This aids troubleshooting crypto applications when a given crypto >>>>>>>>> algorithm is supported by several JCE providers. >>>>>>>>> Some crypto operations delay selecting a provider until they >>>>>>>>> examine the >>>>>>>>> key supplied in the init() method. >>>>>>>>> This fix also accommodates that behaviour. >>>>>>>>> >>>>>>>>> The following crypto operations are supported: Cipher, KeyAgreement, >>>>>>>>> KeyGenerator, KeyPairGenerator, Mac and Signature. >>>>>>>>> To see these new messages, activate JCE provider debugging as normal. >>>>>>>>> For example, >>>>>>>>> >>>>>>>>> % java -Djava.security.debug=provider MySSLClientApp >>>>>>>>> : >>>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>>>> Provider: Signature.SHA1withDSA verification from: SunPKCS11-Solaris >>>>>>>>> Provider: Signature.SHA1withDSA verification from: SunPKCS11-Solaris >>>>>>>>> Provider: Signature.MD5withRSA verification from: SunPKCS11-Solaris >>>>>>>>> Provider: Signature.MD5withRSA verification from: SunPKCS11-Solaris >>>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>>>> Provider: KeyPairGenerator.EC from: SunPKCS11-Solaris >>>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>>>> Provider: KeyGenerator.SunTls12RsaPremasterSecret from: SunJCE >>>>>>>>> Provider: Cipher.RSA/ECB/PKCS1Padding key wrapping from: >>>>>>>>> SunPKCS11-Solaris >>>>>>>>> Provider: KeyGenerator.SunTls12MasterSecret from: SunJCE >>>>>>>>> Provider: KeyGenerator.SunTls12KeyMaterial from: SunJCE >>>>>>>>> Provider: Signature.SHA512withRSA signing from: SunPKCS11-Solaris >>>>>>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>>>> Provider: KeyGenerator.SunTls12KeyMaterial from: SunJCE >>>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>>>>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>>>> : >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8056026 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.00/ >>>>>>> >>>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simone.bordet at gmail.com Wed Sep 17 15:30:37 2014 From: simone.bordet at gmail.com (Simone Bordet) Date: Wed, 17 Sep 2014 17:30:37 +0200 Subject: [undertow-dev] NoSuchMethod in 9ea-b30 getRawHostnameSE In-Reply-To: <20140917170434.00000e0e.ecki@zusammenkunft.net> References: <20140917033827.00002df6.ecki@zusammenkunft.net> <5418EE6D.6010004@redhat.com> <20140917170434.00000e0e.ecki@zusammenkunft.net> Message-ID: Hi, On Wed, Sep 17, 2014 at 5:04 PM, Bernd Eckenfels wrote: > Hello, > > thanks Stuart, I should have known to look for this. > > I mentioned before, that this is a quite important thing for JSSE to > support (or actually the SSL API). But I did not expect that the JEtty > workaround is already used. In Jetty we have a mechanism to start the server with ALPN only if we have the right version of ALPN for the JDK that is running the server. For example, Jetty would refuse to start with a message in JDK 9 with ALPN enabled. A bit harsh, but at least you know what's going on :) But yes, having ALPN support in JDK 9 will definitely be great. -- 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 Wed Sep 17 15:41:15 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 17 Sep 2014 16:41:15 +0100 Subject: TLS extensions API, ALPN and HTTP 2.0 In-Reply-To: References: <54196911.6050903@oracle.com> <5419967A.9060500@oracle.com> Message-ID: <5419AB9B.2010909@oracle.com> On 17/09/14 16:25, Simone Bordet wrote: > Hi, > > On Wed, Sep 17, 2014 at 4:11 PM, Michael McMahon > wrote: >> Okay, I see the point you are making. It's more a question of whether >> the constraints themselves are appropriate. > And convince the HTTP/2 editors :( > >> I've another question. In the work you've done so far, did you allow >> for the possibility of separate certificates to be selected per ALPN >> instance? >> >> I'm guessing that if multiple applications are to be supported >> over one TCP port (client or server) then different certificates might be >> needed for each application. Or is that not a reasonable assumption? No, I was thinking something like the following: foo.domain.com:443 supports two different server applications - "h2" and something else (say some proprietary application "fooapp"). They require two different certificates and we want TLS to choose the right cert for the right application. Or it could be a client trying to connect to either of the two applications above on port 443, and where the client wishes to use two different client certs. It is analogous to SNI because the choice of the cert has to occur during the TLS handshake, which is why it needs to be built into TLS. But, I assume that SNI is able to choose a cert based on the domain name and doesn't need any additional help from the API. - Michael > If I understand you correctly, you are saying that you want a > connection with SNI=foo.domain.com to *not* trigger ALPN, but a > connection with SNI=bar.domain.com to trigger ALPN ? > > We don't support this right now in Jetty, but the current ALPN API > probably does: at the moment of selecting the protocol, the > application can retrieve the SNI and decide what protocol to select. > See for example: > http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/tree/jetty-alpn/jetty-alpn-server/src/main/java/org/eclipse/jetty/alpn/server/ALPNServerConnection.java#n49 > There you can call getSSLEngine(), which will be able to return a > number of information about the handshake (such as the cipher chosen). > > Makes sense ? > From simone.bordet at gmail.com Wed Sep 17 17:18:56 2014 From: simone.bordet at gmail.com (Simone Bordet) Date: Wed, 17 Sep 2014 19:18:56 +0200 Subject: TLS extensions API, ALPN and HTTP 2.0 In-Reply-To: <5419AB9B.2010909@oracle.com> References: <54196911.6050903@oracle.com> <5419967A.9060500@oracle.com> <5419AB9B.2010909@oracle.com> Message-ID: Hi, On Wed, Sep 17, 2014 at 5:41 PM, Michael McMahon wrote: > No, I was thinking something like the following: > > foo.domain.com:443 supports two different server applications - "h2" > and something else (say some proprietary application "fooapp"). > They require two different certificates and we want > TLS to choose the right cert for the right application. > > Or it could be a client trying to connect to either of the two applications > above on port 443, and where the client wishes to use two different > client certs. > > It is analogous to SNI because the choice of the cert has to occur > during the TLS handshake, which is why it needs to be built into TLS. > But, I assume that SNI is able to choose a cert based on the domain > name and doesn't need any additional help from the API. SNI is a property of the connection, AFAIK, therefore clients that want to connect to the same server with different SNIs would need to open different connections, right ? If there are different connections, then ALPN can be negotiated differently on each connection. For the server to differentiate between those 2 connections he would need the SNI information, which I don't think it's currently available in JDK 8, right ? That is why I was proposing for a review of the whole TLS extensions API: I would like a server to be able to do something like: TLSExtension sni = sslEngine.findTLSExtension(SNITLSExtension.class) rather than http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/samples/sni/SSLExplorer.java (yuck :) -- 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 vincent.x.ryan at oracle.com Wed Sep 17 17:57:57 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 17 Sep 2014 18:57:57 +0100 Subject: JEP Review Request: Transition the default keystore type from JKS to PKCS12 Message-ID: <5419CBA5.5090902@oracle.com> Hello, The draft JEP ?Transition the default keystore type from JKS to PKCS12? is now available for community review: https://bugs.openjdk.java.net/browse/JDK-8044445 It?s a proposal to move to an improved default keystore format without disrupting existing applications that access keystores. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Sep 17 19:12:15 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 17 Sep 2014 15:12:15 -0400 Subject: [9] RFR 8056026 Debug security logging should print Provider used for each crypto operation In-Reply-To: <7C8A77B0-52D2-4C50-9A71-7B71EB49EEEE@oracle.com> References: <541701F9.8000609@oracle.com> <54170ACD.9020005@oracle.com> <241BE800-B528-4D72-865A-2F55C311283B@oracle.com> <541856DC.1040108@oracle.com> <5418A688.5010500@oracle.com> <7C8A77B0-52D2-4C50-9A71-7B71EB49EEEE@oracle.com> Message-ID: <5419DD0F.5000503@oracle.com> Looks good to me. --Sean On 09/17/2014 06:33 AM, Vincent Ryan wrote: > I?ve renamed that boolean flag and inverted its logic: > > - privatestaticfinalbooleandoDebug = !(Debug.isOn("engine=") && > !Debug.isOn(?XXX")); > + privatestaticfinalbooleanskipDebug = Debug.isOn("engine=") && > !Debug.isOn(?XXX?); > > > Updated webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.02/ > > Docs bug: https://bugs.openjdk.java.net/browse/JDK-8058624 > > > On 16 Sep 2014, at 22:07, Sean Mullan > wrote: > >> On 09/16/2014 11:27 AM, Vincent Ryan wrote: >>> Here's an updated webrev that supports including/excluding specific >>> JCA engines: >>> >>> Webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.01/ >> >> Looks good, although the doDebug boolean is making my head spin, is >> there an easier way to specify that? >> >> Also, can you open a corresponding docs bug to update the >> troubleshooting guide: >> http://docs.oracle.com/javase/8/docs/technotes/guides/security/troubleshooting-security.html >> >> --Sean >> >>> >>> >>> For example, use the following to trace only MessageDigest and >>> Signature engines: >>> >>> -Djava.security.debug=provider:engine=MessageDigest,Signature >>> >>> and use the following to trace all supported engines: >>> >>> -Djava.security.debug=provider >>> or >>> -Djava.security.debug=all >>> >>> >>> >>> On 15/09/2014 16:57, Vincent Ryan wrote: >>>> >>>> On 15 Sep 2014, at 16:50, Sean Mullan >>> > wrote: >>>> >>>>> On 09/15/2014 11:34 AM, Vincent Ryan wrote: >>>>>> Originally I did support tracing for MessageDigest but removed it >>>>>> because of the huge quantity of log messages that were generated. >>>>>> Hashes are very widely used before an application even starts. >>>>>> SecureRandom is similar. >>>>> >>>>> Hmm, it would be nice to specify the engine classes you want to see. >>>>> Maybe that's too much work right now, but something like: >>>>> >>>>> java -Djava.security.debug="provider engine=MessageDigest,Signature" ? >>>> >>>> We can log the JCE provider for all engine classes by default and also >>>> support a filtering mechanism using the ?engine' sub-option as you >>>> suggest above. >>>> >>>> >>>>> >>>>>> Also I omitted KeyStore log messages because there is usually only a >>>>>> single implementation for a given keystore type so the >>>>>> JCE provider which has been selected is obvious. I?ll add support >>>>>> for KeyStore. >>>>> >>>>> Ok. I think it would be primarily useful to see the KeyStore when >>>>> PKCS11 is used with unextractable keys to help debug any subsequent >>>>> delayed provider selection. >>>>> >>>>> --Sean >>>>> >>>>>> >>>>>> >>>>>> On 15 Sep 2014, at 16:12, Sean Mullan >>>>> > wrote: >>>>>> >>>>>>> Can you also add similar log messages for MessageDigest, >>>>>>> SecureRandom, and KeyStore? >>>>>>> >>>>>>> Otherwise looks good. Please add a noreg label. Also the fix is >>>>>>> helpful to any platform and not just solaris/sparc so you should >>>>>>> change those fields to be generic. >>>>>>> >>>>>>> --Sean >>>>>>> >>>>>>> On 09/12/2014 11:11 AM, Vincent Ryan wrote: >>>>>>>> >>>>>>>> Please review this change to display the JCE provider that has been >>>>>>>> selected for common crypto operations. >>>>>>>> This aids troubleshooting crypto applications when a given crypto >>>>>>>> algorithm is supported by several JCE providers. >>>>>>>> Some crypto operations delay selecting a provider until they >>>>>>>> examine the >>>>>>>> key supplied in the init() method. >>>>>>>> This fix also accommodates that behaviour. >>>>>>>> >>>>>>>> The following crypto operations are supported: Cipher, KeyAgreement, >>>>>>>> KeyGenerator, KeyPairGenerator, Mac and Signature. >>>>>>>> To see these new messages, activate JCE provider debugging as >>>>>>>> normal. >>>>>>>> For example, >>>>>>>> >>>>>>>> % java -Djava.security.debug=provider MySSLClientApp >>>>>>>> : >>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>>> Provider: Signature.SHA1withDSA verification from: SunPKCS11-Solaris >>>>>>>> Provider: Signature.SHA1withDSA verification from: SunPKCS11-Solaris >>>>>>>> Provider: Signature.MD5withRSA verification from: SunPKCS11-Solaris >>>>>>>> Provider: Signature.MD5withRSA verification from: SunPKCS11-Solaris >>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>>> Provider: KeyPairGenerator.EC from: SunPKCS11-Solaris >>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign >>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>>> Provider: KeyGenerator.SunTls12RsaPremasterSecret from: SunJCE >>>>>>>> Provider: Cipher.RSA/ECB/PKCS1Padding key wrapping from: >>>>>>>> SunPKCS11-Solaris >>>>>>>> Provider: KeyGenerator.SunTls12MasterSecret from: SunJCE >>>>>>>> Provider: KeyGenerator.SunTls12KeyMaterial from: SunJCE >>>>>>>> Provider: Signature.SHA512withRSA signing from: SunPKCS11-Solaris >>>>>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>>> Provider: KeyGenerator.SunTls12KeyMaterial from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>>>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE >>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE >>>>>>>> : >>>>>>>> >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8056026 >>>>>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.00/ >>>>>> >>>> > From raghu.k.nair at oracle.com Thu Sep 18 07:33:12 2014 From: raghu.k.nair at oracle.com (raghu k.nair) Date: Thu, 18 Sep 2014 13:03:12 +0530 Subject: Review request for CR 8049039 Need new tests for sun.securiy.x509 classes In-Reply-To: <5411D4A2.9050709@oracle.com> References: <53E99EF2.8010900@oracle.com> <53FAECEE.3010007@oracle.com> <53FCCCE6.3080701@oracle.com> <53FD5B06.2020607@oracle.com> <53FDFA94.6050607@oracle.com> <540617B0.7010801@oracle.com> <54086F1E.6010603@oracle.com> <540A1CE8.4060905@oracle.com> <5411D4A2.9050709@oracle.com> Message-ID: <541A8AB8.7070809@oracle.com> Hi Vincent / Jason, Please find the updated webrev with minor changes like re-using println method , possible NPE fixes etc. http://cr.openjdk.java.net/~rhalade/8049039/webrev.05/ Thanks, Raghu Nair On 9/11/2014 10:28 PM, raghu k.nair wrote: > Hi Jason, > I have removed those lines from copyright headers. Here is the > updated webrev. > http://cr.openjdk.java.net/~rhalade/8049039/webrev.04/ > > Thanks, > Raghu Nair > On 9/6/2014 1:58 AM, Jason Uh wrote: >> Hi Raghu, >> >> Formatting looks good, but one last thing about the copyright >> headers. I noticed that in lines 7-9, you have the lines >> >> * ... Oracle designates this >> * particular file as subject to the "Classpath" exception as provided >> * by Oracle in the LICENSE file that accompanied this code. >> >> Can you remove that sentence? In general, I think the license that >> includes those lines is meant for source files, not for test files. >> If you look at other tests, you'll see that this final sentence isn't >> there. >> >> Thanks, >> Jason >> >> On 9/4/14 6:54 AM, raghu k.nair wrote: >>> Hi Jason, >>> Please review the updated webrev . I have addressed your comments. >>> http://cr.openjdk.java.net/~tyan/raghu/8049039/webrev03/ >>> >>> >>> Thanks, >>> Raghu >>> On 9/3/2014 12:47 AM, Jason Uh wrote: >>>> On 8/27/14 8:34 AM, raghu k.nair wrote: >>>>> Hi Vincent / Jason, >>>>> Please review the updated webrev based on Jason's comments. >>>>> webrev: http://cr.openjdk.java.net/~tyan/raghu/8049039/webrev02/ >>>>> >>>>> >>>>> Thanks, >>>>> Raghu Nair >>>>> On 8/27/2014 9:43 AM, raghu k.nair wrote: >>>>>> Hi Jason, >>>>>> Thanks for your review comments. >>>>>> On 8/26/2014 11:37 PM, Jason Uh wrote: >>>>>>> Hi Raghu, >>>>>>> >>>>>>> I'm not an official Reviewer, but I have some comments, mostly >>>>>>> about >>>>>>> X509Test.java. >>>>>>> >>>>>>> 1. I'm not sure if this matters, but the formatting of your >>>>>>> copyright >>>>>>> header is a little strange. The text appears to be correct, but the >>>>>>> line breaks occur at non-standard places. If you look at any other >>>>>>> file, the first couple lines would look like this: >>>>>>> >>>>>>> /* >>>>>>> * Copyright (c) 2014, Oracle and/or its affiliates. All rights >>>>>>> reserved. >>>>>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>>>> >>>>>>> Again, not sure how important this is, but it applies to every file >>>>>>> in the webrev. I'd suggest changing them. >>>>>>> >>>>>> This happened due to default formatting by Netbeans . I will correct >>>>>> it. >>>> >>>> I was actually showing the issue with the entire copyright header by >>>> quoting just the beginning. Sorry if I wasn't clear, but it looks like >>>> you only corrected the formatting on the first two lines. Could you >>>> please redo the entire copyright header for all of these files? (You >>>> can look at any existing test for reference and you'll see the >>>> difference.) >>>> >>>>>>> 2. checkMethod(): >>>>>>> Doesn't appear to be used anywhere. Do you want to keep this? If >>>>>>> you >>>>>>> do, could you add a comment to explain the parameters? >>>>>>> >>>>>>> Also, in general for the rest of the methods, there are a lot of >>>>>>> parameters noted with the @param tag. If you want to leave those >>>>>>> javadoc style comments in, could you please describe the params? >>>>>>> >>>>>> X509Test is used by many other tests ( appart from these tests as >>>>>> part >>>>>> of the webrev). I will add comment and description for the params. >>>>>> >>>> >>>> Minor detail, but there is an extra space in line 53 and 55 of >>>> X509Test. Could you please remove them? >>>> >>>> Otherwise, looks good to me, but you'll still need an official >>>> Reviewer. >>>> >>>> Thanks, >>>> Jason >>>> >>>>>>> 3. equals() and assertByteArray() both seem to be >>>>>>> "assertEquals()"-style methods, but they are named a bit >>>>>>> differently. >>>>>>> could you make the naming consistent? For example, maybe >>>>>>> assertEquals >>>>>>> / assertByteArrayEquals. >>>>>>> >>>>>> Yes it make sense. I will make the necessary changes . >>>>>> >>>>>> 4. getElementesTest() should probably read getElementsTest(). You >>>>>> use >>>>>> this method in IssuerAlternativeNameExtensionTest.java, by the way. >>>>>> >>>>>> typo needs to be fixed. >>>>>> >>>>>> Thanks, >>>>>> Raghu >>>>>>> Otherwise, I think the tests look good to me, but again, I'm not a >>>>>>> Reviewer, so you still need an official review. >>>>>>> >>>>>>> Thanks, >>>>>>> Jason >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 08/25/2014 03:59 AM, raghu k.nair wrote: >>>>>>>> Hi Vincent / Jason, >>>>>>>> Could you please help in reviewing the following test. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Raghu Nair >>>>>>>> >>>>>>>> On 8/12/2014 10:28 AM, raghu k.nair wrote: >>>>>>>>> Hello, >>>>>>>>> Please review the tests for sun.security.x509 classes. >>>>>>>>> These cover tests for GeneralName, GeneralNames, GeneralSubtree, >>>>>>>>> GeneralSubtrees, IPAddressName and >>>>>>>>> IssuerAlternativeNameExtension. >>>>>>>>> >>>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~rhalade/8049039/webrev.00/ >>>>>>>>> >>>>>>>>> Bug: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049039 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Raghu Nair >>>>>>>> >>>>>> >>>>> >>>> >>> >> > From atsuhiko.yamanaka at gmail.com Thu Sep 18 08:50:29 2014 From: atsuhiko.yamanaka at gmail.com (Atsuhiko Yamanaka) Date: Thu, 18 Sep 2014 17:50:29 +0900 Subject: JDK-8039921: SHA1WithDSA with key > 1024 bits not working Message-ID: Hi there, We have been developing pure java SSH2 client library named as JSch, and you may know that it has been integrated and used in Eclipse, NetBeans, IntelliJ IDEA, ant, Ivy, JGit, etc. Recently, we have received feed backs that JSch has failed to connect to some sshds on Java8. After some investigations, we have found that the problem has been caused by a problem reported at JDK-8039921[1]. It seems some sshds have been using long key for Digital Signature(SHA1WithDSA). On Java7(and previous) JSch can handle such a long key successfully, but on Java8 it can not on Java8, due to a change by JDK-8039921. It means Eclipse, NetBeans, IntelliJ IDEA, ant, Ivy, JGit, etc, can not connect to those sshds anymore on Java8. That change has made huge impacts to those software. Some developer at Oracle has commented as follows[2], For SHA1withDSA signature, DSA keys less than 1024 bits are allowed for the sake of backward compatibility. As for 2048-bit DSA key pairs, they should be used with signature algorithms using the SHA-2 family of message digests as specified in FIPS 186-3. >From my understanding, FIPS 186-3 is the standard to use Digital Signature in Federal Government entities. So, if JDK's JCE(SunJCE) is used in other entities, it should not been influenced by that standard. IMHO, the original motivation of JDK-7044060[3] is to add algorithms required by Suite B Cryptography, and it must not intend to force JDK's JCE to be functional only for Federal Government entities. Please reopen JDK-8039921, and reconsider to allow to use longer key for SHA1WithDSA. [1] https://bugs.openjdk.java.net/browse/JDK-8039921 [2] https://bugs.openjdk.java.net/browse/JDK-8039921?focusedCommentId=13486968&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13486968 [3] https://bugs.openjdk.java.net/browse/JDK-7044060 Sincerely, -- Atsuhiko Yamanaka JCraft,Inc. 1-14-20 HONCHO AOBA-KU, SENDAI, MIYAGI 980-0014 Japan. Tel +81-22-723-2150 Skype callto://jcraft/ Twitter: http://twitter.com/ymnk Facebook: http://facebook.com/aymnk From atsuhiko.yamanaka at gmail.com Thu Sep 18 08:51:35 2014 From: atsuhiko.yamanaka at gmail.com (Atsuhiko Yamanaka) Date: Thu, 18 Sep 2014 17:51:35 +0900 Subject: JDK-8039921: SHA1WithDSA with key > 1024 bits not working Message-ID: Hi there, We have been developing pure java SSH2 client library named as JSch, and you may know that it has been integrated and used in Eclipse, NetBeans, IntelliJ IDEA, ant, Ivy, JGit, etc. Recently we have received feed backs that JSch has failed to connect to some sshd on Java8. After some investigations, we have found that the problem been caused by a problem reported at JDK-8039921[1]. It seems some sshds have been using long key for Digital Signature(SHA1WithDSA), and JSch can handle those key successfully on Java7, but, due to a change by JDK-8039921 on Java8, it can not connect to those sshds any more on Java8. It means Eclipse, NetBeans, IntelliJ IDEA, ant, Ivy, JGit, etc, can not work for those sshds anymore. That change has made huge impacts to those software. Some developer at Oracle has commented as follows[2], For SHA1withDSA signature, DSA keys less than 1024 bits are allowed for the sake of backward compatibility. As for 2048-bit DSA key pairs, they should be used with signature algorithms using the SHA-2 family of message digests as specified in FIPS 186-3. >From my understanding, FIPS 186-3 is the standard to use Digital Signature in Federal Government entities. So, if JDK's JCE(SunJCE) has been used in other entities, it should been not influenced by that standard. [1] https://bugs.openjdk.java.net/browse/JDK-8039921 [2] https://bugs.openjdk.java.net/browse/JDK-8039921?focusedCommentId=13486968&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13486968 From sean.coffey at oracle.com Thu Sep 18 14:52:18 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Thu, 18 Sep 2014 15:52:18 +0100 Subject: RFR: 8057813: Alterations to jdk_security3 test target Message-ID: <541AF1A2.8060007@oracle.com> Continuation of the security test target clean up for jdk7u. 7u doesn't have the test groups concept so I had to break down some test targets to explicit directory names. Also found that the javax/xml/crypto was missing for 7u testing. http://cr.openjdk.java.net/~coffeys/webrev.7u.8057813/webrev/ https://bugs.openjdk.java.net/browse/JDK-8057813 regards, Sean. From sean.mullan at oracle.com Thu Sep 18 15:26:35 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 18 Sep 2014 11:26:35 -0400 Subject: RFR: 8057813: Alterations to jdk_security3 test target In-Reply-To: <541AF1A2.8060007@oracle.com> References: <541AF1A2.8060007@oracle.com> Message-ID: <541AF9AB.2000706@oracle.com> On 09/18/2014 10:52 AM, Se?n Coffey wrote: > Continuation of the security test target clean up for jdk7u. > > 7u doesn't have the test groups concept so I had to break down some > test targets to explicit directory names. Also found that the > javax/xml/crypto > was missing for 7u testing. Good catch, looks good to me. --Sean > > http://cr.openjdk.java.net/~coffeys/webrev.7u.8057813/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8057813 > > regards, > Sean. From valerie.peng at oracle.com Fri Sep 19 00:04:58 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 18 Sep 2014 17:04:58 -0700 Subject: JDK-8039921: SHA1WithDSA with key > 1024 bits not working In-Reply-To: References: Message-ID: <541B732A.2080804@oracle.com> Atsuhiko, Back in Java7, SUN provider only supports DSA keys w/ up-to-1024 bit length. The SHA1withDSA signature doesn't explicitly check and reject longer keys though, so I understand how this may be viewed as a regression. At the time when the large DSA key support is added, we followed the recommendation by FIPS 186-3 since using a shorter hash weakens the security strength offered by the larger key. Regardless of entities, I'd think people prefer to be more secure rather than less. However, if such (potentially insecure) practice is common, we may consider relax the restraint for the sake of being interoperable. Do you have any more info such as CA certs using large DSA keys with SHA1withDSA signature algorithm, etc.? This will help us decide whether and how to best accommodate this. Regards, Valerie On 9/18/2014 1:51 AM, Atsuhiko Yamanaka wrote: > Hi there, > > We have been developing pure java SSH2 client library named as JSch, > and you may know that it has been integrated and used in Eclipse, NetBeans, > IntelliJ IDEA, ant, Ivy, JGit, etc. > > Recently we have received feed backs that JSch has failed to connect > to some sshd on Java8. > After some investigations, we have found that the problem been caused > by a problem reported at JDK-8039921[1]. > > It seems some sshds have been using long key for Digital Signature(SHA1WithDSA), > and JSch can handle those key successfully on Java7, but, due to a > change by JDK-8039921 on Java8, > it can not connect to those sshds any more on Java8. It means > Eclipse, NetBeans, IntelliJ IDEA, ant, Ivy, JGit, etc, > can not work for those sshds anymore. That change has made huge > impacts to those software. > > Some developer at Oracle has commented as follows[2], > For SHA1withDSA signature, DSA keys less than 1024 bits are allowed > for the sake of backward compatibility. As for 2048-bit DSA key pairs, > they should be used with signature algorithms using the SHA-2 family > of message digests as specified in FIPS 186-3. > > From my understanding, FIPS 186-3 is the standard to use Digital > Signature in Federal Government entities. > So, if JDK's JCE(SunJCE) has been used in other entities, it should > been not influenced by that standard. > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8039921 > [2] https://bugs.openjdk.java.net/browse/JDK-8039921?focusedCommentId=13486968&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13486968 From atsuhiko.yamanaka at gmail.com Fri Sep 19 00:56:02 2014 From: atsuhiko.yamanaka at gmail.com (Atsuhiko Yamanaka) Date: Fri, 19 Sep 2014 09:56:02 +0900 Subject: JDK-8039921: SHA1WithDSA with key > 1024 bits not working In-Reply-To: <541B732A.2080804@oracle.com> References: <541B732A.2080804@oracle.com> Message-ID: Hi, Thank you for your quick response, On Fri, Sep 19, 2014 at 9:04 AM, Valerie Peng wrote: > Do you have any > more info such as CA certs using large DSA keys with SHA1withDSA signature > algorithm, etc.? Our problem has appeared in SSH2 connections, not in CA certs. On SSH2 protocol, the key exchange will be used to share the secret between client and server, and that secret will be used to encrypt packets. SHA1WithDSA has been used to confirm if the secret is successfully shared or not. The SSH2's RFCs have defined some methods for key-exchanges. RFC4419[1] has defined "diffie-hellman-group-exchange-sha1" at its Section 3, and it has allowed to use keys between 1024 and 8192. And also, RFC4253[2] has defined "diffie-hellman-group1-sha1". In that key-change method, 1024 bit-length key will be used, but some sshds have been using the longer keys. It seems those sshds have been widely used unfortunately, and pure java SSH2 clients have not been able to connect to them in using Java8's SunJCE. I hope this is the expected answer for your question. [1] http://tools.ietf.org/html/rfc4419 [2] http://tools.ietf.org/html/rfc4253#section-8.1 Sincerely, -- Atsuhiko Yamanaka JCraft,Inc. 1-14-20 HONCHO AOBA-KU, SENDAI, MIYAGI 980-0014 Japan. Tel +81-22-723-2150 Skype callto://jcraft/ Twitter: http://twitter.com/ymnk Facebook: http://facebook.com/aymnk From ecki at zusammenkunft.net Fri Sep 19 01:22:29 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 19 Sep 2014 03:22:29 +0200 Subject: JDK-8039921: SHA1WithDSA with key > 1024 bits not working In-Reply-To: References: <541B732A.2080804@oracle.com> Message-ID: <20140919032229.000011b8.ecki@zusammenkunft.net> Hello, I can understand that the PKI Path implementation or SSL engine does need to do some policy decisions. And for this I guess its not really a problem to combine larger RSA with larger hashes (especially as the CAs need to phase them out anyway). But - as the SSH example shows - there are protocols which have different needs and threat scenarios. Crypto primitives should stay away from that policing. Gruss Bernd Am Fri, 19 Sep 2014 09:56:02 +0900 schrieb Atsuhiko Yamanaka : > Hi, > > Thank you for your quick response, > > On Fri, Sep 19, 2014 at 9:04 AM, Valerie Peng > wrote: > > Do > > you have any more info such as CA certs using large DSA keys with > > SHA1withDSA signature algorithm, etc.? > > Our problem has appeared in SSH2 connections, not in CA certs. > > On SSH2 protocol, the key exchange will be used to share the secret > between client > and server, and that secret will be used to encrypt packets. > SHA1WithDSA has been > used to confirm if the secret is successfully shared or not. The > SSH2's RFCs have defined > some methods for key-exchanges. > > RFC4419[1] has defined "diffie-hellman-group-exchange-sha1" at its > Section 3, and it has > allowed to use keys between 1024 and 8192. And also, RFC4253[2] has > defined "diffie-hellman-group1-sha1". In that key-change method, 1024 > bit-length key will be used, but some sshds have been using > the longer keys. It seems those sshds have been widely used > unfortunately, and pure java SSH2 clients > have not been able to connect to them in using Java8's SunJCE. > > I hope this is the expected answer for your question. > > [1] http://tools.ietf.org/html/rfc4419 > [2] http://tools.ietf.org/html/rfc4253#section-8.1 > > > Sincerely, > -- > Atsuhiko Yamanaka > JCraft,Inc. > 1-14-20 HONCHO AOBA-KU, > SENDAI, MIYAGI 980-0014 Japan. > Tel +81-22-723-2150 > Skype callto://jcraft/ > Twitter: http://twitter.com/ymnk > Facebook: http://facebook.com/aymnk From jason.uh at oracle.com Fri Sep 19 01:27:39 2014 From: jason.uh at oracle.com (Jason Uh) Date: Thu, 18 Sep 2014 18:27:39 -0700 Subject: [9] RFR: 8037550: Update RFC references in javadoc to RFC 5280 Message-ID: <541B868B.4050901@oracle.com> Please review this changeset, which updates references to RFC 3280 to RFC 5280. RFC 5280 has obsoleted 3280. http://cr.openjdk.java.net/~juh/8037550/webrev.03/ Thanks, Jason From weijun.wang at oracle.com Fri Sep 19 02:04:32 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 19 Sep 2014 10:04:32 +0800 Subject: [9] RFR: 8037550: Update RFC references in javadoc to RFC 5280 In-Reply-To: <541B868B.4050901@oracle.com> References: <541B868B.4050901@oracle.com> Message-ID: <2C4F7B47-67E2-4150-A377-903847CDA668@oracle.com> Hi Jason The change looks quite straightforward, but have you checked if our codes actually comply with RFC 5280 especially for those areas where RFC 5280 is different from RFC 3280? http://tools.ietf.org/html/rfc5280#page-5 lists the differences. For example, there is an item: * Section 4.2.1.5 recommends marking the policy mappings extension as critical. RFC 3280 required that the policy mappings extension be marked as non-critical. In PolicyMappingsExtension.java, the 2 constructors that generate a PolicyMappingsExtension object both set critical to false. Is this something we should reconsider? Thanks Max On Sep 19, 2014, at 9:27, Jason Uh wrote: > Please review this changeset, which updates references to RFC 3280 to RFC 5280. RFC 5280 has obsoleted 3280. > > http://cr.openjdk.java.net/~juh/8037550/webrev.03/ > > Thanks, > Jason From zaiyao.liu at oracle.com Fri Sep 19 03:04:00 2014 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Fri, 19 Sep 2014 11:04:00 +0800 Subject: RFR 8048619: Implement tests for converting PKCS12 keystores In-Reply-To: References: <5403CDE6.6070006@oracle.com> Message-ID: <541B9D20.3030006@oracle.com> Hi Max, Can you help to review it? Thanks Kevin ? 2014/9/1 13:25, Wang Weijun ??: > On vacation now. Can you look for someone else? I will be back in Sep 17 if you are not in a hurry. > > --Max > > On Sep 1, 2014, at 9:37, zaiyao liu wrote: > >> Hi Max, >> >> Please review the code change,the purpose of this fix is implement tests that convert PKCS12 keystores to other formats. >> >> Webrev: http://cr.openjdk.java.net/~tyan/kevin/JDK-8048619/webrev01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8048619 >> >> Thanks >> >> Kevin From weijun.wang at oracle.com Fri Sep 19 07:34:46 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 19 Sep 2014 15:34:46 +0800 Subject: RFR 8048619: Implement tests for converting PKCS12 keystores In-Reply-To: <541B9D20.3030006@oracle.com> References: <5403CDE6.6070006@oracle.com> <541B9D20.3030006@oracle.com> Message-ID: <327859DE-91C4-4EE6-B16E-CDD715FCD318@oracle.com> In compareCerts(), you should not compare Certificate.toString(), its equals() method is more reliable. There is no need to define compareKeys() and compareCerts(). Instead, you should try not to repeat lines 223-231 on 252-260. The two calls on lines 204 and 205 have keystore names exchanged but keypass order is the same. Also, with two calls it means the comparisons of keys and certs are duplicated. The else block on line 206 looks strange. Do you mean the size is always 1 here? If so, check it. Otherwise, there is no guarantee the aliases appear in the same order. I would be glad to see a generalized comparison method no matter what the keystore size is. Minor issues: It will be clear if you divide the constant strings at the beginning into 2 parts, one for provider names, and one for algorithms. Line 143 and 145, there should be spaces around the testCase name. --Max On Sep 19, 2014, at 11:04, zaiyao liu wrote: > Hi Max, > > Can you help to review it? > > Thanks > > Kevin > ? 2014/9/1 13:25, Wang Weijun ??: >> On vacation now. Can you look for someone else? I will be back in Sep 17 if you are not in a hurry. >> >> --Max >> >> On Sep 1, 2014, at 9:37, zaiyao liu wrote: >> >>> Hi Max, >>> >>> Please review the code change,the purpose of this fix is implement tests that convert PKCS12 keystores to other formats. >>> >>> Webrev: http://cr.openjdk.java.net/~tyan/kevin/JDK-8048619/webrev01/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048619 >>> >>> Thanks >>> >>> Kevin > From bradford.wetmore at oracle.com Sun Sep 21 22:51:45 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Sun, 21 Sep 2014 15:51:45 -0700 Subject: RFR: JDK-8058845 : Update JCE environment for build improvements Message-ID: <541F5681.2090908@oracle.com> Hi Sean/Mandy/Erik/Magnus/Alan/David/others, Please review: JDK-8058845 : Update JCE environment for build improvements http://cr.openjdk.java.net/~wetmore/8058845/ This change is to alleviate some of the overly-complicated steps we (Oracle) have in building and maintaining the JCE jar files in JDK 9. Besides the Makefiles and a class rename, there is very little change to the Open code for the OpenJDK Security folks. The OpenJDK build folks shouldn't really notice any difference. I do wish we could completely do away with this code completely, but we (Oracle and closed licensees) do still need to follow the regulations. For the Iced Tea maintainers, this will necessitate a small incremental change to your JCE patch. Thanks, Brad From xuelei.fan at oracle.com Mon Sep 22 04:06:47 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 22 Sep 2014 12:06:47 +0800 Subject: RFR 8038089: TLS optional support for Kerberos cipher suites needs to be re-examine In-Reply-To: <54192305.2030905@oracle.com> References: <61B179BE-E775-4A32-9660-D5FFBB4CC150@oracle.com> <5418F18A.9070109@oracle.com> <541919BA.1040601@oracle.com> <2823CD99-98C1-4349-82B7-1D0DD2400AAE@oracle.com> <54192305.2030905@oracle.com> Message-ID: <541FA057.7020301@oracle.com> My idea about the new service looks like: -------------------- public interface ClientKeyExchange { // Get the peer principal of this client key exchange public Principal getPeerPrincipal(); // Get the local principal of this client key exchange public Principal getLocalPrincipal(); // Create a new client key exchange message // // Should be called in client side. public HandshakeMessage createClientKeyExchange(String hostname, AccessControlContext acc, int protocolVerson, SecureRandom rand) throws IOException; // Parse a client key exchange message // // Should be called in server side. public HandshakeMessage parseClientKeyExchange(int protocolVerson, int clientRequestedVersion, SecureRandom rand, byte[] encodedTicket, byte[] encrypted, AccessControlContext acc) throws IOException; // Negotiate the pre-master secret of this client key exchange. public SecretKey clientKeyExchange() throws IOException; } -------------------- Still need a few methods in order to support session resumption. The initialization method may depend on the service loading approach. For example, if it is defined as SPI, we can call it via algorithm name ("KRB5"); if it is defined to be load with ServiceLoader, may need to define a new sub-class for KRB5. In TLS handshaking, the usage of the methods may look like: ----------------------- Client Server krb5-ciphers ---ClientHelloRequst--> Support Krb5? initialize Krb5 ClientKeyExchange <----- ServerHello ---- <---ServerHelloDone---- initialize Krb5 ClientKeyExchange create krb5 ClientKeyExchange message ---ClientKeyExchange--> parse ClientKeyExchange msg get the pre-master secret negotiate the shared secret ---changeCipherSpec---> -------Finished-------> get the pre-master secret negotiate the shared secret <---changeCipherSpec--- <-------Finished------- ... ----------------------- Thanks, Xuelei On 9/17/2014 1:58 PM, Xuelei Fan wrote: > On 9/17/2014 1:49 PM, Wang Weijun wrote: >>> I would prefer we do it now. If I did not miss something, the new design should be more simple >>> and straightforward. >> >> Maybe, but I am not sure since this would surely touch more TLS side codes. If you want to be totally separated, we also need to move the ciphersuites definitions outside CipherSuite.java. The TLS side can iterate through all providers to add them back and create something like a Map. Then we could use this map in all "switch (keyExchange)" blocks. >> >> Do you think it's easier to make these changes based on the current codes? Or based on my modified codes? >> >> Can you describe the KeyExchangeService interface you are thinking about? Currently I have to define a two-level interface -- ExternalCipherSuiteProvider and ExternalCipherSuiteProvider.Exchanger -- to model the service and the exchange instance. >> > OK, I will wrap up my ideas of the KeyExchangeService. But it may take a > few more days. Wish I could get it ready by next Monday. > > Thanks, > Xuelei > From gnu.andrew at redhat.com Mon Sep 22 14:25:41 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 22 Sep 2014 10:25:41 -0400 (EDT) Subject: [7u80] Request for review for CR 4963723: Implement SHA-224 In-Reply-To: <541A19D1.40606@oracle.com> References: <155489540.24500766.1410975144648.JavaMail.zimbra@redhat.com> <5419FA7F.903@oracle.com> <965519084.24587907.1410996112530.JavaMail.zimbra@redhat.com> <541A19D1.40606@oracle.com> Message-ID: <43988642.26705122.1411395941534.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Code changes generally require two approvals: codereview, performed by a > reviewer, (in this case from security-dev) and push approval, performed > by a gatekeeper. Given your email template matches the push approval > template I understood that you intended the latter. Generally speaking > codereview requests would say "Request for review" as opposed to > "Request for approval" so a reviewer could overlook your mail if you > intended the former. > > -Rob > > On 18/09/14 00:21, Andrew Hughes wrote: > > > > ----- Original Message ----- > >> Hi Andrew, > >> > >> Sorry to be a pest, but given the scope of the change I'd feel more > >> comfortable with an explicit codereview for the backport. > >> > >> -Rob > >> > >> On 17/09/14 18:32, Andrew Hughes wrote: > >>> This is the first of three backports to 7u designed to retain SSL > >>> compatibility with servers implemented in other languages switching > >>> to larger key sizes (notably DH >=2048 in Apache 2.4.7 [0]). > >>> > >>> This patch is a per-requisite of the patch which brings NSA Suite B > >>> support to 7. It applies largely unchanged, bar the following: > >>> > >>> * Copyright header adjustment > >>> * Removal of change to java.security.spec.MGF1ParameterSpec to avoid > >>> introducing a new public variable. The SHA-224 variant is constructed > >>> directly in com.sun.crypto.provider.OAEPParameters instead. > >>> * A change to OAEPParameters is dropped as it was already incorporated > >>> in the backport of 7180907 & 8049480 (addition of SHA-224 to > >>> convertToStandardName) > >>> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-4963723 > >>> Webrev: http://cr.openjdk.java.net/~andrew/jdk7u/4963723/webrev.01/ > >>> > >>> [0] https://httpd.apache.org/docs/2.4/mod/mod_ssl.html > >>> > >>> Ok to push? > >>> > >>> Thanks, > >> > > Which is what I asked for, no? > > > > If I wasn't waiting on a review first, I'd have pushed the change. > > This was the only applicable template on: http://openjdk.java.net/projects/jdk7u/ Anyway, now including security-dev for review. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From david.katleman at oracle.com Mon Sep 22 22:44:37 2014 From: david.katleman at oracle.com (David Katleman) Date: Mon, 22 Sep 2014 15:44:37 -0700 Subject: RFR: JDK-8058845 : Update JCE environment for build improvements In-Reply-To: <541F5681.2090908@oracle.com> References: <541F5681.2090908@oracle.com> Message-ID: <5420A655.20200@oracle.com> Hi Brad, Approved, changes look fine. Thanks for simplifying the JCE jar file builds. Dave On 9/21/2014 3:51 PM, Bradford Wetmore wrote: > > Hi Sean/Mandy/Erik/Magnus/Alan/David/others, > > Please review: > > JDK-8058845 : Update JCE environment for build improvements > http://cr.openjdk.java.net/~wetmore/8058845/ > > This change is to alleviate some of the overly-complicated steps we > (Oracle) have in building and maintaining the JCE jar files in JDK 9. > Besides the Makefiles and a class rename, there is very little change > to the Open code for the OpenJDK Security folks. The OpenJDK build > folks shouldn't really notice any difference. > > I do wish we could completely do away with this code completely, but > we (Oracle and closed licensees) do still need to follow the regulations. > > For the Iced Tea maintainers, this will necessitate a small > incremental change to your JCE patch. > > Thanks, > > Brad From bov at severgazbank.ru Tue Sep 23 05:20:39 2014 From: bov at severgazbank.ru (=?koi8-r?B?4sXSxM7Jy8/XIO8u9y4=?=) Date: Tue, 23 Sep 2014 05:20:39 +0000 Subject: problem JDK-8049839 Message-ID: <57C08081BA453149853C2A2E3438F2EE58DEB5E5@mailhost.sgb.rus> Hello, We have the problem JDK-8049839 (https://bugs.openjdk.java.net/browse/JDK-8049839) in production and this bug has been closed due to it is a duplicate of JDK-8042756. But I cannot browse JDK-8042756 via https://bugs.openjdk.java.net/browse/JDK-8042756. Please help, we need information about this bug. Win 7 enterprise 64 x, virtual. jre-7u11-windows-i586 ? ?????????, ????????? ???? ???????????? ??????? ?????????? ?????? ?????????????? ???????? ??? ??? ??? "???? ???" ???. +7 8202 516119 ???. +79218261654 E-mail: bov at severgazbank.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid1828.log Type: application/octet-stream Size: 27421 bytes Desc: hs_err_pid1828.log URL: From ivan.gerasimov at oracle.com Tue Sep 23 08:31:56 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 23 Sep 2014 12:31:56 +0400 Subject: problem JDK-8049839 In-Reply-To: <57C08081BA453149853C2A2E3438F2EE58DEB5E5@mailhost.sgb.rus> References: <57C08081BA453149853C2A2E3438F2EE58DEB5E5@mailhost.sgb.rus> Message-ID: <54212FFC.20701@oracle.com> Thank you Oleg Vladimirovich for your report. I've reopened the bug JDK-8049839 and updated it with your log file. Sincerely yours, Ivan On 23.09.2014 9:20, ????????? ?.?. wrote: > > Hello, > > We have the problem JDK-8049839 > (https://bugs.openjdk.java.net/browse/JDK-8049839) in production and > this bug has been closed due to it is a duplicate of JDK-8042756. > > But I cannot browse JDK-8042756 via > https://bugs.openjdk.java.net/browse/JDK-8042756. > > Please help, we need information about this bug. > > Win 7 enterprise 64 x, virtual. > > jre-7u11-windows-i586 > > ? ?????????, > > ????????? ???? ???????????? > > ??????? ?????????? ?????? ?????????????? ???????? ??? ??? > > ??? "???? ???" > > ???. +7 8202 516119 > > ???. +79218261654 > > E-mail: bov at severgazbank.ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Sep 23 09:45:25 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 23 Sep 2014 10:45:25 +0100 Subject: RFR: JDK-8058845 : Update JCE environment for build improvements In-Reply-To: <541F5681.2090908@oracle.com> References: <541F5681.2090908@oracle.com> Message-ID: <54214135.90502@oracle.com> On 21/09/2014 23:51, Bradford Wetmore wrote: > > Hi Sean/Mandy/Erik/Magnus/Alan/David/others, > > Please review: > > JDK-8058845 : Update JCE environment for build improvements > http://cr.openjdk.java.net/~wetmore/8058845/ > > This change is to alleviate some of the overly-complicated steps we > (Oracle) have in building and maintaining the JCE jar files in JDK 9. The overall change is very welcome. I'm not an expert in this area but I have looked through the changes. In JceSecurity maybe verifyProviderJar could be renamed to verifyProvider or something better as it should not be limited to JAR files. I also wonder about the name URLVerifier. With the current implementation then JarVerifier is more obvious but of course that will change very soon when we have security providers linked into the image. Just mentioning it as renaming this to ProviderVerifier or something better might make it a bit clearer. -Alan. From mala.bankal at oracle.com Tue Sep 23 13:13:40 2014 From: mala.bankal at oracle.com (mala bankal) Date: Tue, 23 Sep 2014 18:43:40 +0530 Subject: Request for review : 8037591 - Still seeing Invalid Padding length SSL errors after the fix for JDK-8014618 Message-ID: <54217204.2020604@oracle.com> HI Brad, All, Request your review for bug # 8037591 https://bugs.openjdk.java.net/browse/JDK-8037591 Solaris mechanisms trims out the leading zeros due to which the Invalid Padding length errors are to be seen. The fix disables the mechanisms in the sunpkcs11-solaris.cfg. webrev : http://cr.openjdk.java.net/~mbankal/8037591/webrev.00/ rgds mala From mandy.chung at oracle.com Tue Sep 23 16:31:20 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 23 Sep 2014 09:31:20 -0700 Subject: RFR: JDK-8058845 : Update JCE environment for build improvements In-Reply-To: <541F5681.2090908@oracle.com> References: <541F5681.2090908@oracle.com> Message-ID: <5421A058.4010504@oracle.com> On 9/21/14 3:51 PM, Bradford Wetmore wrote: > > Hi Sean/Mandy/Erik/Magnus/Alan/David/others, > > Please review: > > JDK-8058845 : Update JCE environment for build improvements > http://cr.openjdk.java.net/~wetmore/8058845/ > The change looks fine in general. Some minor comments: javax/crypto/Cipher.java line 264: this is not part of your change but caught my attention. I wonder if you want to include some descriptive message in NPE to help diagnosing the problem especially in jdk9 where future changes will be made to support modules. javax/crypto/JceSecurity.java line 79: this could be (PrivilegedExceptionAction) as the return value is ignored It may be better to rename URLVerifier to ProviderVerifier as it verifies the security provider of the given codebase. URLVerifier might give an interpretation of verifying the given URL. Similarly, the verifyProviderJar method can be renamed to verifyProvider. javax/crypto/URLVerifier.java line 117: should it be pae.getCause()? Mandy From weijun.wang at oracle.com Thu Sep 25 10:54:35 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 25 Sep 2014 18:54:35 +0800 Subject: RFR 8044500: Add kinit options and krb5.conf flags that allow users to obtain renewable tickets and specify ticket lifetimes Message-ID: Hi All Please review the code change at http://cr.openjdk.java.net/~weijun/8044500/webrev.00 It adds support for ticket_lifetime and renew_lifetime in krb5.conf, and add -r -l -R to kinit (on Windows). Thanks Max From bradford.wetmore at oracle.com Fri Sep 26 03:02:12 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 25 Sep 2014 20:02:12 -0700 Subject: RFR: JDK-8058845 : Update JCE environment for build improvements In-Reply-To: <5421A058.4010504@oracle.com> References: <541F5681.2090908@oracle.com> <5421A058.4010504@oracle.com> Message-ID: <5424D734.5080006@oracle.com> > javax/crypto/JceSecurity.java > line 79: this could be (PrivilegedExceptionAction) as the > return value is ignored Good catch. > It may be better to rename URLVerifier to ProviderVerifier as it verifies > the security provider of the given codebase. URLVerifier might give > an interpretation of verifying the given URL. Similarly, the > verifyProviderJar > method can be renamed to verifyProvider. Done. > javax/crypto/URLVerifier.java > line 117: should it be pae.getCause()? Yes, that would be a better one. Thanks for the review. brad From ymnk at jcraft.com Fri Sep 26 17:19:06 2014 From: ymnk at jcraft.com (Atsuhiko Yamanaka) Date: Sat, 27 Sep 2014 02:19:06 +0900 Subject: JDK-8039921: SHA1WithDSA with key > 1024 bits not working In-Reply-To: <541B732A.2080804@oracle.com> References: <541B732A.2080804@oracle.com> Message-ID: Hi, Is there any update on this issue? On Fri, Sep 19, 2014 at 9:04 AM, Valerie Peng wrote: > However, if such (potentially insecure) practice is common, we may consider > relax the restraint for the sake of being interoperable. Do you have any > more info such as CA certs using large DSA keys with SHA1withDSA signature > algorithm, etc.? This will help us decide whether and how to best > accommodate this. As Mr. Bernd Eckenfels has commented, > But - as the SSH example shows - there are protocols which have > different needs and threat scenarios. Crypto primitives should stay > away from that policing. that functionality is not only for CA. Could you please consider relax the restraint? Sincerely, -- Atsuhiko Yamanaka JCraft,Inc. 1-14-20 HONCHO AOBA-KU, SENDAI, MIYAGI 980-0014 Japan. Tel +81-22-723-2150 Skype callto://jcraft/ Twitter: http://twitter.com/ymnk Facebook: http://facebook.com/aymnk From sean.mullan at oracle.com Fri Sep 26 18:03:58 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 26 Sep 2014 14:03:58 -0400 Subject: TLS extensions API, ALPN and HTTP 2.0 In-Reply-To: References: <54196911.6050903@oracle.com> <5419967A.9060500@oracle.com> <5419AB9B.2010909@oracle.com> Message-ID: <5425AA8E.8050004@oracle.com> On 09/17/2014 01:18 PM, Simone Bordet wrote: > For the server to differentiate between those 2 connections he would > need the SNI information, which I don't think it's currently available > in JDK 8, right ? No. It is. We added support for SNI in JDK 8. See: http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#SNIExtension --Sean From simone.bordet at gmail.com Fri Sep 26 19:53:44 2014 From: simone.bordet at gmail.com (Simone Bordet) Date: Fri, 26 Sep 2014 21:53:44 +0200 Subject: TLS extensions API, ALPN and HTTP 2.0 In-Reply-To: <5425AA8E.8050004@oracle.com> References: <54196911.6050903@oracle.com> <5419967A.9060500@oracle.com> <5419AB9B.2010909@oracle.com> <5425AA8E.8050004@oracle.com> Message-ID: Hi, On Fri, Sep 26, 2014 at 8:03 PM, Sean Mullan wrote: > On 09/17/2014 01:18 PM, Simone Bordet wrote: >> >> For the server to differentiate between those 2 connections he would >> need the SNI information, which I don't think it's currently available >> in JDK 8, right ? > > > No. It is. We added support for SNI in JDK 8. See: > > http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#SNIExtension I understand one cannot extract the string with the SNI name into the application, you can only match for certificates via SNIMatcher; and that is the reason for SSLExplorer - to extract the SNI names. Am I missing something ? For example, how can I negotiate h2 via ALPN only for certain domains ? List allowedDomains = ... // provided by some server configuration SNIServerName sniName = ... // what here ? if (allowedDomains.contains(sniName)) doALPN(); 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 Sat Sep 27 02:23:56 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 27 Sep 2014 10:23:56 +0800 Subject: TLS extensions API, ALPN and HTTP 2.0 In-Reply-To: References: <54196911.6050903@oracle.com> <5419967A.9060500@oracle.com> <5419AB9B.2010909@oracle.com> <5425AA8E.8050004@oracle.com> Message-ID: <54261FBC.7060609@oracle.com> On 9/27/2014 3:53 AM, Simone Bordet wrote: > Hi, > > On Fri, Sep 26, 2014 at 8:03 PM, Sean Mullan wrote: >> On 09/17/2014 01:18 PM, Simone Bordet wrote: >>> >>> For the server to differentiate between those 2 connections he would >>> need the SNI information, which I don't think it's currently available >>> in JDK 8, right ? >> >> >> No. It is. We added support for SNI in JDK 8. See: >> >> http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#SNIExtension > > I understand one cannot extract the string with the SNI name into the > application, you can only match for certificates via SNIMatcher; and > that is the reason for SSLExplorer - to extract the SNI names. > Am I missing something ? > I used to think it is better to have SSLExplorer as a public utility but not a part of JSSE, because the extract is not involved in TLS transactions. Please let me know if the SSLExplorer cannot meet your requirements. Xuelei > For example, how can I negotiate h2 via ALPN only for certain domains ? > > List allowedDomains = ... // provided by some server configuration > SNIServerName sniName = ... // what here ? > if (allowedDomains.contains(sniName)) > doALPN(); > > Thanks ! > From weijun.wang at oracle.com Sat Sep 27 09:13:20 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 27 Sep 2014 17:13:20 +0800 Subject: RFR 8059313: Enable keytool NSS test on Mac Message-ID: <6CB55A7A-0371-4B0C-BB63-58FB3898125C@oracle.com> Hi Vinnie Can you review the fix at http://cr.openjdk.java.net/~weijun/8059313/webrev.00/ The test will try several places to look for NSS libs. If the machine has no Firefox or Thunderbird installed the NSS part won't run. At least this enables myself running NSS-related tests on my machine. I tried to do the same for PKCS11Test.java but cannot find a way to set DYLD_LIBRARY_PATH (or equivalent settings in Java) inside the test. If you know how to do that, I'll be happy to include it as well. BTW, I added the environment variable on jtreg command line and among 62 pkcs11 tests, 54 pass and 8 fail. There seems to be some extra work. Thanks Max From vincent.x.ryan at oracle.com Sat Sep 27 09:32:03 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Sat, 27 Sep 2014 10:32:03 +0100 Subject: RFR 8059313: Enable keytool NSS test on Mac In-Reply-To: <6CB55A7A-0371-4B0C-BB63-58FB3898125C@oracle.com> References: <6CB55A7A-0371-4B0C-BB63-58FB3898125C@oracle.com> Message-ID: Your fix looks good Max. I?ll examine the issue with PKCS11Test.java on Monday. Thanks. On 27 Sep 2014, at 10:13, Wang Weijun wrote: > Hi Vinnie > > Can you review the fix at > > http://cr.openjdk.java.net/~weijun/8059313/webrev.00/ > > The test will try several places to look for NSS libs. If the machine has no Firefox or Thunderbird installed the NSS part won't run. At least this enables myself running NSS-related tests on my machine. > > I tried to do the same for PKCS11Test.java but cannot find a way to set DYLD_LIBRARY_PATH (or equivalent settings in Java) inside the test. If you know how to do that, I'll be happy to include it as well. BTW, I added the environment variable on jtreg command line and among 62 pkcs11 tests, 54 pass and 8 fail. There seems to be some extra work. > > Thanks > Max > From weijun.wang at oracle.com Sun Sep 28 08:55:23 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Sun, 28 Sep 2014 16:55:23 +0800 Subject: RFR 8044215: Unable to initiate SpNego using a S4U2Proxy GSSCredential (Krb5ProxyCredential) Message-ID: Please review the fix at http://cr.openjdk.java.net/~weijun/8044215/webrev.00 If a service is using constrained delegation to act as a client, it should not be able to request for a traditional delegation to another service (on behalf of the client). Otherwise it automatically elevate itself into a higher privilege and thus break out the constrained state. Java currently does not prevent the request from being sent out, and when the KDC denies the request, user would see a confusing error message "Client principal does not match". Actually here the KDC is sending back a ticket for the service itself (instead of for the client). This fix simply ignores any traditional delegation request in this case so the request will never be sent out. Throwing an exception in this case is not a good solution because the application might not be able to know if it's using a constrained delegation or a traditional delegation. If it's a constrained delegation and the KDC has been configured to allow a further constrained delegation to the 2nd service, it would still work anyway (because a constrained delegation does not need a request). Thanks Max From sbordet at intalio.com Mon Sep 29 09:30:41 2014 From: sbordet at intalio.com (Simone Bordet) Date: Mon, 29 Sep 2014 11:30:41 +0200 Subject: TLS extensions API, ALPN and HTTP 2.0 In-Reply-To: <54261FBC.7060609@oracle.com> References: <54196911.6050903@oracle.com> <5419967A.9060500@oracle.com> <5419AB9B.2010909@oracle.com> <5425AA8E.8050004@oracle.com> <54261FBC.7060609@oracle.com> Message-ID: Hi, On Sat, Sep 27, 2014 at 4:23 AM, Xuelei Fan wrote: > I used to think it is better to have SSLExplorer as a public utility but > not a part of JSSE, because the extract is not involved in TLS > transactions. I am not sure I understand this. Can you expand ? A number of TLS Extensions are designed to be consumed by applications: SNI, ALPN, NPN, renegotiation, etc. Eventually these features crop up in the API (e.g. SSLParameters.setServerNames()), or even applications need to have control on whether these extensions have to be added or not (e.g. ALPN) in a dynamic way that cannot be expressed via system properties. So I would rather prefer a full fledged extensions API exposed by the JDK (also to cope with future extensions). > Please let me know if the SSLExplorer cannot meet your > requirements. Definitely not :) It has too many assumptions on how many bytes have been read, it does not work for async reads that may read only part of TLS frames, it parses again the TLS bytes, etc. Sure we can do all that in the application in order to fullfill SSLExplorer requirements, but I really hope that is not the way to solve this problem. Every application out there would have its own tweaked version of SSLExplorer, tweaks may introduce vulnerabilities, etc. The whole point is to have a standard API to rely on. Internally OpenJDK already does the parsing of the SNI extension, so I see no point in forcing application to do it again: just expose what's already been read. I think we should go the extra mile and just expose in the right way what's already in the JDK: there already is a ServerNameExtension class, hopefully there will be NPNExtension, ALPNExtension classes, etc, all part of the same API, which is available to applications. As I said before, it seems that ALPN is only one piece required to support HTTP/2. The HTTP/2 spec editors are being adamant on cipher requirements, so for example an application would need to know the type of cipher as defined by RFC 5246 section 6.2.3: something like cipher.isStream(), cipher.isBlock(), etc, along with whether the cipher supports forward secrecy (currently ephemeral key exchange). I will try to come up with the list of necessary things for HTTP/2, but I would appreciate any thought on introducing a full fledged TLS extensions API available to applications to the JDK. I'd like to know in advance if this is not possible at all. Thanks ! -- Simone Bordet ---- http://cometd.org http://webtide.com http://intalio.com Developer advice, training, services and support from the Jetty & CometD experts. Intalio, the modern way to build business applications. From xuelei.fan at oracle.com Mon Sep 29 12:08:28 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 29 Sep 2014 20:08:28 +0800 Subject: TLS extensions API, ALPN and HTTP 2.0 In-Reply-To: References: <54196911.6050903@oracle.com> <5419967A.9060500@oracle.com> <5419AB9B.2010909@oracle.com> <5425AA8E.8050004@oracle.com> <54261FBC.7060609@oracle.com> Message-ID: <54294BBC.6070400@oracle.com> > I will try to come up with the list of necessary things for HTTP/2, > but I would appreciate any thought on introducing a full fledged TLS > extensions API available to applications to the JDK. > I'd like to know in advance if this is not possible at all. ;-) Impossible is nothing. Thanks for the list of necessary things. Please let me know the requirements and the user scenarios if the list is ready, especially these things that java cannot support. Thanks for that in advance. >> I used to think it is better to have SSLExplorer as a public utility >> but not a part of JSSE, because the extract is not involved in TLS >> transactions. > > I am not sure I understand this. Can you expand? SSLExplorer is only needed for virtual server dispatcher, for which the virtual servers are not hosted in the same JVM. SSLExplorer can be easily implemented in application layer. The virtual server dispatcher is not really a part of SSL/TLS handshaking. It just redirects the stream to the right virtual server. Application may have more effective implementation than the sample SSLExplorer. It's OK to me to have it in JDK if customers really want to see it in JDK. > Internally OpenJDK already does the parsing of the SNI extension, so I > see no point in forcing application to do it again: just expose what's > already been read. I'm not sure I understand this point. SSLExplorer is expected to be used in different circumstance than the SSL/TLS handshaking. Please read more scenarios in the JSSE reference guide: http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#SNIExamples Or would you mind describe the scenarios in details? Thanks, Xuelei On 9/29/2014 5:30 PM, Simone Bordet wrote: > Hi, > > On Sat, Sep 27, 2014 at 4:23 AM, Xuelei Fan wrote: >> I used to think it is better to have SSLExplorer as a public utility but >> not a part of JSSE, because the extract is not involved in TLS >> transactions. > > I am not sure I understand this. Can you expand ? > > A number of TLS Extensions are designed to be consumed by > applications: SNI, ALPN, NPN, renegotiation, etc. > Eventually these features crop up in the API (e.g. > SSLParameters.setServerNames()), or even applications need to have > control on whether these extensions have to be added or not (e.g. > ALPN) in a dynamic way that cannot be expressed via system properties. > > So I would rather prefer a full fledged extensions API exposed by the > JDK (also to cope with future extensions). > >> Please let me know if the SSLExplorer cannot meet your >> requirements. > > Definitely not :) > > It has too many assumptions on how many bytes have been read, it does > not work for async reads that may read only part of TLS frames, it > parses again the TLS bytes, etc. > Sure we can do all that in the application in order to fullfill > SSLExplorer requirements, but I really hope that is not the way to > solve this problem. > Every application out there would have its own tweaked version of > SSLExplorer, tweaks may introduce vulnerabilities, etc. > The whole point is to have a standard API to rely on. > > Internally OpenJDK already does the parsing of the SNI extension, so I > see no point in forcing application to do it again: just expose what's > already been read. > > I think we should go the extra mile and just expose in the right way > what's already in the JDK: there already is a ServerNameExtension > class, hopefully there will be NPNExtension, ALPNExtension classes, > etc, all part of the same API, which is available to applications. > > As I said before, it seems that ALPN is only one piece required to > support HTTP/2. > The HTTP/2 spec editors are being adamant on cipher requirements, so > for example an application would need to know the type of cipher as > defined by RFC 5246 section 6.2.3: something like cipher.isStream(), > cipher.isBlock(), etc, along with whether the cipher supports forward > secrecy (currently ephemeral key exchange). > > I will try to come up with the list of necessary things for HTTP/2, > but I would appreciate any thought on introducing a full fledged TLS > extensions API available to applications to the JDK. > I'd like to know in advance if this is not possible at all. > > Thanks ! > From kepi at sg.ibm.com Mon Sep 29 14:03:37 2014 From: kepi at sg.ibm.com (Ke Pi) Date: Mon, 29 Sep 2014 22:03:37 +0800 Subject: AUTO: Ke Pi is out of the office (returning 10/09/2014) Message-ID: I am out of the office until 10/09/2014. If you have Java Security related issues, please kindly contact Tianyu Tang/Singapore/IBM at IBMSG or Zhemin Feng/Singapore/IBM at IBMSG. Note: This is an automated response to your message "security-dev Digest, Vol 87, Issue 19" sent on 09/29/2014 17:30:45. This is the only notification you will receive while this person is away. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Mon Sep 29 20:33:31 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 29 Sep 2014 13:33:31 -0700 Subject: JEP Review: JVM Hardware Crypto Acceleration Message-ID: <5429C21B.2040204@oracle.com> Hi, Please review the below JEP for JVM Hardware Crypto Acceleration. The focus is to use ISA crypto instructions available in x86 and sparc platforms and to help access to use them. https://bugs.openjdk.java.net/browse/JDK-8046943 Tony From jamil.j.nimeh at oracle.com Mon Sep 29 21:11:11 2014 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 29 Sep 2014 14:11:11 -0700 Subject: RFR: JDK-8032573 Message-ID: <5429CAEF.3090308@oracle.com> Hello all, This review fixes a small regression in the generateCertificates() and generateCRLs() methods for the CertificateFactory class. At some point, input consisting entirely of non-certificate data ceased to throw CertificateException or CRLException and instead returned an empty collection. This restores the exception-throwing behavior, but only when the entire stream is non-cert data. Cases where there is leading/trailing text around a valid PEM-encoded certificate or CRL will still ignore the leading/trailing data and parse the certificate/CRL properly as before. Bug: https://bugs.openjdk.java.net/browse/JDK-8032573 Review: http://cr.openjdk.java.net/~ascarpino/8032573/webrev.01/ Thank you, --Jamil From weijun.wang at oracle.com Tue Sep 30 00:39:15 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 30 Sep 2014 08:39:15 +0800 Subject: RFR: JDK-8032573 In-Reply-To: <5429CAEF.3090308@oracle.com> References: <5429CAEF.3090308@oracle.com> Message-ID: <8502FC15-C494-4F5F-A96A-F39678D233D3@oracle.com> X509Factory.java: 502 data = readOneBlock(is); Should it be pbis? Actually I would suggest reusing the variable name "is" to prevent any such error. Also, I am not sure if using a PushbackInputStream will hurt the performance. The readOneBlock() method already includes the read-first-byte logic inside so maybe we can change it a little to cover the fix. For example, I can think of renaming it to readOneBlock(firstByte, is) so inside your fix you can call readOneBlock(perkByte, is) and in other cases call readOneBlock(is.read(), is). This might look a little strange but hopefully you can find a more concise one. Thanks Max On Sep 30, 2014, at 5:11, Jamil Nimeh wrote: > Hello all, > > This review fixes a small regression in the generateCertificates() and generateCRLs() methods for the CertificateFactory class. At some point, input consisting entirely of non-certificate data ceased to throw CertificateException or CRLException and instead returned an empty collection. This restores the exception-throwing behavior, but only when the entire stream is non-cert data. Cases where there is leading/trailing text around a valid PEM-encoded certificate or CRL will still ignore the leading/trailing data and parse the certificate/CRL properly as before. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8032573 > Review: http://cr.openjdk.java.net/~ascarpino/8032573/webrev.01/ > > Thank you, > --Jamil > From jamil.j.nimeh at oracle.com Tue Sep 30 01:17:57 2014 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 29 Sep 2014 18:17:57 -0700 Subject: RFR: JDK-8032573 In-Reply-To: <8502FC15-C494-4F5F-A96A-F39678D233D3@oracle.com> References: <5429CAEF.3090308@oracle.com> <8502FC15-C494-4F5F-A96A-F39678D233D3@oracle.com> Message-ID: <542A04C5.5060007@oracle.com> 502: sigh, yes. It needs to be pbis. I thought I caught all those. Thanks for catching that, I'll get that fixed up. I had considered a similar alternate approach to using a PushbackInputStream, but I thought passing the first byte in and checking there seemed awkward (as you said as well). I wanted to preserve the stateless nature of readOneBlock as well, so doing the initial single byte read and preserving its value in the caller to rOB made sense. The two methods that return collections right now can't distinguish if a null value on the first block is because the stream was already at the end, or if it read some data and couldn't find anything. That distinction matters though on the first block only. Yet in single valued methods like generateCertificate (singlular), a null return value from rOB value is always an exception case. That's why I went looking for an interface that would let me consume the stream for one byte, and then "put it back" and keep the logic of rOB intact. PushbackInputStream doesn't seem to be too bad on performance, since any bytes you choose to unread go onto a byte array created at construction time (only one byte in this particular case). Subsequent reads will pull from this byte array first and when exhausted will then go to the backing input stream. Thanks for the feedback, --Jamil On 09/29/2014 05:39 PM, Wang Weijun wrote: > X509Factory.java: > > 502 data = readOneBlock(is); > > Should it be pbis? > > Actually I would suggest reusing the variable name "is" to prevent any such error. > > Also, I am not sure if using a PushbackInputStream will hurt the performance. The readOneBlock() method already includes the read-first-byte logic inside so maybe we can change it a little to cover the fix. For example, I can think of renaming it to readOneBlock(firstByte, is) so inside your fix you can call readOneBlock(perkByte, is) and in other cases call readOneBlock(is.read(), is). This might look a little strange but hopefully you can find a more concise one. > > Thanks > Max > > On Sep 30, 2014, at 5:11, Jamil Nimeh wrote: > >> Hello all, >> >> This review fixes a small regression in the generateCertificates() and generateCRLs() methods for the CertificateFactory class. At some point, input consisting entirely of non-certificate data ceased to throw CertificateException or CRLException and instead returned an empty collection. This restores the exception-throwing behavior, but only when the entire stream is non-cert data. Cases where there is leading/trailing text around a valid PEM-encoded certificate or CRL will still ignore the leading/trailing data and parse the certificate/CRL properly as before. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8032573 >> Review: http://cr.openjdk.java.net/~ascarpino/8032573/webrev.01/ >> >> Thank you, >> --Jamil >> From weijun.wang at oracle.com Tue Sep 30 03:14:26 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 30 Sep 2014 11:14:26 +0800 Subject: RFR 8058657: Add @jdk.Exported to com.sun.jarsigner APIs Message-ID: <235B3FC9-8C85-4E9E-BCB5-A4C07D76DB70@oracle.com> Hi All Please review the code change at http://cr.openjdk.java.net/~weijun/8058657/webrev.00/ It includes both the dev repo and dev/jdk repo. While the change in dev/jdk is useless with today's modules environment, it is included here and will be backported into jdk8u. Thanks Max From mandy.chung at oracle.com Tue Sep 30 04:18:11 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 29 Sep 2014 21:18:11 -0700 Subject: RFR 8058657: Add @jdk.Exported to com.sun.jarsigner APIs In-Reply-To: <235B3FC9-8C85-4E9E-BCB5-A4C07D76DB70@oracle.com> References: <235B3FC9-8C85-4E9E-BCB5-A4C07D76DB70@oracle.com> Message-ID: <542A2F03.20500@oracle.com> On 9/29/2014 8:14 PM, Wang Weijun wrote: > Hi All > > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8058657/webrev.00/ > > It includes both the dev repo and dev/jdk repo. While the change in dev/jdk is useless with today's modules environment, it is included here and will be backported into jdk8u. Looks fine to me. One thing to add is that com.sun.jarsigner is an exported interface. 8u40 jdeps reads @jdk.Exported to determine if it's an exported API or not and it currently flags com.sun.jarsigner as JDK internal API. Fixing this in 8u40 is good. thanks Mandy From Alan.Bateman at oracle.com Tue Sep 30 04:19:54 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 29 Sep 2014 21:19:54 -0700 Subject: RFR 8058657: Add @jdk.Exported to com.sun.jarsigner APIs In-Reply-To: <235B3FC9-8C85-4E9E-BCB5-A4C07D76DB70@oracle.com> References: <235B3FC9-8C85-4E9E-BCB5-A4C07D76DB70@oracle.com> Message-ID: <542A2F6A.8060808@oracle.com> On 29/09/2014 20:14, Wang Weijun wrote: > Hi All > > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8058657/webrev.00/ > > It includes both the dev repo and dev/jdk repo. While the change in dev/jdk is useless with today's modules environment, it is included here and will be backported into jdk8u. > This looks okay except for the first statement in the renamed package-info. It might read a bit better if you drop the first statement and have the second start with "This package comprises the interfaces ...". Otherwise the changes look good to me. Once we have the module system in JDK 9 then we can drop @jdk.Exported. -Alan From ks at trustbuilder.be Tue Sep 30 06:56:41 2014 From: ks at trustbuilder.be (Koen Serry) Date: Tue, 30 Sep 2014 08:56:41 +0200 Subject: Fwd: Issue JDK-8048194 backport in jdk9 ? In-Reply-To: <5422CF43.2060902@trustbuilder.be> References: <5422CF43.2060902@trustbuilder.be> Message-ID: <542A5429.9080302@trustbuilder.be> Hi, could anyone merge the code of jdk9 into jdk8 as supposedly done in the ticket. I see the code in jdk9 forest, not in the jdk8 forest. kind regards, Koen Serry -------- Original Message -------- Subject: RE: Issue JDK-8048194 backport in jdk9 ? Date: Mon, 22 Sep 2014 11:17:13 -0700 From: Iris Clark To: Koen Serry , Hi, Koen. https://bugs.openjdk.java.net/browse/JDK-8048194 From my read of bug JDK-8048194, it appears that the bug was fixed in JDK 9 only. I base this on the "Fix Version/s" value of "9", and the "Activity", "Comments" at 2014-07-21 18:31 showing the fix got pushed to the jdk9/dev forest, and the 2014-07-30 12:25 showing the fix pushed to the jdk9/jdk9 forest. I don't see any indication that the fix was backported to JDK 8 update, so I don't think it should be in JDK 8 u40. Since the bug has a "Component" of "security-libs", I recommend that you send e-mail to security-dev [1] where you'll find the bug's current owner and other experts in the area. They'll be able to provide you with definitive answers. Thanks, Iris Clark -----Original Message----- From: Koen Serry [mailto:ks at trustbuilder.be] Sent: Monday, September 22, 2014 1:41 AM To:help at openjdk.java.net Subject: Issue JDK-8048194 backport in jdk9 ? Hi, I don't know if someone will get my email, but anyway here goes nothing. I've stumbled upon this bug with jdk7 : https://bugs.openjdk.java.net/browse/JDK-8048194 and since any reason was as good for upgrading to jdk8 as this. I though about upgrading as it would fix this issue. However, even though it says it's been fixed in jdk8 (u9), if I test it in the oracle provided jdk8u40b06 I still have the issue. The strange thing is that the commit only happened in the jdk9 forest, so am I getting this wrong or should I be building from the source? Thank you so much if someone could shed some light on this. Koen Serry @koen_serry -------------- next part -------------- An HTML attachment was scrubbed... URL: From fweimer at redhat.com Tue Sep 30 09:51:00 2014 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 30 Sep 2014 11:51:00 +0200 Subject: JEP Review: JVM Hardware Crypto Acceleration In-Reply-To: <5429C21B.2040204@oracle.com> References: <5429C21B.2040204@oracle.com> Message-ID: <542A7D04.1030605@redhat.com> On 09/29/2014 10:33 PM, Anthony Scarpino wrote: > Please review the below JEP for JVM Hardware Crypto Acceleration. The > focus is to use ISA crypto instructions available in x86 and sparc > platforms and to help access to use them. > > https://bugs.openjdk.java.net/browse/JDK-8046943 Can you show what you actually benchmarked? Just GHASH, or the full cipher suite? The actual impact of this change will be less than expected for TLS because after fixing GHASH (for which I had already posted a patch), the TLS implementation is largely GC-bound. -- Florian Weimer / Red Hat Product Security From vincent.x.ryan at oracle.com Tue Sep 30 10:46:55 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 30 Sep 2014 11:46:55 +0100 Subject: [9] RFR 8059462: Typo in keytool resource file Message-ID: <03117A7C-358B-4BD1-8FE9-BDCCC0D1A28D@oracle.com> Please review this correction to a key used by the keytool utility to access its L10N strings: Webrev: http://cr.openjdk.java.net/~vinnie/8059462/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8059462 Thanks. From weijun.wang at oracle.com Tue Sep 30 12:21:32 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 30 Sep 2014 20:21:32 +0800 Subject: [9] RFR 8059462: Typo in keytool resource file In-Reply-To: <03117A7C-358B-4BD1-8FE9-BDCCC0D1A28D@oracle.com> References: <03117A7C-358B-4BD1-8FE9-BDCCC0D1A28D@oracle.com> Message-ID: <8DEA6065-36B0-4913-8884-B4E0A33E57A7@oracle.com> Change looks good. I think it can labelled noreg-trivial. Thanks Max On Sep 30, 2014, at 18:46, Vincent Ryan wrote: > Please review this correction to a key used by the keytool utility to access its L10N strings: > > Webrev: http://cr.openjdk.java.net/~vinnie/8059462/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8059462 > > Thanks. > From vincent.x.ryan at oracle.com Tue Sep 30 12:22:31 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 30 Sep 2014 13:22:31 +0100 Subject: [9] RFR 8059462: Typo in keytool resource file In-Reply-To: <8DEA6065-36B0-4913-8884-B4E0A33E57A7@oracle.com> References: <03117A7C-358B-4BD1-8FE9-BDCCC0D1A28D@oracle.com> <8DEA6065-36B0-4913-8884-B4E0A33E57A7@oracle.com> Message-ID: Thanks for the quick review. On 30 Sep 2014, at 13:21, Wang Weijun wrote: > Change looks good. I think it can labelled noreg-trivial. > > Thanks > Max > > On Sep 30, 2014, at 18:46, Vincent Ryan wrote: > >> Please review this correction to a key used by the keytool utility to access its L10N strings: >> >> Webrev: http://cr.openjdk.java.net/~vinnie/8059462/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8059462 >> >> Thanks. >> > From sean.coffey at oracle.com Tue Sep 30 16:05:26 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Tue, 30 Sep 2014 17:05:26 +0100 Subject: Fwd: Issue JDK-8048194 backport in jdk9 ? In-Reply-To: <542A5429.9080302@trustbuilder.be> References: <5422CF43.2060902@trustbuilder.be> <542A5429.9080302@trustbuilder.be> Message-ID: <542AD4C6.2090101@oracle.com> Iris is correct. This fix is in JDK 9 only. I'm not sure why you think it's fixed in jdk8u. Max - are you willing to pull this fix into the JDK 8u code line or shall I ? regards, Sean. On 30/09/2014 07:56, Koen Serry wrote: > > Hi, > > could anyone merge the code of jdk9 into jdk8 as supposedly done in > the ticket. > I see the code in jdk9 forest, not in the jdk8 forest. > > kind regards, > Koen Serry > > -------- Original Message -------- > Subject: RE: Issue JDK-8048194 backport in jdk9 ? > Date: Mon, 22 Sep 2014 11:17:13 -0700 > From: Iris Clark > To: Koen Serry , > > > > Hi, Koen. > > https://bugs.openjdk.java.net/browse/JDK-8048194 > > From my read of bug JDK-8048194, it appears that the bug was fixed in JDK 9 only. I base this on the "Fix Version/s" value of "9", and the "Activity", "Comments" at 2014-07-21 18:31 showing the fix got pushed to the jdk9/dev forest, and the 2014-07-30 12:25 showing the fix pushed to the jdk9/jdk9 forest. I don't see any indication that the fix was backported to JDK 8 update, so I don't think it should be in JDK 8 u40. > > Since the bug has a "Component" of "security-libs", I recommend that you send e-mail to security-dev [1] where you'll find the bug's current owner and other experts in the area. They'll be able to provide you with definitive answers. > > Thanks, > Iris Clark > > -----Original Message----- > From: Koen Serry [mailto:ks at trustbuilder.be] > Sent: Monday, September 22, 2014 1:41 AM > To:help at openjdk.java.net > Subject: Issue JDK-8048194 backport in jdk9 ? > > Hi, > > I don't know if someone will get my email, but anyway here goes nothing. > > I've stumbled upon this bug with jdk7 : > https://bugs.openjdk.java.net/browse/JDK-8048194 > and since any reason was as good for upgrading to jdk8 as this. I though about upgrading as it would fix this issue. > > However, even though it says it's been fixed in jdk8 (u9), if I test it in the oracle provided jdk8u40b06 I still have the issue. > > The strange thing is that the commit only happened in the jdk9 forest, so am I getting this wrong or should I be building from the source? > > Thank you so much if someone could shed some light on this. > > Koen Serry > @koen_serry > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Tue Sep 30 18:06:20 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 30 Sep 2014 11:06:20 -0700 Subject: JEP Review: JVM Hardware Crypto Acceleration In-Reply-To: <542A7D04.1030605@redhat.com> References: <5429C21B.2040204@oracle.com> <542A7D04.1030605@redhat.com> Message-ID: <542AF11C.8000003@oracle.com> On 09/30/2014 02:51 AM, Florian Weimer wrote: > On 09/29/2014 10:33 PM, Anthony Scarpino wrote: >> Please review the below JEP for JVM Hardware Crypto Acceleration. The >> focus is to use ISA crypto instructions available in x86 and sparc >> platforms and to help access to use them. >> >> https://bugs.openjdk.java.net/browse/JDK-8046943 > > Can you show what you actually benchmarked? Just GHASH, or the full > cipher suite? > > The actual impact of this change will be less than expected for TLS > because after fixing GHASH (for which I had already posted a patch), the > TLS implementation is largely GC-bound. > As this being a work in progress, much isn't done. That being said, the prototype using PCLMULQDQ with AES-GCM performed roughly 34x better. Tony