From weijun.wang at oracle.com Tue Sep 1 06:50:52 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 1 Sep 2015 14:50:52 +0800 Subject: RFR 8056174: New APIs for jar signing In-Reply-To: <55DB22A9.40704@oracle.com> References: <55DB22A9.40704@oracle.com> Message-ID: <55E54ACC.6020004@oracle.com> Updated a little: rewrite of jarsigner tool itself using the JarSigner API included. Still at the same URL below. --Max On 08/24/2015 09:56 PM, Weijun Wang wrote: > Hi All > > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8056174/webrev.02/ > > A new JarSigner public API is introduced to OpenJDK. The code change > chooses a two-layer implementation style, with public JarSigner/Builder > in jdk.security and private JarSignerX/BuilderX in sun.security. The > private side contains some unpopular options which I hope can be used to > implement the jarsigner tool itself in another changeset. > > Some spec clarification is made since my last mail [1], including > Builder#sign, JarSigner#getDigestAlg, and JarSigner#getSigAlg. In > Builder, I am still using short method names (sigAlg, digestAlg, and > tsa) since I think the jarsigner option names are already widely > accepted. Otherwise, a name like setDigestAlgorithm seems a little > unfamiliar. > > Thanks > Max > > [1] > http://mail.openjdk.java.net/pipermail/security-dev/2015-August/012636.html From aph at redhat.com Tue Sep 1 14:45:17 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 1 Sep 2015 15:45:17 +0100 Subject: RFR: 8134869: AARCH64: GHASH intrinsic is not optimal Message-ID: <55E5B9FD.805@redhat.com> I've been looking at the intrinsic we have for GHASH. While it is decent as it goes, its performance is considerably worse than some other implementations of GHASH on the same processor. Thanks are due to Alexander Alexeev who did a fine job implementing the x86 algorithm on AArch64, but the result is not optimal. on AArch64 we have the advantage of a bit-reversal instruction which x86 parts don't have, and this makes it possible to write a fully little-endian implementation of GHASH which is far more idiomatic on AArch64 than the big-endian implementation the x86 version uses. This gets us an overall performance improvement of AES/GCM of 10-20%. I've also taken the opportunity to add a lot of comments. The algorithms used are (fairly) obscure and most open source software implementations don't really explain what they're doing. In particular, the bizarre representation of polynomials in GF(2) (where byte ordering is little endian but bit ordering is big endian) is very confusing and surely deserves a comment or two. http://cr.openjdk.java.net/~aph/8134869-ghash-1/ One other remark: the AES/GCM implementation has a lot of overhead. Some profile data (on x86) looks like this: samples cum. samples % cum. % image name symbol name 479605 479605 36.8408 36.8408 31156.jo aescrypt_encryptBlock 301014 780619 23.1224 59.9632 31156.jo ghash_processBlocks 196563 977182 15.0990 75.0621 31156.jo int com.sun.crypto.provider.GCTR.doFinal(byte[], int, int, byte[], int) 50061 1027243 3.8454 78.9076 31156.jo void TestAESEncode.run() 48159 1075402 3.6993 82.6069 31156.jo void TestAESDecode.run() 18506 1093908 1.4215 84.0284 libjvm.so TypeArrayKlass::allocate_common(int, bool, Thread*) GCTR.doFinal() doesn't need do anything except increment a counter and call aescrypt_encryptBlock, but it still takes 15% of the total runtime. Intrinsifying GCTR.update() would solve this problem. Andrew. From sean.mullan at oracle.com Tue Sep 1 15:22:48 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 1 Sep 2015 11:22:48 -0400 Subject: [9] RFR 8133801: sun/security/pkcs11/Provider/ConfigShortPath.java failed in jigsaw nightly at Windows In-Reply-To: <55E4E7F8.5070608@oracle.com> References: <55E4E7F8.5070608@oracle.com> Message-ID: <55E5C2C8.4030707@oracle.com> Looks good to me. --Sean On 08/31/2015 07:49 PM, Valerie Peng wrote: > Hi, > > Can someone please help reviewing this regression test update? > > http://cr.openjdk.java.net/~valeriep/8133801/webrev.00/ > > Both tests are updated to not using private SunPKCS11 constructors. > The test Absolute.java has been updated in Jigsaw workspace, so I just > matched the copy in JDK workspace to it. > As for the test ConfigShortPath.java, the configuration files are > OS-specific, so a bit more OS-specific handling is needed. > > I have run JPRT against both JDK and Jigsaw workspace with the changed > files and results look fine. > Thanks, > Valerie From anthony.scarpino at oracle.com Tue Sep 1 15:42:09 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 1 Sep 2015 10:42:09 -0500 Subject: GCM performance and Unsafe byte array accesses In-Reply-To: <55DF3211.3060206@redhat.com> References: <55DF3211.3060206@redhat.com> Message-ID: Hi Andrew, Does your alignment changes affect x86 only or should this help all architectures? In general I don't see a disadvantage and that it could be expanded to other places in crypto too. But I have think about the effects on sparc, so that would need to be tested. Right now the sparc intrinsic does alignment checking and realigning, so it would be interesting to see if ByteArrays performed better than the intrinsic alignment. I assume you don't have the hardware to test sparc, right? Tony > On Aug 27, 2015, at 10:51 AM, Andrew Haley wrote: > > I've been looking at the performance of AES/GCM. The profile is quite > surprising: > > samples cum. samples % cum. % symbol name > 476009 476009 36.7033 36.7033 aescrypt_encryptBlock > 297239 773248 22.9190 59.6224 ghash_processBlocks > 195334 968582 15.0615 74.6839 int com.sun.crypto.provider.GCTR.doFinal(byte[], int, int, byte[], int) > > I would have expected aescrypt_encryptBlock and ghash_processBlocks to > be very high, but that GCTR.doFinal is so high is rather surprising: > all it has to do is increment a counter, call aescrypt_encryptBlock, > and xor the result with the plaintext. > > The problem seems to be due to byte accesses in GCTR.doFinal() and > GaloisCounterMode.update(). Earlier this year I wrote a bunch of new > Unsafe.get/put-XX-Unaligned methods, and these are ideal for bulk > accesses to byte arrays. So, as an experiment I wrote some methods to > do array accesses and used them to speed up GCM, with this result: > > 492274 492274 40.8856 40.8856 13256.jo aescrypt_encryptBlock > 298185 790459 24.7656 65.6512 13256.jo ghash_processBlocks > 86325 876784 7.1697 72.8209 13256.jo int com.sun.crypto.provider.GCTR.update(byte[], int, int, byte[], int) > > GCTR.update() is twice as fast as it was, and overall the performance > of AES/GCM is 10% better. > > The changes to the GCM code are quite minor: > > diff -r 6940407d544a src/java.base/share/classes/com/sun/crypto/provider/GCTR.java > --- a/src/java.base/share/classes/com/sun/crypto/provider/GCTR.java Thu Aug 20 07:36:37 2015 -0700 > +++ b/src/java.base/share/classes/com/sun/crypto/provider/GCTR.java Thu Aug 27 16:17:25 2015 +0100 > @@ -94,11 +97,12 @@ > int numOfCompleteBlocks = inLen / AES_BLOCK_SIZE; > for (int i = 0; i < numOfCompleteBlocks; i++) { > aes.encryptBlock(counter, 0, encryptedCntr, 0); > - for (int n = 0; n < AES_BLOCK_SIZE; n++) { > - int index = (i * AES_BLOCK_SIZE + n); > - out[outOfs + index] = > - (byte) ((in[inOfs + index] ^ encryptedCntr[n])); > - } > + int index = i * AES_BLOCK_SIZE; > + ByteArrays.putLongs(out, outOfs + index, > + (ByteArrays.getLong(in, inOfs + index + 0) ^ > + ByteArrays.getLong(encryptedCntr, 0)), > + (ByteArrays.getLong(in, inOfs + index + 8) ^ > + ByteArrays.getLong(encryptedCntr, 8))); > GaloisCounterMode.increment32(counter); > } > return inLen; > diff -r 6940407d544a src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java > --- a/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java Thu Aug 20 07:36:37 2015 -0700 > +++ b/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java Thu Aug 27 16:17:25 2015 +0100 > @@ -82,11 +82,8 @@ > // should never happen > throw new ProviderException("Illegal counter block length"); > } > - // start from last byte and only go over 4 bytes, i.e. total 32 bits > - int n = value.length - 1; > - while ((n >= value.length - 4) && (++value[n] == 0)) { > - n--; > - } > + int counter = ByteArrays.getInt(value, value.length - 4, true); > + ByteArrays.putInt(value, value.length - 4, counter + 1, true); > } > > // ivLen in bits > > I've attached the full diff. > > So, here's my question: there are many places over the crypto code > base where we could take advantage of this. Do you think it makes > sense to make changes like this? I can't see any major disadvantages, > and it's a considerable performance improvement. > > Andrew. > > > From aph at redhat.com Tue Sep 1 16:40:55 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 1 Sep 2015 17:40:55 +0100 Subject: GCM performance and Unsafe byte array accesses In-Reply-To: References: <55DF3211.3060206@redhat.com> Message-ID: <55E5D517.6000805@redhat.com> On 09/01/2015 04:42 PM, Anthony Scarpino wrote: > Does your alignment changes affect x86 only or should this help all > architectures? It does the best thing it can on every architecture. On those which support unaligned accesses, it uses them; if not, it doesn't. But there is a very cool optimization on machines without unaligned memory accesses: if the profile data says that accesses at a particular call site are always aligned, C2 generates optimistic code to do the aligned fetch, plus a very simple check. > In general I don't see a disadvantage and that it could be expanded > to other places in crypto too. Yes, lots of other places. This one is my poster child because the effect is so dramatic. > But I have think about the effects on sparc, so that would need to > be tested. Right now the sparc intrinsic does alignment checking > and realigning, so it would be interesting to see if ByteArrays > performed better than the intrinsic alignment. I assume you don't > have the hardware to test sparc, right? I don't. My guess is, though, that it'll not lose on SPARC, and will probably win. If it does lose that's something to look at. Andrew. From sean.mullan at oracle.com Tue Sep 1 18:29:33 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 1 Sep 2015 14:29:33 -0400 Subject: RFR JDK-8134364: Add defensive copies to get/set methods for OCSPNonceExtension In-Reply-To: <55E109F9.1030701@oracle.com> References: <55DBF538.7070000@oracle.com> <55DC23DE.1080806@oracle.com> <55DC7059.2090706@oracle.com> <55DC859D.2090704@oracle.com> <55E109F9.1030701@oracle.com> Message-ID: <55E5EE8D.1000004@oracle.com> On 08/28/2015 09:25 PM, Jamil Nimeh wrote: > Hello all, > > I've removed the CertAttrSet interface from OCSPNonceExtension and > trimmed away a few unneeded methods. As a result the class is immutable > now. Looks a lot cleaner. Strictly speaking, the cloning is not necessary since this is an internal class -- unless the array can leak through some code path to untrusted code, but I think in this case it is good practice and probably won't affect performance much as nonces are a rarely used feature (I think). A few comments (some stylistic based on [1]) on OCSPNonceExtension: 48: make class final 49: constants are generally named upper case and with "_" as a word separator, so EXTENSION_NAME is better. 58: move this private method after the constructors (or better yet, embed it inside the ctor since it is only called from there) 84: not necessarily the SUN provider, depends on the configured provider order 174: toString should probably use StringBuilder.append instead of "+". --Sean [1] review ongoing at http://cr.openjdk.java.net/~alundblad/styleguide/feedback.html > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8134364 > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8134364/webrev.01 > > Thanks, > --Jamil > > On 08/25/2015 08:11 AM, Jamil Nimeh wrote: >> Hi Sean, >> >> Yes, I was just following Extension convention in terms of >> implementing CertAttrSet. Within sun.security.x509, X509CertInfo uses >> the set methods from other objects implementing CertAttrSet. But >> OCSPNonceExtension really isn't a certificate attribute so it probably >> doesn't need to bring this interface in. >> >> I'll refactor this and alter the tests to match. >> >> --Jamil >> >> On 08/25/2015 06:40 AM, Sean Mullan wrote: >>> Is it necessary for the class to implement CertAttrSet? I realize all >>> of the internal X.509 extensions implement that, but that was done a >>> long time ago and not something we really want to carry forward if >>> not needed. I think it would be cleaner not to do that as it would >>> more easily allow you to make the class immutable, and would allow >>> you to remove the set method. >>> >>> Thanks, >>> Sean >>> >>> On 08/25/2015 04:14 AM, Xuelei Fan wrote: >>>> OCSPNonceExtension.java >>>> ======================= >>>> - nonceData = (byte[])obj; >>>> + nonceData = ((byte[])obj).clone(); >>>> >>>> Do you want to check null obj? >>>> >>>> - return nonceData; >>>> + return (nonceData != null ? nonceData.clone() : null); >>>> >>>> I think you may want to enclose the "!=" operator as: >>>> >>>> + return (nonceData != null) ? nonceData.clone() : null; >>>> >>>> >>>> Xuelei >>>> >>>> On 8/25/2015 12:55 PM, Jamil Nimeh wrote: >>>>> Hi all, >>>>> >>>>> This is a quick fix to the OCSPNonceExtension class to add a couple >>>>> defensive copies to public get/set methods. >>>>> >>>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8134364 >>>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8134364/webrev.00 >>>>> >>>>> Thanks, >>>>> --Jamil >>>> >> > From vladimir.kozlov at oracle.com Tue Sep 1 20:45:00 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 1 Sep 2015 13:45:00 -0700 Subject: RFR: 8134869: AARCH64: GHASH intrinsic is not optimal In-Reply-To: <55E5B9FD.805@redhat.com> References: <55E5B9FD.805@redhat.com> Message-ID: <55E60E4C.4030807@oracle.com> Very nice rewrite. Looks good. Thanks, Vladimir On 9/1/15 7:45 AM, Andrew Haley wrote: > I've been looking at the intrinsic we have for GHASH. While it is > decent as it goes, its performance is considerably worse than some > other implementations of GHASH on the same processor. > > Thanks are due to Alexander Alexeev who did a fine job implementing > the x86 algorithm on AArch64, but the result is not optimal. on > AArch64 we have the advantage of a bit-reversal instruction which x86 > parts don't have, and this makes it possible to write a fully > little-endian implementation of GHASH which is far more idiomatic on > AArch64 than the big-endian implementation the x86 version uses. This > gets us an overall performance improvement of AES/GCM of 10-20%. > > I've also taken the opportunity to add a lot of comments. The > algorithms used are (fairly) obscure and most open source software > implementations don't really explain what they're doing. In > particular, the bizarre representation of polynomials in GF(2) (where > byte ordering is little endian but bit ordering is big endian) is very > confusing and surely deserves a comment or two. > > http://cr.openjdk.java.net/~aph/8134869-ghash-1/ > > One other remark: the AES/GCM implementation has a lot of overhead. > Some profile data (on x86) looks like this: > > samples cum. samples % cum. % image name symbol name > 479605 479605 36.8408 36.8408 31156.jo aescrypt_encryptBlock > 301014 780619 23.1224 59.9632 31156.jo ghash_processBlocks > 196563 977182 15.0990 75.0621 31156.jo int com.sun.crypto.provider.GCTR.doFinal(byte[], int, int, byte[], int) > 50061 1027243 3.8454 78.9076 31156.jo void TestAESEncode.run() > 48159 1075402 3.6993 82.6069 31156.jo void TestAESDecode.run() > 18506 1093908 1.4215 84.0284 libjvm.so TypeArrayKlass::allocate_common(int, bool, Thread*) > > GCTR.doFinal() doesn't need do anything except increment a counter > and call aescrypt_encryptBlock, but it still takes 15% of the total > runtime. Intrinsifying GCTR.update() would solve this problem. > > Andrew. > From jamil.j.nimeh at oracle.com Tue Sep 1 21:12:13 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 01 Sep 2015 14:12:13 -0700 Subject: RFR JDK-8134364: Add defensive copies to get/set methods for OCSPNonceExtension In-Reply-To: <55E5EE8D.1000004@oracle.com> References: <55DBF538.7070000@oracle.com> <55DC23DE.1080806@oracle.com> <55DC7059.2090706@oracle.com> <55DC859D.2090704@oracle.com> <55E109F9.1030701@oracle.com> <55E5EE8D.1000004@oracle.com> Message-ID: <55E614AD.4070500@oracle.com> Hi Sean, thanks for the comments, they all sound very reasonable to me. I'll get on fixing those now. WRT the cloning, I figured that since the class had public visibility and the methods in question were public methods that it was better to err on the side of safety, even with the class being in a "sun" package. Thanks also for the link [1]...interesting reading. --Jamil On 09/01/2015 11:29 AM, Sean Mullan wrote: > On 08/28/2015 09:25 PM, Jamil Nimeh wrote: >> Hello all, >> >> I've removed the CertAttrSet interface from OCSPNonceExtension and >> trimmed away a few unneeded methods. As a result the class is immutable >> now. > > Looks a lot cleaner. Strictly speaking, the cloning is not necessary > since this is an internal class -- unless the array can leak through > some code path to untrusted code, but I think in this case it is good > practice and probably won't affect performance much as nonces are a > rarely used feature (I think). A few comments (some stylistic based on > [1]) on OCSPNonceExtension: > > 48: make class final > > 49: constants are generally named upper case and with "_" as a word > separator, so EXTENSION_NAME is better. > > 58: move this private method after the constructors (or better yet, > embed it inside the ctor since it is only called from there) > > 84: not necessarily the SUN provider, depends on the configured > provider order > > 174: toString should probably use StringBuilder.append instead of "+". > > --Sean > > [1] review ongoing at > http://cr.openjdk.java.net/~alundblad/styleguide/feedback.html > >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8134364 >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8134364/webrev.01 >> >> Thanks, >> --Jamil >> >> On 08/25/2015 08:11 AM, Jamil Nimeh wrote: >>> Hi Sean, >>> >>> Yes, I was just following Extension convention in terms of >>> implementing CertAttrSet. Within sun.security.x509, X509CertInfo uses >>> the set methods from other objects implementing CertAttrSet. But >>> OCSPNonceExtension really isn't a certificate attribute so it probably >>> doesn't need to bring this interface in. >>> >>> I'll refactor this and alter the tests to match. >>> >>> --Jamil >>> >>> On 08/25/2015 06:40 AM, Sean Mullan wrote: >>>> Is it necessary for the class to implement CertAttrSet? I realize all >>>> of the internal X.509 extensions implement that, but that was done a >>>> long time ago and not something we really want to carry forward if >>>> not needed. I think it would be cleaner not to do that as it would >>>> more easily allow you to make the class immutable, and would allow >>>> you to remove the set method. >>>> >>>> Thanks, >>>> Sean >>>> >>>> On 08/25/2015 04:14 AM, Xuelei Fan wrote: >>>>> OCSPNonceExtension.java >>>>> ======================= >>>>> - nonceData = (byte[])obj; >>>>> + nonceData = ((byte[])obj).clone(); >>>>> >>>>> Do you want to check null obj? >>>>> >>>>> - return nonceData; >>>>> + return (nonceData != null ? nonceData.clone() : null); >>>>> >>>>> I think you may want to enclose the "!=" operator as: >>>>> >>>>> + return (nonceData != null) ? nonceData.clone() : null; >>>>> >>>>> >>>>> Xuelei >>>>> >>>>> On 8/25/2015 12:55 PM, Jamil Nimeh wrote: >>>>>> Hi all, >>>>>> >>>>>> This is a quick fix to the OCSPNonceExtension class to add a couple >>>>>> defensive copies to public get/set methods. >>>>>> >>>>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8134364 >>>>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8134364/webrev.00 >>>>>> >>>>>> Thanks, >>>>>> --Jamil >>>>> >>> >> From artem.smotrakov at oracle.com Tue Sep 1 23:15:06 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 1 Sep 2015 16:15:06 -0700 Subject: [9] RFR: 8134708: Certpath validation fails to load certs and CRLs if AIA and CRLDP extensions point to LDAP resources Message-ID: <55E6317A.7080401@oracle.com> Hello, Please review this fix for 9. Certpath validation fails to load certs and CRLs if AIA and CRLDP extensions point to LDAP resources. This happens because LDAPCertStore accepts only instances of LDAPCertStoreParameters and URICertStoreParameters classes, but sun.security.provider.certpath.URICertStore uses an inner static URICertStoreParameters class. Please see details in the bug. This fix removes URICertStore.URICertStoreParameters class, and updates URICertStore and DistributionPointFetcher to use new java.security.cert.URICertStoreParameters class. A regression test starts a local name service which logs requested host names. The test checks that host names from AIA and CRLDP extensions were loaded and requested to resolve during certpath validation. Bug: https://bugs.openjdk.java.net/browse/JDK-8134708 Webrev: http://cr.openjdk.java.net/~asmotrak/8134708/webrev.01/ Artem -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Wed Sep 2 01:14:15 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 01 Sep 2015 18:14:15 -0700 Subject: RFR JDK-8134364: Add defensive copies to get/set methods for OCSPNonceExtension In-Reply-To: <55E5EE8D.1000004@oracle.com> References: <55DBF538.7070000@oracle.com> <55DC23DE.1080806@oracle.com> <55DC7059.2090706@oracle.com> <55DC859D.2090704@oracle.com> <55E109F9.1030701@oracle.com> <55E5EE8D.1000004@oracle.com> Message-ID: <55E64D67.2080803@oracle.com> Hi Sean, et al., I've updated the review to incorporate Sean's comments. Sean, I was able to remove encodeInternal() and make it into a one-liner inside each of the ctors, so that shrunk things down a bit more which is nice. Let me know what you think. Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8134364/webrev.02/ Thanks, --Jamil On 09/01/2015 11:29 AM, Sean Mullan wrote: > On 08/28/2015 09:25 PM, Jamil Nimeh wrote: >> Hello all, >> >> I've removed the CertAttrSet interface from OCSPNonceExtension and >> trimmed away a few unneeded methods. As a result the class is immutable >> now. > > Looks a lot cleaner. Strictly speaking, the cloning is not necessary > since this is an internal class -- unless the array can leak through > some code path to untrusted code, but I think in this case it is good > practice and probably won't affect performance much as nonces are a > rarely used feature (I think). A few comments (some stylistic based on > [1]) on OCSPNonceExtension: > > 48: make class final > > 49: constants are generally named upper case and with "_" as a word > separator, so EXTENSION_NAME is better. > > 58: move this private method after the constructors (or better yet, > embed it inside the ctor since it is only called from there) > > 84: not necessarily the SUN provider, depends on the configured > provider order > > 174: toString should probably use StringBuilder.append instead of "+". > > --Sean > > [1] review ongoing at > http://cr.openjdk.java.net/~alundblad/styleguide/feedback.html > >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8134364 >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8134364/webrev.01 >> >> Thanks, >> --Jamil >> >> On 08/25/2015 08:11 AM, Jamil Nimeh wrote: >>> Hi Sean, >>> >>> Yes, I was just following Extension convention in terms of >>> implementing CertAttrSet. Within sun.security.x509, X509CertInfo uses >>> the set methods from other objects implementing CertAttrSet. But >>> OCSPNonceExtension really isn't a certificate attribute so it probably >>> doesn't need to bring this interface in. >>> >>> I'll refactor this and alter the tests to match. >>> >>> --Jamil >>> >>> On 08/25/2015 06:40 AM, Sean Mullan wrote: >>>> Is it necessary for the class to implement CertAttrSet? I realize all >>>> of the internal X.509 extensions implement that, but that was done a >>>> long time ago and not something we really want to carry forward if >>>> not needed. I think it would be cleaner not to do that as it would >>>> more easily allow you to make the class immutable, and would allow >>>> you to remove the set method. >>>> >>>> Thanks, >>>> Sean >>>> >>>> On 08/25/2015 04:14 AM, Xuelei Fan wrote: >>>>> OCSPNonceExtension.java >>>>> ======================= >>>>> - nonceData = (byte[])obj; >>>>> + nonceData = ((byte[])obj).clone(); >>>>> >>>>> Do you want to check null obj? >>>>> >>>>> - return nonceData; >>>>> + return (nonceData != null ? nonceData.clone() : null); >>>>> >>>>> I think you may want to enclose the "!=" operator as: >>>>> >>>>> + return (nonceData != null) ? nonceData.clone() : null; >>>>> >>>>> >>>>> Xuelei >>>>> >>>>> On 8/25/2015 12:55 PM, Jamil Nimeh wrote: >>>>>> Hi all, >>>>>> >>>>>> This is a quick fix to the OCSPNonceExtension class to add a couple >>>>>> defensive copies to public get/set methods. >>>>>> >>>>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8134364 >>>>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8134364/webrev.00 >>>>>> >>>>>> Thanks, >>>>>> --Jamil >>>>> >>> >> From weijun.wang at oracle.com Wed Sep 2 02:05:58 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 2 Sep 2015 10:05:58 +0800 Subject: RFR 8129789: implies() of ServicePermission and DelegationPermission underspecified Message-ID: <55E65986.3050601@oracle.com> Please review this spec clarification at http://cr.openjdk.java.net/~weijun/8129789/webrev.00 Thanks Max From sha.jiang at oracle.com Wed Sep 2 04:58:29 2015 From: sha.jiang at oracle.com (Sha Jiang) Date: Wed, 2 Sep 2015 12:58:29 +0800 Subject: RFR JDK-8075286: Additional tests for signature algorithm OIDs and transformation string Message-ID: <55E681F5.2000607@oracle.com> Hi Security developers, I have a security test bug https://bugs.openjdk.java.net/browse/JDK-8075286, which adds more cases for NSA Suite B algorithms in jdk repo. Please review this patch at http://cr.openjdk.java.net/~fyuan/jjiang/8075286/webrev.00/ Every comment is appreciated. Best Regards, John Jiang From frank.yuan at oracle.com Wed Sep 2 07:54:38 2015 From: frank.yuan at oracle.com (Frank Yuan) Date: Wed, 2 Sep 2015 15:54:38 +0800 Subject: RFR JDK-8074931: Additional tests for CertPath API Message-ID: <033f01d0e554$9f9dd900$ded98b00$@oracle.com> Hi Security developers I have a security test bug https://bugs.openjdk.java.net/browse/JDK-8074931, which is to add more coverage for CertPath and X509CertSelector in jdk repo. Would you like to review this patch http://cr.openjdk.java.net/~fyuan/8074931/webrev.00/? Your comment will be appreciated. Best Regards Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Wed Sep 2 10:23:46 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Wed, 02 Sep 2015 11:23:46 +0100 Subject: [9] RFR: 8134708: Certpath validation fails to load certs and CRLs if AIA and CRLDP extensions point to LDAP resources In-Reply-To: <55E6317A.7080401@oracle.com> References: <55E6317A.7080401@oracle.com> Message-ID: <55E6CE32.6040604@oracle.com> Hi Artem, I'll let the main review to other reviewers but while we're here, can you consider improving the original exception message that was seen in this issue ? In LDAPCertStore constructor : } else { throw new InvalidAlgorithmParameterException( "parameters must be either LDAPCertStoreParameters or " + "URICertStoreParameters"); } Can we print the instance type of the 'params' variable in the exception message ? params.getClass().getName() should be sufficient. I see 2-3 other exceptions in LDAPCertStore that could be improved there also. If you can change them, that would be great - otherwise we can follow up with enhancement request. if (!u.getScheme().equalsIgnoreCase("ldap")) { throw new InvalidAlgorithmParameterException( "Only LDAP URIs are supported for LDAP Certore"); Let's print the scheme received! } else if (!(selector instanceof X509CertSelector)) { throw new CertStoreException("need X509CertSelector to find certs"); this code occurs twice. Let's print the selector class received. Regards, Sean. On 02/09/15 00:15, Artem Smotrakov wrote: > Hello, > > Please review this fix for 9. > > Certpath validation fails to load certs and CRLs if AIA and CRLDP > extensions point to LDAP resources. This happens because LDAPCertStore > accepts only instances of LDAPCertStoreParameters and > URICertStoreParameters classes, but > sun.security.provider.certpath.URICertStore uses an inner static > URICertStoreParameters class. Please see details in the bug. > > This fix removes URICertStore.URICertStoreParameters class, and > updates URICertStore and DistributionPointFetcher to use new > java.security.cert.URICertStoreParameters class. > > A regression test starts a local name service which logs requested > host names. The test checks that host names from AIA and CRLDP > extensions were loaded and requested to resolve during certpath > validation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8134708 > Webrev: http://cr.openjdk.java.net/~asmotrak/8134708/webrev.01/ > > Artem -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Sep 2 11:11:08 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 2 Sep 2015 07:11:08 -0400 Subject: RFR 8129789: implies() of ServicePermission and DelegationPermission underspecified In-Reply-To: <55E65986.3050601@oracle.com> References: <55E65986.3050601@oracle.com> Message-ID: <55E6D94C.2060404@oracle.com> Looks good. --Sean On 09/01/2015 10:05 PM, Weijun Wang wrote: > Please review this spec clarification at > > http://cr.openjdk.java.net/~weijun/8129789/webrev.00 > > Thanks > Max From valerie.peng at oracle.com Wed Sep 2 20:45:34 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 02 Sep 2015 13:45:34 -0700 Subject: [9] RFR: 8130875 Out of memory when using TLS_RSA_WITH_AES_128_GCM_SHA256 Message-ID: <55E75FEE.6020702@oracle.com> Can someone help review this java workaround for Solaris memory leak bug in Ucrypto library? Essentially, the memory leak occurs when a null output buffer is specified when doing encryption/decryption. So, the workaround in OracleUcrypto provider is to use non-null output buffers. Webrev: http://cr.openjdk.java.net/~valeriep/8130875/webrev.00/ The fix is verified by running a program for a while and observe the memory usage. Valerie From anthony.scarpino at oracle.com Thu Sep 3 03:50:26 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 2 Sep 2015 22:50:26 -0500 Subject: [9] RFR: 8130875 Out of memory when using TLS_RSA_WITH_AES_128_GCM_SHA256 In-Reply-To: <55E75FEE.6020702@oracle.com> References: <55E75FEE.6020702@oracle.com> Message-ID: <15D5756C-8FA7-47F1-8D69-348C1413D413@oracle.com> > On Sep 2, 2015, at 3:45 PM, Valerie Peng wrote: > > > Can someone help review this java workaround for Solaris memory leak bug in Ucrypto library? > Essentially, the memory leak occurs when a null output buffer is specified when doing encryption/decryption. > So, the workaround in OracleUcrypto provider is to use non-null output buffers. > > Webrev: http://cr.openjdk.java.net/~valeriep/8130875/webrev.00/ > > The fix is verified by running a program for a while and observe the memory usage. > Valerie Not related to the code, I think the bug synopsis should be more specific to the issue. It looks too eye-catching by saying java runs out of memory with that cipher suite, when it?s the OS library not cleaning up correctly for a particular provider when using AES GCM only. I would not be surprised if a future issue got incorrectly linked because the synopsis was too generic. Maybe something like ?OracleUcrypto workaround for AES GCM with a null bufOut pointer during doFinal()" As for the code, I?m a bit unsure about using outLen?s reference as the bufOut pointer. However, after seeing there are checks to make sure outLen is zero and it?s documented well that this is a workaround, I?m ok with this. Tony From anthony.scarpino at oracle.com Thu Sep 3 14:20:56 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 3 Sep 2015 09:20:56 -0500 Subject: [9] RFR: 8130875 Out of memory when using TLS_RSA_WITH_AES_128_GCM_SHA256 In-Reply-To: <15D5756C-8FA7-47F1-8D69-348C1413D413@oracle.com> References: <55E75FEE.6020702@oracle.com> <15D5756C-8FA7-47F1-8D69-348C1413D413@oracle.com> Message-ID: <07219F74-9237-45AA-A5C3-8BFA8A34F13B@oracle.com> > On Sep 2, 2015, at 10:50 PM, Anthony Scarpino wrote: > > >> On Sep 2, 2015, at 3:45 PM, Valerie Peng wrote: >> >> >> Can someone help review this java workaround for Solaris memory leak bug in Ucrypto library? >> Essentially, the memory leak occurs when a null output buffer is specified when doing encryption/decryption. >> So, the workaround in OracleUcrypto provider is to use non-null output buffers. >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8130875/webrev.00/ >> >> The fix is verified by running a program for a while and observe the memory usage. >> Valerie > > > Not related to the code, I think the bug synopsis should be more specific to the issue. It looks too eye-catching by saying java runs out of memory with that cipher suite, when it?s the OS library not cleaning up correctly for a particular provider when using AES GCM only. I would not be surprised if a future issue got incorrectly linked because the synopsis was too generic. Maybe something like ?OracleUcrypto workaround for AES GCM with a null bufOut pointer during doFinal()" > > As for the code, I?m a bit unsure about using outLen?s reference as the bufOut pointer. However, after seeing there are checks to make sure outLen is zero and it?s documented well that this is a workaround, I?m ok with this. > > Tony Thanks to Jamil for asking me about the webrev privately, I discounted a concern because I misread the webrev. So the comments are purely from the JNI code checks. Maybe there are checks in the java code that prevent the below situations, but it?s still uneasy having no protection in the JNI code The change around 438, does not make sure outLen is zero, so if bufOut points to the reference of outLen, it could start overwriting data or even somewhere else with the offset also being unchecked. The check should fail if outLen is not zero. Before the change, having bufOut being null we could depend on the OS library to check, now giving it a false pointer, we should do more checking. Tony From ivan.gerasimov at oracle.com Thu Sep 3 15:53:22 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 3 Sep 2015 18:53:22 +0300 Subject: RFR 8132082: Let OracleUcrypto accept RSAPrivateKey Message-ID: <55E86CF2.9000601@oracle.com> Hello! Would you please help review this fix, which adds support for RSAPrivateKey to the OracleUcrypto provider? The fix was provided by Valerie Peng. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8132082 WEBREV: http://cr.openjdk.java.net/~igerasim/8132082/00/webrev/ Sincerely yours, Ivan From sean.coffey at oracle.com Thu Sep 3 17:44:34 2015 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 3 Sep 2015 18:44:34 +0100 Subject: RFR 8132082: Let OracleUcrypto accept RSAPrivateKey In-Reply-To: <55E86CF2.9000601@oracle.com> References: <55E86CF2.9000601@oracle.com> Message-ID: <55E88702.4050904@oracle.com> Looks good to me Ivan. Thanks for handling. Some new exception messages need padding out as per efforts in 8133535 but I'll re-sync/rework my patch once your changes hit the repo. Regards, Sean. On 03/09/2015 16:53, Ivan Gerasimov wrote: > Hello! > > Would you please help review this fix, which adds support for > RSAPrivateKey to the OracleUcrypto provider? > The fix was provided by Valerie Peng. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8132082 > WEBREV: http://cr.openjdk.java.net/~igerasim/8132082/00/webrev/ > > > Sincerely yours, > Ivan > From ivan.gerasimov at oracle.com Thu Sep 3 19:33:37 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 3 Sep 2015 22:33:37 +0300 Subject: RFR 8132082: Let OracleUcrypto accept RSAPrivateKey In-Reply-To: <55E88702.4050904@oracle.com> References: <55E86CF2.9000601@oracle.com> <55E88702.4050904@oracle.com> Message-ID: <55E8A091.8050109@oracle.com> On 03.09.2015 20:44, Se?n Coffey wrote: > Looks good to me Ivan. Thanks for handling. > Thank you Se?n! > Some new exception messages need padding out as per efforts in 8133535 > but I'll re-sync/rework my patch once your changes hit the repo. > Yes, that will be very helpful! Sincerely yours, Ivan > Regards, > Sean. > > On 03/09/2015 16:53, Ivan Gerasimov wrote: >> Hello! >> >> Would you please help review this fix, which adds support for >> RSAPrivateKey to the OracleUcrypto provider? >> The fix was provided by Valerie Peng. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8132082 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8132082/00/webrev/ >> >> >> Sincerely yours, >> Ivan >> > > From sean.mullan at oracle.com Thu Sep 3 20:39:44 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 3 Sep 2015 16:39:44 -0400 Subject: RFR 8056174: New APIs for jar signing In-Reply-To: <55E54ACC.6020004@oracle.com> References: <55DB22A9.40704@oracle.com> <55E54ACC.6020004@oracle.com> Message-ID: <55E8B010.70905@oracle.com> On 09/01/2015 02:50 AM, Weijun Wang wrote: > Updated a little: rewrite of jarsigner tool itself using the JarSigner > API included. Still at the same URL below. I notice that you don't use the new JarSigner API at all in the jarsigner tool and go straight to the BuilderX/JarSignerX classes. This worries me as it means the API is not sufficient for our own uses and therefore may not be sufficient for anyone else either. I think the flaw is that we have not made it extensible. JarSigner is a final class, so it can't be subclassed with new functionality. Removing the final keyword would be easy, but that doesn't really solve the problem. It looks like we are not the first ones to tackle this problem. Here is one link: https://weblogs.java.net/blog/emcmanus/archive/2010/10/25/using-builder-pattern-subclasses Can you think about this some more and see if the design can be adapted to allow JarSigner to be extended? Thanks, Sean > > --Max > > On 08/24/2015 09:56 PM, Weijun Wang wrote: >> Hi All >> >> Please review the code change at >> >> http://cr.openjdk.java.net/~weijun/8056174/webrev.02/ >> >> A new JarSigner public API is introduced to OpenJDK. The code change >> chooses a two-layer implementation style, with public JarSigner/Builder >> in jdk.security and private JarSignerX/BuilderX in sun.security. The >> private side contains some unpopular options which I hope can be used to >> implement the jarsigner tool itself in another changeset. >> >> Some spec clarification is made since my last mail [1], including >> Builder#sign, JarSigner#getDigestAlg, and JarSigner#getSigAlg. In >> Builder, I am still using short method names (sigAlg, digestAlg, and >> tsa) since I think the jarsigner option names are already widely >> accepted. Otherwise, a name like setDigestAlgorithm seems a little >> unfamiliar. >> >> Thanks >> Max >> >> [1] >> http://mail.openjdk.java.net/pipermail/security-dev/2015-August/012636.html >> From valerie.peng at oracle.com Thu Sep 3 20:40:21 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 03 Sep 2015 13:40:21 -0700 Subject: [9] RFR: 8130875 Out of memory when using TLS_RSA_WITH_AES_128_GCM_SHA256 In-Reply-To: <07219F74-9237-45AA-A5C3-8BFA8A34F13B@oracle.com> References: <55E75FEE.6020702@oracle.com> <15D5756C-8FA7-47F1-8D69-348C1413D413@oracle.com> <07219F74-9237-45AA-A5C3-8BFA8A34F13B@oracle.com> Message-ID: <55E8B035.7010601@oracle.com> Alright, I will update the synopsis. I am not exactly sure if it's GCM only as CipherFinal() call is used for all Ucrypto encryption/decryption. The testcase is using AES/GCM, but I am not sure if the underlying native code which has the problem is GCM specific. The using outLen's reference as the bufOut is from Solaris team. Since null output buffer is always used with 0 output length when java code calls the JNI code, it should be ok. However, let me see where I can add more checks. Thanks, Valerie On 9/3/2015 7:20 AM, Anthony Scarpino wrote: >> On Sep 2, 2015, at 10:50 PM, Anthony Scarpino wrote: >> >> >>> On Sep 2, 2015, at 3:45 PM, Valerie Peng wrote: >>> >>> >>> Can someone help review this java workaround for Solaris memory leak bug in Ucrypto library? >>> Essentially, the memory leak occurs when a null output buffer is specified when doing encryption/decryption. >>> So, the workaround in OracleUcrypto provider is to use non-null output buffers. >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8130875/webrev.00/ >>> >>> The fix is verified by running a program for a while and observe the memory usage. >>> Valerie >> >> Not related to the code, I think the bug synopsis should be more specific to the issue. It looks too eye-catching by saying java runs out of memory with that cipher suite, when it?s the OS library not cleaning up correctly for a particular provider when using AES GCM only. I would not be surprised if a future issue got incorrectly linked because the synopsis was too generic. Maybe something like ?OracleUcrypto workaround for AES GCM with a null bufOut pointer during doFinal()" >> >> As for the code, I?m a bit unsure about using outLen?s reference as the bufOut pointer. However, after seeing there are checks to make sure outLen is zero and it?s documented well that this is a workaround, I?m ok with this. >> >> Tony > Thanks to Jamil for asking me about the webrev privately, I discounted a concern because I misread the webrev. > > So the comments are purely from the JNI code checks. Maybe there are checks in the java code that prevent the below situations, but it?s still uneasy having no protection in the JNI code > > The change around 438, does not make sure outLen is zero, so if bufOut points to the reference of outLen, it could start overwriting data or even somewhere else with the offset also being unchecked. The check should fail if outLen is not zero. Before the change, having bufOut being null we could depend on the OS library to check, now giving it a false pointer, we should do more checking. > > Tony > From valerie.peng at oracle.com Thu Sep 3 21:25:33 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 03 Sep 2015 14:25:33 -0700 Subject: [9] RFR: 8130875 Out of memory when using TLS_RSA_WITH_AES_128_GCM_SHA256 In-Reply-To: <07219F74-9237-45AA-A5C3-8BFA8A34F13B@oracle.com> References: <55E75FEE.6020702@oracle.com> <15D5756C-8FA7-47F1-8D69-348C1413D413@oracle.com> <07219F74-9237-45AA-A5C3-8BFA8A34F13B@oracle.com> Message-ID: <55E8BACD.5070107@oracle.com> For all the JavaCritical calls, it's impossible to have the combination of (bufOut==NULL && outLen!=0) as the outLen value is generated by VM based on bufOut. Anyway, just to play it safe, I added a line to set outLen to 0 just to match what is done for line 657. http://cr.openjdk.java.net/~valeriep/8130875/webrev.01/ Thanks, Valerie On 9/3/2015 7:20 AM, Anthony Scarpino wrote: >> On Sep 2, 2015, at 10:50 PM, Anthony Scarpino wrote: >> >> >>> On Sep 2, 2015, at 3:45 PM, Valerie Peng wrote: >>> >>> >>> Can someone help review this java workaround for Solaris memory leak bug in Ucrypto library? >>> Essentially, the memory leak occurs when a null output buffer is specified when doing encryption/decryption. >>> So, the workaround in OracleUcrypto provider is to use non-null output buffers. >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8130875/webrev.00/ >>> >>> The fix is verified by running a program for a while and observe the memory usage. >>> Valerie >> >> Not related to the code, I think the bug synopsis should be more specific to the issue. It looks too eye-catching by saying java runs out of memory with that cipher suite, when it?s the OS library not cleaning up correctly for a particular provider when using AES GCM only. I would not be surprised if a future issue got incorrectly linked because the synopsis was too generic. Maybe something like ?OracleUcrypto workaround for AES GCM with a null bufOut pointer during doFinal()" >> >> As for the code, I?m a bit unsure about using outLen?s reference as the bufOut pointer. However, after seeing there are checks to make sure outLen is zero and it?s documented well that this is a workaround, I?m ok with this. >> >> Tony > Thanks to Jamil for asking me about the webrev privately, I discounted a concern because I misread the webrev. > > So the comments are purely from the JNI code checks. Maybe there are checks in the java code that prevent the below situations, but it?s still uneasy having no protection in the JNI code > > The change around 438, does not make sure outLen is zero, so if bufOut points to the reference of outLen, it could start overwriting data or even somewhere else with the offset also being unchecked. The check should fail if outLen is not zero. Before the change, having bufOut being null we could depend on the OS library to check, now giving it a false pointer, we should do more checking. > > Tony > From valerie.peng at oracle.com Fri Sep 4 00:24:11 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 03 Sep 2015 17:24:11 -0700 Subject: RFR 8132082: Let OracleUcrypto accept RSAPrivateKey In-Reply-To: <55E8A091.8050109@oracle.com> References: <55E86CF2.9000601@oracle.com> <55E88702.4050904@oracle.com> <55E8A091.8050109@oracle.com> Message-ID: <55E8E4AB.2020106@oracle.com> Thanks for taking care of this~ Valerie On 9/3/2015 12:33 PM, Ivan Gerasimov wrote: > > > On 03.09.2015 20:44, Se?n Coffey wrote: >> Looks good to me Ivan. Thanks for handling. >> > Thank you Se?n! > >> Some new exception messages need padding out as per efforts in >> 8133535 but I'll re-sync/rework my patch once your changes hit the repo. >> > Yes, that will be very helpful! > > Sincerely yours, > Ivan > > > >> Regards, >> Sean. >> >> On 03/09/2015 16:53, Ivan Gerasimov wrote: >>> Hello! >>> >>> Would you please help review this fix, which adds support for >>> RSAPrivateKey to the OracleUcrypto provider? >>> The fix was provided by Valerie Peng. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8132082 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8132082/00/webrev/ >>> >>> >>> Sincerely yours, >>> Ivan >>> >> >> > From sean.mullan at oracle.com Fri Sep 4 14:10:28 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 4 Sep 2015 10:10:28 -0400 Subject: RFR JDK-8134364: Add defensive copies to get/set methods for OCSPNonceExtension In-Reply-To: <55E64D67.2080803@oracle.com> References: <55DBF538.7070000@oracle.com> <55DC23DE.1080806@oracle.com> <55DC7059.2090706@oracle.com> <55DC859D.2090704@oracle.com> <55E109F9.1030701@oracle.com> <55E5EE8D.1000004@oracle.com> <55E64D67.2080803@oracle.com> Message-ID: <55E9A654.20607@oracle.com> Looks good. --Sean On 09/01/2015 09:14 PM, Jamil Nimeh wrote: > Hi Sean, et al., > > I've updated the review to incorporate Sean's comments. Sean, I was > able to remove encodeInternal() and make it into a one-liner inside each > of the ctors, so that shrunk things down a bit more which is nice. Let > me know what you think. > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8134364/webrev.02/ > > Thanks, > --Jamil > > On 09/01/2015 11:29 AM, Sean Mullan wrote: >> On 08/28/2015 09:25 PM, Jamil Nimeh wrote: >>> Hello all, >>> >>> I've removed the CertAttrSet interface from OCSPNonceExtension and >>> trimmed away a few unneeded methods. As a result the class is immutable >>> now. >> >> Looks a lot cleaner. Strictly speaking, the cloning is not necessary >> since this is an internal class -- unless the array can leak through >> some code path to untrusted code, but I think in this case it is good >> practice and probably won't affect performance much as nonces are a >> rarely used feature (I think). A few comments (some stylistic based on >> [1]) on OCSPNonceExtension: >> >> 48: make class final >> >> 49: constants are generally named upper case and with "_" as a word >> separator, so EXTENSION_NAME is better. >> >> 58: move this private method after the constructors (or better yet, >> embed it inside the ctor since it is only called from there) >> >> 84: not necessarily the SUN provider, depends on the configured >> provider order >> >> 174: toString should probably use StringBuilder.append instead of "+". >> >> --Sean >> >> [1] review ongoing at >> http://cr.openjdk.java.net/~alundblad/styleguide/feedback.html >> >>> >>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8134364 >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8134364/webrev.01 >>> >>> Thanks, >>> --Jamil >>> >>> On 08/25/2015 08:11 AM, Jamil Nimeh wrote: >>>> Hi Sean, >>>> >>>> Yes, I was just following Extension convention in terms of >>>> implementing CertAttrSet. Within sun.security.x509, X509CertInfo uses >>>> the set methods from other objects implementing CertAttrSet. But >>>> OCSPNonceExtension really isn't a certificate attribute so it probably >>>> doesn't need to bring this interface in. >>>> >>>> I'll refactor this and alter the tests to match. >>>> >>>> --Jamil >>>> >>>> On 08/25/2015 06:40 AM, Sean Mullan wrote: >>>>> Is it necessary for the class to implement CertAttrSet? I realize all >>>>> of the internal X.509 extensions implement that, but that was done a >>>>> long time ago and not something we really want to carry forward if >>>>> not needed. I think it would be cleaner not to do that as it would >>>>> more easily allow you to make the class immutable, and would allow >>>>> you to remove the set method. >>>>> >>>>> Thanks, >>>>> Sean >>>>> >>>>> On 08/25/2015 04:14 AM, Xuelei Fan wrote: >>>>>> OCSPNonceExtension.java >>>>>> ======================= >>>>>> - nonceData = (byte[])obj; >>>>>> + nonceData = ((byte[])obj).clone(); >>>>>> >>>>>> Do you want to check null obj? >>>>>> >>>>>> - return nonceData; >>>>>> + return (nonceData != null ? nonceData.clone() : null); >>>>>> >>>>>> I think you may want to enclose the "!=" operator as: >>>>>> >>>>>> + return (nonceData != null) ? nonceData.clone() : null; >>>>>> >>>>>> >>>>>> Xuelei >>>>>> >>>>>> On 8/25/2015 12:55 PM, Jamil Nimeh wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> This is a quick fix to the OCSPNonceExtension class to add a couple >>>>>>> defensive copies to public get/set methods. >>>>>>> >>>>>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8134364 >>>>>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8134364/webrev.00 >>>>>>> >>>>>>> Thanks, >>>>>>> --Jamil >>>>>> >>>> >>> > From anthony.scarpino at oracle.com Fri Sep 4 15:20:25 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 4 Sep 2015 10:20:25 -0500 Subject: [9] RFR: 8130875 Out of memory when using TLS_RSA_WITH_AES_128_GCM_SHA256 In-Reply-To: <55E8BACD.5070107@oracle.com> References: <55E75FEE.6020702@oracle.com> <15D5756C-8FA7-47F1-8D69-348C1413D413@oracle.com> <07219F74-9237-45AA-A5C3-8BFA8A34F13B@oracle.com> <55E8BACD.5070107@oracle.com> Message-ID: <69C8AC7E-157F-4F9B-878A-8A08E8E71835@oracle.com> Ok. The changes looks good. Thanks for looking into it and changing the bug synopsis. Tony > On Sep 3, 2015, at 4:25 PM, Valerie Peng wrote: > > > For all the JavaCritical calls, it's impossible to have the combination of (bufOut==NULL && outLen!=0) as the outLen value is generated by VM based on bufOut. Anyway, just to play it safe, I added a line to set outLen to 0 just to match what is done for line 657. > > http://cr.openjdk.java.net/~valeriep/8130875/webrev.01/ > > Thanks, > Valerie > > On 9/3/2015 7:20 AM, Anthony Scarpino wrote: >>> On Sep 2, 2015, at 10:50 PM, Anthony Scarpino wrote: >>> >>> >>>> On Sep 2, 2015, at 3:45 PM, Valerie Peng wrote: >>>> >>>> >>>> Can someone help review this java workaround for Solaris memory leak bug in Ucrypto library? >>>> Essentially, the memory leak occurs when a null output buffer is specified when doing encryption/decryption. >>>> So, the workaround in OracleUcrypto provider is to use non-null output buffers. >>>> >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8130875/webrev.00/ >>>> >>>> The fix is verified by running a program for a while and observe the memory usage. >>>> Valerie >>> >>> Not related to the code, I think the bug synopsis should be more specific to the issue. It looks too eye-catching by saying java runs out of memory with that cipher suite, when it?s the OS library not cleaning up correctly for a particular provider when using AES GCM only. I would not be surprised if a future issue got incorrectly linked because the synopsis was too generic. Maybe something like ?OracleUcrypto workaround for AES GCM with a null bufOut pointer during doFinal()" >>> >>> As for the code, I?m a bit unsure about using outLen?s reference as the bufOut pointer. However, after seeing there are checks to make sure outLen is zero and it?s documented well that this is a workaround, I?m ok with this. >>> >>> Tony >> Thanks to Jamil for asking me about the webrev privately, I discounted a concern because I misread the webrev. >> >> So the comments are purely from the JNI code checks. Maybe there are checks in the java code that prevent the below situations, but it?s still uneasy having no protection in the JNI code >> >> The change around 438, does not make sure outLen is zero, so if bufOut points to the reference of outLen, it could start overwriting data or even somewhere else with the offset also being unchecked. The check should fail if outLen is not zero. Before the change, having bufOut being null we could depend on the OS library to check, now giving it a false pointer, we should do more checking. >> >> Tony >> From sean.mullan at oracle.com Fri Sep 4 15:51:05 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 4 Sep 2015 11:51:05 -0400 Subject: RFR: JDK-8015388 : Required algorithms for JDK 9 Message-ID: <55E9BDE9.7080401@oracle.com> The JDK includes a list of required security algorithms that all implementations must support: http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#impl This list is reviewed before each major release to check if new algorithms should be added (or existing algorithms removed). For JDK 9, we are proposing to add several new algorithms and keysizes that are recommended by standards bodies for cryptographic operations and security protocols. Adding these as requirements ensures that Java applications can depend on them to be available on all Java 9 implementations. The new requirements are: 1. Signature: SHA256withDSA 2. KeyPairGenerator: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. AlgorithmParameterGenerator: DSA (2048), DiffieHellman (2048, 4096) 4. Cipher: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. SSLContext: TLSv1.1, TLSv1.2 webrev: http://cr.openjdk.java.net/~mullan/webrevs/8015388/webrev.00/ Thanks, Sean From sean.mullan at oracle.com Fri Sep 4 16:07:35 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 4 Sep 2015 12:07:35 -0400 Subject: [9] RFR: 8134708: Certpath validation fails to load certs and CRLs if AIA and CRLDP extensions point to LDAP resources In-Reply-To: <55E6317A.7080401@oracle.com> References: <55E6317A.7080401@oracle.com> Message-ID: <55E9C1C7.2050708@oracle.com> Looks good to me. --Sean On 09/01/2015 07:15 PM, Artem Smotrakov wrote: > Hello, > > Please review this fix for 9. > > Certpath validation fails to load certs and CRLs if AIA and CRLDP > extensions point to LDAP resources. This happens because LDAPCertStore > accepts only instances of LDAPCertStoreParameters and > URICertStoreParameters classes, but > sun.security.provider.certpath.URICertStore uses an inner static > URICertStoreParameters class. Please see details in the bug. > > This fix removes URICertStore.URICertStoreParameters class, and updates > URICertStore and DistributionPointFetcher to use new > java.security.cert.URICertStoreParameters class. > > A regression test starts a local name service which logs requested host > names. The test checks that host names from AIA and CRLDP extensions > were loaded and requested to resolve during certpath validation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8134708 > Webrev: http://cr.openjdk.java.net/~asmotrak/8134708/webrev.01/ > > Artem From sean.mullan at oracle.com Fri Sep 4 16:08:18 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 4 Sep 2015 12:08:18 -0400 Subject: [9] RFR: 8134708: Certpath validation fails to load certs and CRLs if AIA and CRLDP extensions point to LDAP resources In-Reply-To: <55E6CE32.6040604@oracle.com> References: <55E6317A.7080401@oracle.com> <55E6CE32.6040604@oracle.com> Message-ID: <55E9C1F2.8000900@oracle.com> On 09/02/2015 06:23 AM, Se?n Coffey wrote: > if (!u.getScheme().equalsIgnoreCase("ldap")) { > throw new InvalidAlgorithmParameterException( > "Only LDAP URIs are supported for LDAP Certore"); > > Let's print the scheme received! And fix the typo: s/Certore/CertStore/ --Sean From valerie.peng at oracle.com Fri Sep 4 19:23:20 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 04 Sep 2015 12:23:20 -0700 Subject: [9] RFR: 8130875 Out of memory when using TLS_RSA_WITH_AES_128_GCM_SHA256 In-Reply-To: <69C8AC7E-157F-4F9B-878A-8A08E8E71835@oracle.com> References: <55E75FEE.6020702@oracle.com> <15D5756C-8FA7-47F1-8D69-348C1413D413@oracle.com> <07219F74-9237-45AA-A5C3-8BFA8A34F13B@oracle.com> <55E8BACD.5070107@oracle.com> <69C8AC7E-157F-4F9B-878A-8A08E8E71835@oracle.com> Message-ID: <55E9EFA8.6070202@oracle.com> Thanks for the review~ Valerie On 9/4/2015 8:20 AM, Anthony Scarpino wrote: > Ok. The changes looks good. Thanks for looking into it and changing the bug synopsis. > > Tony > >> On Sep 3, 2015, at 4:25 PM, Valerie Peng wrote: >> >> >> For all the JavaCritical calls, it's impossible to have the combination of (bufOut==NULL&& outLen!=0) as the outLen value is generated by VM based on bufOut. Anyway, just to play it safe, I added a line to set outLen to 0 just to match what is done for line 657. >> >> http://cr.openjdk.java.net/~valeriep/8130875/webrev.01/ >> >> Thanks, >> Valerie >> >> On 9/3/2015 7:20 AM, Anthony Scarpino wrote: >>>> On Sep 2, 2015, at 10:50 PM, Anthony Scarpino wrote: >>>> >>>> >>>>> On Sep 2, 2015, at 3:45 PM, Valerie Peng wrote: >>>>> >>>>> >>>>> Can someone help review this java workaround for Solaris memory leak bug in Ucrypto library? >>>>> Essentially, the memory leak occurs when a null output buffer is specified when doing encryption/decryption. >>>>> So, the workaround in OracleUcrypto provider is to use non-null output buffers. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8130875/webrev.00/ >>>>> >>>>> The fix is verified by running a program for a while and observe the memory usage. >>>>> Valerie >>>> Not related to the code, I think the bug synopsis should be more specific to the issue. It looks too eye-catching by saying java runs out of memory with that cipher suite, when it?s the OS library not cleaning up correctly for a particular provider when using AES GCM only. I would not be surprised if a future issue got incorrectly linked because the synopsis was too generic. Maybe something like ?OracleUcrypto workaround for AES GCM with a null bufOut pointer during doFinal()" >>>> >>>> As for the code, I?m a bit unsure about using outLen?s reference as the bufOut pointer. However, after seeing there are checks to make sure outLen is zero and it?s documented well that this is a workaround, I?m ok with this. >>>> >>>> Tony >>> Thanks to Jamil for asking me about the webrev privately, I discounted a concern because I misread the webrev. >>> >>> So the comments are purely from the JNI code checks. Maybe there are checks in the java code that prevent the below situations, but it?s still uneasy having no protection in the JNI code >>> >>> The change around 438, does not make sure outLen is zero, so if bufOut points to the reference of outLen, it could start overwriting data or even somewhere else with the offset also being unchecked. The check should fail if outLen is not zero. Before the change, having bufOut being null we could depend on the OS library to check, now giving it a false pointer, we should do more checking. >>> >>> Tony >>> From rajan.halade at oracle.com Fri Sep 4 20:43:56 2015 From: rajan.halade at oracle.com (Rajan Halade) Date: Fri, 4 Sep 2015 13:43:56 -0700 Subject: [9] RFR: 8048356: SecureRandom default provider tests Message-ID: <55EA028C.9030607@oracle.com> Please help with your review of this new test to check default provider used with SecureRandom. Bug: https://bugs.openjdk.java.net/browse/JDK-8048356 Webrev: http://cr.openjdk.java.net/~rhalade/8048356/webrev.00/ Thanks, Rajan From xuelei.fan at oracle.com Sat Sep 5 00:32:10 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 5 Sep 2015 08:32:10 +0800 Subject: RFR: JDK-8015388 : Required algorithms for JDK 9 In-Reply-To: <55E9BDE9.7080401@oracle.com> References: <55E9BDE9.7080401@oracle.com> Message-ID: <55EA380A.4060100@oracle.com> Looks fine to me. Xuelei On 9/4/2015 11:51 PM, Sean Mullan wrote: > The JDK includes a list of required security algorithms that all > implementations must support: > http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#impl > > > This list is reviewed before each major release to check if new > algorithms should be added (or existing algorithms removed). > > For JDK 9, we are proposing to add several new algorithms and keysizes > that are recommended by standards bodies for cryptographic operations > and security protocols. Adding these as requirements ensures that Java > applications can depend on them to be available on all Java 9 > implementations. The new requirements are: > > 1. Signature: SHA256withDSA > 2. KeyPairGenerator: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) > 3. AlgorithmParameterGenerator: DSA (2048), DiffieHellman (2048, 4096) > 4. Cipher: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) > 5. SSLContext: TLSv1.1, TLSv1.2 > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8015388/webrev.00/ > > Thanks, > Sean From bradford.wetmore at oracle.com Mon Sep 7 03:54:18 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Sun, 6 Sep 2015 20:54:18 -0700 Subject: TLS ALPN Proposal v4 Message-ID: <55ED0A6A.3050806@oracle.com> Hi all, Simone/Xuelei/I wrote: >>>> Per my understanding, application protocol should be negotiated before >>>> >>>cipher suite and protocol version negotiated. >>> >> >>> >>This is not possible for HTTP/2. >>> >>Application protocol negotiation MUST happen*after* the TLS protocol >>> >>and the TLS cipher are negotiated. >> > >> >Yes, that's my understanding as well. > What are the behaviors of other vendors? Can we ask for a clarification > from both HTTP/2 and TLS WG? and then Simone wrote: > I support Xuelei in that you should ask confirmation to the HTTP/2 > editor. Thanks for the encouragement, Simone. As you've probably heard, I did contact the IETF HTTP/2 working group and posed several questions about expected usage[1]. I'm combining those responses plus several other points that came up since the last discussion. This may be repeating some things already said, but serves as useful background info for those here that might not be following closely: 1. HTTP/2 (aka H2) and TLSv1.3 were developed in parallel. The H2 designers wanted the ciphersuite restrictions in the proposed TLSv1.3. But since TLSv1.3 wasn't ready, they compromised by allowing TLSv1.2 to be used but with the restriction that only those ciphersuites that were expected/allowed for TLSv1.3 could be used. That is, there is a blacklist of ciphersuites for TLSv1.2: if a suite is present, it can't be used in TLSv1.2. (e.g. no RSA KeyExchange, no CBC-based block ciphers, no stream ciphers, etc.) 2. RFC 7301 says in a couple places that it would be advantageous to have the chosen ALPN value used by the certificate selection mechanism (See sections 1 & 4). Without a radical rewrite of the current selection mechanism (n-tuple), that means ALPN selection should be done before the ciphersuite is selected. We could also check after, but I have a different approach (see below). 3. From the H2 working group discussion, a server instance will very likely support both H2 and legacy HTTP/1.1. This means for servers that prefer H2, any iterative cipher selection mechanisms needs to try the H2-specific ciphersuites first, then legacy non-H2 suites. That is, the suites must be ordered appropriately so that the ciphersuite selection mechanism won't attempt a blacklisted suite before exhausting all H2-acceptable suites. This ordering can be requested today in JSSE by the server calling sslParameters.setUseCipherSuitesOrder(true). This particular point won't matter when TLSv1.3 is in play, as we wouldn't try those suites at all. 4. Clients may not know whether a server will be H2 or HTTP/1.1, so they should also appropriately sort ciphersuites based on their ALPN preferences. (H2 first, H1 second.) 5. For our SunJSSE, while I think our current enabled list order is generally ok, we should probably reorder the ciphersuite priorities so that the TLSv1.3 acceptable suites are up front, with the others following. This prefers forward secrecy ciphersuites to our current ordering. I am thinking we should probably do this for JDK 9, and maybe backport as well. The current webrev (link below) doesn't have this yet. 6. To avoid downgrade attacks, applications should not provide for a fallback mechanism. This includes ALPN selection. Connection#1: {"h2", "http/1.1"} // Don't make two connections. Connection#2: {"http/1.1"} POODLE was a good example where allowing fallbacks bit hard. Of course, we can't control this at the JSSE layer, it's the application layer responsibility. > Tradeoff between A) change radically the OpenJDK implementation to > support an iterative processing of TLS protocols, extensions (all of > them), ciphers, aliases, etc. that would be future proof (if that is > even possible) and B) hack in just enough of what is needed to support > H2 today (for which we already have working examples) ? Given where we are now schedule wise (integration currently due at the end of September), and that SunJSSE is such an iterative implementation, coming up with a multi-selector API is likely beyond what we can do at this point. (webrev link below). IMHO, the following works well. I've added a new method that contains the ordered list of ciphersuites still to be tried which is a hint for ALPN selection, but we delay the actual ciphersuite selection until after the ALPN value is chosen. So the algorithm is now: 0. Applications (especially server) might order suites with h2 first for TLSv1.2. sslParameters.setUseCipherSuitesOrder(true) should be called on the server to ensure those suites are tried first. 1. Start Handshake. 2. Internal server handshaker chooses the TLS version. 3. The internal server handshaker finds the client/server/protocol version intersection of the suites, loads the initial ordered list into a new method on a SSLSession (obtained by the getHandshakeSSLSession()), then iterates through the ordered list of ciphersuites as usual. 4. For each "candidate" ciphersuite, first call the ApplicationProtocolSelector to choose an appropriate ALPN value. The getHandshakeSSLSession() contains the negotiated TLS protocol version and the ordered ciphersuite list with the "candidate" suite as the first entry. Note: If the client sent unsupported ALPN values, the Selector can throw a SSLHandshakeException at this point and generate the "no_application_protocol" alert. The Selector can also either choose to ignore/skip the suite, or accept the suite but choose no ALPN value. 5. Continue the ciphersuite selection routine as usual (check for appropriate Keys, etc). The KeyManager now has access to the negotiated TLS version and ALPN value along with the ciphersuite via the same/usual getHandshakeSSLSession(). This satisfies the RFC 7301 goal of having the certificate selection mechanism use the ALPN value. As ciphersuites are removed from consideration via the internal iterator in 3, they are also removed from the corresponding SSLSession entry. 6. When handshaking is complete, the applications should verify that the session parameters (protocol version, ALPN value, and ciphersuites, etc.) are suitable, and send a HTTP-level INADEQUATE_SECURITY (H2) if there's a problem. In general, if the ciphersuites aren't ordered properly, that should be considered a configuration error on the part of the application(s). However, this dynamic ALPN selection approach still allows for appropriate ALPN values to be selected for each possible ciphersuite. That is, if the suites were ordered H1/H2, the ALPN value should be H1. For an example of such a selector, please see the new H2/H2+H1/H1 ApplicationProtocolSelector implementions in ApplicationProtocolSelector.java, and how they are called in ServerHandshaker.java. Here is the latest: http://cr.openjdk.java.net/~wetmore/8051498/webrev.09 The main changes from the previous webrev: ApplicationProtocolSelector.java ================================ 1. Added default implementations for H2, H2+H1, H1 so that people don't have to write their own. This makes things much more convenient. If folks want to insert their own SPDY implementations (H2/SPDY*/H1), they can use the these implementation as a wrapper class to their own code: public class MySpdyALPN implements ApplicationProtocolSelector { ApplicationProtocolSelector aps; MySpdyALPN(ApplicationProtocolSelector aps) { this.aps = aps; } public String select() { String retval = aps.select(); if (retval.equals("h2")) { return retval; } if (someSPDY3Conditions()) { return "spdy/3"; } if (someSPDY2Conditions()) { return "spdy/2"; } return retval; } } 2. Added a public List of the RFC 7540 Blacklisted ciphersuites. For historical reasons, the Standard Names prefixes for JSSE ciphersuites are a mix of "SSL_" and "TLS_", so everyone who wants to implement a blacklist would have to get these values right. I've added this both for my default implementations and for developer convenience. 3. Added some examples in the class descriptor. ExtendedSSLSession.java ======================= public String[] getHandshakeCipherSuiteList() 1. This returns an ordered dynamic list of ciphersuites still under consideration for this handshake. As ciphersuites are removed from consideration, successive calls will return smaller arrays. 2. ApplicationSelector now distinguishes between null and empty String return values: * @return a non-empty protocol {@code String} to send to the client, * an empty string if no protocol indication (i.e. extension) * should be sent, or null if the current most-preferred ciphersuite * should be skipped. That is, if the return value is null, we skip this suite from consideration and go to the next one. This is useful if only H2 is being considered, and we find out that a suite is on the blacklist. There is no reason to consider it further. SSLParameters.java ======================= Added an examples in the class description. As far as backporting goes, this API is not particularly friendly in that it requires a ApplicationProtocolSelector. We could add a private API, or use a system property and provide a default selector that looks at the property and takes the most preferred one. Vinnie is reworking his original ALPN code to use the new API, so we should be in pretty good shape for integration at the end of Sept. Thanks, Brad [1] https://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/0154.html From sbordet at webtide.com Mon Sep 7 14:18:06 2015 From: sbordet at webtide.com (Simone Bordet) Date: Mon, 7 Sep 2015 16:18:06 +0200 Subject: TLS ALPN Proposal v4 In-Reply-To: <55ED0A6A.3050806@oracle.com> References: <55ED0A6A.3050806@oracle.com> Message-ID: Hi, On Mon, Sep 7, 2015 at 5:54 AM, Bradford Wetmore wrote: > IMHO, the following works well. I've added a new method that contains the > ordered list of ciphersuites still to be tried which is a hint for ALPNinboked > selection, but we delay the actual ciphersuite selection until after the > ALPN value is chosen. So the algorithm is now: > > 0. Applications (especially server) might order suites with h2 > first for TLSv1.2. sslParameters.setUseCipherSuitesOrder(true) > should be called on the server to ensure those suites are > tried first. > > 1. Start Handshake. > > 2. Internal server handshaker chooses the TLS version. > > 3. The internal server handshaker finds the client/server/protocol > version intersection of the suites, loads the initial ordered > list into a new method on a SSLSession (obtained by the > getHandshakeSSLSession()), then iterates through the > ordered list of ciphersuites as usual. > > 4. For each "candidate" ciphersuite, first call the > ApplicationProtocolSelector to choose an appropriate ALPN value. > The getHandshakeSSLSession() contains the negotiated TLS > protocol version and the ordered ciphersuite list with the > "candidate" suite as the first entry. > > Note: If the client sent unsupported ALPN values, the Selector > can throw a SSLHandshakeException at this point and generate the > "no_application_protocol" alert. >inboked > The Selector can also either choose to ignore/skip the suite, or > accept the suite but choose no ALPN value. > > 5. Continue the ciphersuite selection routine as usual (check for > appropriate Keys, etc). The KeyManager now has access to the > negotiated TLS version and ALPN value along with theit > ciphersuite via the same/usual > getHandshakeSSLSession(). > This satisfies the RFC 7301 goal of having > the certificate selection mechanism use the ALPN value. > > As ciphersuites are removed from consideration via the > internal iterator in 3, they are also removed from the > corresponding SSLSession entry. > > 6. When handshaking is complete, the applications should verify > that the session parameters (protocol version, ALPN value, and > ciphersuites, etc.) are suitable, and send a HTTP-level > INADEQUATE_SECURITY (H2) if there's a problem. > > In general, if the ciphersuites aren't ordered properly, that should be > considered a configuration error on the part of the application(s). However, > this dynamic ALPN selection approach still allows for appropriate ALPN > values to be selected for each possible ciphersuite. That is, if the suites > were ordered H1/H2, the ALPN value should be H1. > > For an example of such a selector, please see the new H2/H2+H1/H1 > ApplicationProtocolSelector implementions in > ApplicationProtocolSelector.java, and how they are called in > ServerHandshaker.java. > > > Here is the latest: > > http://cr.openjdk.java.net/~wetmore/8051498/webrev.09 Are you sure this is the latest code ? The relevant changes in ServerHandshaker are commented out. I have the feeling that ApplicationProtocolSelector (APS) is not really an application protocol selector, but a cipher suite selector. APS seem to conflate cipher suite selection with application protocol selection: the return value of select() actually is a 2-tuple that means (ciphers[0], protocol) so that returning the empty string or null does not have any effect on protocol selection, but only on cipher selection. You can for example implement APS without even looking at the application protocol, just to exclude dynamically certain ciphers from selection (e.g. based on performance or remote IP). I don't understand exactly bullet 5 above. If APS chooses a cipher and a protocol, but this is not a valid combination for the KeyManager to select a certificate, what happens ? That APS is called again, right ? But what if that was the last cipher ? Then APS won't be called again. How can an application know that it is done trying to select a protocol and that the protocol it chose is actually used ? I guess this also brings to bullet 6: how can an application verify that the N-tuple chosen is actually a correct one ? Is there an additional callback that is being invoked (that applications can implement) before the ServerHello is actually sent to the client ? A very important point that I saw in the comments is support for TLS session resumption - this has been asked multiple times by Jetty users that were using Jetty's ALPN (and we implemented it). Just make sure that whatever proposal enters JDK 9, session resumption is supported. My preference would go to the previous proposal (akin to Jetty - I know I am biased) where protocol selection was happening in isolation *after* cipher selection. It is much simpler, and has the only drawback of not allowing certificate selection based on application protocol (for which we never had request from the community). This proposal seems less clear to me, a bit of compromise between a full fledged multi-selector API (it is in fact a 2-selector API for cipher and application protocol) and the previous proposal (that was a select-after-the-cipher selector API). If the times are tight, I would go for the simpler approach and leave the full fledged multi-selector API for JDK 10. Thanks ! -- Simone Bordet ---- http://cometd.org http://webtide.com Developer advice, training, services and support from the Jetty & CometD experts. From weijun.wang at oracle.com Tue Sep 8 06:15:53 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 8 Sep 2015 14:15:53 +0800 Subject: Question about X509Certificate SAN DNS Name In-Reply-To: <201509080453.t884rmI4029039@d23av06.au.ibm.com> References: <201509080453.t884rmI4029039@d23av06.au.ibm.com> Message-ID: <55EE7D19.6020506@oracle.com> Hi Sean You closed 8016345 as a dup of 8007706, but it's about the 1st letter in a DNSName and 8007706 is about '_' inside. Should they be treated differently? Thanks Max On 09/08/2015 12:52 PM, kepi at sg.ibm.com wrote: > I have a question on one of the bug > described at > https://bugs.openjdk.java.net/browse/JDK-8016345 > > The status of this bug is closed as it duplicates > https://bugs.openjdk.java.net/browse/JDK-8007706. In bug _JDK-8007706_ > you were claiming that your > implementation conforms to RFCs 5280, 1034, and 1123. > > But after carefully reading the RFCs, I think the bug reported in JDK-8016345 > should be fixed. > > From RFC 5280 Section 4.2.1.6, below block says: > > When the subjectAltName extension contains a domain name system > label, the domain name MUST be stored in the dNSName (an IA5String). > The name MUST be in the "preferred name syntax", as specified by > Section 3.5 of [RFC1034] and as modified by Section 2.1 of > [RFC1123]. > > In RFC1034, it says the name should begin with a letter. However, in RFC1123 > Section 2.1, the syntax is relaxed and it says the first character can be either > a letter or digit. > > From RFC1123 Section 2.1 > The syntax of a legal Internet host name was specified in _RFC-952_ > > [DNS:4]. One aspect of host name syntax is hereby changed: the > restriction on the first character is relaxed to allow either a > letter or a digit. From sean.coffey at oracle.com Tue Sep 8 08:00:21 2015 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 8 Sep 2015 09:00:21 +0100 Subject: RFR : 8133535: Better exception messaging in Ucrypto code In-Reply-To: <55DB1401.70207@oracle.com> References: <55DB1401.70207@oracle.com> Message-ID: <55EE9595.6010102@oracle.com> With recent changes from (JDK-8132082) affecting the same ucrypto code, I've re-based my patch. Here's the new webrev : http://cr.openjdk.java.net/~coffeys/webrev.8133535.jdk9.v2/webrev/ Regards, Sean. On 24/08/2015 13:54, Se?n Coffey wrote: > Hoping to improve some of the exception messaging that is thrown from > Ucrypto code. I'm hoping to tackle other components in the security > libraries on a case by case basis. Aim is to improve exception > messages and capture detail for end user where possible. > > bug report : https://bugs.openjdk.java.net/browse/JDK-8133535 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8133535.jdk9/webrev/ > From ivan.gerasimov at oracle.com Tue Sep 8 09:42:18 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 8 Sep 2015 12:42:18 +0300 Subject: RFR : 8133535: Better exception messaging in Ucrypto code In-Reply-To: <55EE9595.6010102@oracle.com> References: <55DB1401.70207@oracle.com> <55EE9595.6010102@oracle.com> Message-ID: <55EEAD7A.2020007@oracle.com> Thanks, Se?n! On 08.09.2015 11:00, Se?n Coffey wrote: > With recent changes from (JDK-8132082) affecting the same ucrypto > code, I've re-based my patch. Here's the new webrev : > > http://cr.openjdk.java.net/~coffeys/webrev.8133535.jdk9.v2/webrev/ > This looks very useful. NativeCipher.java: 283 ("Wrong IV length: must be " + blockSize + 284 " bytes long"); Would it make sense to include the actual length of the vector? In a couple of places (e.g. NativeKey.java, line #146) the indentation isn't consistent. Otherwise looks good to me! Sincerely yours, Ivan > Regards, > Sean. > > On 24/08/2015 13:54, Se?n Coffey wrote: >> Hoping to improve some of the exception messaging that is thrown from >> Ucrypto code. I'm hoping to tackle other components in the security >> libraries on a case by case basis. Aim is to improve exception >> messages and capture detail for end user where possible. >> >> bug report : https://bugs.openjdk.java.net/browse/JDK-8133535 >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8133535.jdk9/webrev/ >> > > From sean.coffey at oracle.com Tue Sep 8 09:48:19 2015 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 8 Sep 2015 10:48:19 +0100 Subject: RFR : 8133535: Better exception messaging in Ucrypto code In-Reply-To: <55EEAD7A.2020007@oracle.com> References: <55DB1401.70207@oracle.com> <55EE9595.6010102@oracle.com> <55EEAD7A.2020007@oracle.com> Message-ID: <55EEAEE3.6020106@oracle.com> On 08/09/2015 10:42, Ivan Gerasimov wrote: > Thanks, Se?n! > > On 08.09.2015 11:00, Se?n Coffey wrote: >> With recent changes from (JDK-8132082) affecting the same ucrypto >> code, I've re-based my patch. Here's the new webrev : >> >> http://cr.openjdk.java.net/~coffeys/webrev.8133535.jdk9.v2/webrev/ >> > This looks very useful. > > NativeCipher.java: > 283 ("Wrong IV length: must be " + > blockSize + > 284 " bytes long"); > Would it make sense to include the actual length of the vector? Yes - good catch Ivan. Will include that value. > > In a couple of places (e.g. NativeKey.java, line #146) the indentation > isn't consistent. Good point, I'll run through indentation again before final push. Thanks, Sean. > > Otherwise looks good to me! > > Sincerely yours, > Ivan > >> Regards, >> Sean. >> >> On 24/08/2015 13:54, Se?n Coffey wrote: >>> Hoping to improve some of the exception messaging that is thrown >>> from Ucrypto code. I'm hoping to tackle other components in the >>> security libraries on a case by case basis. Aim is to improve >>> exception messages and capture detail for end user where possible. >>> >>> bug report : https://bugs.openjdk.java.net/browse/JDK-8133535 >>> webrev : >>> http://cr.openjdk.java.net/~coffeys/webrev.8133535.jdk9/webrev/ >>> >> >> > From sean.mullan at oracle.com Tue Sep 8 12:32:07 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 8 Sep 2015 08:32:07 -0400 Subject: Question about X509Certificate SAN DNS Name In-Reply-To: <55EE7D19.6020506@oracle.com> References: <201509080453.t884rmI4029039@d23av06.au.ibm.com> <55EE7D19.6020506@oracle.com> Message-ID: <55EED547.3000506@oracle.com> On 09/08/2015 02:15 AM, Weijun Wang wrote: > Hi Sean > > You closed 8016345 as a dup of 8007706, but it's about the 1st letter in > a DNSName and 8007706 is about '_' inside. Should they be treated > differently? Yes, probably. Please re-open the bug. --Sean > > Thanks > Max > > On 09/08/2015 12:52 PM, kepi at sg.ibm.com wrote: >> I have a question on one of the bug >> described at >> https://bugs.openjdk.java.net/browse/JDK-8016345 >> >> The status of this bug is closed as it duplicates >> https://bugs.openjdk.java.net/browse/JDK-8007706. In bug _JDK-8007706_ >> you were claiming >> that your >> implementation conforms to RFCs 5280, 1034, and 1123. >> >> But after carefully reading the RFCs, I think the bug reported in >> JDK-8016345 >> should be fixed. >> >> From RFC 5280 Section 4.2.1.6, below block says: >> >> When the subjectAltName extension contains a domain name system >> label, the domain name MUST be stored in the dNSName (an IA5String). >> The name MUST be in the "preferred name syntax", as specified by >> Section 3.5 of [RFC1034] and as modified by Section 2.1 of >> [RFC1123]. >> >> In RFC1034, it says the name should begin with a letter. However, in >> RFC1123 >> Section 2.1, the syntax is relaxed and it says the first character can >> be either >> a letter or digit. >> >> From RFC1123 Section 2.1 >> The syntax of a legal Internet host name was specified in >> _RFC-952_ >> >> [DNS:4]. One aspect of host name syntax is hereby changed: the >> restriction on the first character is relaxed to allow either a >> letter or a digit. From weijun.wang at oracle.com Tue Sep 8 13:16:57 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 8 Sep 2015 21:16:57 +0800 Subject: Question about X509Certificate SAN DNS Name In-Reply-To: <55EED547.3000506@oracle.com> References: <201509080453.t884rmI4029039@d23av06.au.ibm.com> <55EE7D19.6020506@oracle.com> <55EED547.3000506@oracle.com> Message-ID: <55EEDFC9.6040802@oracle.com> On 09/08/2015 08:32 PM, Sean Mullan wrote: > On 09/08/2015 02:15 AM, Weijun Wang wrote: >> Hi Sean >> >> You closed 8016345 as a dup of 8007706, but it's about the 1st letter in >> a DNSName and 8007706 is about '_' inside. Should they be treated >> differently? > > Yes, probably. Please re-open the bug. Done. --Max From artem.smotrakov at oracle.com Tue Sep 8 17:00:03 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 8 Sep 2015 20:00:03 +0300 Subject: [9] RFR: 8134708: Certpath validation fails to load certs and CRLs if AIA and CRLDP extensions point to LDAP resources In-Reply-To: <55E6CE32.6040604@oracle.com> References: <55E6317A.7080401@oracle.com> <55E6CE32.6040604@oracle.com> Message-ID: <55EF1413.7050804@oracle.com> Hi Sean, I updated LDAPCertStore, please take a look http://cr.openjdk.java.net/~asmotrak/8134708/webrev.02/ - updated exception messages - fixed typos - added @Override annotations - removed unused field - removed unused imports Artem On 09/02/2015 01:23 PM, Se?n Coffey wrote: > Hi Artem, > > I'll let the main review to other reviewers but while we're here, can > you consider improving the original exception message that was seen in > this issue ? > In LDAPCertStore constructor : > > } else { > throw new InvalidAlgorithmParameterException( > "parameters must be either LDAPCertStoreParameters or " + > "URICertStoreParameters"); > } > > Can we print the instance type of the 'params' variable in the > exception message ? params.getClass().getName() should be sufficient. > > I see 2-3 other exceptions in LDAPCertStore that could be improved > there also. If you can change them, that would be great - otherwise > we can follow up with enhancement request. > > if (!u.getScheme().equalsIgnoreCase("ldap")) { > throw new InvalidAlgorithmParameterException( > "Only LDAP URIs are supported for LDAP Certore"); > > Let's print the scheme received! > > > } else if (!(selector instanceof X509CertSelector)) { > throw new CertStoreException("need X509CertSelector to > find certs"); > > this code occurs twice. Let's print the selector class received. > > Regards, > Sean. > On 02/09/15 00:15, Artem Smotrakov wrote: >> Hello, >> >> Please review this fix for 9. >> >> Certpath validation fails to load certs and CRLs if AIA and CRLDP >> extensions point to LDAP resources. This happens because >> LDAPCertStore accepts only instances of LDAPCertStoreParameters and >> URICertStoreParameters classes, but >> sun.security.provider.certpath.URICertStore uses an inner static >> URICertStoreParameters class. Please see details in the bug. >> >> This fix removes URICertStore.URICertStoreParameters class, and >> updates URICertStore and DistributionPointFetcher to use new >> java.security.cert.URICertStoreParameters class. >> >> A regression test starts a local name service which logs requested >> host names. The test checks that host names from AIA and CRLDP >> extensions were loaded and requested to resolve during certpath >> validation. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8134708 >> Webrev: http://cr.openjdk.java.net/~asmotrak/8134708/webrev.01/ >> >> Artem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Tue Sep 8 19:42:58 2015 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 8 Sep 2015 20:42:58 +0100 Subject: [9] RFR: 8134708: Certpath validation fails to load certs and CRLs if AIA and CRLDP extensions point to LDAP resources In-Reply-To: <55EF1413.7050804@oracle.com> References: <55E6317A.7080401@oracle.com> <55E6CE32.6040604@oracle.com> <55EF1413.7050804@oracle.com> Message-ID: <55EF3A42.6030501@oracle.com> Looks good to me Artem. Thanks for modifying! Regards, Sean. On 08/09/2015 18:00, Artem Smotrakov wrote: > Hi Sean, > > I updated LDAPCertStore, please take a look > > http://cr.openjdk.java.net/~asmotrak/8134708/webrev.02/ > > - updated exception messages > - fixed typos > - added @Override annotations > - removed unused field > - removed unused imports > > Artem > > On 09/02/2015 01:23 PM, Se?n Coffey wrote: >> Hi Artem, >> >> I'll let the main review to other reviewers but while we're here, can >> you consider improving the original exception message that was seen >> in this issue ? >> In LDAPCertStore constructor : >> >> } else { >> throw new InvalidAlgorithmParameterException( >> "parameters must be either LDAPCertStoreParameters or " + >> "URICertStoreParameters"); >> } >> >> Can we print the instance type of the 'params' variable in the >> exception message ? params.getClass().getName() should be sufficient. >> >> I see 2-3 other exceptions in LDAPCertStore that could be improved >> there also. If you can change them, that would be great - otherwise >> we can follow up with enhancement request. >> >> if (!u.getScheme().equalsIgnoreCase("ldap")) { >> throw new InvalidAlgorithmParameterException( >> "Only LDAP URIs are supported for LDAP Certore"); >> >> Let's print the scheme received! >> >> >> } else if (!(selector instanceof X509CertSelector)) { >> throw new CertStoreException("need X509CertSelector to >> find certs"); >> >> this code occurs twice. Let's print the selector class received. >> >> Regards, >> Sean. >> On 02/09/15 00:15, Artem Smotrakov wrote: >>> Hello, >>> >>> Please review this fix for 9. >>> >>> Certpath validation fails to load certs and CRLs if AIA and CRLDP >>> extensions point to LDAP resources. This happens because >>> LDAPCertStore accepts only instances of LDAPCertStoreParameters and >>> URICertStoreParameters classes, but >>> sun.security.provider.certpath.URICertStore uses an inner static >>> URICertStoreParameters class. Please see details in the bug. >>> >>> This fix removes URICertStore.URICertStoreParameters class, and >>> updates URICertStore and DistributionPointFetcher to use new >>> java.security.cert.URICertStoreParameters class. >>> >>> A regression test starts a local name service which logs requested >>> host names. The test checks that host names from AIA and CRLDP >>> extensions were loaded and requested to resolve during certpath >>> validation. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8134708 >>> Webrev: http://cr.openjdk.java.net/~asmotrak/8134708/webrev.01/ >>> >>> Artem >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Tue Sep 8 20:33:28 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 08 Sep 2015 13:33:28 -0700 Subject: [9] Urgent RFR 8135099 "9-dev solaris builds failed on 2015-09-04" Message-ID: <55EF4618.2060906@oracle.com> Hi, I need someone to help reviewing for this bug ASAP: http://cr.openjdk.java.net/~valeriep/8135099/webrev.00/ The build is broken due to the compilation warning introduced in 8130875 which slipped through un-detected due to the "--disable-warnings-as-errors" setting in my local workspace. Thanks, Valerie From vincent.x.ryan at oracle.com Tue Sep 8 20:36:22 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 8 Sep 2015 21:36:22 +0100 Subject: [9] Urgent RFR 8135099 "9-dev solaris builds failed on 2015-09-04" In-Reply-To: <55EF4618.2060906@oracle.com> References: <55EF4618.2060906@oracle.com> Message-ID: <5B898D5A-E0B8-4F2C-A616-237EBD908FE2@oracle.com> Your fix looks fine to me. Thanks. > On 8 Sep 2015, at 21:33, Valerie Peng wrote: > > Hi, > > I need someone to help reviewing for this bug ASAP: > http://cr.openjdk.java.net/~valeriep/8135099/webrev.00/ > > The build is broken due to the compilation warning introduced in 8130875 which slipped through un-detected due to the "--disable-warnings-as-errors" setting in my local workspace. > > Thanks, > Valerie > From tristan.yan at oracle.com Tue Sep 8 21:44:15 2015 From: tristan.yan at oracle.com (Tristan Yan) Date: Tue, 8 Sep 2015 14:44:15 -0700 Subject: RFR 8044199: tests for RSA keys and key specifications In-Reply-To: <55E0CCBF.7070405@oracle.com> References: <55D600E9.4040003@oracle.com> <55E0CCBF.7070405@oracle.com> Message-ID: <4BB1B0D8-4785-4446-963A-30360356EBE3@oracle.com> Hi Valerie Thank you for reviewing this, I fixed 2 points in latest webrev. Do you mind sponsor this for me if you?re OK with this version. http://cr.openjdk.java.net/~tyan/8044199/webrev.03/ Cheers. Tristan > On Aug 28, 2015, at 2:03 PM, Valerie Peng > wrote: > > Hi Tristan, > > Mostly fine, just 2 more nits: > 1) KeySizeTest: the @test and @bug are still on the same line. > 2) SpecTest.java: the @run command from line 40 - 45 still have the old name, e.g. KeyModulusTest? I think u need to match them. > > Thanks, > Valerie > On 8/20/2015 9:31 AM, Tristan Yan wrote: >> >> Thanks Valerie >> >> Please review the fixed version. >> >> http://cr.openjdk.java.net/~tyan/8044199/webrev.02/ >> >> Tristan >> >> >> > Tristan, >> > >> > - Given that the tests are against SunRsaSign provider, I think >> > sun/security/rsa subdirectory is a better choice than java/security/rsa. >> > - Put @test and @bug on separate lines >> > - Elaborate more on what is tested and what is the expected result in >> > the bug record. The current content isn't very clear. >> > - Can u have more unique names for these tests? Currently, they are too >> > similarly named and it's somewhat confusing. The directory already >> > contains RSA, I don't feel that u need to have RSA again in the names of >> > the test especially when SunRsaSign provider doesn't support non-RSA >> > algorithms. >> > >> > For KeyTest.java >> > 1) typo on line 69, rsaPrivateKey2 should be rsaPrivateKey >> > 2) This test is based on the> >> provider specific behavior that CRT key is >> > generated by default for RSA. It'd be much clearer if you can add an >> > instanceof check on the generated RSA private key objects before the >> > KeyFactory + RSAPrivateKeySpec code. In addition, add additional code to >> > check for equality with the matching KeySpec (e.g. RSAPrivateCrtKeySpec >> > for RSAPrivateCrtKey) is used. >> > 3) line 58, add a space between '//" and text. >> > >> > For RSAKeySizeTest.java >> > 1) specify provider "SunRSASign" for all getInstance() calls. >> > 2) line 55 can be moved up to before the for-loop. >> > 3) instead of using toString(int), probably bitLength() would be a >> > better choice. >> > 4) sizeTest() doesn't really check size but rather it compares the >> > modulus values being equal. This check can be moved to RSAKeySizeTest.java. >> > >> > For RSATest.java >> > 1) specify provider "SunRSASign" for all getInstance() calls. >> > >> > Thanks, >> > Valerie >> > >> > On 8/3/2015 10:27 AM, Tristan Yan wrote: >> >> Hi >> >> >> >> Please review new tests for RSA keys and key specifications >> >> >> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8044199 >> >> Webrev:http://cr.openjdk.java.net/~tyan/8044199/webrev.01/ > >> >> >> >> >> Thanks >> >> Tristan >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Tue Sep 8 22:06:20 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 08 Sep 2015 15:06:20 -0700 Subject: RFR 8044199: tests for RSA keys and key specifications In-Reply-To: <4BB1B0D8-4785-4446-963A-30360356EBE3@oracle.com> References: <55D600E9.4040003@oracle.com> <55E0CCBF.7070405@oracle.com> <4BB1B0D8-4785-4446-963A-30360356EBE3@oracle.com> Message-ID: <55EF5BDC.10705@oracle.com> Sure, can u please send me the putback message/comment that u would like to use? And your OpenJDK user name if u have one. Thanks, Valerie On 9/8/2015 2:44 PM, Tristan Yan wrote: > Hi Valerie > > Thank you for reviewing this, I fixed 2 points in latest webrev. Do > you mind sponsor this for me if you?re OK with this version. > http://cr.openjdk.java.net/~tyan/8044199/webrev.03/ > > Cheers. > Tristan > >> On Aug 28, 2015, at 2:03 PM, Valerie Peng > > wrote: >> >> Hi Tristan, >> >> Mostly fine, just 2 more nits: >> 1) KeySizeTest: the @test and @bug are still on the same line. >> 2) SpecTest.java: the @run command from line 40 - 45 still have the >> old name, e.g. KeyModulusTest? I think u need to match them. >> >> Thanks, >> Valerie >> On 8/20/2015 9:31 AM, Tristan Yan wrote: >>> Thanks Valerie >>> >>> Please review the fixed version. >>> >>> http://cr.openjdk.java.net/~tyan/8044199/webrev.02/ >>> >>> Tristan >>> >>> >>> > Tristan, >>> > >>> > - Given that the tests are against SunRsaSign provider, I think >>> > sun/security/rsa subdirectory is a better choice than java/security/rsa. >>> > - Put @test and @bug on separate lines >>> > - Elaborate more on what is tested and what is the expected result in >>> > the bug record. The current content isn't very clear. >>> > - Can u have more unique names for these tests? Currently, they are too >>> > similarly named and it's somewhat confusing. The directory already >>> > contains RSA, I don't feel that u need to have RSA again in the names of >>> > the test especially when SunRsaSign provider doesn't support non-RSA >>> > algorithms. >>> > >>> > For KeyTest.java >>> > 1) typo on line 69, rsaPrivateKey2 should be rsaPrivateKey >>> > 2) This test is based on the> >>> provider specific behavior that CRT key is >>> > generated by default for RSA. It'd be much clearer if you can add an >>> > instanceof check on the generated RSA private key objects before the >>> > KeyFactory + RSAPrivateKeySpec code. In addition, add additional code to >>> > check for equality with the matching KeySpec (e.g. RSAPrivateCrtKeySpec >>> > for RSAPrivateCrtKey) is used. >>> > 3) line 58, add a space between '//" and text. >>> > >>> > For RSAKeySizeTest.java >>> > 1) specify provider "SunRSASign" for all getInstance() calls. >>> > 2) line 55 can be moved up to before the for-loop. >>> > 3) instead of using toString(int), probably bitLength() would be a >>> > better choice. >>> > 4) sizeTest() doesn't really check size but rather it compares the >>> > modulus values being equal. This check can be moved to RSAKeySizeTest.java. >>> > >>> > For RSATest.java >>> > 1) specify provider "SunRSASign" for all getInstance() calls. >>> > >>> > Thanks, >>> > Valerie >>> > >>> > On 8/3/2015 10:27 AM, Tristan Yan wrote: >>> >>/ Hi >>> />>/ >>> />>/ Please review new tests for RSA keys and key specifications >>> />>/ >>> />>/ Bug:https://bugs.openjdk.java.net/browse/JDK-8044199 >>> />>/ Webrev:http://cr.openjdk.java.net/~tyan/8044199/webrev.01/ > >>> />>/ >>> />>/ Thanks >>> />>/ Tristan >>> />> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mike.Gardiner at safenet-inc.com Tue Sep 8 20:48:36 2015 From: Mike.Gardiner at safenet-inc.com (Gardiner, Mike) Date: Tue, 8 Sep 2015 16:48:36 -0400 Subject: 8028192 Use of PKCS11-NSS provider in FIPS mode broken Message-ID: <39A385F269A9E349AA6606AD4E327D7605E992CDCB@BEL1EXCH02.amer.sfnt.local> Hello all, This recently came up with a customer of ours and I wanted to get some answers from the horse's mouth if I could. ;) I work for SafeNet (Now Gemalto) and we provide a JCA/JCE provider to use our Luna brand of HSMs. We recommend using our provider rather than the PKCS11 wrapper/provider as we take advantage of custom extension functions and take care to avoid usage which is not allowed in our modules (EG: no private/secret key may transit the FIPS boundary in the clear) We don't provide our own JSSE implementation and instead have historically relied on the Sun/IBM implementation to properly use the java provider list. There are always little gotchas that pop up but it's generally resolved through configuration changes. The changes to RSAClientKeyExchange in regards to requiring the RSA Cipher to support TlsRsaPremasterSecretParameterSpec have thrown us for a bit of a loop though. Given that we support multiple JVMs I really don't want to start handling parameter spec objects from the sun namespace. Especially when marked "@deprecated Sun JDK internal use only --- WILL BE REMOVED in a future release." ;) Is there any chance this parameter spec would be moved to be more official? Or to go back to the old behaviour if the RSA Cipher instance doesn't support it? (We throw an InvalidAlgorithmParameterException when given an unsupported parameter spec) Cheers, Mike -- The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Sep 10 08:48:21 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 10 Sep 2015 16:48:21 +0800 Subject: [9] RFR: 8075299: Additional tests for 6857795 In-Reply-To: <55C36437.6040605@oracle.com> References: <55C1ECEF.5000204@oracle.com> <55C22076.8090602@oracle.com> <55C36437.6040605@oracle.com> Message-ID: <50E1B5BF-04A8-4E08-BFA1-0A2DB97AEDF3@oracle.com> Everything is fine. Some answers inline: > On Aug 6, 2015, at 9:42 PM, Artem Smotrakov wrote: > > By the way, as far as I know, currently it is not possible to specify a port number in "java.security.krb5.kdc?. Yep. > > What do you think? I have thought about analyzing the strings and treat one as port if it?s only digits. For example, a:1:b:c means a:1, b and c. a:1:2 looks invalid but accept it for compatibility and treat it as a:1 and 2, at least if a:1 works 2 will not be touched. >> The conf file only contains realm and kdc and nothing else. If both conf file and system properties are provided, how do you prove the conf file is also read and not ignored? > The test doesn't check it. I see the following ways to check it: > - Corrupt krb5 conf, and run kinit with it. I suppose it should fail. > - Add some extra parameters to krb5, run kinit, and then try to use obtained data, and check that those extra parameters were used (I am not sure about details right now, need to do some experiments) > > What do you think? You can add forwardable=true and check if the output is indeed forwardable. In case it?s default true, try again with forwardable=false. :-) Thanks Max From artem.smotrakov at oracle.com Thu Sep 10 12:18:30 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 10 Sep 2015 15:18:30 +0300 Subject: [9] RFR: 8075299: Additional tests for 6857795 In-Reply-To: <50E1B5BF-04A8-4E08-BFA1-0A2DB97AEDF3@oracle.com> References: <55C1ECEF.5000204@oracle.com> <55C22076.8090602@oracle.com> <55C36437.6040605@oracle.com> <50E1B5BF-04A8-4E08-BFA1-0A2DB97AEDF3@oracle.com> Message-ID: <55F17516.7060607@oracle.com> Hi Max, It seems that kinit doesn't print any info about ticket flags [1] (I am not sure that it is a good idea to rely on -Dsun.security.krb5.debug=true here). But klist does. I updated the test to run klist which checks tickets for forwardable and proxiable flags. http://cr.openjdk.java.net/~asmotrak/8075299/webrev.02/ [1] http://docs.oracle.com/javase/8/docs/technotes/tools/windows/kinit.html Artem On 09/10/2015 11:48 AM, Wang Weijun wrote: > Everything is fine. Some answers inline: > >> On Aug 6, 2015, at 9:42 PM, Artem Smotrakov wrote: >> >> By the way, as far as I know, currently it is not possible to specify a port number in "java.security.krb5.kdc?. > Yep. > >> What do you think? > I have thought about analyzing the strings and treat one as port if it?s only digits. For example, a:1:b:c means a:1, b and c. a:1:2 looks invalid but accept it for compatibility and treat it as a:1 and 2, at least if a:1 works 2 will not be touched. > >>> The conf file only contains realm and kdc and nothing else. If both conf file and system properties are provided, how do you prove the conf file is also read and not ignored? >> The test doesn't check it. I see the following ways to check it: >> - Corrupt krb5 conf, and run kinit with it. I suppose it should fail. >> - Add some extra parameters to krb5, run kinit, and then try to use obtained data, and check that those extra parameters were used (I am not sure about details right now, need to do some experiments) >> >> What do you think? > You can add forwardable=true and check if the output is indeed forwardable. In case it?s default true, try again with forwardable=false. :-) > > Thanks > Max > From artem.smotrakov at oracle.com Thu Sep 10 13:52:34 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 10 Sep 2015 16:52:34 +0300 Subject: [9] RFR: 8075299: Additional tests for 6857795 In-Reply-To: <55F17516.7060607@oracle.com> References: <55C1ECEF.5000204@oracle.com> <55C22076.8090602@oracle.com> <55C36437.6040605@oracle.com> <50E1B5BF-04A8-4E08-BFA1-0A2DB97AEDF3@oracle.com> <55F17516.7060607@oracle.com> Message-ID: <55F18B22.1060900@oracle.com> Sorry, I forgot to remove "-f" and "-p" options for kinit http://cr.openjdk.java.net/~asmotrak/8075299/webrev.03/ Artem On 09/10/2015 03:18 PM, Artem Smotrakov wrote: > Hi Max, > > It seems that kinit doesn't print any info about ticket flags [1] (I > am not sure that it is a good idea to rely on > -Dsun.security.krb5.debug=true here). But klist does. I updated the > test to run klist which checks tickets for forwardable and proxiable > flags. > > http://cr.openjdk.java.net/~asmotrak/8075299/webrev.02/ > > [1] > http://docs.oracle.com/javase/8/docs/technotes/tools/windows/kinit.html > > Artem > > On 09/10/2015 11:48 AM, Wang Weijun wrote: >> Everything is fine. Some answers inline: >> >>> On Aug 6, 2015, at 9:42 PM, Artem Smotrakov >>> wrote: >>> >>> By the way, as far as I know, currently it is not possible to >>> specify a port number in "java.security.krb5.kdc?. >> Yep. >> >>> What do you think? >> I have thought about analyzing the strings and treat one as port if >> it?s only digits. For example, a:1:b:c means a:1, b and c. a:1:2 >> looks invalid but accept it for compatibility and treat it as a:1 and >> 2, at least if a:1 works 2 will not be touched. >> >>>> The conf file only contains realm and kdc and nothing else. If both >>>> conf file and system properties are provided, how do you prove the >>>> conf file is also read and not ignored? >>> The test doesn't check it. I see the following ways to check it: >>> - Corrupt krb5 conf, and run kinit with it. I suppose it should fail. >>> - Add some extra parameters to krb5, run kinit, and then try to use >>> obtained data, and check that those extra parameters were used (I am >>> not sure about details right now, need to do some experiments) >>> >>> What do you think? >> You can add forwardable=true and check if the output is indeed >> forwardable. In case it?s default true, try again with >> forwardable=false. :-) >> >> Thanks >> Max >> > From weijun.wang at oracle.com Thu Sep 10 14:22:06 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 10 Sep 2015 22:22:06 +0800 Subject: [9] RFR: 8075299: Additional tests for 6857795 In-Reply-To: <55F18B22.1060900@oracle.com> References: <55C1ECEF.5000204@oracle.com> <55C22076.8090602@oracle.com> <55C36437.6040605@oracle.com> <50E1B5BF-04A8-4E08-BFA1-0A2DB97AEDF3@oracle.com> <55F17516.7060607@oracle.com> <55F18B22.1060900@oracle.com> Message-ID: <6A724C55-0248-45BA-8ECC-3DFB3928A814@oracle.com> Everything is fine now. Thanks Max > http://cr.openjdk.java.net/~asmotrak/8075299/webrev.03/ From artem.smotrakov at oracle.com Fri Sep 11 11:46:57 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 11 Sep 2015 14:46:57 +0300 Subject: [9] RFR: 8134232: KeyStore.load() throws an IOException with a wrong cause in case of wrong password Message-ID: <55F2BF31.70704@oracle.com> Hello, Please review this for 9. According to [1], KeyStore.load(InputStream, char[]) method should throw an IOException, and the cause of the IOException should be an UnrecoverableKeyException: ... Throws: IOException - if there is an I/O or format problem with the keystore data, if a password is required but not given, or if the given password was incorrect. If the error is due to a wrong password, the cause of the IOException should be an UnrecoverableKeyException ... But in case of PKCS11, PKCS12 and JCEKS keystores it throws an IOException, but the cause is not UnrecoverableKeyException. This fix updates PKCS11, PKCS12 and JCEKS keystore implementations to use UnrecoverableKeyException in case of wrong password. Also updated a couple of existing tests. Please note that an additional test will be added in https://bugs.openjdk.java.net/browse/JDK-8048622 (review pending). Bug: https://bugs.openjdk.java.net/browse/JDK-8134232 Webrev: http://cr.openjdk.java.net/~asmotrak/8134232/webrev.00/ [1] http://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html#load-java.io.InputStream-char:A- Artem From artem.smotrakov at oracle.com Fri Sep 11 11:50:19 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 11 Sep 2015 14:50:19 +0300 Subject: [9] RFR: 8048622: Enhance tests for PKCS11 keystores with NSS In-Reply-To: <55D78B41.3050003@oracle.com> References: <55D78B41.3050003@oracle.com> Message-ID: <55F2BFFB.3060303@oracle.com> Hello, I just sent out a suggested fix for 8048622. I'll update ProblemList.txt here if 8048622 is integrated. Please take a look. Artem On 08/21/2015 11:34 PM, Artem Smotrakov wrote: > Hello, > > Please review a couple of changes for PKCS11 tests: > - Added a new test which checks that a keystore can't be loaded with > incorrect password, > found https://bugs.openjdk.java.net/browse/JDK-8134232 > - Added a check that a trusted entry can be removedfrom keystore > - Updated existing tests not to use random data > - Updated existing tests to use try-with-resources for I/O > operationswith files > - Small cosmetic updates > > Bug: https://bugs.openjdk.java.net/browse/JDK-8048622 > Webrev: http://cr.openjdk.java.net/~asmotrak/8048622/webrev.00/ > > Artem From valerie.peng at oracle.com Fri Sep 11 23:50:51 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 11 Sep 2015 16:50:51 -0700 Subject: RFR JDK-8075286: Additional tests for signature algorithm OIDs and transformation string In-Reply-To: <55CC58AF.7080608@oracle.com> References: <55CC58AF.7080608@oracle.com> Message-ID: <55F368DB.701@oracle.com> Mostly are fine, just a few comments: 1) the convention is to place the regression tests based on the provider which they are for, e.g. SunJCE provider -> com/sun/crypto/provider SUN provider -> sun/security/provider SunEC provider -> sun/security/ec Given that there is not a lot of dependency between these tests, can u place them into the sub-directories under the dedicated path? The utility class TestSignatureOidHelper.java into can be placed under sun/security. 2) several tests has "...must be failed", probably should be changed to "...should fail" 3) the variable naming seems confusing, e.g. cipherAlgorithm and cipherOid both refer to Cipher objects while cipherText refers to encrypted text. For future development, u may want to name the cipher variables differently so it's obvious that they represent Cipher objects. Thanks, Valerie On 8/13/2015 1:43 AM, Sha Jiang wrote: > Hi Security developers, > I have a security test bug > https://bugs.openjdk.java.net/browse/JDK-8075286, which adds more > cases for NSA Suite B algorithms in jdk repo. > Please review this patch at > http://cr.openjdk.java.net/~fyuan/jjiang/8075286/webrev.00/ > Every comment is appreciated. > > Best Regards, > John Jiang -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Sat Sep 12 09:23:45 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 12 Sep 2015 17:23:45 +0800 Subject: RFR 8136425: KeystoreImpl.m using wrong type for cert format Message-ID: <0810B468-158E-429C-8265-8F855F99106B@oracle.com> Please take a look at http://cr.openjdk.java.net/~weijun/8136425/webrev.00/ It looks like a wrong type is used, kSecFormatX509Cert and kSecFormatWrappedPKCS8 are of SecExternalFormat and the SecKeychainItemImport function also uses this type for its 3rd argument. Constants and function are all defined in http://www.opensource.apple.com/source/libsecurity_keychain/libsecurity_keychain-40768/lib/SecImportExport.h It is an enum, so still works. Thanks Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.x.ryan at oracle.com Sat Sep 12 12:55:53 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Sat, 12 Sep 2015 13:55:53 +0100 Subject: RFR 8136425: KeystoreImpl.m using wrong type for cert format In-Reply-To: <0810B468-158E-429C-8265-8F855F99106B@oracle.com> References: <0810B468-158E-429C-8265-8F855F99106B@oracle.com> Message-ID: <4712A9F4-3CF8-47D2-8400-541ECE7BFE76@oracle.com> Your fix looks fine to me. Thanks. > On 12 Sep 2015, at 10:23, Wang Weijun wrote: > > Please take a look at > > http://cr.openjdk.java.net/~weijun/8136425/webrev.00/ > > It looks like a wrong type is used, kSecFormatX509Cert and kSecFormatWrappedPKCS8 are of SecExternalFormat and the SecKeychainItemImport function also uses this type for its 3rd argument. Constants and function are all defined in > > http://www.opensource.apple.com/source/libsecurity_keychain/libsecurity_keychain-40768/lib/SecImportExport.h > > It is an enum, so still works. > > Thanks > Max > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Sep 14 04:08:34 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 14 Sep 2015 12:08:34 +0800 Subject: 8136436: jarsigner tests include both a warnings.sh and a warnings subdir Message-ID: I?ve filed the bug at https://bugs.openjdk.java.net/browse/JDK-8136436. jtreg first creates the "warnings" directory to store jtr files of tests in warnings subdir, and then clean it up and store retained files for warnings.sh there. The jtr files are now lost. No webrev to look at, I just cd test/sun/security/tools/jarsigner/ hg mv warnings.sh warning.sh and the patch file looks like diff --git a/test/sun/security/tools/jarsigner/warnings.sh b/test/sun/security/tools/jarsigner/warning.sh rename from test/sun/security/tools/jarsigner/warnings.sh rename to test/sun/security/tools/jarsigner/warning.sh CCing Jon, there is no other solution, right? Thanks Max From vincent.x.ryan at oracle.com Mon Sep 14 13:10:23 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 14 Sep 2015 14:10:23 +0100 Subject: [9] RFR: 8134232: KeyStore.load() throws an IOException with a wrong cause in case of wrong password In-Reply-To: <55F2BF31.70704@oracle.com> References: <55F2BF31.70704@oracle.com> Message-ID: Your fix looks fine Artem. Thanks. > On 11 Sep 2015, at 12:46, Artem Smotrakov wrote: > > Hello, > > Please review this for 9. > > According to [1], KeyStore.load(InputStream, char[]) method should throw an IOException, and the cause of the IOException should be an UnrecoverableKeyException: > > ... > Throws: > IOException - if there is an I/O or format problem with the keystore data, if a password is required but not given, or if the given password was incorrect. If the error is due to a wrong password, the cause of the IOException should be an UnrecoverableKeyException > ... > > But in case of PKCS11, PKCS12 and JCEKS keystores it throws an IOException, but the cause is not UnrecoverableKeyException. > > This fix updates PKCS11, PKCS12 and JCEKS keystore implementations to use UnrecoverableKeyException in case of wrong password. Also updated a couple of existing tests. Please note that an additional test will be added in https://bugs.openjdk.java.net/browse/JDK-8048622 (review pending). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8134232 > Webrev: http://cr.openjdk.java.net/~asmotrak/8134232/webrev.00/ > > [1] http://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html#load-java.io.InputStream-char:A- > > Artem From vincent.x.ryan at oracle.com Mon Sep 14 13:13:04 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 14 Sep 2015 14:13:04 +0100 Subject: [9] RFR: 8048622: Enhance tests for PKCS11 keystores with NSS In-Reply-To: <55D78B41.3050003@oracle.com> References: <55D78B41.3050003@oracle.com> Message-ID: <791B099C-8022-4583-A8E5-4FA71CA77CFB@oracle.com> Your fix looks fine. Thanks. > On 21 Aug 2015, at 21:34, Artem Smotrakov wrote: > > Hello, > > Please review a couple of changes for PKCS11 tests: > - Added a new test which checks that a keystore can't be loaded with incorrect password, > found https://bugs.openjdk.java.net/browse/JDK-8134232 > - Added a check that a trusted entry can be removedfrom keystore > - Updated existing tests not to use random data > - Updated existing tests to use try-with-resources for I/O operationswith files > - Small cosmetic updates > > Bug: https://bugs.openjdk.java.net/browse/JDK-8048622 > Webrev: http://cr.openjdk.java.net/~asmotrak/8048622/webrev.00/ > > Artem From sean.mullan at oracle.com Mon Sep 14 18:59:15 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 14 Sep 2015 14:59:15 -0400 Subject: RFR JDK-8074931: Additional tests for CertPath API In-Reply-To: <033f01d0e554$9f9dd900$ded98b00$@oracle.com> References: <033f01d0e554$9f9dd900$ded98b00$@oracle.com> Message-ID: <55F71903.2070903@oracle.com> These tests look fine to me. --Sean On 09/02/2015 03:54 AM, Frank Yuan wrote: > Hi Security developers > > I have a security test bug > https://bugs.openjdk.java.net/browse/JDK-8074931, which is to add more > coverage for CertPath and X509CertSelector in jdk repo. > > Would you like to review this patch > http://cr.openjdk.java.net/~fyuan/8074931/webrev.00/? Your comment will > be appreciated. > > Best Regards > > Frank > From bradford.wetmore at oracle.com Mon Sep 14 22:20:55 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 14 Sep 2015 15:20:55 -0700 Subject: [9] RFR: 8048356: SecureRandom default provider tests In-Reply-To: <55EA028C.9030607@oracle.com> References: <55EA028C.9030607@oracle.com> Message-ID: <55F74847.6010806@oracle.com> I might also suggest grabbing a byte from the various implementations to ensure they return working implementations. You should also include a comment which mentions that this is an implementation-specific test for the Oracle & stock OpenJDK implementations, and that other implementations might use other SecureRandom implementations in which case this test would need to be adjusted. Does that make sense? Brad On 9/4/2015 1:43 PM, Rajan Halade wrote: > Please help with your review of this new test to check default provider > used with SecureRandom. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8048356 > Webrev: http://cr.openjdk.java.net/~rhalade/8048356/webrev.00/ > > Thanks, > Rajan From frank.yuan at oracle.com Tue Sep 15 02:07:13 2015 From: frank.yuan at oracle.com (Frank Yuan) Date: Tue, 15 Sep 2015 10:07:13 +0800 Subject: RFR JDK-8074931: Additional tests for CertPath API In-Reply-To: <55F71903.2070903@oracle.com> References: <033f01d0e554$9f9dd900$ded98b00$@oracle.com> <55F71903.2070903@oracle.com> Message-ID: <019a01d0ef5b$3eb86a40$bc293ec0$@oracle.com> Thank you, Sean Best Regards Frank -----Original Message----- From: Sean Mullan [mailto:sean.mullan at oracle.com] Sent: Tuesday, September 15, 2015 2:59 AM To: Frank Yuan ; security-dev at openjdk.java.net Subject: Re: RFR JDK-8074931: Additional tests for CertPath API These tests look fine to me. --Sean On 09/02/2015 03:54 AM, Frank Yuan wrote: > Hi Security developers > > I have a security test bug > https://bugs.openjdk.java.net/browse/JDK-8074931, which is to add more > coverage for CertPath and X509CertSelector in jdk repo. > > Would you like to review this patch > http://cr.openjdk.java.net/~fyuan/8074931/webrev.00/? Your comment > will be appreciated. > > Best Regards > > Frank > From sean.mullan at oracle.com Tue Sep 15 11:43:23 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 15 Sep 2015 07:43:23 -0400 Subject: RFR: JDK-8015388 : Required algorithms for JDK 9 In-Reply-To: <55EA380A.4060100@oracle.com> References: <55E9BDE9.7080401@oracle.com> <55EA380A.4060100@oracle.com> Message-ID: <55F8045B.4050005@oracle.com> On 09/04/2015 08:32 PM, Xuelei Fan wrote: > Looks fine to me. One additional change. I have added PKIX as a required algorithm for TrustManagerFactory. Please review the updated webrev: http://cr.openjdk.java.net/~mullan/webrevs/8015388/webrev.01/ Thanks, Sean > > Xuelei > > On 9/4/2015 11:51 PM, Sean Mullan wrote: >> The JDK includes a list of required security algorithms that all >> implementations must support: >> http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#impl >> >> >> This list is reviewed before each major release to check if new >> algorithms should be added (or existing algorithms removed). >> >> For JDK 9, we are proposing to add several new algorithms and keysizes >> that are recommended by standards bodies for cryptographic operations >> and security protocols. Adding these as requirements ensures that Java >> applications can depend on them to be available on all Java 9 >> implementations. The new requirements are: >> >> 1. Signature: SHA256withDSA >> 2. KeyPairGenerator: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) >> 3. AlgorithmParameterGenerator: DSA (2048), DiffieHellman (2048, 4096) >> 4. Cipher: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) >> 5. SSLContext: TLSv1.1, TLSv1.2 >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8015388/webrev.00/ >> >> Thanks, >> Sean > From xuelei.fan at oracle.com Tue Sep 15 14:54:58 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 15 Sep 2015 22:54:58 +0800 Subject: RFR: JDK-8015388 : Required algorithms for JDK 9 In-Reply-To: <55F8045B.4050005@oracle.com> References: <55E9BDE9.7080401@oracle.com> <55EA380A.4060100@oracle.com> <55F8045B.4050005@oracle.com> Message-ID: <55F83142.1090900@oracle.com> It's OK to me. Thanks, Xuelei On 9/15/2015 7:43 PM, Sean Mullan wrote: > On 09/04/2015 08:32 PM, Xuelei Fan wrote: >> Looks fine to me. > > One additional change. I have added PKIX as a required algorithm for > TrustManagerFactory. Please review the updated webrev: > > http://cr.openjdk.java.net/~mullan/webrevs/8015388/webrev.01/ > > Thanks, > Sean > >> >> Xuelei >> >> On 9/4/2015 11:51 PM, Sean Mullan wrote: >>> The JDK includes a list of required security algorithms that all >>> implementations must support: >>> http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#impl >>> >>> >>> >>> This list is reviewed before each major release to check if new >>> algorithms should be added (or existing algorithms removed). >>> >>> For JDK 9, we are proposing to add several new algorithms and keysizes >>> that are recommended by standards bodies for cryptographic operations >>> and security protocols. Adding these as requirements ensures that Java >>> applications can depend on them to be available on all Java 9 >>> implementations. The new requirements are: >>> >>> 1. Signature: SHA256withDSA >>> 2. KeyPairGenerator: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) >>> 3. AlgorithmParameterGenerator: DSA (2048), DiffieHellman (2048, 4096) >>> 4. Cipher: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) >>> 5. SSLContext: TLSv1.1, TLSv1.2 >>> >>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8015388/webrev.00/ >>> >>> Thanks, >>> Sean >> From bradford.wetmore at oracle.com Tue Sep 15 18:23:08 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 15 Sep 2015 11:23:08 -0700 Subject: RFR: JDK-8015388 : Required algorithms for JDK 9 In-Reply-To: <55F8045B.4050005@oracle.com> References: <55E9BDE9.7080401@oracle.com> <55EA380A.4060100@oracle.com> <55F8045B.4050005@oracle.com> Message-ID: <55F8620C.4090207@oracle.com> I just reviewed the new TrustManagerFactory, looks ok to me too. Brad On 9/15/2015 4:43 AM, Sean Mullan wrote: > On 09/04/2015 08:32 PM, Xuelei Fan wrote: >> Looks fine to me. > > One additional change. I have added PKIX as a required algorithm for > TrustManagerFactory. Please review the updated webrev: > > http://cr.openjdk.java.net/~mullan/webrevs/8015388/webrev.01/ > > Thanks, > Sean > >> >> Xuelei >> >> On 9/4/2015 11:51 PM, Sean Mullan wrote: >>> The JDK includes a list of required security algorithms that all >>> implementations must support: >>> http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#impl >>> >>> >>> >>> This list is reviewed before each major release to check if new >>> algorithms should be added (or existing algorithms removed). >>> >>> For JDK 9, we are proposing to add several new algorithms and keysizes >>> that are recommended by standards bodies for cryptographic operations >>> and security protocols. Adding these as requirements ensures that Java >>> applications can depend on them to be available on all Java 9 >>> implementations. The new requirements are: >>> >>> 1. Signature: SHA256withDSA >>> 2. KeyPairGenerator: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) >>> 3. AlgorithmParameterGenerator: DSA (2048), DiffieHellman (2048, 4096) >>> 4. Cipher: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) >>> 5. SSLContext: TLSv1.1, TLSv1.2 >>> >>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8015388/webrev.00/ >>> >>> Thanks, >>> Sean >> From valerie.peng at oracle.com Wed Sep 16 03:15:48 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 15 Sep 2015 20:15:48 -0700 Subject: RFR for JDK-8048604 : Tests for strong crypto ciphers In-Reply-To: <55CBD193.5020504@oracle.com> References: <55CBD193.5020504@oracle.com> Message-ID: <55F8DEE4.5020404@oracle.com> Most of the tests are DES, DESede, and Blowfish and they are written in a way which won't work with AES due to the larger block size as the block size 8 is dispersed through out the tests instead of as a constant. At some point, I think we need to enhance these tests to cover AES instead of the legacy algorithms such as DES, DESede, etc. Can u define a constant for the block size and replace 8 with this constant? Some nit - If tests are already placed under CICO directory, their names do not need to contain CICO. Also, maybe u can just place the tests under com/sun/crypto/provider/CICO instead of com/sun/crypto/provider/Cipher/CICO. - if my reading of the code is right, the equalsBlockSave(byte[] b1, byte[]b2, int bLen, int save) method compares b1 and b2 by chopping up b1 into blocks of 'bLen' and b2 into blocks of 'save', and then compare the first 'save' bytes of each block to make sure they are equal. line 59 looks incorrect - the number of blocks should be computed using b1.length instead of b2.length. The term "save" seems confusing too. Maybe "partial" would be more suitable? Or maybe changing "bLen" to "b1Len", and "save" to "b2Len". The description on line 50 could use some more words to explain what this method does without reading through the code. - after line 85, check that there are no further data available after reading "recoveredText". - line 63, "is not exist" should be "does not exist" or "not found". - the comments on line 67-68 and line 77 seems contradictory to each other. Essentially, NoPadding is tested for all modes vs PKCS5Padding is tested for some modes. - the check from line106-110 should be moved up to right after the Cipher.getInstance() calls on line 97 and 98. - line 74, instead of byte[] plainText, I think it's clearer to just have "int inputLen". The content of the input array is not used in any of the enum values, but rather just the length for output buffer allocation. - the variable "ci1" should really be named "ciIn" so that it's clear that this argument is the cipher associated with the CipherInputStream. - line 124, "blockLen" should really be "numOfBlocks". - Will LengthLimitException ever be thrown for this test? Given that you are only using default key length, I doubt the check on line 163 will be true. - line 178-180 seems redundant? I think they can just be removed. - line 184, why is the key length check being done here again inside the same method? This one for sure is useless. - Instead of 2 constructors with comments indicating what ciphers they are for, it's better to just use static factory method. The implementation isn't that different, they both return a pair of ciphers. U can handle the different parameter type and secret key generation using a switch construct based on the specified algorithm 'algo'. - line 217 and 234, 45 should be 'save' - the testPaddingScheme() method doesn't seem too useful as it is testing the PKCS5Padding inside the test class itself. How would this detect any regression in SunJCE provider? I understand that the test may have problem accessing the actual PKCS5Padding class inside the SunJCE provider, but still, copy-n-paste the internal class out into test class is meaningless. This test method and the cut-n-pasted classes should be removed. I will send u comments on PBE ones in a separate email. Thanks, Valerie On 8/12/2015 4:06 PM, Tristan Yan wrote: > Please be free review these new tests for strong crypto ciphers. > > webrev : http://cr.openjdk.java.net/~tyan/8048604/webrev.01/ > bug : https://bugs.openjdk.java.net/browse/JDK-8048604 > > Thank you very much > Tristan -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.x.ryan at oracle.com Wed Sep 16 19:12:43 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 16 Sep 2015 20:12:43 +0100 Subject: [9] request for review: 8136534: Loading JKS keystore using non-null InputStream results in closed stream Message-ID: <04464722-3A79-4842-A207-0812DBE0EF47@oracle.com> Please review this JDK 9 fix to stop KeyStore.load from closing the input stream passed to it. Thanks. Bug: https://bugs.openjdk.java.net/browse/JDK-8136534 Webrev: http://cr.openjdk.java.net/~vinnie/8136534/webrev.00/ From bradford.wetmore at oracle.com Wed Sep 16 21:04:51 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 16 Sep 2015 14:04:51 -0700 Subject: [9] request for review: 8136534: Loading JKS keystore using non-null InputStream results in closed stream In-Reply-To: <04464722-3A79-4842-A207-0812DBE0EF47@oracle.com> References: <04464722-3A79-4842-A207-0812DBE0EF47@oracle.com> Message-ID: <55F9D973.1000508@oracle.com> Line 257 looks long. Not sure why you changed it. Otherwise, looks good. Brad On 9/16/2015 12:12 PM, Vincent Ryan wrote: > Please review this JDK 9 fix to stop KeyStore.load from closing the input stream passed to it. > Thanks. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8136534 > Webrev: http://cr.openjdk.java.net/~vinnie/8136534/webrev.00/ > From valerie.peng at oracle.com Wed Sep 16 22:24:53 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 16 Sep 2015 15:24:53 -0700 Subject: RFR for JDK-8048604 : Tests for strong crypto ciphers In-Reply-To: <55F8DEE4.5020404@oracle.com> References: <55CBD193.5020504@oracle.com> <55F8DEE4.5020404@oracle.com> Message-ID: <55F9EC35.1060400@oracle.com> Can u please make sure that all the Cipher objects are retrieved using "SunJCE" provider? I noticed some inconsistencies here and there. - line 94, 'provider' object should be used here. - need @library tag to find the TestUtilities class, otherwise, the compilation fails. - variable "model" should be named "mode". - nit: rename the class to PBEAlgorithm for consistency. - line 98 has a typo, I think u meant "or" instead of "of" - typo on line51: TANSFORMATION should be TRANSFORMATION - line 94, why not just init with mode directly as in other Wrapper classes? - line 63, variable name normally starts with lower case. Can u fix it for better readability? Same goes for other PBE tests. - the test class description is not very readable and contains a few typos. Can u please double check? - typo on lin 132 - decript - both the proceedSkipTestUsingXXX() methods should check to ensure that "SAVE" number of bytes are read. - line 79 doesn't look right at all. The comparison should be made against the output written to output stream instead of itself. if (!TestUtilities.equalsBlock(plainText, plainText, TEXT_SIZE)) { That's all. Valerie On 9/15/2015 8:15 PM, Valerie Peng wrote: > > Most of the tests are DES, DESede, and Blowfish and they are written > in a way which won't work with AES due to the larger block size as the > block size 8 is dispersed through out the tests instead of as a constant. > At some point, I think we need to enhance these tests to cover AES > instead of the legacy algorithms such as DES, DESede, etc. Can u > define a constant for the block size and replace 8 with this constant? > > Some nit - If tests are already placed under CICO directory, their > names do not need to contain CICO. > Also, maybe u can just place the tests under > com/sun/crypto/provider/CICO instead of > com/sun/crypto/provider/Cipher/CICO. > > > - if my reading of the code is right, the equalsBlockSave(byte[] b1, > byte[]b2, int bLen, int save) method compares b1 and b2 by chopping up > b1 into blocks of 'bLen' and b2 into blocks of 'save', and then > compare the first 'save' bytes of each block to make sure they are > equal. line 59 looks incorrect - the number of blocks should be > computed using b1.length instead of b2.length. The term "save" seems > confusing too. Maybe "partial" would be more suitable? Or maybe > changing "bLen" to "b1Len", and "save" to "b2Len". > The description on line 50 could use some more words to explain what > this method does without reading through the code. > > > - after line 85, check that there are no further data available after > reading "recoveredText". > > > - line 63, "is not exist" should be "does not exist" or "not found". > - the comments on line 67-68 and line 77 seems contradictory to each > other. Essentially, NoPadding is tested for all modes vs PKCS5Padding > is tested for some modes. > - the check from line106-110 should be moved up to right after the > Cipher.getInstance() calls on line 97 and 98. > > > - line 74, instead of byte[] plainText, I think it's clearer to just > have "int inputLen". The content of the input array is not used in any > of the enum values, but rather just the length for output buffer > allocation. > - the variable "ci1" should really be named "ciIn" so that it's clear > that this argument is the cipher associated with the CipherInputStream. > > > - line 124, "blockLen" should really be "numOfBlocks". > - Will LengthLimitException ever be thrown for this test? Given that > you are only using default key length, I doubt the check on line 163 > will be true. > - line 178-180 seems redundant? I think they can just be removed. > - line 184, why is the key length check being done here again inside > the same method? This one for sure is useless. > - Instead of 2 constructors with comments indicating what ciphers they > are for, it's better to just use static factory method. The > implementation isn't that different, they both return a pair of > ciphers. U can handle the different parameter type and secret key > generation using a switch construct based on the specified algorithm > 'algo'. > - line 217 and 234, 45 should be 'save' > > > - the testPaddingScheme() method doesn't seem too useful as it is > testing the PKCS5Padding inside the test class itself. How would this > detect any regression in SunJCE provider? I understand that the test > may have problem accessing the actual PKCS5Padding class inside the > SunJCE provider, but still, copy-n-paste the internal class out into > test class is meaningless. This test method and the cut-n-pasted > classes should be removed. > > I will send u comments on PBE ones in a separate email. > Thanks, > Valerie > > On 8/12/2015 4:06 PM, Tristan Yan wrote: >> Please be free review these new tests for strong crypto ciphers. >> >> webrev : http://cr.openjdk.java.net/~tyan/8048604/webrev.01/ >> bug : https://bugs.openjdk.java.net/browse/JDK-8048604 >> >> Thank you very much >> Tristan -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Sep 17 02:06:19 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 17 Sep 2015 10:06:19 +0800 Subject: 8136436: jarsigner tests include both a warnings.sh and a warnings subdir In-Reply-To: References: Message-ID: <8FB40969-239D-468E-846E-41393A0AAD7E@oracle.com> Ping again. > On Sep 14, 2015, at 12:08 PM, Wang Weijun wrote: > > I?ve filed the bug at https://bugs.openjdk.java.net/browse/JDK-8136436. > > jtreg first creates the "warnings" directory to store jtr files of tests in warnings subdir, and then clean it up and store retained files for warnings.sh there. The jtr files are now lost. > > No webrev to look at, I just > > cd test/sun/security/tools/jarsigner/ > hg mv warnings.sh warning.sh > > and the patch file looks like > > diff --git a/test/sun/security/tools/jarsigner/warnings.sh b/test/sun/security/tools/jarsigner/warning.sh > rename from test/sun/security/tools/jarsigner/warnings.sh > rename to test/sun/security/tools/jarsigner/warning.sh > > CCing Jon, there is no other solution, right? > > Thanks > Max > From xuelei.fan at oracle.com Thu Sep 17 02:27:48 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 17 Sep 2015 10:27:48 +0800 Subject: 8136436: jarsigner tests include both a warnings.sh and a warnings subdir In-Reply-To: <8FB40969-239D-468E-846E-41393A0AAD7E@oracle.com> References: <8FB40969-239D-468E-846E-41393A0AAD7E@oracle.com> Message-ID: <55FA2524.304@oracle.com> Looks fine to me. Xuelei On 9/17/2015 10:06 AM, Wang Weijun wrote: > Ping again. > >> On Sep 14, 2015, at 12:08 PM, Wang Weijun wrote: >> >> I?ve filed the bug at https://bugs.openjdk.java.net/browse/JDK-8136436. >> >> jtreg first creates the "warnings" directory to store jtr files of tests in warnings subdir, and then clean it up and store retained files for warnings.sh there. The jtr files are now lost. >> >> No webrev to look at, I just >> >> cd test/sun/security/tools/jarsigner/ >> hg mv warnings.sh warning.sh >> >> and the patch file looks like >> >> diff --git a/test/sun/security/tools/jarsigner/warnings.sh b/test/sun/security/tools/jarsigner/warning.sh >> rename from test/sun/security/tools/jarsigner/warnings.sh >> rename to test/sun/security/tools/jarsigner/warning.sh >> >> CCing Jon, there is no other solution, right? >> >> Thanks >> Max >> > From sean.mullan at oracle.com Thu Sep 17 17:53:39 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 17 Sep 2015 13:53:39 -0400 Subject: Brainpool curves In-Reply-To: <84b37f14179b57a34c10d0596b6f7dc0@protonmail.ch> References: <84b37f14179b57a34c10d0596b6f7dc0@protonmail.ch> Message-ID: <55FAFE23.1030502@oracle.com> On 08/19/2015 05:48 PM, Jiri Stary wrote: > Hello, > > do you plan to support brainpool curves for TLS in Java 9 (RFC 7027) ? There is no plan to support it in 9. There is an open RFE for supporting brainpool in JCE: https://bugs.openjdk.java.net/browse/JDK-7007966 but no specific release has been targeted at this time. --Sean > > Regards > Jiri > > Sent from ProtonMail , encrypted email based in > Switzerland. From sean.mullan at oracle.com Fri Sep 18 16:28:21 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 18 Sep 2015 12:28:21 -0400 Subject: [9] request for review: 8136534: Loading JKS keystore using non-null InputStream results in closed stream In-Reply-To: <04464722-3A79-4842-A207-0812DBE0EF47@oracle.com> References: <04464722-3A79-4842-A207-0812DBE0EF47@oracle.com> Message-ID: <55FC3BA5.5000107@oracle.com> Looks fine to me. --Sean On 09/16/2015 03:12 PM, Vincent Ryan wrote: > Please review this JDK 9 fix to stop KeyStore.load from closing the input stream passed to it. > Thanks. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8136534 > Webrev: http://cr.openjdk.java.net/~vinnie/8136534/webrev.00/ > From amanda.jiang at oracle.com Fri Sep 18 19:27:55 2015 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Fri, 18 Sep 2015 12:27:55 -0700 Subject: RFR 8050402: Tests to check for use of policy files In-Reply-To: <55B914F3.1010403@oracle.com> References: <55A55FDA.3030606@oracle.com> <55B914F3.1010403@oracle.com> Message-ID: <55FC65BB.7010200@oracle.com> Hi Sean, Thanks for your comments. Tests has been updated by your comments. For one test case, which needs to create and sign a jar file, then add signed jar file to classpatth, so I create another java file for that test case. Please check new webrev below and let me know your suggestions. webrev: http://cr.openjdk.java.net/~amjiang/8050402/webrev.02/ Thanks, Amanda On 7/29/15, 11:01 AM, Sean Mullan wrote: > Hi Amanda, > > Rather than exec-ing java from within the test, I think it would be > better if you used jtreg @run options to do that. For example: > > @run main/java.security.policy=ExtensiblePolicyTest1.policy > ExtensiblePolicyTest1 false > @run main/java.security.policy=ExtensiblePolicyTest2.policy > ExtensiblePolicyTest1 true > > etc.. > > I think this would lead to a more robust test and eliminate some > overhead. > > Thanks, > Sean > > On 07/14/2015 03:15 PM, Amanda Jiang wrote: >> Hi, >> >> Please review a new test which checks Policy is extensible with user >> defined permissions. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8050402 >> Webrev: http://cr.openjdk.java.net/~amjiang/8050402/webrev.01/ >> >> Thanks, >> Amanda From valerie.peng at oracle.com Sat Sep 19 00:37:55 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 18 Sep 2015 17:37:55 -0700 Subject: RFR 8130648: JCK test api/java_security/AuthProvider/ProviderTests_login starts failing after JDK-7191662 In-Reply-To: <55AEDDCA.9010202@oracle.com> References: <55AEDDCA.9010202@oracle.com> Message-ID: <55FCAE63.7030408@oracle.com> Sean, I have updated the webrev based on your suggestions and CCC has also been filed: Webrev: http://cr.openjdk.java.net/~valeriep/8130648/webrev.00/ http://ccc.us.oracle.com/8130648 Thanks, Valerie On 7/21/2015 5:03 PM, Valerie Peng wrote: > > Anyone can help review this? > As part of 7191662, the default SunPKCS11 provider (without > configuration) is created by default for non-Solaris systems. This is > to help runtime configuration of custom PKCS11 providers. However, > given that SunPKCS11 extends AuthProvider, JCK test would expect the > default PKCS11 provider to be able to login/logout. Thus, I have to > refactor the code so that the default SunPKCS11 provider does not > extend AuthProvider and will be skipped by JCK test when testing > AuthProvider APIs. The two regression tests are just test clean up. > Since it's already covered by JCK test, I didn't add regression test. > > Webrev: http://cr.openjdk.java.net/~valeriep/8130648/webrev.00/ > > Thanks, > Valerie From bradford.wetmore at oracle.com Sat Sep 19 05:15:58 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 18 Sep 2015 22:15:58 -0700 Subject: TLS ALPN Proposal v5 In-Reply-To: References: <55ED0A6A.3050806@oracle.com> Message-ID: <55FCEF8E.2080608@oracle.com> Hi all, On 9/7/2015 7:18 AM, Simone Bordet wrote: > On Mon, Sep 7, 2015 at 5:54 AM, Bradford Wetmore > wrote: >> In general, if the ciphersuites aren't ordered properly, that should be >> considered a configuration error on the part of the application(s). However, >> this dynamic ALPN selection approach still allows for appropriate ALPN >> values to be selected for each possible ciphersuite. That is, if the suites >> were ordered H1/H2, the ALPN value should be H1. >> >> For an example of such a selector, please see the new H2/H2+H1/H1 >> ApplicationProtocolSelector implementions in >> ApplicationProtocolSelector.java, and how they are called in >> ServerHandshaker.java. >> >> >> Here is the latest: >> >> http://cr.openjdk.java.net/~wetmore/8051498/webrev.09 > > Are you sure this is the latest code ? > The relevant changes in ServerHandshaker are commented out. Yes, sorry for not making this clear. We've had a lot of internal discussions about the API and how to implement it: the comments in the implementation classes (sun.security.ssl) are primarily for Vinnie who has been working on the implementation. But I thought they provide some explanation as to how things might be implemented internally so I left them in the webrev. > I have the feeling that ApplicationProtocolSelector (APS) is not > really an application protocol selector, but a cipher suite selector. It was *(note past tense)* primarily an application protocol selector. The fact that it could also influence ciphersuite selection was an optimization to avoid using suites known not to work with a particular ALPN value, but were going to be attempted anyway (say due to a server misconfiguration). However, that has changed as the API has taken a different direction. You mentioned "session resumption" in your email, which reminded me that ALPN values should be attached to connections (i.e. SSLSocket/SSLEngine), not SSLSessions. That simplified things in several areas, especially in the Protocol Selector. We no longer have an ApplicationProtocolSelector, but rather an interface called ApplicationProtocol. These are concrete implementations of each ALPN/NPN value, and are responsible for examining the state of the connection so far and to return true if the conditions are right. These instances are passed as List to SSLParameters and then to SSLSocket/SSLEngines. We have a similar but somewhat simpler server selection algorithm than what was described earlier: Select TLS version for each ciphersuite load ALPN query with: proposed TLS version + proposed ciphersuite SSLSocket/SSLEngine + handshaking state for each ALPN value if (ALPN.matches()) temporarily assign ALPN to the handshaking SSLSocket/SSLEngine approve ciphersuite calls KeyManager for alias (can use ALPN value above) checks cipher/MAC restrictions, etc break; if no errors assign ciphersuite to handshakeSession assign ALPN to SSLSocket/SSLEngine assign handshakeSesion as the actual Session to SSLSocket/SSLEngine > APS seem to conflate cipher suite selection with application protocol > selection: the return value of select() actually is a 2-tuple that > means (ciphers[0], protocol) so that returning the empty string or > null does not have any effect on protocol selection, but only on > cipher selection. To restate the point I think you raising, "Should the ALPN selection mechanism influence the TLS protocol version selection mechanism?" We had a similar discussion internally. Why would we want to encourage/enable the selection of downrev'd TLS protocol versions based on ALPN values? If we actually support the higher/stronger TLS version, IMHO we should be using them. 1. I think the stronger security benefits from the later protocols should always take priority over ALPN values and that we shouldn't be encouraging downrev'ing at all. For example, if there is a TLSv1.2/1.1/1.0 server, and we negotiated down to 1.0 just to support some ALPN value (or due to a bug in the selector), we lose GCM (v1.2) and the explicit IV (v1.1). ALPN values are application values, which I would expect to not be as security sensitive as the protocol values. 2. The server hello's protocol version is supposed to be the lower of that suggested by the client in the client hello and the highest supported by the server. Returning a lower value just to satisfy an ALPN selection would indicate to anyone listening (proxy, other connection from same VM?) that the higher TLS values are not supported on this server, which I think is incorrect. Future connections to this server might cache this lower protocol value and lose the stronger protocols. 3. I would expect that "older" ALPN values will likely still be supported in later versions of the TLS protocol. I would be surprised if something like http/1.1 would be phased out in TLSv1.4. If it were, apps probably shouldn't be offering it in combination with newer TLS versions in the first place. > You can for example implement APS without even looking at the > application protocol, just to exclude dynamically certain ciphers from > selection (e.g. based on performance or remote IP). > > I don't understand exactly bullet 5 above. If APS chooses a cipher and > a protocol, but this is not a valid combination for the KeyManager to > select a certificate, what happens ? That APS is called again, right ? Since the API has changed, I'll won't spend much time to comment here/there. Yes, the ciphersuite is incremented for the next iteration. > But what if that was the last cipher ? Then APS won't be called again. > How can an application know that it is done trying to select a > protocol and that the protocol it chose is actually used ? Your question seems similar to asking if the KM can know if this is the last call it will get, and if it can know that the alias it selected might not be the final one. When the connection is done handshaking, the app can check the values now attached to the SSLSocket/SSLEngine. They can use the same Application Protocol object that did the selection/matches(), or do it by hand. > I guess this also brings to bullet 6: how can an application verify > that the N-tuple chosen is actually a correct one ? Is there an > additional callback that is being invoked (that applications can > implement) before the ServerHello is actually sent to the client ? No, the ApplicationProtocol callback needs to return the right ALPN values for the conditions passed. > A very important point that I saw in the comments is support for TLS > session resumption - this has been asked multiple times by Jetty users > that were using Jetty's ALPN (and we implemented it). > Just make sure that whatever proposal enters JDK 9, session resumption > is supported. Yes, thanks for the reminder about this. From RFC 7301: ...deleted...When session resumption or session tickets [RFC5077] are used, the previous contents of this extension are irrelevant, and only the values in the new handshake messages are considered. So we had to move the ALPN values from session to SSLSocket/SSLEngine. > My preference would go to the previous proposal (akin to Jetty - I > know I am biased) Yes, I guessed as much! ;) > where protocol selection was happening in isolation > *after* cipher selection. > It is much simpler, and has the only drawback of not allowing > certificate selection based on application protocol (for which we > never had request from the community). Understood. But I remain concerned about that point and future/undefined ALPN values. Here is the new webrev: http://cr.openjdk.java.net/~wetmore/8051498/webrev.12/ Unless there are major objections, we need to get ALPN into JDK very soon to make JDK 9. We can still tweak the APIs if something is found later. Major changes: 1. ApplicationProtocols interface + H2 + HTTP/1.1 impls Both client/server call SSLParameters.setApplicationProtocols(List<>) to set their preferences. The matches method can be used for: . During server handshaking to determine an acceptable ALPN value. . potentially during client preparation to eliminate known bad ciphersuites/protocols combos. If you are going to only request TLSv1.1 and earlier, you can disable H2 because it won't match. In this second case, you may not have a SSLSocket/SSLEngine yet, but you still want to do the checks based on ciphersuite/protocol, so the second parameters can be null. 2. ApplicationProtocolSelector gone. 3. SSLParameters AP_HTTP_1_1/AP_H2 effectively moved to ApplicationProtocol. Selection logic added to ApplicationProtocol. 4. Moved ALPN values from SSLSession to SSLSocket/SSLSEngine. Added a "handshaking in progress" variant. 5. SSLSession.getPeerApplicationProtocols() and getHandshakeCipherSuiteList() are gone. These are all handled internally. Thanks, Brad From amanda.jiang at oracle.com Mon Sep 21 04:54:16 2015 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Sun, 20 Sep 2015 21:54:16 -0700 Subject: RFR 8050461: Tests for syntax checking of JAAS configuration file In-Reply-To: <55857BBC.7000306@oracle.com> References: <558498C5.4060602@oracle.com> <55857BBC.7000306@oracle.com> Message-ID: <55FF8D78.9000600@oracle.com> Hi Max, Thanks for reviewing this webrev. I have updated test cases by your comments and simplify codes, please check latest webrev below and let me know if there are any problems: http://cr.openjdk.java.net/~amjiang/8050461/webrev.03/ Thanks, Amanda On 6/20/15, 7:42 AM, Weijun Wang wrote: > Hi Amanda > > I'd rather see 5 JAAS conf files directly included (instead of > generating them with codes). Then it seems you can write a single test > with 5 @run lines. > > Thanks > Max > > On 6/20/2015 6:33 AM, Amanda Jiang wrote: >> Hello, >> >> Please help to review following changeset, which includes new tests to >> Verify syntax checking of java.security.auth.login.config file. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8050461 >> Webrev: http://cr.openjdk.java.net/~amjiang/8050461/webrev.02/ >> >> Thanks, >> Amanda From weijun.wang at oracle.com Mon Sep 21 07:01:59 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 21 Sep 2015 15:01:59 +0800 Subject: RFR 8050461: Tests for syntax checking of JAAS configuration file In-Reply-To: <55FF8D78.9000600@oracle.com> References: <558498C5.4060602@oracle.com> <55857BBC.7000306@oracle.com> <55FF8D78.9000600@oracle.com> Message-ID: <1DA949AB-63E6-43E6-BE53-F3823ED18802@oracle.com> Great. Everything looks fine now. Thanks Max > ? 2015?9?21??12:54?Amanda Jiang ??? > > Hi Max, > > Thanks for reviewing this webrev. I have updated test cases by your comments and simplify codes, please check latest webrev below and let me know if there are any problems: > http://cr.openjdk.java.net/~amjiang/8050461/webrev.03/ > > Thanks, > Amanda > >> On 6/20/15, 7:42 AM, Weijun Wang wrote: >> Hi Amanda >> >> I'd rather see 5 JAAS conf files directly included (instead of generating them with codes). Then it seems you can write a single test with 5 @run lines. >> >> Thanks >> Max >> >>> On 6/20/2015 6:33 AM, Amanda Jiang wrote: >>> Hello, >>> >>> Please help to review following changeset, which includes new tests to >>> Verify syntax checking of java.security.auth.login.config file. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8050461 >>> Webrev: http://cr.openjdk.java.net/~amjiang/8050461/webrev.02/ >>> >>> Thanks, >>> Amanda > From amanda.jiang at oracle.com Mon Sep 21 07:16:07 2015 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Mon, 21 Sep 2015 00:16:07 -0700 Subject: RFR 8050461: Tests for syntax checking of JAAS configuration file In-Reply-To: <1DA949AB-63E6-43E6-BE53-F3823ED18802@oracle.com> References: <558498C5.4060602@oracle.com> <55857BBC.7000306@oracle.com> <55FF8D78.9000600@oracle.com> <1DA949AB-63E6-43E6-BE53-F3823ED18802@oracle.com> Message-ID: <55FFAEB7.4050308@oracle.com> Thank you Max, Could you please sponsor this ? Thanks, Amanda On 9/21/15, 12:01 AM, Wang Weijun wrote: > Great. Everything looks fine now. > > Thanks > Max > >> ? 2015?9?21??12:54?Amanda Jiang ??? >> >> Hi Max, >> >> Thanks for reviewing this webrev. I have updated test cases by your comments and simplify codes, please check latest webrev below and let me know if there are any problems: >> http://cr.openjdk.java.net/~amjiang/8050461/webrev.03/ >> >> Thanks, >> Amanda >> >>> On 6/20/15, 7:42 AM, Weijun Wang wrote: >>> Hi Amanda >>> >>> I'd rather see 5 JAAS conf files directly included (instead of generating them with codes). Then it seems you can write a single test with 5 @run lines. >>> >>> Thanks >>> Max >>> >>>> On 6/20/2015 6:33 AM, Amanda Jiang wrote: >>>> Hello, >>>> >>>> Please help to review following changeset, which includes new tests to >>>> Verify syntax checking of java.security.auth.login.config file. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8050461 >>>> Webrev: http://cr.openjdk.java.net/~amjiang/8050461/webrev.02/ >>>> >>>> Thanks, >>>> Amanda From tristan.yan at oracle.com Mon Sep 21 17:14:53 2015 From: tristan.yan at oracle.com (Tristan Yan) Date: Mon, 21 Sep 2015 10:14:53 -0700 Subject: RFR for JDK-8048604 : Tests for strong crypto ciphers In-Reply-To: <55F9EC35.1060400@oracle.com> References: <55CBD193.5020504@oracle.com> <55F8DEE4.5020404@oracle.com> <55F9EC35.1060400@oracle.com> Message-ID: <10EA3908-7CB8-43A9-ACA6-F3512F39D75D@oracle.com> Thank you Valerie. Please review the updated version of it http://cr.openjdk.java.net/~tyan/8048604/webrev.02/ Cheers Tristan > On Sep 16, 2015, at 3:24 PM, Valerie Peng > wrote: > > > Can u please make sure that all the Cipher objects are retrieved using "SunJCE" provider? > I noticed some inconsistencies here and there. > > > - line 94, 'provider' object should be used here. > - need @library tag to find the TestUtilities class, otherwise, the compilation fails. > > > - variable "model" should be named "mode". > - nit: rename the class to PBEAlgorithm for consistency. > > > - line 98 has a typo, I think u meant "or" instead of "of" > > > - typo on line51: TANSFORMATION should be TRANSFORMATION > - line 94, why not just init with mode directly as in other Wrapper classes? > > > - line 63, variable name normally starts with lower case. Can u fix it for better readability? Same goes for other PBE tests. > > > - the test class description is not very readable and contains a few typos. Can u please double check? > - typo on lin 132 - decript > - both the proceedSkipTestUsingXXX() methods should check to ensure that "SAVE" number of bytes are read. > > > - line 79 doesn't look right at all. The comparison should be made against the output written to output stream instead of itself. > if (!TestUtilities.equalsBlock(plainText, plainText, TEXT_SIZE)) { > That's all. > Valerie > > On 9/15/2015 8:15 PM, Valerie Peng wrote: >> >> >> Most of the tests are DES, DESede, and Blowfish and they are written in a way which won't work with AES due to the larger block size as the block size 8 is dispersed through out the tests instead of as a constant. >> At some point, I think we need to enhance these tests to cover AES instead of the legacy algorithms such as DES, DESede, etc. Can u define a constant for the block size and replace 8 with this constant? >> >> Some nit - If tests are already placed under CICO directory, their names do not need to contain CICO. >> Also, maybe u can just place the tests under com/sun/crypto/provider/CICO instead of com/sun/crypto/provider/Cipher/CICO. >> >> >> - if my reading of the code is right, the equalsBlockSave(byte[] b1, byte[]b2, int bLen, int save) method compares b1 and b2 by chopping up b1 into blocks of 'bLen' and b2 into blocks of 'save', and then compare the first 'save' bytes of each block to make sure they are equal. line 59 looks incorrect - the number of blocks should be computed using b1.length instead of b2.length. The term "save" seems confusing too. Maybe "partial" would be more suitable? Or maybe changing "bLen" to "b1Len", and "save" to "b2Len". >> The description on line 50 could use some more words to explain what this method does without reading through the code. >> >> >> - after line 85, check that there are no further data available after reading "recoveredText". >> >> >> - line 63, "is not exist" should be "does not exist" or "not found". >> - the comments on line 67-68 and line 77 seems contradictory to each other. Essentially, NoPadding is tested for all modes vs PKCS5Padding is tested for some modes. >> - the check from line106-110 should be moved up to right after the Cipher.getInstance() calls on line 97 and 98. >> >> >> - line 74, instead of byte[] plainText, I think it's clearer to just have "int inputLen". The content of the input array is not used in any of the enum values, but rather just the length for output buffer allocation. >> - the variable "ci1" should really be named "ciIn" so that it's clear that this argument is the cipher associated with the CipherInputStream. >> >> >> - line 124, "blockLen" should really be "numOfBlocks". >> - Will LengthLimitException ever be thrown for this test? Given that you are only using default key length, I doubt the check on line 163 will be true. >> - line 178-180 seems redundant? I think they can just be removed. >> - line 184, why is the key length check being done here again inside the same method? This one for sure is useless. >> - Instead of 2 constructors with comments indicating what ciphers they are for, it's better to just use static factory method. The implementation isn't that different, they both return a pair of ciphers. U can handle the different parameter type and secret key generation using a switch construct based on the specified algorithm 'algo'. >> - line 217 and 234, 45 should be 'save' >> >> >> - the testPaddingScheme() method doesn't seem too useful as it is testing the PKCS5Padding inside the test class itself. How would this detect any regression in SunJCE provider? I understand that the test may have problem accessing the actual PKCS5Padding class inside the SunJCE provider, but still, copy-n-paste the internal class out into test class is meaningless. This test method and the cut-n-pasted classes should be removed. >> >> I will send u comments on PBE ones in a separate email. >> Thanks, >> Valerie >> >> On 8/12/2015 4:06 PM, Tristan Yan wrote: >>> >>> Please be free review these new tests for strong crypto ciphers. >>> >>> webrev : http://cr.openjdk.java.net/~tyan/8048604/webrev.01/ >>> bug : https://bugs.openjdk.java.net/browse/JDK-8048604 >>> >>> Thank you very much >>> Tristan -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Sep 22 01:12:05 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 22 Sep 2015 09:12:05 +0800 Subject: RFR 8056174: New APIs for jar signing In-Reply-To: <55E8B010.70905@oracle.com> References: <55DB22A9.40704@oracle.com> <55E54ACC.6020004@oracle.com> <55E8B010.70905@oracle.com> Message-ID: <5600AAE5.3010009@oracle.com> OK, webrev updated at http://cr.openjdk.java.net/~weijun/8056174/webrev.05/ A new method setProperty() is added to JarSigner.Builder (as well as getProperty() in JarSigner) to cover all misc settings. JarSignerX and BuilderX are removed now. Thanks Max On 09/04/2015 04:39 AM, Sean Mullan wrote: > On 09/01/2015 02:50 AM, Weijun Wang wrote: >> Updated a little: rewrite of jarsigner tool itself using the JarSigner >> API included. Still at the same URL below. > > I notice that you don't use the new JarSigner API at all in the > jarsigner tool and go straight to the BuilderX/JarSignerX classes. This > worries me as it means the API is not sufficient for our own uses and > therefore may not be sufficient for anyone else either. > > I think the flaw is that we have not made it extensible. JarSigner is a > final class, so it can't be subclassed with new functionality. Removing > the final keyword would be easy, but that doesn't really solve the problem. > > It looks like we are not the first ones to tackle this problem. Here is > one link: > > https://weblogs.java.net/blog/emcmanus/archive/2010/10/25/using-builder-pattern-subclasses > > > Can you think about this some more and see if the design can be adapted > to allow JarSigner to be extended? > > Thanks, > Sean > >> >> --Max >> >> On 08/24/2015 09:56 PM, Weijun Wang wrote: >>> Hi All >>> >>> Please review the code change at >>> >>> http://cr.openjdk.java.net/~weijun/8056174/webrev.02/ >>> >>> A new JarSigner public API is introduced to OpenJDK. The code change >>> chooses a two-layer implementation style, with public JarSigner/Builder >>> in jdk.security and private JarSignerX/BuilderX in sun.security. The >>> private side contains some unpopular options which I hope can be used to >>> implement the jarsigner tool itself in another changeset. >>> >>> Some spec clarification is made since my last mail [1], including >>> Builder#sign, JarSigner#getDigestAlg, and JarSigner#getSigAlg. In >>> Builder, I am still using short method names (sigAlg, digestAlg, and >>> tsa) since I think the jarsigner option names are already widely >>> accepted. Otherwise, a name like setDigestAlgorithm seems a little >>> unfamiliar. >>> >>> Thanks >>> Max >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/security-dev/2015-August/012636.html >>> >>> From weijun.wang at oracle.com Tue Sep 22 03:43:05 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 22 Sep 2015 11:43:05 +0800 Subject: RFR 8056174: New APIs for jar signing In-Reply-To: <5600AAE5.3010009@oracle.com> References: <55DB22A9.40704@oracle.com> <55E54ACC.6020004@oracle.com> <55E8B010.70905@oracle.com> <5600AAE5.3010009@oracle.com> Message-ID: <5600CE49.1020604@oracle.com> Missing from the webrev, some extra lines needed in modules.xml of the parent repo jdk9/dev: jdk.jartool java.base com.sun.jarsigner + + jdk.security.jarsigner + Thanks Max On 09/22/2015 09:12 AM, Weijun Wang wrote: > OK, webrev updated at > > http://cr.openjdk.java.net/~weijun/8056174/webrev.05/ > > A new method setProperty() is added to JarSigner.Builder (as well as > getProperty() in JarSigner) to cover all misc settings. JarSignerX and > BuilderX are removed now. > > Thanks > Max > From simone.bordet at gmail.com Tue Sep 22 07:56:32 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Tue, 22 Sep 2015 09:56:32 +0200 Subject: TLS ALPN Proposal v5 In-Reply-To: <55FCEF8E.2080608@oracle.com> References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> Message-ID: Hi, On Sat, Sep 19, 2015 at 7:15 AM, Bradford Wetmore wrote: > Here is the new webrev: > > http://cr.openjdk.java.net/~wetmore/8051498/webrev.12/ > > Unless there are major objections, we need to get ALPN into JDK very soon to > make JDK 9. We can still tweak the APIs if something is found later. > > Major changes: > > 1. ApplicationProtocols interface + H2 + HTTP/1.1 impls > > Both client/server call SSLParameters.setApplicationProtocols(List<>) to set > their preferences. > > The matches method can be used for: > > . During server handshaking to determine an acceptable ALPN value. > > . potentially during client preparation to eliminate known bad > ciphersuites/protocols combos. If you are going to only request TLSv1.1 and > earlier, you can disable H2 because it won't match. > > In this second case, you may not have a SSLSocket/SSLEngine yet, but you > still want to do the checks based on ciphersuite/protocol, so the second > parameters can be null. > > 2. ApplicationProtocolSelector gone. > > 3. SSLParameters AP_HTTP_1_1/AP_H2 effectively moved to > ApplicationProtocol. Selection logic added to ApplicationProtocol. > > 4. Moved ALPN values from SSLSession to SSLSocket/SSLSEngine. Added a > "handshaking in progress" variant. > > 5. SSLSession.getPeerApplicationProtocols() and > getHandshakeCipherSuiteList() are gone. These are all handled internally. This new proposal still requires that ciphers are sorted in a way that matches the ApplicationProtocol order. Would be nice if, along with the HTTP/2 blacklist, there is a HTTP/2 comparator that sorts ciphers putting the blacklisted ones at the end. I don't like the first parameter of ApplicationProtocol.match() to be a Map; I would prefer a full blown class at this point, that contains all the parameters, for example: inner class ApplicationProtocol.Info { tlsProtocol cipher sslEngine sessionIsResuming etc. } I also don't understand why there are 2 methods for the protocol name ? What value does it bring to have 2 methods for the same thing ? I would just use: class ApplicationProtocol { public String getName() } RFC 7301 hints that the bytes to send over the network are the UTF-8 bytes from that string. There are still a lot of details missing, such as where is the chosen ALPN value stored (and how it can be retrieved by the KeyManager, for example), as well as the webrev not showing any real implementation, and how exactly the ApplicationProtocol instances are called, etc. For example, client sends ["h2"], server has ["http/1.1", "h2"]. Will the instance of ApplicationProtocol corresponding to "http/1.1" be invoked at all ? If not, there is a missing step in your algorithm above, where the implementation intersects the ALPN values from both peers. Finally, I think this API may be suitable for the server, but not much for the client, which is equally important. I don't see how a client application can figure out what protocol has been chosen by the server, because there is no final notification about that and the API seems totally geared towards server "matching" more than client notification. For me this is a blocker. Can you please provide an example of how a client application would use this new API to be notified that the server has chosen protocol "foo" ? I still remain convinced that - so far - the Jetty API proposal (or the similar version that was proposed here 2-3 proposals ago) is superior to the latest ones. 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 amanda.jiang at oracle.com Tue Sep 22 15:49:17 2015 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Tue, 22 Sep 2015 08:49:17 -0700 Subject: RFR 8050427 LoginContext tests to cover JDK-4703361 In-Reply-To: <55D18D5A.7020207@oracle.com> References: <55D17387.7030201@oracle.com> <55D18D5A.7020207@oracle.com> Message-ID: <5601787D.6040203@oracle.com> Hi Max, Thanks for your comments ,please check updated webrev and my replies inline. webrev: http://cr.openjdk.java.net/~amjiang/8050427/webrev.02/ Regards, Amanda On 8/17/15, 12:29 AM, Weijun Wang wrote: > There are something I don't understand. > > MyConfiguration.java: > > - optionOrder: Is it possible to make this an argument of the > constructor? Fixed, made this an argument of the constructor. > > - getConfiguration/setConfiguration: If these are useless, why adding > these methods? Removed useless methods. > > SmartLoginModule.java: > > - initialize: Why don't you use the callbackHandler argument? See below. > > - shouldSucceed: It is always very confusing to make a field > accessible from outside a class. Originally the test tried to test with different password , "shouldSucceed" is used to control which password will be set. MycallbackHandler is called in initialize( ) method and "shouldSucceed" is parsed as an argument to control which password would be set to "PasswdCallback" 123 this.callbackHandler = new MyCallbackHandler(myUsername, myPassword, 124 shouldSucceed); 341 public MyCallbackHandler(String username, char[] password, boolean action) { 342 super(); 343 userName = username; 344 this.password = password; 345 this.action = action; 346 } 361 PasswordCallback pc = (PasswordCallback) callback; 362 if (action) { 363 pc.setPassword(password); 364 } else { 365 pc.setPassword(wrongpd); 366 } I agree with you this may be confusing, so I simplify this test, "shouldSucceed" value is remove, please check updated webrev. > > DynamicConfigurationTest.java: > > - test: why the if checks are based on both isNegative and success? > Why not only on isNegative? If you want to test 2 stages (initialize > and login), you can provide 2 isNegative flags. "success" was for controlling correct/wrong passwords, "isNegative" was for checking if exception is expected. Tests are re-organized , so I do not use these two flags now, please check updated webrev. > > Thanks > Max > > > On 08/17/2015 01:39 PM, Amanda Jiang wrote: >> Hi All, >> >> Please be free to review these new tests for Dynamic configuration of >> authentication modules. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8050427 >> webrev:http://cr.openjdk.java.net/~amjiang/8050427/webrev.01/ >> >> >> Thanks, >> Amanda >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Tue Sep 22 20:41:14 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 22 Sep 2015 16:41:14 -0400 Subject: RFR 8130648: JCK test api/java_security/AuthProvider/ProviderTests_login starts failing after JDK-7191662 In-Reply-To: <55FCAE63.7030408@oracle.com> References: <55AEDDCA.9010202@oracle.com> <55FCAE63.7030408@oracle.com> Message-ID: <5601BCEA.5060204@oracle.com> On 09/18/2015 08:37 PM, Valerie Peng wrote: > Sean, > > I have updated the webrev based on your suggestions and CCC has also > been filed: > > Webrev: http://cr.openjdk.java.net/~valeriep/8130648/webrev.00/ SunPKCS11.java 110: can use diamond operator for anon classes now, ex: PrivilegedExceptionAction<> 116-118: wouldn't it be easier to do the following: 116 if (this.pHandler != null) { 117 newOne.pHandler = this.pHandler; 118 } then you don't need the catch block on lines 124-128. --Sean From valerie.peng at oracle.com Tue Sep 22 21:31:25 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 22 Sep 2015 14:31:25 -0700 Subject: RFR 8130648: JCK test api/java_security/AuthProvider/ProviderTests_login starts failing after JDK-7191662 In-Reply-To: <5601BCEA.5060204@oracle.com> References: <55AEDDCA.9010202@oracle.com> <55FCAE63.7030408@oracle.com> <5601BCEA.5060204@oracle.com> Message-ID: <5601C8AD.3070907@oracle.com> Hi, Sean, Thanks for the comments, I have changed to use the <> for line 110. For line 116-118, the difference is in the security check. With the current changes, the new provider will need to be granted |SecurityPermission("authProvider.name")| for the configuration call to complete and return the new provider. Or, one alternative is to not carrying over the callback handler if the particular permission is not granted for the new provider? Not sure if direct assignment/carryover would lead to anything bad, maybe I am being too paranoid... Thanks, Valerie On 9/22/2015 1:41 PM, Sean Mullan wrote: > On 09/18/2015 08:37 PM, Valerie Peng wrote: >> Sean, >> >> I have updated the webrev based on your suggestions and CCC has also >> been filed: >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8130648/webrev.00/ > > SunPKCS11.java > > 110: can use diamond operator for anon classes now, ex: > PrivilegedExceptionAction<> > > 116-118: wouldn't it be easier to do the following: > > 116 if (this.pHandler != null) { > 117 newOne.pHandler = this.pHandler; > 118 } > > then you don't need the catch block on lines 124-128. > > --Sean > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Tue Sep 22 23:30:40 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 22 Sep 2015 16:30:40 -0700 Subject: RFR for JDK-8048604 : Tests for strong crypto ciphers In-Reply-To: <10EA3908-7CB8-43A9-ACA6-F3512F39D75D@oracle.com> References: <55CBD193.5020504@oracle.com> <55F8DEE4.5020404@oracle.com> <55F9EC35.1060400@oracle.com> <10EA3908-7CB8-43A9-ACA6-F3512F39D75D@oracle.com> Message-ID: <5601E4A0.4070805@oracle.com> Hi, Tristan, The updated webrev addressed most of my previous comments except the few that I noted below: - Can u please make sure that all the Cipher objects are retrieved using "SunJCE" provider? At least the AESPBEWrapper.java, CICOSkipTest.java (there may be more as I didn't check all) didn't specify a provider when calling Cipher.getInstance(). - both the proceedSkipTestUsingXXX() methods should check to ensure that "SAVE" number of bytes are read. - line 217 is redundant Thanks, Valerie On 9/21/2015 10:14 AM, Tristan Yan wrote: > Thank you Valerie. Please review the updated version of it > http://cr.openjdk.java.net/~tyan/8048604/webrev.02/ > > > Cheers > Tristan > >> On Sep 16, 2015, at 3:24 PM, Valerie Peng > > wrote: >> >> >> Can u please make sure that all the Cipher objects are retrieved >> using "SunJCE" provider? >> I noticed some inconsistencies here and there. >> >> >> - line 94, 'provider' object should be used here. >> - need @library tag to find the TestUtilities class, otherwise, the >> compilation fails. >> >> >> - variable "model" should be named "mode". >> - nit: rename the class to PBEAlgorithm for consistency. >> >> >> - line 98 has a typo, I think u meant "or" instead of "of" >> >> >> - typo on line51: TANSFORMATION should be TRANSFORMATION >> - line 94, why not just init with mode directly as in other Wrapper >> classes? >> >> >> - line 63, variable name normally starts with lower case. Can u fix >> it for better readability? Same goes for other PBE tests. >> >> >> - the test class description is not very readable and contains a few >> typos. Can u please double check? >> - typo on lin 132 - decript >> - both the proceedSkipTestUsingXXX() methods should check to ensure >> that "SAVE" number of bytes are read. >> >> >> - line 79 doesn't look right at all. The comparison should be made >> against the output written to output stream instead of itself. >> if (!TestUtilities.equalsBlock(plainText, plainText, TEXT_SIZE)) { >> That's all. >> Valerie >> >> On 9/15/2015 8:15 PM, Valerie Peng wrote: >>> >>> Most of the tests are DES, DESede, and Blowfish and they are written >>> in a way which won't work with AES due to the larger block size as >>> the block size 8 is dispersed through out the tests instead of as a >>> constant. >>> At some point, I think we need to enhance these tests to cover AES >>> instead of the legacy algorithms such as DES, DESede, etc. Can u >>> define a constant for the block size and replace 8 with this constant? >>> >>> Some nit - If tests are already placed under CICO directory, their >>> names do not need to contain CICO. >>> Also, maybe u can just place the tests under >>> com/sun/crypto/provider/CICO instead of >>> com/sun/crypto/provider/Cipher/CICO. >>> >>> >>> - if my reading of the code is right, the equalsBlockSave(byte[] b1, >>> byte[]b2, int bLen, int save) method compares b1 and b2 by chopping >>> up b1 into blocks of 'bLen' and b2 into blocks of 'save', and then >>> compare the first 'save' bytes of each block to make sure they are >>> equal. line 59 looks incorrect - the number of blocks should be >>> computed using b1.length instead of b2.length. The term "save" seems >>> confusing too. Maybe "partial" would be more suitable? Or maybe >>> changing "bLen" to "b1Len", and "save" to "b2Len". >>> The description on line 50 could use some more words to explain what >>> this method does without reading through the code. >>> >>> >>> - after line 85, check that there are no further data available >>> after reading "recoveredText". >>> >>> >>> - line 63, "is not exist" should be "does not exist" or "not found". >>> - the comments on line 67-68 and line 77 seems contradictory to each >>> other. Essentially, NoPadding is tested for all modes vs >>> PKCS5Padding is tested for some modes. >>> - the check from line106-110 should be moved up to right after the >>> Cipher.getInstance() calls on line 97 and 98. >>> >>> >>> - line 74, instead of byte[] plainText, I think it's clearer to just >>> have "int inputLen". The content of the input array is not used in >>> any of the enum values, but rather just the length for output buffer >>> allocation. >>> - the variable "ci1" should really be named "ciIn" so that it's >>> clear that this argument is the cipher associated with the >>> CipherInputStream. >>> >>> >>> - line 124, "blockLen" should really be "numOfBlocks". >>> - Will LengthLimitException ever be thrown for this test? Given that >>> you are only using default key length, I doubt the check on line 163 >>> will be true. >>> - line 178-180 seems redundant? I think they can just be removed. >>> - line 184, why is the key length check being done here again inside >>> the same method? This one for sure is useless. >>> - Instead of 2 constructors with comments indicating what ciphers >>> they are for, it's better to just use static factory method. The >>> implementation isn't that different, they both return a pair of >>> ciphers. U can handle the different parameter type and secret key >>> generation using a switch construct based on the specified algorithm >>> 'algo'. >>> - line 217 and 234, 45 should be 'save' >>> >>> >>> - the testPaddingScheme() method doesn't seem too useful as it is >>> testing the PKCS5Padding inside the test class itself. How would >>> this detect any regression in SunJCE provider? I understand that the >>> test may have problem accessing the actual PKCS5Padding class inside >>> the SunJCE provider, but still, copy-n-paste the internal class out >>> into test class is meaningless. This test method and the >>> cut-n-pasted classes should be removed. >>> >>> I will send u comments on PBE ones in a separate email. >>> Thanks, >>> Valerie >>> >>> On 8/12/2015 4:06 PM, Tristan Yan wrote: >>>> Please be free review these new tests for strong crypto ciphers. >>>> >>>> webrev : http://cr.openjdk.java.net/~tyan/8048604/webrev.01/ >>>> bug : https://bugs.openjdk.java.net/browse/JDK-8048604 >>>> >>>> Thank you very much >>>> Tristan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Sep 23 01:45:46 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 23 Sep 2015 09:45:46 +0800 Subject: RFR 8050427 LoginContext tests to cover JDK-4703361 In-Reply-To: <5601787D.6040203@oracle.com> References: <55D17387.7030201@oracle.com> <55D18D5A.7020207@oracle.com> <5601787D.6040203@oracle.com> Message-ID: <5602044A.5040500@oracle.com> OK, the code is much easier to understand now. In some places, there are modern and simple ways to code. For example, in SmartLoginModule.java, 170 // verify the username/password 171 boolean usernameCorrect = false; 172 boolean passwordCorrect = true; 173 if (username.equals(myUsername)) { 174 usernameCorrect = true; 175 } 176 177 if (!usernameCorrect || password.length != 13) { 178 passwordCorrect = false; 179 } 180 181 for (int i = 0; i < password.length; i++) { 182 if (password[i] != myPassword[i]) { 183 passwordCorrect = false; 184 } 185 can be as simple as if (username.equals(myUsername) && Arrays.equals(password, myPassword)) Also, in MyConfiguration.java: 52 AppConfigurationEntry.LoginModuleControlFlag[] flags 53 = new AppConfigurationEntry.LoginModuleControlFlag[2]; 54 flags[0] = optionOrder ? OPTIONAL : REQUIRED; 55 flags[1] = optionOrder ? SUFFICIENT : REQUIRED; 56 ptAE[0] = new AppConfigurationEntry("SmartLoginModule", 57 flags[0], 58 map); 59 ptAE[1] = new AppConfigurationEntry("DummyLoginModule", 60 flags[1], 61 map); It seems unnecessary to introduce the flags variable. Thanks Max On 09/22/2015 11:49 PM, Amanda Jiang wrote: > Hi Max, > > Thanks for your comments ,please check updated webrev and my replies > inline. > webrev: http://cr.openjdk.java.net/~amjiang/8050427/webrev.02/ > > Regards, > Amanda > > On 8/17/15, 12:29 AM, Weijun Wang wrote: >> There are something I don't understand. >> >> MyConfiguration.java: >> >> - optionOrder: Is it possible to make this an argument of the >> constructor? > Fixed, made this an argument of the constructor. >> >> - getConfiguration/setConfiguration: If these are useless, why adding >> these methods? > Removed useless methods. >> >> SmartLoginModule.java: >> >> - initialize: Why don't you use the callbackHandler argument? > See below. >> >> - shouldSucceed: It is always very confusing to make a field >> accessible from outside a class. > Originally the test tried to test with different password , > "shouldSucceed" is used to control which password will be set. > MycallbackHandler is called in initialize( ) method and > "shouldSucceed" is parsed as an argument to control which password would > be set to "PasswdCallback" > > 123 this.callbackHandler = new MyCallbackHandler(myUsername, > myPassword, > 124 shouldSucceed); > > 341 public MyCallbackHandler(String username, char[] password, > boolean action) { > 342 super(); > 343 userName = username; > 344 this.password = password; > 345 this.action = action; > 346 } > > 361 PasswordCallback pc = (PasswordCallback) callback; > 362 if (action) { > 363 pc.setPassword(password); > 364 } else { > 365 pc.setPassword(wrongpd); > 366 } > > I agree with you this may be confusing, so I simplify this test, > "shouldSucceed" value is remove, please check updated webrev. >> >> DynamicConfigurationTest.java: >> >> - test: why the if checks are based on both isNegative and success? >> Why not only on isNegative? If you want to test 2 stages (initialize >> and login), you can provide 2 isNegative flags. > "success" was for controlling correct/wrong passwords, > "isNegative" was for checking if exception is expected. > Tests are re-organized , so I do not use these two flags > now, please check updated webrev. >> >> Thanks >> Max >> >> >> On 08/17/2015 01:39 PM, Amanda Jiang wrote: >>> Hi All, >>> >>> Please be free to review these new tests for Dynamic configuration of >>> authentication modules. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8050427 >>> webrev:http://cr.openjdk.java.net/~amjiang/8050427/webrev.01/ >>> >>> >>> Thanks, >>> Amanda >>> >>> > > > From bradford.wetmore at oracle.com Wed Sep 23 05:04:00 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 22 Sep 2015 22:04:00 -0700 Subject: TLS ALPN Proposal v5 In-Reply-To: References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> Message-ID: <560232C0.40903@oracle.com> > This new proposal still requires that ciphers are sorted in a way that > matches the ApplicationProtocol order. > Would be nice if, along with the HTTP/2 blacklist, there is a HTTP/2 > comparator that sorts ciphers putting the blacklisted ones at the end. Hm...is the sample code at the end of the initial class description insufficient? Adding a comparator seems a little heavyweight in that it could require access to the ciphersuite internals and would add a lot of complexity for this one known use case. When TLSv1.3 is done, the blacklist stuff in HTTP/2 goes away. > I don't like the first parameter of ApplicationProtocol.match() to be > a Map; I personally don't like the Map either, but for situations where we don't have a connection yet (e.g. trying to reduce the set of protocols and/or ciphersuites for setEnabledCiphersuites()), this worked. Xuelei suggested the String->String map for future expansion, making it easier to add new parameters in between major releases if new ALPN protocols are introduced. (For those who aren't aware, adding classes/methods/variables/etc. is pretty much forbidden in update (minor) releases, but simply adding a new string to a Map is generally OK.) > I would prefer a full blown class at this > point, that contains all the parameters, for example: > > inner class ApplicationProtocol.Info > { > tlsProtocol > cipher > sslEngine > sessionIsResuming > etc. > } The other problem here is having a way to get at all the parameters of a connection. Enumerating them all in such a class is essentially duplicating methods that are already currently available in the SSLSession (handshakeSession) + SSLSocket/SSLEngines classes. Any future enhancements to SSLSocket/SSLEngine would have to be added here again in such a class. > I also don't understand why there are 2 methods for the protocol name > ? What value does it bring to have 2 methods for the same thing ? Please see the IANA registry: http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids for RFC 7301: http://www.rfc-editor.org/info/rfc7301 getProtocolName() is the IANA/IETF textual representation of the protocol name (i.e. "Protocol" column), for example "HTTP/1.1", "SPDY/3", and "HTTP/2 over TLS". I suppose toString() could be used instead, but thought it might eventually output additional ALPN value state. I don't have any concrete plans at this point. getNetworkSequence() is the identification sequence for the protocol (i.e. "Identification Sequence" column), and represents the actual byte identifiers that will travel the network in an ALPN extension. 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 ("http/1.1") 0x73 0x70 0x64 0x79 0x2f 0x33 ("spdy/3") 0x68 0x32 ("h2") When client wants to send the extension over the network, it grabs the ApplicationProtocols values from the SSLParameters, then calls getNetworkSequence() on each ApplicationProtocol to obtain the actual opaque ProtocolName(1..2^8-1) to send. Likewise on the server side, we match the incoming active ALPN opaque values with the list of mutually agreeable ALPN values. And of course, send back the final selected value. > RFC 7301 hints that the bytes to send over the network are the UTF-8 > bytes from that string. Intentional, this ApplicationProtocol class and these two contained values eliminate that problem. There is no UTF-8 to network byte conversion needed. The network sequence is hard-coded into the ApplicationProtocol and is used directly as the network bytes. The protocolName string is for user clarity. > There are still a lot of details missing, such as where is the chosen > ALPN value stored In SSLSocket/SSLEngine. If the connection is in the middle of a handshake and you need the handshake value: getHandshakeApplicationProtocol() Once the connection has finished handshaking, you can get the final/active value: getApplicationProtocol() The ALPN value is no longer in SSLSession, since it needs to be per-connection, not per session. > (and how it can be retrieved by the KeyManager, for > example), JSSE makes calls to X509KeyManagers (for SSLSockets) and X509ExtendedKeyManager (for SSLEngines). The chooseServerAlias methods are passed SSLSocket/SSLEngines for the connection being negotiated. As above, SSLSocket/SSLEngine now have: getHandshakeApplicationProtocol(); // if handshaking getApplicationProtocol(); // if not handshaking So if chooseServerAlias is called, we're in the middle of a handshake, and can get the ALPN value thusly: chooseClientAlias(String[] keyType, Principal[] issuers, Socket socket) { ...deleted... ApplicationProtocol alpn = socket.getHandshakeApplicationProtocol(); ...deleted... > as well as the webrev not showing any real implementation, Yes, I'm using pseudo-code at this point, Vinnie has merged the actual code but is waiting on the API. > and how exactly the ApplicationProtocol instances are called, etc. See the test code for typical application examples. The line numbers are for the latest webrev (see below). Look in SSLEngineAlpnHttp2.java: SSLParameter ALPN Configuration: server: line 340-342 client: lines 353-355 Ciphersuite reordering for H2: server: line 330-337/360-387 This is directly from the class description. ALPN client-side verification of server's choice: client: line 272-287 The server check could be added in a similar manner. I also added a SSLSocket test, which is almost identical with the exception of the handshake completion. In SSLEngine, you look for the HANDSHAKE_COMPLETED result. But in SSLSocket, a call to startHandshake() will complete the initial handshake. You then call sslSocket.getApplicationProtocol() and do your verification. If you want, you could also register a HandshakeCompletedListener, but that isn't very useful in this case. > For example, client sends ["h2"], server has ["http/1.1", "h2"]. Will > the instance of ApplicationProtocol corresponding to "http/1.1" be > invoked at all ? No. > If not, there is a missing step in your algorithm above, where the > implementation intersects the ALPN values from both peers. Missing? You mean in this part? Select TLS version for each ciphersuite ...deleted... for each ALPN value Yes, I didn't mention the ALPN value calculation, it's just the intersection as you would expect. That code is in ServerHandshaker.java. 536 // apl = alpn.getPeerAPs() intersection localApl()) { > Finally, I think this API may be suitable for the server, but not much > for the client, which is equally important. Absolutely. The client must know which protocol was negotiated before sending any application data (e.g. H2 vs http/1.1 requests). > I don't see how a client application can figure out what protocol has > been chosen by the server, because there is no final notification > about that and the API seems totally geared towards server "matching" > more than client notification. For me this is a blocker. Please see the above. > Can you please provide an example of how a client application would > use this new API to be notified that the server has chosen protocol > "foo" ? I've updated the webrev to include an SSLSocket test variant, and added a few more comments. http://cr.openjdk.java.net/~wetmore/8051498/webrev.14/ Hopefully things are more clear now. Thanks for your review/comments. Brad From sha.jiang at oracle.com Wed Sep 23 05:21:53 2015 From: sha.jiang at oracle.com (John Jiang) Date: Wed, 23 Sep 2015 13:21:53 +0800 Subject: RFR JDK-8075286: Additional tests for signature algorithm OIDs and transformation string In-Reply-To: <55F368DB.701@oracle.com> References: <55CC58AF.7080608@oracle.com> <55F368DB.701@oracle.com> Message-ID: <560236F1.1050500@oracle.com> Hi Valerie, Thanks for your comments. Please review the updated patch at http://cr.openjdk.java.net/~fyuan/jjiang/8075286/webrev.01/ Best regards, John Jiang On 2015/9/12 7:50, Valerie Peng wrote: > > Mostly are fine, just a few comments: > > 1) the convention is to place the regression tests based on the > provider which they are for, e.g. > SunJCE provider -> com/sun/crypto/provider > SUN provider -> sun/security/provider > SunEC provider -> sun/security/ec > Given that there is not a lot of dependency between these tests, can u > place them into the sub-directories under the dedicated path? > The utility class TestSignatureOidHelper.java into can be placed under > sun/security. > > 2) several tests has "...must be failed", probably should be changed > to "...should fail" > > 3) the variable naming seems confusing, e.g. cipherAlgorithm and > cipherOid both refer to Cipher objects while cipherText refers to > encrypted text. For future development, u may want to name the cipher > variables differently so it's obvious that they represent Cipher objects. > > Thanks, > Valerie > > On 8/13/2015 1:43 AM, Sha Jiang wrote: >> Hi Security developers, >> I have a security test bug >> https://bugs.openjdk.java.net/browse/JDK-8075286, which adds more >> cases for NSA Suite B algorithms in jdk repo. >> Please review this patch at >> http://cr.openjdk.java.net/~fyuan/jjiang/8075286/webrev.00/ >> Every comment is appreciated. >> >> Best Regards, >> John Jiang -------------- next part -------------- An HTML attachment was scrubbed... URL: From simone.bordet at gmail.com Wed Sep 23 09:33:57 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Wed, 23 Sep 2015 11:33:57 +0200 Subject: TLS ALPN Proposal v5 In-Reply-To: <560232C0.40903@oracle.com> References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> Message-ID: Hi, On Wed, Sep 23, 2015 at 7:04 AM, Bradford Wetmore wrote: > >> This new proposal still requires that ciphers are sorted in a way that >> matches the ApplicationProtocol order. >> Would be nice if, along with the HTTP/2 blacklist, there is a HTTP/2 >> comparator that sorts ciphers putting the blacklisted ones at the end. > > Hm...is the sample code at the end of the initial class description > insufficient? Adding a comparator seems a little heavyweight in that it > could require access to the ciphersuite internals and would add a lot of > complexity for this one known use case. When TLSv1.3 is done, the blacklist > stuff in HTTP/2 goes away. Sure, but until TLS 1.3 widely deployed, applications will have to sort the ciphers to put HTTP/2 ones before the blacklisted ones. Providing this comparator is as trivial as providing ApplicationProtocol.HTTP2BLACKLIST, so I thought to mention it. >> I also don't understand why there are 2 methods for the protocol name >> ? What value does it bring to have 2 methods for the same thing ? > > Please see the IANA registry: > > http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids > > for RFC 7301: > > http://www.rfc-editor.org/info/rfc7301 > > getProtocolName() is the IANA/IETF textual representation of the protocol > name (i.e. "Protocol" column), for example "HTTP/1.1", "SPDY/3", and "HTTP/2 > over TLS". I suppose toString() could be used instead, but thought it might > eventually output additional ALPN value state. I don't have any concrete > plans at this point. > > getNetworkSequence() is the identification sequence for the protocol (i.e. > "Identification Sequence" column), and represents the actual byte > identifiers that will travel the network in an ALPN extension. > > 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 ("http/1.1") > 0x73 0x70 0x64 0x79 0x2f 0x33 ("spdy/3") > 0x68 0x32 ("h2") > > When client wants to send the extension over the network, it grabs the > ApplicationProtocols values from the SSLParameters, then calls > getNetworkSequence() on each ApplicationProtocol to obtain the actual opaque > ProtocolName(1..2^8-1) to send. Likewise on the server side, we match the > incoming active ALPN opaque values with the list of mutually agreeable ALPN > values. And of course, send back the final selected value. Sure, but application will have to implement two methods instead of one, and AFAIU the JDK implementation is never calling getProtocolName() since it's just a description for humans. > I've updated the webrev to include an SSLSocket test variant, and added a > few more comments. > > http://cr.openjdk.java.net/~wetmore/8051498/webrev.14/ > > Hopefully things are more clear now. Thanks for your review/comments. I see now, thanks for the pointers ! Indulge me a bit more below on the Map passed as parameter to ApplicationProtocol :) IIUC, by the time we are executing the code that calls ApplicationProtocol.match(), the TLS protocol is already chosen and it's available in SSLSession. When remains is the transient value of cipher that is being chosen. Because we already have modified the API to support the application protocol transient value (by adding SSLEngine.getHandshakeApplicationProtocol()) to be used by KeyManagers, I was wondering if we cannot either: A) add: String SSLEngine.getHandshakeCipherSuite(), to be used by ApplicationProtocol or B) add: Map SSLEngine.getHandshakeParameters() or perhaps: Map SSLParameters.getHandshakeParameters(). 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 tomas at primekey.se Wed Sep 23 15:27:17 2015 From: tomas at primekey.se (Tomas Gustavsson) Date: Wed, 23 Sep 2015 17:27:17 +0200 Subject: Brainpool curves In-Reply-To: <55FAFE23.1030502@oracle.com> References: <84b37f14179b57a34c10d0596b6f7dc0@protonmail.ch> <55FAFE23.1030502@oracle.com> Message-ID: <5602C4D5.8040702@primekey.se> +1 for this. On 2015-09-17 19:53, Sean Mullan wrote: > On 08/19/2015 05:48 PM, Jiri Stary wrote: >> Hello, >> >> do you plan to support brainpool curves for TLS in Java 9 (RFC 7027) ? > > There is no plan to support it in 9. There is an open RFE for supporting > brainpool in JCE: https://bugs.openjdk.java.net/browse/JDK-7007966 but > no specific release has been targeted at this time. > > --Sean > >> >> Regards >> Jiri >> >> Sent from ProtonMail , encrypted email based in >> Switzerland. From tristan.yan at oracle.com Wed Sep 23 16:50:55 2015 From: tristan.yan at oracle.com (Tristan Yan) Date: Wed, 23 Sep 2015 09:50:55 -0700 Subject: RFR for JDK-8048604 : Tests for strong crypto ciphers In-Reply-To: <5601E4A0.4070805@oracle.com> References: <55CBD193.5020504@oracle.com> <55F8DEE4.5020404@oracle.com> <55F9EC35.1060400@oracle.com> <10EA3908-7CB8-43A9-ACA6-F3512F39D75D@oracle.com> <5601E4A0.4070805@oracle.com> Message-ID: Thanks Valerie, I fixed with new version, please review it again. http://cr.openjdk.java.net/~tyan/8048604/webrev.03/ Tristan > On Sep 22, 2015, at 4:30 PM, Valerie Peng wrote: > > Hi, Tristan, > > The updated webrev addressed most of my previous comments except the few that I noted below: > > > - Can u please make sure that all the Cipher objects are retrieved using "SunJCE" provider? At least the AESPBEWrapper.java, CICOSkipTest.java (there may be more as I didn't check all) didn't specify a provider when calling Cipher.getInstance(). > > > - both the proceedSkipTestUsingXXX() methods should check to ensure that "SAVE" number of bytes are read. > > > - line 217 is redundant > > Thanks, > Valerie > > On 9/21/2015 10:14 AM, Tristan Yan wrote: >> >> Thank you Valerie. Please review the updated version of it >> http://cr.openjdk.java.net/~tyan/8048604/webrev.02/ >> >> Cheers >> Tristan >> >>> On Sep 16, 2015, at 3:24 PM, Valerie Peng > wrote: >>> >>> >>> Can u please make sure that all the Cipher objects are retrieved using "SunJCE" provider? >>> I noticed some inconsistencies here and there. >>> >>> >>> - line 94, 'provider' object should be used here. >>> - need @library tag to find the TestUtilities class, otherwise, the compilation fails. >>> >>> >>> - variable "model" should be named "mode". >>> - nit: rename the class to PBEAlgorithm for consistency. >>> >>> >>> - line 98 has a typo, I think u meant "or" instead of "of" >>> >>> >>> - typo on line51: TANSFORMATION should be TRANSFORMATION >>> - line 94, why not just init with mode directly as in other Wrapper classes? >>> >>> >>> - line 63, variable name normally starts with lower case. Can u fix it for better readability? Same goes for other PBE tests. >>> >>> >>> - the test class description is not very readable and contains a few typos. Can u please double check? >>> - typo on lin 132 - decript >>> - both the proceedSkipTestUsingXXX() methods should check to ensure that "SAVE" number of bytes are read. >>> >>> >>> - line 79 doesn't look right at all. The comparison should be made against the output written to output stream instead of itself. >>> if (!TestUtilities.equalsBlock(plainText, plainText, TEXT_SIZE)) { >>> That's all. >>> Valerie >>> >>> On 9/15/2015 8:15 PM, Valerie Peng wrote: >>>> >>>> >>>> Most of the tests are DES, DESede, and Blowfish and they are written in a way which won't work with AES due to the larger block size as the block size 8 is dispersed through out the tests instead of as a constant. >>>> At some point, I think we need to enhance these tests to cover AES instead of the legacy algorithms such as DES, DESede, etc. Can u define a constant for the block size and replace 8 with this constant? >>>> >>>> Some nit - If tests are already placed under CICO directory, their names do not need to contain CICO. >>>> Also, maybe u can just place the tests under com/sun/crypto/provider/CICO instead of com/sun/crypto/provider/Cipher/CICO. >>>> >>>> >>>> - if my reading of the code is right, the equalsBlockSave(byte[] b1, byte[]b2, int bLen, int save) method compares b1 and b2 by chopping up b1 into blocks of 'bLen' and b2 into blocks of 'save', and then compare the first 'save' bytes of each block to make sure they are equal. line 59 looks incorrect - the number of blocks should be computed using b1.length instead of b2.length. The term "save" seems confusing too. Maybe "partial" would be more suitable? Or maybe changing "bLen" to "b1Len", and "save" to "b2Len". >>>> The description on line 50 could use some more words to explain what this method does without reading through the code. >>>> >>>> >>>> - after line 85, check that there are no further data available after reading "recoveredText". >>>> >>>> >>>> - line 63, "is not exist" should be "does not exist" or "not found". >>>> - the comments on line 67-68 and line 77 seems contradictory to each other. Essentially, NoPadding is tested for all modes vs PKCS5Padding is tested for some modes. >>>> - the check from line106-110 should be moved up to right after the Cipher.getInstance() calls on line 97 and 98. >>>> >>>> >>>> - line 74, instead of byte[] plainText, I think it's clearer to just have "int inputLen". The content of the input array is not used in any of the enum values, but rather just the length for output buffer allocation. >>>> - the variable "ci1" should really be named "ciIn" so that it's clear that this argument is the cipher associated with the CipherInputStream. >>>> >>>> >>>> - line 124, "blockLen" should really be "numOfBlocks". >>>> - Will LengthLimitException ever be thrown for this test? Given that you are only using default key length, I doubt the check on line 163 will be true. >>>> - line 178-180 seems redundant? I think they can just be removed. >>>> - line 184, why is the key length check being done here again inside the same method? This one for sure is useless. >>>> - Instead of 2 constructors with comments indicating what ciphers they are for, it's better to just use static factory method. The implementation isn't that different, they both return a pair of ciphers. U can handle the different parameter type and secret key generation using a switch construct based on the specified algorithm 'algo'. >>>> - line 217 and 234, 45 should be 'save' >>>> >>>> >>>> - the testPaddingScheme() method doesn't seem too useful as it is testing the PKCS5Padding inside the test class itself. How would this detect any regression in SunJCE provider? I understand that the test may have problem accessing the actual PKCS5Padding class inside the SunJCE provider, but still, copy-n-paste the internal class out into test class is meaningless. This test method and the cut-n-pasted classes should be removed. >>>> >>>> I will send u comments on PBE ones in a separate email. >>>> Thanks, >>>> Valerie >>>> >>>> On 8/12/2015 4:06 PM, Tristan Yan wrote: >>>>> >>>>> Please be free review these new tests for strong crypto ciphers. >>>>> >>>>> webrev : http://cr.openjdk.java.net/~tyan/8048604/webrev.01/ >>>>> bug : https://bugs.openjdk.java.net/browse/JDK-8048604 >>>>> >>>>> Thank you very much >>>>> Tristan >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Wed Sep 23 17:46:20 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 23 Sep 2015 10:46:20 -0700 Subject: RFR for JDK-8048604 : Tests for strong crypto ciphers In-Reply-To: References: <55CBD193.5020504@oracle.com> <55F8DEE4.5020404@oracle.com> <55F9EC35.1060400@oracle.com> <10EA3908-7CB8-43A9-ACA6-F3512F39D75D@oracle.com> <5601E4A0.4070805@oracle.com> Message-ID: <5602E56C.5000203@oracle.com> The updated webrev looks good. Valerie On 9/23/2015 9:50 AM, Tristan Yan wrote: > Thanks Valerie, I fixed with new version, please review it again. > http://cr.openjdk.java.net/~tyan/8048604/webrev.03/ > > Tristan > >> On Sep 22, 2015, at 4:30 PM, Valerie Peng > > wrote: >> >> Hi, Tristan, >> >> The updated webrev addressed most of my previous comments except the >> few that I noted below: >> >> >> - Can u please make sure that all the Cipher objects are retrieved >> using "SunJCE" provider? At least the AESPBEWrapper.java, >> CICOSkipTest.java (there may be more as I didn't check all) didn't >> specify a provider when calling Cipher.getInstance(). >> >> >> - both the proceedSkipTestUsingXXX() methods should check to ensure >> that "SAVE" number of bytes are read. >> >> >> - line 217 is redundant >> >> Thanks, >> Valerie >> >> On 9/21/2015 10:14 AM, Tristan Yan wrote: >>> Thank you Valerie. Please review the updated version of it >>> http://cr.openjdk.java.net/~tyan/8048604/webrev.02/ >>> >>> >>> Cheers >>> Tristan >>> >>>> On Sep 16, 2015, at 3:24 PM, Valerie Peng >>> > wrote: >>>> >>>> >>>> Can u please make sure that all the Cipher objects are retrieved >>>> using "SunJCE" provider? >>>> I noticed some inconsistencies here and there. >>>> >>>> >>>> - line 94, 'provider' object should be used here. >>>> - need @library tag to find the TestUtilities class, otherwise, the >>>> compilation fails. >>>> >>>> >>>> - variable "model" should be named "mode". >>>> - nit: rename the class to PBEAlgorithm for consistency. >>>> >>>> >>>> - line 98 has a typo, I think u meant "or" instead of "of" >>>> >>>> >>>> - typo on line51: TANSFORMATION should be TRANSFORMATION >>>> - line 94, why not just init with mode directly as in other Wrapper >>>> classes? >>>> >>>> >>>> - line 63, variable name normally starts with lower case. Can u fix >>>> it for better readability? Same goes for other PBE tests. >>>> >>>> >>>> - the test class description is not very readable and contains a >>>> few typos. Can u please double check? >>>> - typo on lin 132 - decript >>>> - both the proceedSkipTestUsingXXX() methods should check to ensure >>>> that "SAVE" number of bytes are read. >>>> >>>> >>>> - line 79 doesn't look right at all. The comparison should be made >>>> against the output written to output stream instead of itself. >>>> if (!TestUtilities.equalsBlock(plainText, plainText, TEXT_SIZE)) { >>>> That's all. >>>> Valerie >>>> >>>> On 9/15/2015 8:15 PM, Valerie Peng wrote: >>>>> >>>>> Most of the tests are DES, DESede, and Blowfish and they are >>>>> written in a way which won't work with AES due to the larger block >>>>> size as the block size 8 is dispersed through out the tests >>>>> instead of as a constant. >>>>> At some point, I think we need to enhance these tests to cover AES >>>>> instead of the legacy algorithms such as DES, DESede, etc. Can u >>>>> define a constant for the block size and replace 8 with this constant? >>>>> >>>>> Some nit - If tests are already placed under CICO directory, their >>>>> names do not need to contain CICO. >>>>> Also, maybe u can just place the tests under >>>>> com/sun/crypto/provider/CICO instead of >>>>> com/sun/crypto/provider/Cipher/CICO. >>>>> >>>>> >>>>> - if my reading of the code is right, the equalsBlockSave(byte[] >>>>> b1, byte[]b2, int bLen, int save) method compares b1 and b2 by >>>>> chopping up b1 into blocks of 'bLen' and b2 into blocks of 'save', >>>>> and then compare the first 'save' bytes of each block to make sure >>>>> they are equal. line 59 looks incorrect - the number of blocks >>>>> should be computed using b1.length instead of b2.length. The term >>>>> "save" seems confusing too. Maybe "partial" would be more >>>>> suitable? Or maybe changing "bLen" to "b1Len", and "save" to "b2Len". >>>>> The description on line 50 could use some more words to explain >>>>> what this method does without reading through the code. >>>>> >>>>> >>>>> - after line 85, check that there are no further data available >>>>> after reading "recoveredText". >>>>> >>>>> >>>>> - line 63, "is not exist" should be "does not exist" or "not found". >>>>> - the comments on line 67-68 and line 77 seems contradictory to >>>>> each other. Essentially, NoPadding is tested for all modes vs >>>>> PKCS5Padding is tested for some modes. >>>>> - the check from line106-110 should be moved up to right after the >>>>> Cipher.getInstance() calls on line 97 and 98. >>>>> >>>>> >>>>> - line 74, instead of byte[] plainText, I think it's clearer to >>>>> just have "int inputLen". The content of the input array is not >>>>> used in any of the enum values, but rather just the length for >>>>> output buffer allocation. >>>>> - the variable "ci1" should really be named "ciIn" so that it's >>>>> clear that this argument is the cipher associated with the >>>>> CipherInputStream. >>>>> >>>>> >>>>> - line 124, "blockLen" should really be "numOfBlocks". >>>>> - Will LengthLimitException ever be thrown for this test? Given >>>>> that you are only using default key length, I doubt the check on >>>>> line 163 will be true. >>>>> - line 178-180 seems redundant? I think they can just be removed. >>>>> - line 184, why is the key length check being done here again >>>>> inside the same method? This one for sure is useless. >>>>> - Instead of 2 constructors with comments indicating what ciphers >>>>> they are for, it's better to just use static factory method. The >>>>> implementation isn't that different, they both return a pair of >>>>> ciphers. U can handle the different parameter type and secret key >>>>> generation using a switch construct based on the specified >>>>> algorithm 'algo'. >>>>> - line 217 and 234, 45 should be 'save' >>>>> >>>>> >>>>> - the testPaddingScheme() method doesn't seem too useful as it is >>>>> testing the PKCS5Padding inside the test class itself. How would >>>>> this detect any regression in SunJCE provider? I understand that >>>>> the test may have problem accessing the actual PKCS5Padding class >>>>> inside the SunJCE provider, but still, copy-n-paste the internal >>>>> class out into test class is meaningless. This test method and the >>>>> cut-n-pasted classes should be removed. >>>>> >>>>> I will send u comments on PBE ones in a separate email. >>>>> Thanks, >>>>> Valerie >>>>> >>>>> On 8/12/2015 4:06 PM, Tristan Yan wrote: >>>>>> Please be free review these new tests for strong crypto ciphers. >>>>>> >>>>>> webrev : http://cr.openjdk.java.net/~tyan/8048604/webrev.01/ >>>>>> bug : https://bugs.openjdk.java.net/browse/JDK-8048604 >>>>>> >>>>>> Thank you very much >>>>>> Tristan >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Wed Sep 23 19:51:39 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 23 Sep 2015 12:51:39 -0700 Subject: RFR JDK-8075286: Additional tests for signature algorithm OIDs and transformation string In-Reply-To: <560236F1.1050500@oracle.com> References: <55CC58AF.7080608@oracle.com> <55F368DB.701@oracle.com> <560236F1.1050500@oracle.com> Message-ID: <560302CB.7030208@oracle.com> Updated webrev looks fine. Thanks, Valerie On 9/22/2015 10:21 PM, John Jiang wrote: > Hi Valerie, > Thanks for your comments. > Please review the updated patch at > http://cr.openjdk.java.net/~fyuan/jjiang/8075286/webrev.01/ > > Best regards, > John Jiang > > On 2015/9/12 7:50, Valerie Peng wrote: >> >> Mostly are fine, just a few comments: >> >> 1) the convention is to place the regression tests based on the >> provider which they are for, e.g. >> SunJCE provider -> com/sun/crypto/provider >> SUN provider -> sun/security/provider >> SunEC provider -> sun/security/ec >> Given that there is not a lot of dependency between these tests, can >> u place them into the sub-directories under the dedicated path? >> The utility class TestSignatureOidHelper.java into can be placed >> under sun/security. >> >> 2) several tests has "...must be failed", probably should be changed >> to "...should fail" >> >> 3) the variable naming seems confusing, e.g. cipherAlgorithm and >> cipherOid both refer to Cipher objects while cipherText refers to >> encrypted text. For future development, u may want to name the cipher >> variables differently so it's obvious that they represent Cipher objects. >> >> Thanks, >> Valerie >> >> On 8/13/2015 1:43 AM, Sha Jiang wrote: >>> Hi Security developers, >>> I have a security test bug >>> https://bugs.openjdk.java.net/browse/JDK-8075286, which adds more >>> cases for NSA Suite B algorithms in jdk repo. >>> Please review this patch at >>> http://cr.openjdk.java.net/~fyuan/jjiang/8075286/webrev.00/ >>> Every comment is appreciated. >>> >>> Best Regards, >>> John Jiang > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Thu Sep 24 01:26:29 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 23 Sep 2015 18:26:29 -0700 Subject: [9] RFR 8137068: Tests added in JDK-8048604 fail to compile Message-ID: <56035145.7000908@oracle.com> Max or Xuelei, Would either of you be able to review this quickly? There are some problems with the test co-location fix that I integrated. Just one-line fix in 2 tests. Webrev: http://cr.openjdk.java.net/~valeriep/8137068/webrev.00/ Thanks, Valerie From xuelei.fan at oracle.com Thu Sep 24 01:36:35 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 24 Sep 2015 09:36:35 +0800 Subject: [9] RFR 8137068: Tests added in JDK-8048604 fail to compile In-Reply-To: <56035145.7000908@oracle.com> References: <56035145.7000908@oracle.com> Message-ID: <560353A3.3030001@oracle.com> Looks fine to me. Xuelei On 9/24/2015 9:26 AM, Valerie Peng wrote: > Max or Xuelei, > > Would either of you be able to review this quickly? There are some > problems with the test co-location fix that I integrated. > Just one-line fix in 2 tests. > > Webrev: http://cr.openjdk.java.net/~valeriep/8137068/webrev.00/ > > Thanks, > Valerie From amanda.jiang at oracle.com Thu Sep 24 02:11:24 2015 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Wed, 23 Sep 2015 19:11:24 -0700 Subject: RFR 8050427 LoginContext tests to cover JDK-4703361 In-Reply-To: <5602044A.5040500@oracle.com> References: <55D17387.7030201@oracle.com> <55D18D5A.7020207@oracle.com> <5601787D.6040203@oracle.com> <5602044A.5040500@oracle.com> Message-ID: <56035BCC.3010307@oracle.com> Hi Max, Thanks for your suggestions! Two places were fixed and I also edited codes a little bit to make test clear. Please check latest webrev: http://cr.openjdk.java.net/~amjiang/8050427/webrev.03/ Thanks, Amanda On 9/22/15, 6:45 PM, Weijun Wang wrote: > OK, the code is much easier to understand now. > > In some places, there are modern and simple ways to code. For example, > in SmartLoginModule.java, > > 170 // verify the username/password > 171 boolean usernameCorrect = false; > 172 boolean passwordCorrect = true; > 173 if (username.equals(myUsername)) { > 174 usernameCorrect = true; > 175 } > 176 > 177 if (!usernameCorrect || password.length != 13) { > 178 passwordCorrect = false; > 179 } > 180 > 181 for (int i = 0; i < password.length; i++) { > 182 if (password[i] != myPassword[i]) { > 183 passwordCorrect = false; > 184 } > 185 > > can be as simple as > > if (username.equals(myUsername) > && Arrays.equals(password, myPassword)) > > Also, in MyConfiguration.java: > > 52 AppConfigurationEntry.LoginModuleControlFlag[] flags > 53 = new > AppConfigurationEntry.LoginModuleControlFlag[2]; > 54 flags[0] = optionOrder ? OPTIONAL : REQUIRED; > 55 flags[1] = optionOrder ? SUFFICIENT : REQUIRED; > 56 ptAE[0] = new AppConfigurationEntry("SmartLoginModule", > 57 flags[0], > 58 map); > 59 ptAE[1] = new AppConfigurationEntry("DummyLoginModule", > 60 flags[1], > 61 map); > > It seems unnecessary to introduce the flags variable. > > Thanks > Max > > On 09/22/2015 11:49 PM, Amanda Jiang wrote: >> Hi Max, >> >> Thanks for your comments ,please check updated webrev and my replies >> inline. >> webrev: http://cr.openjdk.java.net/~amjiang/8050427/webrev.02/ >> >> Regards, >> Amanda >> >> On 8/17/15, 12:29 AM, Weijun Wang wrote: >>> There are something I don't understand. >>> >>> MyConfiguration.java: >>> >>> - optionOrder: Is it possible to make this an argument of the >>> constructor? >> Fixed, made this an argument of the constructor. >>> >>> - getConfiguration/setConfiguration: If these are useless, why adding >>> these methods? >> Removed useless methods. >>> >>> SmartLoginModule.java: >>> >>> - initialize: Why don't you use the callbackHandler argument? >> See below. >>> >>> - shouldSucceed: It is always very confusing to make a field >>> accessible from outside a class. >> Originally the test tried to test with different password , >> "shouldSucceed" is used to control which password will be set. >> MycallbackHandler is called in initialize( ) method and >> "shouldSucceed" is parsed as an argument to control which password would >> be set to "PasswdCallback" >> >> 123 this.callbackHandler = new MyCallbackHandler(myUsername, >> myPassword, >> 124 shouldSucceed); >> >> 341 public MyCallbackHandler(String username, char[] password, >> boolean action) { >> 342 super(); >> 343 userName = username; >> 344 this.password = password; >> 345 this.action = action; >> 346 } >> >> 361 PasswordCallback pc = (PasswordCallback) callback; >> 362 if (action) { >> 363 pc.setPassword(password); >> 364 } else { >> 365 pc.setPassword(wrongpd); >> 366 } >> >> I agree with you this may be confusing, so I simplify this test, >> "shouldSucceed" value is remove, please check updated webrev. >>> >>> DynamicConfigurationTest.java: >>> >>> - test: why the if checks are based on both isNegative and success? >>> Why not only on isNegative? If you want to test 2 stages (initialize >>> and login), you can provide 2 isNegative flags. >> "success" was for controlling correct/wrong passwords, >> "isNegative" was for checking if exception is expected. >> Tests are re-organized , so I do not use these two flags >> now, please check updated webrev. >>> >>> Thanks >>> Max >>> >>> >>> On 08/17/2015 01:39 PM, Amanda Jiang wrote: >>>> Hi All, >>>> >>>> Please be free to review these new tests for Dynamic configuration of >>>> authentication modules. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8050427 >>>> webrev:http://cr.openjdk.java.net/~amjiang/8050427/webrev.01/ >>>> >>>> >>>> Thanks, >>>> Amanda >>>> >>>> >> >> >> From sha.jiang at oracle.com Thu Sep 24 02:15:36 2015 From: sha.jiang at oracle.com (John Jiang) Date: Thu, 24 Sep 2015 10:15:36 +0800 Subject: RFR JDK-8075286: Additional tests for signature algorithm OIDs and transformation string In-Reply-To: <560302CB.7030208@oracle.com> References: <55CC58AF.7080608@oracle.com> <55F368DB.701@oracle.com> <560236F1.1050500@oracle.com> <560302CB.7030208@oracle.com> Message-ID: <56035CC8.8050408@oracle.com> Valerie, Thanks for your review. Best regards, John Jiang On 2015/9/24 3:51, Valerie Peng wrote: > Updated webrev looks fine. > Thanks, > Valerie > > > On 9/22/2015 10:21 PM, John Jiang wrote: >> Hi Valerie, >> Thanks for your comments. >> Please review the updated patch at >> http://cr.openjdk.java.net/~fyuan/jjiang/8075286/webrev.01/ >> >> Best regards, >> John Jiang >> >> On 2015/9/12 7:50, Valerie Peng wrote: >>> >>> Mostly are fine, just a few comments: >>> >>> 1) the convention is to place the regression tests based on the >>> provider which they are for, e.g. >>> SunJCE provider -> com/sun/crypto/provider >>> SUN provider -> sun/security/provider >>> SunEC provider -> sun/security/ec >>> Given that there is not a lot of dependency between these tests, can >>> u place them into the sub-directories under the dedicated path? >>> The utility class TestSignatureOidHelper.java into can be placed >>> under sun/security. >>> >>> 2) several tests has "...must be failed", probably should be changed >>> to "...should fail" >>> >>> 3) the variable naming seems confusing, e.g. cipherAlgorithm and >>> cipherOid both refer to Cipher objects while cipherText refers to >>> encrypted text. For future development, u may want to name the >>> cipher variables differently so it's obvious that they represent >>> Cipher objects. >>> >>> Thanks, >>> Valerie >>> >>> On 8/13/2015 1:43 AM, Sha Jiang wrote: >>>> Hi Security developers, >>>> I have a security test bug >>>> https://bugs.openjdk.java.net/browse/JDK-8075286, which adds more >>>> cases for NSA Suite B algorithms in jdk repo. >>>> Please review this patch at >>>> http://cr.openjdk.java.net/~fyuan/jjiang/8075286/webrev.00/ >>>> Every comment is appreciated. >>>> >>>> Best Regards, >>>> John Jiang >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Sep 24 02:22:47 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 24 Sep 2015 10:22:47 +0800 Subject: RFR 8050427 LoginContext tests to cover JDK-4703361 In-Reply-To: <56035BCC.3010307@oracle.com> References: <55D17387.7030201@oracle.com> <55D18D5A.7020207@oracle.com> <5601787D.6040203@oracle.com> <5602044A.5040500@oracle.com> <56035BCC.3010307@oracle.com> Message-ID: <56035E77.6060506@oracle.com> Looks fine. I'm glad you also fix the trailing whitespaces. Thanks Max On 09/24/2015 10:11 AM, Amanda Jiang wrote: > Hi Max, > > Thanks for your suggestions! Two places were fixed and I also edited > codes a little bit to make test clear. > Please check latest webrev: > http://cr.openjdk.java.net/~amjiang/8050427/webrev.03/ > > Thanks, > Amanda > > On 9/22/15, 6:45 PM, Weijun Wang wrote: >> OK, the code is much easier to understand now. >> >> In some places, there are modern and simple ways to code. For example, >> in SmartLoginModule.java, >> >> 170 // verify the username/password >> 171 boolean usernameCorrect = false; >> 172 boolean passwordCorrect = true; >> 173 if (username.equals(myUsername)) { >> 174 usernameCorrect = true; >> 175 } >> 176 >> 177 if (!usernameCorrect || password.length != 13) { >> 178 passwordCorrect = false; >> 179 } >> 180 >> 181 for (int i = 0; i < password.length; i++) { >> 182 if (password[i] != myPassword[i]) { >> 183 passwordCorrect = false; >> 184 } >> 185 >> >> can be as simple as >> >> if (username.equals(myUsername) >> && Arrays.equals(password, myPassword)) >> >> Also, in MyConfiguration.java: >> >> 52 AppConfigurationEntry.LoginModuleControlFlag[] flags >> 53 = new >> AppConfigurationEntry.LoginModuleControlFlag[2]; >> 54 flags[0] = optionOrder ? OPTIONAL : REQUIRED; >> 55 flags[1] = optionOrder ? SUFFICIENT : REQUIRED; >> 56 ptAE[0] = new AppConfigurationEntry("SmartLoginModule", >> 57 flags[0], >> 58 map); >> 59 ptAE[1] = new AppConfigurationEntry("DummyLoginModule", >> 60 flags[1], >> 61 map); >> >> It seems unnecessary to introduce the flags variable. >> >> Thanks >> Max >> >> On 09/22/2015 11:49 PM, Amanda Jiang wrote: >>> Hi Max, >>> >>> Thanks for your comments ,please check updated webrev and my replies >>> inline. >>> webrev: http://cr.openjdk.java.net/~amjiang/8050427/webrev.02/ >>> >>> Regards, >>> Amanda >>> >>> On 8/17/15, 12:29 AM, Weijun Wang wrote: >>>> There are something I don't understand. >>>> >>>> MyConfiguration.java: >>>> >>>> - optionOrder: Is it possible to make this an argument of the >>>> constructor? >>> Fixed, made this an argument of the constructor. >>>> >>>> - getConfiguration/setConfiguration: If these are useless, why adding >>>> these methods? >>> Removed useless methods. >>>> >>>> SmartLoginModule.java: >>>> >>>> - initialize: Why don't you use the callbackHandler argument? >>> See below. >>>> >>>> - shouldSucceed: It is always very confusing to make a field >>>> accessible from outside a class. >>> Originally the test tried to test with different password , >>> "shouldSucceed" is used to control which password will be set. >>> MycallbackHandler is called in initialize( ) method and >>> "shouldSucceed" is parsed as an argument to control which password would >>> be set to "PasswdCallback" >>> >>> 123 this.callbackHandler = new MyCallbackHandler(myUsername, >>> myPassword, >>> 124 shouldSucceed); >>> >>> 341 public MyCallbackHandler(String username, char[] password, >>> boolean action) { >>> 342 super(); >>> 343 userName = username; >>> 344 this.password = password; >>> 345 this.action = action; >>> 346 } >>> >>> 361 PasswordCallback pc = (PasswordCallback) callback; >>> 362 if (action) { >>> 363 pc.setPassword(password); >>> 364 } else { >>> 365 pc.setPassword(wrongpd); >>> 366 } >>> >>> I agree with you this may be confusing, so I simplify this test, >>> "shouldSucceed" value is remove, please check updated webrev. >>>> >>>> DynamicConfigurationTest.java: >>>> >>>> - test: why the if checks are based on both isNegative and success? >>>> Why not only on isNegative? If you want to test 2 stages (initialize >>>> and login), you can provide 2 isNegative flags. >>> "success" was for controlling correct/wrong passwords, >>> "isNegative" was for checking if exception is expected. >>> Tests are re-organized , so I do not use these two flags >>> now, please check updated webrev. >>>> >>>> Thanks >>>> Max >>>> >>>> >>>> On 08/17/2015 01:39 PM, Amanda Jiang wrote: >>>>> Hi All, >>>>> >>>>> Please be free to review these new tests for Dynamic configuration of >>>>> authentication modules. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8050427 >>>>> webrev:http://cr.openjdk.java.net/~amjiang/8050427/webrev.01/ >>>>> >>>>> >>>>> Thanks, >>>>> Amanda >>>>> >>>>> >>> >>> >>> > From sean.mullan at oracle.com Thu Sep 24 18:24:43 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 24 Sep 2015 14:24:43 -0400 Subject: RFR 8130648: JCK test api/java_security/AuthProvider/ProviderTests_login starts failing after JDK-7191662 In-Reply-To: <5601C8AD.3070907@oracle.com> References: <55AEDDCA.9010202@oracle.com> <55FCAE63.7030408@oracle.com> <5601BCEA.5060204@oracle.com> <5601C8AD.3070907@oracle.com> Message-ID: <56043FEB.5070206@oracle.com> Ok, I see now. I think now that it also makes sense to change setCallbackHandler to throw IllegalStateException if a provider that requires configuration has not been configured. This is because the permission depends on the name of the provider, which (at least in the case of PKCS11) may not be able to be determined until the provider is configured (since it is part of the configuration data). Thus, then you can assume the handler is null and then there is no need to copy it to the new provider object. Also, while you are fixing this, could you add the "authProvider.{ provider name}" permission to the permission table in the SecurityPermission class summary? It looks like that was an oversight and never got documented there. --Sean On 9/22/15 5:31 PM, Valerie Peng wrote: > Hi, Sean, > > Thanks for the comments, I have changed to use the <> for line 110. > For line 116-118, the difference is in the security check. With the > current changes, the new provider will need to be granted > |SecurityPermission("authProvider.name")| for the configuration call to > complete and return the new provider. > > Or, one alternative is to not carrying over the callback handler if the > particular permission is not granted for the new provider? > Not sure if direct assignment/carryover would lead to anything bad, > maybe I am being too paranoid... > > Thanks, > Valerie > > > On 9/22/2015 1:41 PM, Sean Mullan wrote: >> On 09/18/2015 08:37 PM, Valerie Peng wrote: >>> Sean, >>> >>> I have updated the webrev based on your suggestions and CCC has also >>> been filed: >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8130648/webrev.00/ >> >> SunPKCS11.java >> >> 110: can use diamond operator for anon classes now, ex: >> PrivilegedExceptionAction<> > >> >> 116-118: wouldn't it be easier to do the following: >> >> 116 if (this.pHandler != null) { >> 117 newOne.pHandler = this.pHandler; >> 118 } >> >> then you don't need the catch block on lines 124-128. >> >> --Sean >> >> From sean.mullan at oracle.com Thu Sep 24 19:21:07 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 24 Sep 2015 15:21:07 -0400 Subject: RFR 8050402: Tests to check for use of policy files In-Reply-To: <55FC65BB.7010200@oracle.com> References: <55A55FDA.3030606@oracle.com> <55B914F3.1010403@oracle.com> <55FC65BB.7010200@oracle.com> Message-ID: <56044D23.7010304@oracle.com> Hi Amanda, Just a couple more comments. - The @bug tage in ExtensiblePolicyTest.java should be on a separate line. - I'm not sure why some of the static methods in TVPermission need to be synchronized. In particular I see no reason for getMask and getActions to be synchronized. --Sean On 9/18/15 3:27 PM, Amanda Jiang wrote: > Hi Sean, > > Thanks for your comments. > Tests has been updated by your comments. For one test case, which needs > to create and sign a jar file, then add signed jar file to classpatth, > so I create another java file for that test case. Please check new > webrev below and let me know your suggestions. > > webrev: http://cr.openjdk.java.net/~amjiang/8050402/webrev.02/ > > Thanks, > Amanda > > > On 7/29/15, 11:01 AM, Sean Mullan wrote: >> Hi Amanda, >> >> Rather than exec-ing java from within the test, I think it would be >> better if you used jtreg @run options to do that. For example: >> >> @run main/java.security.policy=ExtensiblePolicyTest1.policy >> ExtensiblePolicyTest1 false >> @run main/java.security.policy=ExtensiblePolicyTest2.policy >> ExtensiblePolicyTest1 true >> >> etc.. >> >> I think this would lead to a more robust test and eliminate some >> overhead. >> >> Thanks, >> Sean >> >> On 07/14/2015 03:15 PM, Amanda Jiang wrote: >>> Hi, >>> >>> Please review a new test which checks Policy is extensible with user >>> defined permissions. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8050402 >>> Webrev: http://cr.openjdk.java.net/~amjiang/8050402/webrev.01/ >>> >>> Thanks, >>> Amanda > From mark.reinhold at oracle.com Thu Sep 24 21:20:31 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 24 Sep 2015 14:20:31 -0700 (PDT) Subject: JEP 273: DRBG-Based SecureRandom Implementations Message-ID: <20150924212031.ACFA57A4C9@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/273 - Mark From bradford.wetmore at oracle.com Thu Sep 24 23:45:23 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 24 Sep 2015 16:45:23 -0700 Subject: TLS ALPN Proposal v5 In-Reply-To: References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> Message-ID: <56048B13.10307@oracle.com> On 9/23/2015 2:33 AM, Simone Bordet wrote: > Hi, > > On Wed, Sep 23, 2015 at 7:04 AM, Bradford Wetmore > wrote: >> >>> This new proposal still requires that ciphers are sorted in a way that >>> matches the ApplicationProtocol order. >>> Would be nice if, along with the HTTP/2 blacklist, there is a HTTP/2 >>> comparator that sorts ciphers putting the blacklisted ones at the end. >> >> Hm...is the sample code at the end of the initial class description >> insufficient? Adding a comparator seems a little heavyweight in that it >> could require access to the ciphersuite internals and would add a lot of >> complexity for this one known use case. When TLSv1.3 is done, the blacklist >> stuff in HTTP/2 goes away. > > Sure, but until TLS 1.3 widely deployed, applications will have to > sort the ciphers to put HTTP/2 ones before the blacklisted ones. > Providing this comparator is as trivial as providing > ApplicationProtocol.HTTP2BLACKLIST, so I thought to mention it. I learned something today: Collections/Arrays.sort()/others are stable. (i.e. equal elements will not be reordered as a result of the sort) My expectation of "equals" was .equals(), not return value == 0. I was concerned that such a Comparator might reorder valid H2 suites from what was passed in. Thankfully, that's not the case, so I've added this Comparator. There is a warning now about "consistency with equals()", as the Strings obvioulsy won't be equals() and thus sorted sets/maps just won't work. (See the Comparator pages for further discussion.) >>> I also don't understand why there are 2 methods for the protocol name >>> ? What value does it bring to have 2 methods for the same thing ? >> >> Please see the IANA registry: >> >> http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids >> >> for RFC 7301: >> >> http://www.rfc-editor.org/info/rfc7301 >> >> getProtocolName() is the IANA/IETF textual representation of the protocol >> name (i.e. "Protocol" column), for example "HTTP/1.1", "SPDY/3", and "HTTP/2 >> over TLS". I suppose toString() could be used instead, but thought it might >> eventually output additional ALPN value state. I don't have any concrete >> plans at this point. >> >> getNetworkSequence() is the identification sequence for the protocol (i.e. >> "Identification Sequence" column), and represents the actual byte >> identifiers that will travel the network in an ALPN extension. >> >> 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 ("http/1.1") >> 0x73 0x70 0x64 0x79 0x2f 0x33 ("spdy/3") >> 0x68 0x32 ("h2") >> >> When client wants to send the extension over the network, it grabs the >> ApplicationProtocols values from the SSLParameters, then calls >> getNetworkSequence() on each ApplicationProtocol to obtain the actual opaque >> ProtocolName(1..2^8-1) to send. Likewise on the server side, we match the >> incoming active ALPN opaque values with the list of mutually agreeable ALPN >> values. And of course, send back the final selected value. > > Sure, but application will have to implement two methods instead of > one, and AFAIU the JDK implementation is never calling > getProtocolName() since it's just a description for humans. I think that a textual name will be better than: // Output: javax.net.ssl.ApplicationProtocol$1 at 1b9e1916 System.out.println(ApplicationProtocol.H2); and there's no UTF-8 ambiguity. >> I've updated the webrev to include an SSLSocket test variant, and added a >> few more comments. >> >> http://cr.openjdk.java.net/~wetmore/8051498/webrev.14/ >> >> Hopefully things are more clear now. Thanks for your review/comments. > > I see now, thanks for the pointers ! > > Indulge me a bit more below on the Map passed as parameter to > ApplicationProtocol :) > > IIUC, by the time we are executing the code that calls > ApplicationProtocol.match(), the TLS protocol is already chosen and > it's available in SSLSession. Not necessarily. This could also be called before the connection has even been attempted, say if the client wants to determine if the proposed protocols or protocol/ciphersuites it wants to use are even allowed by an ApplicationProtocol. > When remains is the transient value of cipher that is being chosen. > Because we already have modified the API to support the application > protocol transient value (by adding > SSLEngine.getHandshakeApplicationProtocol()) to be used by > KeyManagers, I was wondering if we cannot either: CipherSuite is more of a Session value, so it should probably be part of the handshakeSSLSession. We could set handshakeSSLSession.getCipherSuite() before calling the ALPN selector, or pass it in as part of the Map. > A) add: String SSLEngine.getHandshakeCipherSuite(), to be used by > ApplicationProtocol That's kind of what we are doing already, but just in the ApplicationProtocol matcher instead so that it doesn't add extra methods to SSLSocket/SSLEngine. And this doesn't really help the pre-connection situation where you want to query/filter out unacceptable values. http://cr.openjdk.java.net/~wetmore/8051498/webrev.15/ 1. New H2BLACKLISTCOMPARATOR 2. Renamed the HTTP2BLACKLIST to H2BLACKLIST Brad From simone.bordet at gmail.com Fri Sep 25 00:03:59 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Fri, 25 Sep 2015 02:03:59 +0200 Subject: TLS ALPN Proposal v5 In-Reply-To: <56048B13.10307@oracle.com> References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> Message-ID: Hi, On Fri, Sep 25, 2015 at 1:45 AM, Bradford Wetmore wrote: > I think that a textual name will be better than: > > // Output: javax.net.ssl.ApplicationProtocol$1 at 1b9e1916 > > System.out.println(ApplicationProtocol.H2); > > and there's no UTF-8 ambiguity. Sure, but then I would just keep getNetworkSequence(), and remove getProtocolName(), since toString() is sufficient. To have to implement getProtocolName(), I see it as a non-strictly-needed burden to developers that implement ApplicationProtocol. I know of companies that want to use ALPN extensively because they use many different communication protocols internally, so it won't be a rare occasion to implement ApplicationProtocol. > http://cr.openjdk.java.net/~wetmore/8051498/webrev.15/ I gather that the Map parameter can't be solved in other ways, right ? 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 Fri Sep 25 01:44:24 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 25 Sep 2015 09:44:24 +0800 Subject: TLS ALPN Proposal v5 In-Reply-To: <56048B13.10307@oracle.com> References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> Message-ID: <5604A6F8.7010100@oracle.com> On 9/25/2015 7:45 AM, Bradford Wetmore wrote: > > On 9/23/2015 2:33 AM, Simone Bordet wrote: >> Hi, >> >> On Wed, Sep 23, 2015 at 7:04 AM, Bradford Wetmore >> wrote: >>> >>>> This new proposal still requires that ciphers are sorted in a way that >>>> matches the ApplicationProtocol order. >>>> Would be nice if, along with the HTTP/2 blacklist, there is a HTTP/2 >>>> comparator that sorts ciphers putting the blacklisted ones at the end. >>> >>> Hm...is the sample code at the end of the initial class description >>> insufficient? Adding a comparator seems a little heavyweight in that it >>> could require access to the ciphersuite internals and would add a lot of >>> complexity for this one known use case. When TLSv1.3 is done, the >>> blacklist >>> stuff in HTTP/2 goes away. >> >> Sure, but until TLS 1.3 widely deployed, applications will have to >> sort the ciphers to put HTTP/2 ones before the blacklisted ones. >> Providing this comparator is as trivial as providing >> ApplicationProtocol.HTTP2BLACKLIST, so I thought to mention it. > > I learned something today: Collections/Arrays.sort()/others are stable. > (i.e. equal elements will not be reordered as a result of the sort) My > expectation of "equals" was .equals(), not return value == 0. > > I was concerned that such a Comparator might reorder valid H2 suites > from what was passed in. Thankfully, that's not the case, so I've added > this Comparator. There is a warning now about "consistency with > equals()", as the Strings obvioulsy won't be equals() and thus sorted > sets/maps just won't work. (See the Comparator pages for further > discussion.) It might be not customers expected behavior to re-order/sort their preference of cipher suites or preference. For example, a client wants to negotiate {HTTP2, HTTP1.1} or {HTTP1.1, HTTP2} and {TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384}. HTTP1.1/TLS_RSA_WITH_AES_128_CBC_SHA should be negotiated per the TLS and HTTP2 specification. If the cipher suites are sorted, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 would be negotiated, this is not what the customer really expected. The customer preference should be respected. I don't think we really need to re-order the cipher suites. Let's consider the following client requests (prefer cipher suite more than application protocol; blacklisted_CS are HTTP2 blacklisted cipher suite): 1. {HTTP2, HTTP1.1} {strong_cipher_site, blacklisted_CS} HTTP2 and strong_cipher_site should be negotiated. Need not to re-order cipher suites. 2. {HTTP1.1, HTTP2} {strong_cipher_site, blacklisted_CS} HTTP1.1 and strong_cipher_site should be negotiated. Need not to re-order cipher suites. 3. {HTTP2, HTTP1.1} {blacklisted_CS, strong_cipher_site} HTTP1.1 and blacklisted_CS should be negotiated. Need not to re-order cipher suites. 4. {HTTP1.1, HTTP2} {blacklisted_CS, strong_cipher_site} HTTP1.1 and blacklisted_CS should be negotiated. Need not to re-order cipher suites. 5. {HTTP2} {strong_cipher_site, blacklisted_CS} HTTP2 and strong_cipher_site should be negotiated. Need not to re-order cipher suites. 6. {HTTP1.1} {strong_cipher_site, blacklisted_CS} HTTP1.1 and strong_cipher_site should be negotiated. Need not to re-order cipher suites. 7. {HTTP2} {blacklisted_CS, strong_cipher_site} blacklisted_CS would be filtered out as it does not appy to HTTP2. Only strong_cipher_site presents in ClientHello message. HTTP2 and strong_cipher_site should be negotiated. Need not to re-order cipher suites. 8. {HTTP1.1} {blacklisted_CS, strong_cipher_site} HTTP1.1 and blacklisted_CS should be negotiated. Need not to re-order cipher suites. One concern may be that, the customer is not intent to negotiate HTTP2 blacklisted cipher suite. The customer just don't know which are the strong cipher suites among many cipher suites. I think we may need a handy tool to order the cipher suites before configuration. // there are a few cipher suites are available String[] cipherSuites = ... // a array of cipher suites. // Q: Don't know the strength of them // A: OK, there is a handy tool cipherSuites = cipherSuiteReorder.sort(cipherSuites); // configure the cipher suites SSLParameters.setCipherSuites(cipherSuites); The order also apply to the normally cipher suites configuration, not only to application protocols. The re-order should be called by customers explicitly. JSSE would better not sort them automatically. I think, the handy sort tool cannot be simply bind to application protocol. For example, HTTP2 has a blacklisted cipher suites. OK, ApplicationProtocol.H2BLACKLISTCOMPARATOR is expected to make the sort. If, in the future, a new application protocol (AP_NEW) has a different blacklist cipher suites, a new ApplicationProtocol.APNEWBLACKLISTCOMPARATOR would be defined. If both {HTTP2, AP_NEW} would be requested, which comparator for the sorting would be used? None of them can sort the cipher suite properly. The comparator design will not work any more. We may need a handy tool for the sorting for stronger cipher suites. But, AFAIU, the tool does not belong to ALPN. Hope it helps. Xuelei From valerie.peng at oracle.com Fri Sep 25 02:28:43 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 24 Sep 2015 19:28:43 -0700 Subject: RFR 8130648: JCK test api/java_security/AuthProvider/ProviderTests_login starts failing after JDK-7191662 In-Reply-To: <56043FEB.5070206@oracle.com> References: <55AEDDCA.9010202@oracle.com> <55FCAE63.7030408@oracle.com> <5601BCEA.5060204@oracle.com> <5601C8AD.3070907@oracle.com> <56043FEB.5070206@oracle.com> Message-ID: <5604B15B.3060500@oracle.com> Sure, the webrev is updated below with your comments and Joe's suggestion of adding a query API for provider configuration. I added a trivial regression test for the uninitialized PKCS11 provider as well. Webrev: http://cr.openjdk.java.net/~valeriep/8130648/webrev.01/ Will update CCC once the webrev review is done. Thanks, Valerie On 9/24/2015 11:24 AM, Sean Mullan wrote: > Ok, I see now. > > I think now that it also makes sense to change setCallbackHandler to > throw IllegalStateException if a provider that requires configuration > has not been configured. This is because the permission depends on the > name of the provider, which (at least in the case of PKCS11) may not > be able to be determined until the provider is configured (since it is > part of the configuration data). Thus, then you can assume the handler > is null and then there is no need to copy it to the new provider object. > > Also, while you are fixing this, could you add the "authProvider.{ > provider name}" permission to the permission table in the > SecurityPermission class summary? It looks like that was an oversight > and never got documented there. > > --Sean > > On 9/22/15 5:31 PM, Valerie Peng wrote: >> Hi, Sean, >> >> Thanks for the comments, I have changed to use the <> for line 110. >> For line 116-118, the difference is in the security check. With the >> current changes, the new provider will need to be granted >> |SecurityPermission("authProvider.name")| for the configuration call to >> complete and return the new provider. >> >> Or, one alternative is to not carrying over the callback handler if the >> particular permission is not granted for the new provider? >> Not sure if direct assignment/carryover would lead to anything bad, >> maybe I am being too paranoid... >> >> Thanks, >> Valerie >> >> >> On 9/22/2015 1:41 PM, Sean Mullan wrote: >>> On 09/18/2015 08:37 PM, Valerie Peng wrote: >>>> Sean, >>>> >>>> I have updated the webrev based on your suggestions and CCC has also >>>> been filed: >>>> >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8130648/webrev.00/ >>> >>> SunPKCS11.java >>> >>> 110: can use diamond operator for anon classes now, ex: >>> PrivilegedExceptionAction<> >> >>> >>> 116-118: wouldn't it be easier to do the following: >>> >>> 116 if (this.pHandler != null) { >>> 117 newOne.pHandler = this.pHandler; >>> 118 } >>> >>> then you don't need the catch block on lines 124-128. >>> >>> --Sean >>> >>> From dblack at atlassian.com Fri Sep 25 02:46:42 2015 From: dblack at atlassian.com (David Black) Date: Fri, 25 Sep 2015 12:46:42 +1000 Subject: The fix for JDK-806769 breaks some ldap usages. Message-ID: As I do not have an account on https://bugs.openjdk.java.net, yes I have submitted a standard oracle java bug report, I thought it might be of interest to those on this mailing list to forward information on how some java ldap users since the JDK-806769 fix may encounter invalid ldaps hostname issues. When an "ldaps" provider url is set in the environment and a custom SocketFactory, which sets the SSLSocket endpoint identification algorithm to "LDAPS", is set in the ldap environment hostname because of the way the fix for JDK-806769 was implemented some clients encounter a CertificateException. This occurs because the code inside the com.sun.jndi.ldap.Connection class createSocket method[0] "prefers" to invoke the socketFactory.createSocket() method instead of socketFactory.createSocket(String host, int port) when a connection timeout is set, which results in the host not being set in the created ssl socket instance. Steps to reproduce: 1. git clone https://bitbucket.org/atlassian/cwd-4444-java-bug-reproducer.git 2. build the code - `cd src/main/java && javac Broken.java Main.java Working.java` 3. run the Main class and provide an ldaps url - `java Main ldaps://example.java:10636` 4. Observe that when the "Broken" SocketFactory is in use a hostname verification error occurs. Workaround: Naturally, one can workaround the Connection class's "preference" for the no argument createSocket method by not having such a method in the SocketFactory set in the ldap environment. Untested potential patch: --- Connection.java.orig 2015-09-25 11:39:26.323117929 +1000 +++ Connection.java 2015-09-25 12:41:04.175068697 +1000 @@ -33,6 +33,7 @@ import java.io.InputStream; import java.net.Socket; import javax.net.ssl.SSLSocket; +import javax.net.ssl.SSLSocketFactory; import javax.naming.CommunicationException; import javax.naming.ServiceUnavailableException; @@ -287,7 +288,40 @@ Method createSocket = null; - if (connectTimeout > 0) { + if (connectTimeout > 0 && socketFactoryClass instanceof SSLSocketFactory) { + + try { + Socket sock = null; + createSocket = socketFactoryClass.getMethod("createSocket", + new Class[]{Socket.class, String.class, + int.class, boolean.class}); + Constructor socketCons = + Socket.class.getConstructor(new Class[]{}); + + Method connect = Socket.class.getMethod("connect", + new Class[]{Class.forName("java.net.SocketAddress"), + int.class}); + Object endpoint = createInetSocketAddress(host, port); + + // unconnected underlying socket + sock = socketCons.newInstance(new Object[]{}); + + if (debug) { + System.err.println("Connection: creating socket with " + + "a timeout"); + } + // connect the underlying socket + connect.invoke(sock, new Object[]{ + endpoint, new Integer(connectTimeout)}); + // connect the ssl socket + socket = createSocket(sock, host, port, true); + + } catch (NoSuchMethodException e) { + // continue + } + } + + if (connectTimeout > 0 && socket == null) { try { createSocket = socketFactoryClass.getMethod("createSocket", [0] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/7d1d5f4d019a/src/share/classes/com/sun/jndi/ldap/Connection.java#l272 -- David Black / Security Engineer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From amanda.jiang at oracle.com Fri Sep 25 05:27:26 2015 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Thu, 24 Sep 2015 22:27:26 -0700 Subject: RFR 8050402: Tests to check for use of policy files In-Reply-To: <56044D23.7010304@oracle.com> References: <55A55FDA.3030606@oracle.com> <55B914F3.1010403@oracle.com> <55FC65BB.7010200@oracle.com> <56044D23.7010304@oracle.com> Message-ID: <5604DB3E.1000008@oracle.com> Hi Sean, Thanks for reviewing this, new comments has been addressed, please check the webrev below: http://cr.openjdk.java.net/~amjiang/8050402/webrev.03/ Thanks, Amanda On 9/24/15, 12:21 PM, Sean Mullan wrote: > Hi Amanda, > > Just a couple more comments. > > - The @bug tage in ExtensiblePolicyTest.java should be on a separate > line. > > - I'm not sure why some of the static methods in TVPermission need to > be synchronized. In particular I see no reason for getMask and > getActions to be synchronized. > > --Sean > > On 9/18/15 3:27 PM, Amanda Jiang wrote: >> Hi Sean, >> >> Thanks for your comments. >> Tests has been updated by your comments. For one test case, which needs >> to create and sign a jar file, then add signed jar file to classpatth, >> so I create another java file for that test case. Please check new >> webrev below and let me know your suggestions. >> >> webrev: http://cr.openjdk.java.net/~amjiang/8050402/webrev.02/ >> >> Thanks, >> Amanda >> >> >> On 7/29/15, 11:01 AM, Sean Mullan wrote: >>> Hi Amanda, >>> >>> Rather than exec-ing java from within the test, I think it would be >>> better if you used jtreg @run options to do that. For example: >>> >>> @run main/java.security.policy=ExtensiblePolicyTest1.policy >>> ExtensiblePolicyTest1 false >>> @run main/java.security.policy=ExtensiblePolicyTest2.policy >>> ExtensiblePolicyTest1 true >>> >>> etc.. >>> >>> I think this would lead to a more robust test and eliminate some >>> overhead. >>> >>> Thanks, >>> Sean >>> >>> On 07/14/2015 03:15 PM, Amanda Jiang wrote: >>>> Hi, >>>> >>>> Please review a new test which checks Policy is extensible with user >>>> defined permissions. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8050402 >>>> Webrev: http://cr.openjdk.java.net/~amjiang/8050402/webrev.01/ >>>> >>>> Thanks, >>>> Amanda >> From sbordet at webtide.com Fri Sep 25 08:11:58 2015 From: sbordet at webtide.com (Simone Bordet) Date: Fri, 25 Sep 2015 10:11:58 +0200 Subject: TLS ALPN Proposal v5 In-Reply-To: <5604A6F8.7010100@oracle.com> References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> Message-ID: Hi, On Fri, Sep 25, 2015 at 3:44 AM, Xuelei Fan wrote: > For example, a client wants to negotiate {HTTP2, HTTP1.1} or {HTTP1.1, > HTTP2} and {TLS_RSA_WITH_AES_128_CBC_SHA, > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384}. > HTTP1.1/TLS_RSA_WITH_AES_128_CBC_SHA should be negotiated per the TLS > and HTTP2 specification. If the cipher suites are sorted, > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 would be negotiated, this is not > what the customer really expected. The customer preference should be > respected. > > I don't think we really need to re-order the cipher suites. "We" as in the OpenJDK implementation *must not* reorder the cipher suites. "We" as in an application that wants to use HTTP/2 *must* reorder the cipher suites. The comparator provided is only a help to the application to perform this reordering. > Let's consider the following client requests (prefer cipher suite more > than application protocol; blacklisted_CS are HTTP2 blacklisted cipher > suite): > > 1. {HTTP2, HTTP1.1} {strong_cipher_site, blacklisted_CS} > HTTP2 and strong_cipher_site should be negotiated. Need not to re-order > cipher suites. > > 2. {HTTP1.1, HTTP2} {strong_cipher_site, blacklisted_CS} > HTTP1.1 and strong_cipher_site should be negotiated. Need not to > re-order cipher suites. > > 3. {HTTP2, HTTP1.1} {blacklisted_CS, strong_cipher_site} > HTTP1.1 and blacklisted_CS should be negotiated. Need not to re-order > cipher suites. Of course you need to re-order in this case. The application has just provided a preference for HTTP/2 in the application protocol list, it actually happens that HTTP/2 could be negotiated because strong ciphers are present, but instead HTTP/1.1 is chosen. > 4. {HTTP1.1, HTTP2} {blacklisted_CS, strong_cipher_site} > HTTP1.1 and blacklisted_CS should be negotiated. Need not to re-order > cipher suites. > > 5. {HTTP2} {strong_cipher_site, blacklisted_CS} > HTTP2 and strong_cipher_site should be negotiated. Need not to re-order > cipher suites. > > 6. {HTTP1.1} {strong_cipher_site, blacklisted_CS} > HTTP1.1 and strong_cipher_site should be negotiated. Need not to > re-order cipher suites. > > 7. {HTTP2} {blacklisted_CS, strong_cipher_site} > blacklisted_CS would be filtered out as it does not appy to HTTP2. Only > strong_cipher_site presents in ClientHello message. > > HTTP2 and strong_cipher_site should be negotiated. Need not to re-order > cipher suites. > > 8. {HTTP1.1} {blacklisted_CS, strong_cipher_site} > HTTP1.1 and blacklisted_CS should be negotiated. Need not to re-order > cipher suites. > > One concern may be that, the customer is not intent to negotiate HTTP2 > blacklisted cipher suite. The customer just don't know which are the > strong cipher suites among many cipher suites. I think we may need a > handy tool to order the cipher suites before configuration. > > // there are a few cipher suites are available > String[] cipherSuites = ... // a array of cipher suites. > > // Q: Don't know the strength of them > // A: OK, there is a handy tool > cipherSuites = cipherSuiteReorder.sort(cipherSuites); Or, with the comparator: cipherSuites = Arrays.sort(cipherSuites, ApplicationProtocol.H2.CIPHER_COMPARATOR); The comparator is the handy tool. > // configure the cipher suites > SSLParameters.setCipherSuites(cipherSuites); > > The order also apply to the normally cipher suites configuration, not > only to application protocols. The re-order should be called by > customers explicitly. JSSE would better not sort them automatically. > > I think, the handy sort tool cannot be simply bind to application > protocol. For example, HTTP2 has a blacklisted cipher suites. OK, > ApplicationProtocol.H2BLACKLISTCOMPARATOR is expected to make the sort. > If, in the future, a new application protocol (AP_NEW) has a different > blacklist cipher suites, a new > ApplicationProtocol.APNEWBLACKLISTCOMPARATOR would be defined. If both > {HTTP2, AP_NEW} would be requested, which comparator for the sorting > would be used? None of them can sort the cipher suite properly. The > comparator design will not work any more. Sure it does. Because you explicitly set a preference in the order of the application protocol, you only sort to favour the best protocol. In case you have [HTTP/2, AP_NEW, HTTP/1.1], then you can simply compose the comparators to sort first with the H2.CIPHER_COMPARATOR, then with AP_NEW.CIPHER_COMPARATOR. cipherSuites = Arrays.sort(cipherSuites, ApplicationProtocol.H2.CIPHER_COMPARATOR.thenComparing(AP_NEW.CIPHER_COMPARATOR)); > We may need a handy tool for the sorting for stronger cipher suites. > But, AFAIU, the tool does not belong to ALPN. Indeed, it belongs to ApplicationProtocol.H2, not to ApplicationProtocol. -- Simone Bordet ---- http://cometd.org http://webtide.com Developer advice, training, services and support from the Jetty & CometD experts. From xuelei.fan at oracle.com Fri Sep 25 09:47:34 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 25 Sep 2015 17:47:34 +0800 Subject: TLS ALPN Proposal v5 In-Reply-To: References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> Message-ID: <56051836.70901@oracle.com> On 9/25/2015 4:11 PM, Simone Bordet wrote: > Hi, > > On Fri, Sep 25, 2015 at 3:44 AM, Xuelei Fan wrote: >> For example, a client wants to negotiate {HTTP2, HTTP1.1} or {HTTP1.1, >> HTTP2} and {TLS_RSA_WITH_AES_128_CBC_SHA, >> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384}. >> HTTP1.1/TLS_RSA_WITH_AES_128_CBC_SHA should be negotiated per the TLS >> and HTTP2 specification. If the cipher suites are sorted, >> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 would be negotiated, this is not >> what the customer really expected. The customer preference should be >> respected. >> >> I don't think we really need to re-order the cipher suites. > > "We" as in the OpenJDK implementation *must not* reorder the cipher suites. Yes. I agree with this point, OpenJDK MUST NOT reorder the cipher suites. > "We" as in an application that wants to use HTTP/2 *must* reorder the > cipher suites. In an application, the cipher suites preference MUST be used properly, but the "reorder" behavior may be not the application expected order. For some reasons, applications (or customers) may want the preference of {TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384}, rather than reordered to {TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_128_CBC_SHA}. Customers preference should be respected, application and OpenJDK MUST NOT reorder the cipher suites. If there are three roles, OpenJDK, application, customers, there are three result: 1. OpenJDK MUST NOT reorder the cipher suites if no application request. 2. Applications MUST NOT reorder the cipher suites if no customer request. 3. Customers can set the cipher suites order according to they requirements. > The comparator provided is only a help to the application to perform > this reordering. > >> Let's consider the following client requests (prefer cipher suite more >> than application protocol; blacklisted_CS are HTTP2 blacklisted cipher >> suite): >> >> 1. {HTTP2, HTTP1.1} {strong_cipher_site, blacklisted_CS} >> HTTP2 and strong_cipher_site should be negotiated. Need not to re-order >> cipher suites. >> >> 2. {HTTP1.1, HTTP2} {strong_cipher_site, blacklisted_CS} >> HTTP1.1 and strong_cipher_site should be negotiated. Need not to >> re-order cipher suites. >> >> 3. {HTTP2, HTTP1.1} {blacklisted_CS, strong_cipher_site} >> HTTP1.1 and blacklisted_CS should be negotiated. Need not to re-order >> cipher suites. > > Of course you need to re-order in this case. > The application has just provided a preference for HTTP/2 in the > application protocol list, it actually happens that HTTP/2 could be > negotiated because strong ciphers are present, but instead HTTP/1.1 is > chosen. > Here is the question to answer, which preference should be respected firstly between cipher suite and application protocol? If application protocol are preferred at first, of course, application preference should be respected at first; otherwise, cipher suite preference should be respected at first. Let's re-write the example, among {application_protocol_1, application_protocol_2} and {cipher_suite_for_AP2, cipher_suite_for_AP1}. If application protocol preference get respected, application_protocol_1/cipher_suite_for_AP1 would be negotiated; If cipher suite preference get respected, application_protocol_2/cipher_suite_for_AP2 should be negotiated. >From my understand, cipher suite preference should be preferred over application protocols. >> 4. {HTTP1.1, HTTP2} {blacklisted_CS, strong_cipher_site} >> HTTP1.1 and blacklisted_CS should be negotiated. Need not to re-order >> cipher suites. >> >> 5. {HTTP2} {strong_cipher_site, blacklisted_CS} >> HTTP2 and strong_cipher_site should be negotiated. Need not to re-order >> cipher suites. >> >> 6. {HTTP1.1} {strong_cipher_site, blacklisted_CS} >> HTTP1.1 and strong_cipher_site should be negotiated. Need not to >> re-order cipher suites. >> >> 7. {HTTP2} {blacklisted_CS, strong_cipher_site} >> blacklisted_CS would be filtered out as it does not appy to HTTP2. Only >> strong_cipher_site presents in ClientHello message. >> >> HTTP2 and strong_cipher_site should be negotiated. Need not to re-order >> cipher suites. >> >> 8. {HTTP1.1} {blacklisted_CS, strong_cipher_site} >> HTTP1.1 and blacklisted_CS should be negotiated. Need not to re-order >> cipher suites. >> >> One concern may be that, the customer is not intent to negotiate HTTP2 >> blacklisted cipher suite. The customer just don't know which are the >> strong cipher suites among many cipher suites. I think we may need a >> handy tool to order the cipher suites before configuration. >> >> // there are a few cipher suites are available >> String[] cipherSuites = ... // a array of cipher suites. >> >> // Q: Don't know the strength of them >> // A: OK, there is a handy tool >> cipherSuites = cipherSuiteReorder.sort(cipherSuites); > > Or, with the comparator: > > cipherSuites = Arrays.sort(cipherSuites, > ApplicationProtocol.H2.CIPHER_COMPARATOR); > > The comparator is the handy tool. > >> // configure the cipher suites >> SSLParameters.setCipherSuites(cipherSuites); >> >> The order also apply to the normally cipher suites configuration, not >> only to application protocols. The re-order should be called by >> customers explicitly. JSSE would better not sort them automatically. >> >> I think, the handy sort tool cannot be simply bind to application >> protocol. For example, HTTP2 has a blacklisted cipher suites. OK, >> ApplicationProtocol.H2BLACKLISTCOMPARATOR is expected to make the sort. >> If, in the future, a new application protocol (AP_NEW) has a different >> blacklist cipher suites, a new >> ApplicationProtocol.APNEWBLACKLISTCOMPARATOR would be defined. If both >> {HTTP2, AP_NEW} would be requested, which comparator for the sorting >> would be used? None of them can sort the cipher suite properly. The >> comparator design will not work any more. > > Sure it does. > > Because you explicitly set a preference in the order of the > application protocol, you only sort to favour the best protocol. > > In case you have [HTTP/2, AP_NEW, HTTP/1.1], then you can simply > compose the comparators to sort first with the H2.CIPHER_COMPARATOR, > then with AP_NEW.CIPHER_COMPARATOR. > > cipherSuites = Arrays.sort(cipherSuites, > ApplicationProtocol.H2.CIPHER_COMPARATOR.thenComparing(AP_NEW.CIPHER_COMPARATOR)); > Let's look at an example. application_protocol_1 prefer cipher_suite_1, and application_protocol_1 prefer cipher_suite_2. The comparator for application_protocol_1 would set the preference as {cipher_suite_1, cipher_suite_2}. and the comparator for application_protocol_2} would set the preference as {cipher_suite_2, cipher_suite_1}. The result to sort 1 and then 2, and the result to sort 2 and then 1 are different. The call sequence to the comparators, and the call to each comparator would result in difference result. That's may be not the expected behavior. I think, application protocol should not impact the cipher suite strength. Stronger cipher suite should be applicable for the application protocol. Otherwise, the application protocol should blacklist the cipher suite. Therefore, personally, I think application may want a handy tool to sort the cipher suite for the strength for general purpose, but not for application protocol. Xuelei From weijun.wang at oracle.com Fri Sep 25 11:31:07 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 25 Sep 2015 19:31:07 +0800 Subject: TLS ALPN Proposal v5 In-Reply-To: <56051836.70901@oracle.com> References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> Message-ID: <5605307B.8030007@oracle.com> New to ALPN and this thread, just my $0.02. On 09/25/2015 05:47 PM, Xuelei Fan wrote: > Here is the question to answer, which preference should be respected > firstly between cipher suite and application protocol? No concrete answer, but I think it's always better to "first respect what the user has configured". If user has explicitly requested {AP1, AP2} but has not configured cipher suites order himself, ALPN preference should be respected first. This might mean that for different ALPN requests the *default* cipher suite order should be different. --Max From sbordet at webtide.com Fri Sep 25 11:42:49 2015 From: sbordet at webtide.com (Simone Bordet) Date: Fri, 25 Sep 2015 13:42:49 +0200 Subject: TLS ALPN Proposal v5 In-Reply-To: <56051836.70901@oracle.com> References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> Message-ID: Hi, On Fri, Sep 25, 2015 at 11:47 AM, Xuelei Fan wrote: > Here is the question to answer, which preference should be respected > firstly between cipher suite and application protocol? If application > protocol are preferred at first, of course, application preference > should be respected at first; otherwise, cipher suite preference should > be respected at first. The answer to this question has been decided when the algorithm has been chosen to be: for each cipher for each application protocol end end All the rest being equal, ciphers dominate application protocol selection. Are you suggesting to change this to: for each application protocol for each cipher end end ? It's in the hands of the role that configures application protocols and ciphers to decide whether it's more important to prefer a protocol or a cipher. Put it in a different way: If the role prefers application protocols, it has to sort the ciphers to influence that. If the role prefers ciphers, it has to sort the ciphers. No matter what, it has to sort the ciphers. > Therefore, personally, I think application may want a handy tool to sort > the cipher suite for the strength for general purpose, but not for > application protocol. Because HTTP/2 would probably be popular given the success of its predecessor, it would be handy to have a HTTP/2 comparator to influence the selection of the HTTP/2 protocol. Nothing forbids to offer a comparator by cipher strength too. -- Simone Bordet ---- http://cometd.org http://webtide.com Developer advice, training, services and support from the Jetty & CometD experts. From ecki at zusammenkunft.net Fri Sep 25 11:54:34 2015 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Fri, 25 Sep 2015 13:54:34 +0200 Subject: TLS ALPN Proposal v5 In-Reply-To: <56051836.70901@oracle.com> References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> Message-ID: <466fb1a5-7515-4ace-a746-108557323a86.maildroid@localhost> Hello, Just want to mention that with explicite http/https URLs users and applications are somewhat used to select the application protocol first. In fact if I have a H2 client I would expect it to try H2 first (especially given the fact that no weak ciphers could be negotiated anyway). So basically cipher order would select if you want strong but fast or very strong but slower crypto for H2. You could only mess that up by prefering blacklisted ciphers. But even then the serrver can still pick H2 and skip all blacklisted preferences, right? Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: Xuelei Fan To: Simone Bordet Cc: OpenJDK Dev list , "net-dev at openjdk.java.net >> OpenJDK Network Dev list" Sent: Fr., 25 Sep. 2015 11:48 Subject: Re: TLS ALPN Proposal v5 On 9/25/2015 4:11 PM, Simone Bordet wrote: > Hi, > > On Fri, Sep 25, 2015 at 3:44 AM, Xuelei Fan wrote: >> For example, a client wants to negotiate {HTTP2, HTTP1.1} or {HTTP1.1, >> HTTP2} and {TLS_RSA_WITH_AES_128_CBC_SHA, >> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384}. >> HTTP1.1/TLS_RSA_WITH_AES_128_CBC_SHA should be negotiated per the TLS >> and HTTP2 specification. If the cipher suites are sorted, >> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 would be negotiated, this is not >> what the customer really expected. The customer preference should be >> respected. >> >> I don't think we really need to re-order the cipher suites. > > "We" as in the OpenJDK implementation *must not* reorder the cipher suites. Yes. I agree with this point, OpenJDK MUST NOT reorder the cipher suites. > "We" as in an application that wants to use HTTP/2 *must* reorder the > cipher suites. In an application, the cipher suites preference MUST be used properly, but the "reorder" behavior may be not the application expected order. For some reasons, applications (or customers) may want the preference of {TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384}, rather than reordered to {TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_128_CBC_SHA}. Customers preference should be respected, application and OpenJDK MUST NOT reorder the cipher suites. If there are three roles, OpenJDK, application, customers, there are three result: 1. OpenJDK MUST NOT reorder the cipher suites if no application request. 2. Applications MUST NOT reorder the cipher suites if no customer request. 3. Customers can set the cipher suites order according to they requirements. > The comparator provided is only a help to the application to perform > this reordering. > >> Let's consider the following client requests (prefer cipher suite more >> than application protocol; blacklisted_CS are HTTP2 blacklisted cipher >> suite): >> >> 1. {HTTP2, HTTP1.1} {strong_cipher_site, blacklisted_CS} >> HTTP2 and strong_cipher_site should be negotiated. Need not to re-order >> cipher suites. >> >> 2. {HTTP1.1, HTTP2} {strong_cipher_site, blacklisted_CS} >> HTTP1.1 and strong_cipher_site should be negotiated. Need not to >> re-order cipher suites. >> >> 3. {HTTP2, HTTP1.1} {blacklisted_CS, strong_cipher_site} >> HTTP1.1 and blacklisted_CS should be negotiated. Need not to re-order >> cipher suites. > > Of course you need to re-order in this case. > The application has just provided a preference for HTTP/2 in the > application protocol list, it actually happens that HTTP/2 could be > negotiated because strong ciphers are present, but instead HTTP/1.1 is > chosen. > Here is the question to answer, which preference should be respected firstly between cipher suite and application protocol? If application protocol are preferred at first, of course, application preference should be respected at first; otherwise, cipher suite preference should be respected at first. Let's re-write the example, among {application_protocol_1, application_protocol_2} and {cipher_suite_for_AP2, cipher_suite_for_AP1}. If application protocol preference get respected, application_protocol_1/cipher_suite_for_AP1 would be negotiated; If cipher suite preference get respected, application_protocol_2/cipher_suite_for_AP2 should be negotiated. >From my understand, cipher suite preference should be preferred over application protocols. >> 4. {HTTP1.1, HTTP2} {blacklisted_CS, strong_cipher_site} >> HTTP1.1 and blacklisted_CS should be negotiated. Need not to re-order >> cipher suites. >> >> 5. {HTTP2} {strong_cipher_site, blacklisted_CS} >> HTTP2 and strong_cipher_site should be negotiated. Need not to re-order >> cipher suites. >> >> 6. {HTTP1.1} {strong_cipher_site, blacklisted_CS} >> HTTP1.1 and strong_cipher_site should be negotiated. Need not to >> re-order cipher suites. >> >> 7. {HTTP2} {blacklisted_CS, strong_cipher_site} >> blacklisted_CS would be filtered out as it does not appy to HTTP2. Only >> strong_cipher_site presents in ClientHello message. >> >> HTTP2 and strong_cipher_site should be negotiated. Need not to re-order >> cipher suites. >> >> 8. {HTTP1.1} {blacklisted_CS, strong_cipher_site} >> HTTP1.1 and blacklisted_CS should be negotiated. Need not to re-order >> cipher suites. >> >> One concern may be that, the customer is not intent to negotiate HTTP2 >> blacklisted cipher suite. The customer just don't know which are the >> strong cipher suites among many cipher suites. I think we may need a >> handy tool to order the cipher suites before configuration. >> >> // there are a few cipher suites are available >> String[] cipherSuites = ... // a array of cipher suites. >> >> // Q: Don't know the strength of them >> // A: OK, there is a handy tool >> cipherSuites = cipherSuiteReorder.sort(cipherSuites); > > Or, with the comparator: > > cipherSuites = Arrays.sort(cipherSuites, > ApplicationProtocol.H2.CIPHER_COMPARATOR); > > The comparator is the handy tool. > >> // configure the cipher suites >> SSLParameters.setCipherSuites(cipherSuites); >> >> The order also apply to the normally cipher suites configuration, not >> only to application protocols. The re-order should be called by >> customers explicitly. JSSE would better not sort them automatically. >> >> I think, the handy sort tool cannot be simply bind to application >> protocol. For example, HTTP2 has a blacklisted cipher suites. OK, >> ApplicationProtocol.H2BLACKLISTCOMPARATOR is expected to make the sort. >> If, in the future, a new application protocol (AP_NEW) has a different >> blacklist cipher suites, a new >> ApplicationProtocol.APNEWBLACKLISTCOMPARATOR would be defined. If both >> {HTTP2, AP_NEW} would be requested, which comparator for the sorting >> would be used? None of them can sort the cipher suite properly. The >> comparator design will not work any more. > > Sure it does. > > Because you explicitly set a preference in the order of the > application protocol, you only sort to favour the best protocol. > > In case you have [HTTP/2, AP_NEW, HTTP/1.1], then you can simply > compose the comparators to sort first with the H2.CIPHER_COMPARATOR, > then with AP_NEW.CIPHER_COMPARATOR. > > cipherSuites = Arrays.sort(cipherSuites, > ApplicationProtocol.H2.CIPHER_COMPARATOR.thenComparing(AP_NEW.CIPHER_COMPARATOR)); > Let's look at an example. application_protocol_1 prefer cipher_suite_1, and application_protocol_1 prefer cipher_suite_2. The comparator for application_protocol_1 would set the preference as {cipher_suite_1, cipher_suite_2}. and the comparator for application_protocol_2} would set the preference as {cipher_suite_2, cipher_suite_1}. The result to sort 1 and then 2, and the result to sort 2 and then 1 are different. The call sequence to the comparators, and the call to each comparator would result in difference result. That's may be not the expected behavior. I think, application protocol should not impact the cipher suite strength. Stronger cipher suite should be applicable for the application protocol. Otherwise, the application protocol should blacklist the cipher suite. Therefore, personally, I think application may want a handy tool to sort the cipher suite for the strength for general purpose, but not for application protocol. Xuelei From simone.bordet at gmail.com Fri Sep 25 12:19:28 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Fri, 25 Sep 2015 14:19:28 +0200 Subject: TLS ALPN Proposal v5 In-Reply-To: <466fb1a5-7515-4ace-a746-108557323a86.maildroid@localhost> References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <466fb1a5-7515-4ace-a746-108557323a86.maildroid@localhost> Message-ID: Hi, On Fri, Sep 25, 2015 at 1:54 PM, wrote: > Hello, > > Just want to mention that with explicite http/https URLs users and applications are somewhat used to select the application protocol first. Well, kind of :) Some time ago, and still now, if you put "https" in a URL, you are actually talking SPDY over TLS. > In fact if I have a H2 client I would expect it to try H2 first (especially given the fact that no weak ciphers could be negotiated anyway). So basically cipher order would select if you want strong but fast or very strong but slower crypto for H2. You could only mess that up by prefering blacklisted ciphers. But even then the serrver can still pick H2 and skip all blacklisted preferences, right? > No. Currently, the server is given a cipher and based on that cipher has to choose the application protocol. It cannot choose the cipher based on the application protocol. -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From xuelei.fan at oracle.com Fri Sep 25 12:26:52 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 25 Sep 2015 20:26:52 +0800 Subject: TLS ALPN Proposal v5 In-Reply-To: References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> Message-ID: <56053D8C.8080109@oracle.com> On 9/25/2015 7:42 PM, Simone Bordet wrote: > Hi, > > On Fri, Sep 25, 2015 at 11:47 AM, Xuelei Fan wrote: >> Here is the question to answer, which preference should be respected >> firstly between cipher suite and application protocol? If application >> protocol are preferred at first, of course, application preference >> should be respected at first; otherwise, cipher suite preference should >> be respected at first. > > The answer to this question has been decided when the algorithm has > been chosen to be: > > for each cipher > for each application protocol > end > end > > All the rest being equal, ciphers dominate application protocol selection. > > Are you suggesting to change this to: > > for each application protocol > for each cipher > end > end > > ? > No, I would prefer the first approach. Good, we are at the same page at this point, I think. > It's in the hands of the role that configures application protocols > and ciphers to decide whether it's more important to prefer a protocol > or a cipher. > > Put it in a different way: > > If the role prefers application protocols, it has to sort the ciphers > to influence that. > If the role prefers ciphers, it has to sort the ciphers. > I did not catch the idea. if the tole prefers ciphers, why still need to sort the ciphers? Sort for what? > No matter what, it has to sort the ciphers. > I did not get your ideas. Who would sort the preferences? and when the preferences should be sorted? Maybe, we are not on the same page, I think. >From the viewpoint of application or library, if an administrator had made his decision about the preference of application protocols and cipher suites, applications and OpenJDK may be better to respect the decision. // the customers' decision //(1) String[] cipherSuites = {....}; // customer preference, sorted. List appProtocols = {...}; // customer preference, sorted. // configure the parameters // (2) // // customer preferences should be respected. sslParameters.setCipherSuites(cipherSuites); sslParameters.setApplicationProtocols(appProtocols); There might be concerns, customers preference may be not right and need to adjusted. Maybe, a re-order tool is needed before (not after) the configuration of the parameters. // the customers' decision // (1) String[] cipherSuites = {....}; // customer preference List appProtocols = {...}; // customer preference + + // reorde the cipher suites // (1.1) + cipherSuites = ... // the actual customer preference + + // reorder application protocols preference + appProtocols = ... // the actual customer preference // configure the parameters // (2) // // customer preferences should be respected. sslParameters.setCipherSuites(cipherSuites); sslParameters.setApplicationProtocols(appProtocols); >> Therefore, personally, I think application may want a handy tool to sort >> the cipher suite for the strength for general purpose, but not for >> application protocol. > > Because HTTP/2 would probably be popular given the success of its > predecessor, it would be handy to have a HTTP/2 comparator to > influence the selection of the HTTP/2 protocol. > > Nothing forbids to offer a comparator by cipher strength too. > I think a general cipher strength comparator is sufficient for HTTP/2 preference too. What do you think? Maybe, need no extra comparator for HTTP2. Extra comparator would make behaviors pretty complicated and hard to get expected, as I described in the previous mail. Xuelei From simone.bordet at gmail.com Fri Sep 25 12:48:18 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Fri, 25 Sep 2015 14:48:18 +0200 Subject: TLS ALPN Proposal v5 In-Reply-To: <56053D8C.8080109@oracle.com> References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <56053D8C.8080109@oracle.com> Message-ID: Hi, On Fri, Sep 25, 2015 at 2:26 PM, Xuelei Fan wrote: > Maybe, we are not on the same page, I think. We are. > I think a general cipher strength comparator is sufficient for HTTP/2 > preference too. What do you think? I don't know if all the blacklisted ciphers are actually lower strength of all the remaining ciphers, nor what is the exact definition of "strength" that you can use in a comparator. But because the HTTP/2 specification bothered to say what's blacklisted, I would just use that. > Maybe, need no extra comparator for HTTP2. Extra comparator would make > behaviors pretty complicated and hard to get expected, as I described in > the previous mail. There is no complication, really. Two comparators would compose, not exclude. For example, let's say that you want to sort by "bit" strength in a way that you want to prefer 128 bits or lower to favor performance, but also do HTTP/2. The H2 comparator will sort the blacklisted at the end. Among the good ones, they all compare == 0 for the H2 comparator. That is where the second comparator will kick in, grep the cipher name for the bits number and sort them accordingly. -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From xuelei.fan at oracle.com Fri Sep 25 13:20:03 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 25 Sep 2015 21:20:03 +0800 Subject: TLS ALPN Proposal v5 In-Reply-To: References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <56053D8C.8080109@oracle.com> Message-ID: <56054A03.3040907@oracle.com> On 9/25/2015 8:48 PM, Simone Bordet wrote: > Hi, > > On Fri, Sep 25, 2015 at 2:26 PM, Xuelei Fan wrote: >> Maybe, we are not on the same page, I think. > > We are. > >> I think a general cipher strength comparator is sufficient for HTTP/2 >> preference too. What do you think? > > I don't know if all the blacklisted ciphers are actually lower > strength of all the remaining ciphers, nor what is the exact > definition of "strength" that you can use in a comparator. > But because the HTTP/2 specification bothered to say what's > blacklisted, I would just use that. > HTTP/2 blacklists them because they are no so strong because of various reasons. The definition of "strength" can be customized by the customers. Therefore, I don't worry too much because of this flexibility. >> Maybe, need no extra comparator for HTTP2. Extra comparator would make >> behaviors pretty complicated and hard to get expected, as I described in >> the previous mail. > > There is no complication, really. Two comparators would compose, not exclude. > For the complication, I posted the comments in previous mail here: ----------------------------- > In case you have [HTTP/2, AP_NEW, HTTP/1.1], then you can simply > compose the comparators to sort first with the H2.CIPHER_COMPARATOR, > then with AP_NEW.CIPHER_COMPARATOR. > > cipherSuites = Arrays.sort(cipherSuites, > ApplicationProtocol.H2.CIPHER_COMPARATOR. > thenComparing(AP_NEW.CIPHER_COMPARATOR)); > Let's look at an example. application_protocol_1 prefer cipher_suite_1, and application_protocol_1 prefer cipher_suite_2. The comparator for application_protocol_1 would set the preference as {cipher_suite_1, cipher_suite_2}. and the comparator for application_protocol_2} would set the preference as {cipher_suite_2, cipher_suite_1}. The result to sort 1 and then 2, and the result to sort 2 and then 1 are different. The call sequence to the comparators, and the call to each comparator would result in difference result. That's may be not the expected behavior. ----------------------------- It's not easy to use application comparator, I think. > For example, let's say that you want to sort by "bit" strength in a > way that you want to prefer 128 bits or lower to favor performance, > but also do HTTP/2. > > The H2 comparator will sort the blacklisted at the end. > Among the good ones, they all compare == 0 for the H2 comparator. > That is where the second comparator will kick in, grep the cipher name > for the bits number and sort them accordingly. > It's flexible to meet the requirement by customer's customization. Maybe, extra comparator is not necessary here. I think the comparator can be a handy tool, but not belong to ALPN. Xuelei From xuelei.fan at oracle.com Fri Sep 25 14:19:34 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 25 Sep 2015 22:19:34 +0800 Subject: TLS ALPN Proposal v5 In-Reply-To: References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> Message-ID: <560557F6.6090107@oracle.com> On 9/25/2015 9:14 PM, Simone Bordet wrote: > On Fri, Sep 25, 2015 at 2:46 PM, David M. Lloyd wrote: >> > Well, SNI already basically works this way, so it's not so great a stretch. > I don't follow ? > SNI has APIs in JDK 8, you don't use SSLExplorer at all. There are two typical cases for SNI and ALPN. One is that the same server is used for difference SNI/ALPN. Another one is that different server is used for different SNI/ALPN. For example, there is a TLS server 101.101.1.1 for delegation. If SNI www.example.com get requested, the delegation server may redirect the connection to 192.168.1.100 (provide the service for www.example.com). If SNI www.another.com get requested, the delegation server may redirect the connection to 192.168.1.101 (provide the service for www.another.com). Similarly, ALPN need to support the case as above. Another example, there is a server 101.101.1.1. If SNI www.example.com get requested, the server would act as the service for www.example.com. If SNI www.another.com get requested, the server would act as the service for www.another.com. Similarly, ALPN also need to support the case as above. Actually, it was a puzzle to me: whether a concrete server can support both HTTP/2 and HTTP/1.1, or not. If HTTP/2 mode of the server does not work, is it OK to fall-over to use HTTP/1.1 mode? I did not get the answer from the HTTP/2 spec. The current design is based on the idea that a concrete server may support both HTTP/2 and HTTP/1.1 at the same time, and fall-over mode is necessary. Otherwise, the API and implementation can be simplified a lot. Xuelei From simone.bordet at gmail.com Fri Sep 25 14:20:40 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Fri, 25 Sep 2015 16:20:40 +0200 Subject: TLS ALPN Proposal v5 In-Reply-To: <56054A03.3040907@oracle.com> References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <56053D8C.8080109@oracle.com> <56054A03.3040907@oracle.com> Message-ID: Hi, On Fri, Sep 25, 2015 at 3:20 PM, Xuelei Fan wrote: > For the complication, I posted the comments in previous mail here: > > ----------------------------- >> In case you have [HTTP/2, AP_NEW, HTTP/1.1], then you can simply >> compose the comparators to sort first with the H2.CIPHER_COMPARATOR, >> then with AP_NEW.CIPHER_COMPARATOR. >> >> cipherSuites = Arrays.sort(cipherSuites, >> ApplicationProtocol.H2.CIPHER_COMPARATOR. >> thenComparing(AP_NEW.CIPHER_COMPARATOR)); >> > Let's look at an example. application_protocol_1 prefer cipher_suite_1, > and application_protocol_1 prefer cipher_suite_2. > > The comparator for application_protocol_1 would set the preference as > {cipher_suite_1, cipher_suite_2}. and the comparator for > application_protocol_2} would set the preference as {cipher_suite_2, > cipher_suite_1}. > > The result to sort 1 and then 2, and the result to sort 2 and then 1 are > different. > > The call sequence to the comparators, and the call to each comparator > would result in difference result. That's may be not the expected behavior. The example is malformed, since it does not specify which ciphers are good for which application protocol, and neither the order of the application protocols. Let me rewrite it: application protocols: [ap1, ap2] ciphers: [c1, c2] ap1 requires c1, does not work with c2 ap2 requires c2, does not work with c1 Now the question is: you have to configure your system, what you want to do ? If you want to favor ap1, then you sort [c1, c2] If you want to favor ap2, then you sort [c2, c1] If you want to favor c1, then you sort [c1, c2] If you want to favor c2, then you sort [c2, c1] If you want to favor ap1 *and* c2, you have to decide what is more important between the two, because you cannot have both. I don't see any problem, really. That the results are different, sure, but they are predictable. When the configuration uses one comparator, it will always be that result, and same for the other comparator. But you configure the comparators in base of what you want to do. -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From sean.mullan at oracle.com Fri Sep 25 14:23:05 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 25 Sep 2015 10:23:05 -0400 Subject: The fix for JDK-806769 breaks some ldap usages. In-Reply-To: References: Message-ID: <560558C9.40804@oracle.com> JDK-806769 doesn't exist, can you double-check what issue you think caused this? Looks like you are missing a digit. Thanks, Sean On 9/24/15 10:46 PM, David Black wrote: > As I do not have an account on https://bugs.openjdk.java.net, yes I have > submitted a standard oracle java bug report, I thought it might be of > interest to those on this mailing list to forward information on how > some java ldap users since the JDK-806769 fix may encounter invalid > ldaps hostname issues. > > When an "ldaps" provider url is set in the environment and a custom > SocketFactory, which sets the SSLSocket endpoint identification > algorithm to "LDAPS", is set in the ldap environment hostname because of > the way the fix for JDK-806769 was implemented some clients encounter a > CertificateException. This occurs because the code inside the > com.sun.jndi.ldap.Connection class createSocket method[0] "prefers" to > invoke the socketFactory.createSocket() method instead of > socketFactory.createSocket(String host, int port) when a connection > timeout is set, which results in the host not being set in the created > ssl socket instance. > > Steps to reproduce: > 1. git clone > https://bitbucket.org/atlassian/cwd-4444-java-bug-reproducer.git > 2. build the code - `cd src/main/java && javac Broken.java Main.java > Working.java` > 3. run the Main class and provide an ldaps url - `java Main > ldaps://example.java:10636` > 4. Observe that when the "Broken" SocketFactory is in use a hostname > verification error occurs. > > Workaround: > Naturally, one can workaround the Connection class's "preference" for > the no argument createSocket method by not having such a method in the > SocketFactory set in the ldap environment. > > > Untested potential patch: > --- Connection.java.orig2015-09-25 11:39:26.323117929 +1000 > +++ Connection.java2015-09-25 12:41:04.175068697 +1000 > @@ -33,6 +33,7 @@ > import java.io.InputStream; > import java.net.Socket; > import javax.net.ssl.SSLSocket; > +import javax.net.ssl.SSLSocketFactory; > import javax.naming.CommunicationException; > import javax.naming.ServiceUnavailableException; > @@ -287,7 +288,40 @@ > Method createSocket = null; > - if (connectTimeout > 0) { > + if (connectTimeout > 0 && socketFactoryClass instanceof > SSLSocketFactory) { > + > + try { > + Socket sock = null; > + createSocket = > socketFactoryClass.getMethod("createSocket", > + new Class[]{Socket.class, String.class, > + int.class, boolean.class}); > + Constructor socketCons = > + Socket.class.getConstructor(new Class[]{}); > + > + Method connect = Socket.class.getMethod("connect", > + new > Class[]{Class.forName("java.net.SocketAddress"), > + int.class}); > + Object endpoint = createInetSocketAddress(host, port); > + > + // unconnected underlying socket > + sock = socketCons.newInstance(new Object[]{}); > + > + if (debug) { > + System.err.println("Connection: creating socket > with " + > + "a timeout"); > + } > + // connect the underlying socket > + connect.invoke(sock, new Object[]{ > + endpoint, new Integer(connectTimeout)}); > + // connect the ssl socket > + socket = createSocket(sock, host, port, true); > + > + } catch (NoSuchMethodException e) { > + // continue > + } > + } > + > + if (connectTimeout > 0 && socket == null) { > try { > createSocket = > socketFactoryClass.getMethod("createSocket", > > > > [0] > http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/7d1d5f4d019a/src/share/classes/com/sun/jndi/ldap/Connection.java#l272 > > -- > David Black / Security Engineer. From simone.bordet at gmail.com Fri Sep 25 14:28:58 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Fri, 25 Sep 2015 16:28:58 +0200 Subject: No subject Message-ID: Hi, On Fri, Sep 25, 2015 at 4:19 PM, Xuelei Fan wrote: > Actually, it was a puzzle to me: whether a concrete server can support > both HTTP/2 and HTTP/1.1, or not. If HTTP/2 mode of the server does not > work, is it OK to fall-over to use HTTP/1.1 mode? I did not get the > answer from the HTTP/2 spec. Yes, there was an answer to Bradford's email: https://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/0160.html. The answer is "yes". -- 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 david.lloyd at redhat.com Fri Sep 25 14:48:28 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 25 Sep 2015 09:48:28 -0500 Subject: TLS ALPN Proposal v5 In-Reply-To: <560557F6.6090107@oracle.com> References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> Message-ID: <56055EBC.9040202@redhat.com> Sorry I didn't get the reply from Simone Bordet - it must have gone to only one of the two lists (which I'm not on). On 9/25/2015 9:14 PM, Simone Bordet wrote: > I don't follow ? > SNI has APIs in JDK 8, you don't use SSLExplorer at all. They're highly limited; you can only tell the socket/engine to accept or reject a connection based on the SNI information. The ability to react to the server name in order to configure other parameters is highly limited, let alone being able to do things like select a different SSLContext altogether, or proxy the connection to another host. > Also, SNI is a client-to-server information only, while with ALPN you > have to reply to the client, so you have to modify the ServerHello. > I don't see how you can do this without support from the JDK via APIs ? Yes, you would have to add a method - *one* method - to SSLSocket/SSLEngine to specify the selected protocol; this would be done during setup before you initiate handshake (which is why you need to explore the Hello packet in the first place). Better to start simple in any event. With this one single method change, we *could* have a 100% effective solution for all use cases. There could be a fancier solution later, when time isn't ticking towards a JDK 9 deadline. > Are you saying that every application has to write its own TLS parser ? Every *server* application, yes, though most users will rely on a security or server library to do this already. Of course we could always add an SSLExplorer-like function to the JSSE API - that would be very nice - but the point of this suggestion is to keep things realistic and get the job *done*. > Would not that be overkill and full of potential security issues if > one does not get the implementation strictly correct ? Nah, you don't have to do much other than look in the hello packet, make a decision, and then hand it off to the SSL context, which would then do a much more rigorous validation. I don't think there's much risk here. > Also, what if the JDK implementation refuses to use the cipher you > chose along with the application protocol, for whatever reason ? Then you'd get an alert, I'd expect. But my point is that it's not the JDK's business to introspect the application protocol! The JDK should only be looking at (TLS) protocol and cipher suite as it does today. It's up to the application protocol to determine if there are unacceptable cipher suites for that protocol. Any other approach is inherently broken! What if I add a new application protocol, and some cipher suites are unacceptable for it? Should I just rely on the JDK for half the time? Definitely not - the protocol implementation *must* be fully responsible for its own security policy. On 09/25/2015 09:19 AM, Xuelei Fan wrote: > There are two typical cases for SNI and ALPN. One is that the same > server is used for difference SNI/ALPN. Another one is that different > server is used for different SNI/ALPN. > > For example, there is a TLS server 101.101.1.1 for delegation. If SNI > www.example.com get requested, the delegation server may redirect the > connection to 192.168.1.100 (provide the service for www.example.com). > If SNI www.another.com get requested, the delegation server may redirect > the connection to 192.168.1.101 (provide the service for www.another.com). > > Similarly, ALPN need to support the case as above. > > Another example, there is a server 101.101.1.1. If SNI www.example.com > get requested, the server would act as the service for www.example.com. > If SNI www.another.com get requested, the server would act as the > service for www.another.com. > > Similarly, ALPN also need to support the case as above. Exactly - you may want or need to choose different SSL contexts, or even forward to another host, based on this information. Relying solely on SNIMatcher (for example) is already not adequate by itself for many use cases. Consider also that we're talking about server side code here: the number of potential users is small! I believe that end users will only indirectly use this mechanism through server frameworks, meaning that only the framework authors are really the direct consumers. -- - DML From xuelei.fan at oracle.com Fri Sep 25 14:51:09 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 25 Sep 2015 22:51:09 +0800 Subject: TLS ALPN Proposal v5 In-Reply-To: References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <56053D8C.8080109@oracle.com> <56054A03.3040907@oracle.com> Message-ID: <56055F5D.7080001@oracle.com> On 9/25/2015 10:20 PM, Simone Bordet wrote: > Hi, > > On Fri, Sep 25, 2015 at 3:20 PM, Xuelei Fan wrote: >> For the complication, I posted the comments in previous mail here: >> >> ----------------------------- >>> In case you have [HTTP/2, AP_NEW, HTTP/1.1], then you can simply >>> compose the comparators to sort first with the H2.CIPHER_COMPARATOR, >>> then with AP_NEW.CIPHER_COMPARATOR. >>> >>> cipherSuites = Arrays.sort(cipherSuites, >>> ApplicationProtocol.H2.CIPHER_COMPARATOR. >>> thenComparing(AP_NEW.CIPHER_COMPARATOR)); >>> >> Let's look at an example. application_protocol_1 prefer cipher_suite_1, >> and application_protocol_1 prefer cipher_suite_2. >> >> The comparator for application_protocol_1 would set the preference as >> {cipher_suite_1, cipher_suite_2}. and the comparator for >> application_protocol_2} would set the preference as {cipher_suite_2, >> cipher_suite_1}. >> >> The result to sort 1 and then 2, and the result to sort 2 and then 1 are >> different. >> >> The call sequence to the comparators, and the call to each comparator >> would result in difference result. That's may be not the expected behavior. > > The example is malformed, since it does not specify which ciphers are > good for which application protocol, and neither the order of the > application protocols. > > Let me rewrite it: > > application protocols: [ap1, ap2] > ciphers: [c1, c2] > > ap1 requires c1, does not work with c2 > ap2 requires c2, does not work with c1 > OK, as make the case more simple. > Now the question is: you have to configure your system, what you want to do ? > > If you want to favor ap1, then you sort [c1, c2] > If you want to favor ap2, then you sort [c2, c1] > If you want to favor c1, then you sort [c1, c2] > If you want to favor c2, then you sort [c2, c1] > > If you want to favor ap1 *and* c2, you have to decide what is more > important between the two, because you cannot have both. > > I don't see any problem, really. > If "you" as the customer, I don't see any problem. If "you" as OpenJDK, the problem is that OpenJDK know nothing about the conditions (if you want to favor ...), and therefore cannot make the decision (sort) internally. I think we should be on the same page: customers can make any sort as they want. SSLParameters.setCipherSuite() and SSLParameters.setAppliationProtocols() can be used for any decision they made. > That the results are different, sure, but they are predictable. > When the configuration uses one comparator, it will always be that > result, and same for the other comparator. > > But you configure the comparators in base of what you want to do. > Need a confirmation. I think you agree that the sort happens before the calls to SSLParameters.setCipherSuite() and SSLParameters.setAppliationProtocols(), right? As the case I commented in previous mail: ---------------- // the customers' decision // (1) String[] cipherSuites = {....}; // customer preference List appProtocols = {...}; // customer preference + + // reorde the cipher suites // (1.1) + cipherSuites = ... // the actual customer preference + + // reorder application protocols preference + appProtocols = ... // the actual customer preference // configure the parameters // (2) // // customer preferences should be respected. sslParameters.setCipherSuites(cipherSuites); sslParameters.setApplicationProtocols(appProtocols); ---------------- Xuelei From xuelei.fan at oracle.com Fri Sep 25 14:52:03 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 25 Sep 2015 22:52:03 +0800 Subject: TLS ALPN Proposal v5 In-Reply-To: References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> Message-ID: <56055F93.80408@oracle.com> CC security-dev. On 9/25/2015 9:14 PM, Simone Bordet wrote: > Hi, > > On Fri, Sep 25, 2015 at 2:46 PM, David M. Lloyd wrote: >> Well, SNI already basically works this way, so it's not so great a stretch. > > I don't follow ? > SNI has APIs in JDK 8, you don't use SSLExplorer at all. > > Also, SNI is a client-to-server information only, while with ALPN you > have to reply to the client, so you have to modify the ServerHello. > I don't see how you can do this without support from the JDK via APIs ? > >> I imagine the client code simply specifying a list of protocols along with >> today's list of cipher suites. >> >> The user-space server side logic would go like this: >> >> * Receive SSL ServerHello >> * Examine the packet for ALPN and SNI information >> * Read the list of cipher suites >> * Evaluate >> * Select an SSLContext based on protocol and/or server name >> * Construct an SSLSocket or SSLEngine as appropriate >> * Set a property on the SSLSocket/SSLEngine to indicate ALPN protocol name >> * (optional) Change/sort the cipher suite list on the SSLSocket/SSLEngine as >> appropriate >> * Resume negotation by passing the ServerHello in to the SSLSocket/SSLEngine >> as initial data >> >> It's not super elegant but it should work just as well as SNI works, and it >> would cover 100% of use cases since the user has complete flexibility to >> make a decision based on any combination of cipher suite selection, protocol >> name, and host name, even potentially with the option to pretend that ALPN >> wasn't recognized. > > Are you saying that every application has to write its own TLS parser ? > Would not that be overkill and full of potential security issues if > one does not get the implementation strictly correct ? > > Also, what if the JDK implementation refuses to use the cipher you > chose along with the application protocol, for whatever reason ? > > Thanks ! > From sean.mullan at oracle.com Fri Sep 25 14:53:57 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 25 Sep 2015 10:53:57 -0400 Subject: RFR 8050402: Tests to check for use of policy files In-Reply-To: <5604DB3E.1000008@oracle.com> References: <55A55FDA.3030606@oracle.com> <55B914F3.1010403@oracle.com> <55FC65BB.7010200@oracle.com> <56044D23.7010304@oracle.com> <5604DB3E.1000008@oracle.com> Message-ID: <56056005.8020500@oracle.com> Looks fine. --Sean On 9/25/15 1:27 AM, Amanda Jiang wrote: > Hi Sean, > > Thanks for reviewing this, new comments has been addressed, please > check the webrev below: > http://cr.openjdk.java.net/~amjiang/8050402/webrev.03/ > > Thanks, > Amanda > > On 9/24/15, 12:21 PM, Sean Mullan wrote: >> Hi Amanda, >> >> Just a couple more comments. >> >> - The @bug tage in ExtensiblePolicyTest.java should be on a separate >> line. >> >> - I'm not sure why some of the static methods in TVPermission need to >> be synchronized. In particular I see no reason for getMask and >> getActions to be synchronized. >> >> --Sean >> >> On 9/18/15 3:27 PM, Amanda Jiang wrote: >>> Hi Sean, >>> >>> Thanks for your comments. >>> Tests has been updated by your comments. For one test case, which needs >>> to create and sign a jar file, then add signed jar file to classpatth, >>> so I create another java file for that test case. Please check new >>> webrev below and let me know your suggestions. >>> >>> webrev: http://cr.openjdk.java.net/~amjiang/8050402/webrev.02/ >>> >>> Thanks, >>> Amanda >>> >>> >>> On 7/29/15, 11:01 AM, Sean Mullan wrote: >>>> Hi Amanda, >>>> >>>> Rather than exec-ing java from within the test, I think it would be >>>> better if you used jtreg @run options to do that. For example: >>>> >>>> @run main/java.security.policy=ExtensiblePolicyTest1.policy >>>> ExtensiblePolicyTest1 false >>>> @run main/java.security.policy=ExtensiblePolicyTest2.policy >>>> ExtensiblePolicyTest1 true >>>> >>>> etc.. >>>> >>>> I think this would lead to a more robust test and eliminate some >>>> overhead. >>>> >>>> Thanks, >>>> Sean >>>> >>>> On 07/14/2015 03:15 PM, Amanda Jiang wrote: >>>>> Hi, >>>>> >>>>> Please review a new test which checks Policy is extensible with user >>>>> defined permissions. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8050402 >>>>> Webrev: http://cr.openjdk.java.net/~amjiang/8050402/webrev.01/ >>>>> >>>>> Thanks, >>>>> Amanda >>> > From david.lloyd at redhat.com Fri Sep 25 15:05:31 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 25 Sep 2015 10:05:31 -0500 Subject: TLS ALPN Proposal v5 In-Reply-To: References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> Message-ID: <560562BB.8040609@redhat.com> On 09/25/2015 06:42 AM, Simone Bordet wrote: > Hi, > > On Fri, Sep 25, 2015 at 11:47 AM, Xuelei Fan wrote: >> Here is the question to answer, which preference should be respected >> firstly between cipher suite and application protocol? If application >> protocol are preferred at first, of course, application preference >> should be respected at first; otherwise, cipher suite preference should >> be respected at first. > > The answer to this question has been decided when the algorithm has > been chosen to be: > > for each cipher > for each application protocol > end > end > > All the rest being equal, ciphers dominate application protocol selection. > > Are you suggesting to change this to: > > for each application protocol > for each cipher > end > end > > ? > > It's in the hands of the role that configures application protocols > and ciphers to decide whether it's more important to prefer a protocol > or a cipher. I agree with this, but... > Put it in a different way: > > If the role prefers application protocols, it has to sort the ciphers > to influence that. > If the role prefers ciphers, it has to sort the ciphers. > > No matter what, it has to sort the ciphers. ...why does sorting even matter? Why should selection not be implemented 100% in user code, based on both the cipher suites list and application protocol, rendering this whole discussion pointless? It's clearly a complex enough process (which is highly protocol-specific) that it seems to me quite unlikely that the JDK can possibly implement this in a way that will work for all use cases. >> Therefore, personally, I think application may want a handy tool to sort >> the cipher suite for the strength for general purpose, but not for >> application protocol. > > Because HTTP/2 would probably be popular given the success of its > predecessor, it would be handy to have a HTTP/2 comparator to > influence the selection of the HTTP/2 protocol. > > Nothing forbids to offer a comparator by cipher strength too. Ugh, why not just let the user decide *if* they want to sort (and filter) ciphers, and if so, they can do it themselves using Arrays.sort() on the ciphers array which already should be more than adequate. In fact, why not just use the SSLExplorer approach and be done with this already? -- - DML From david.lloyd at redhat.com Fri Sep 25 15:05:48 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 25 Sep 2015 10:05:48 -0500 Subject: TLS ALPN Proposal v5 In-Reply-To: References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> Message-ID: <560562CC.2030101@redhat.com> On 09/25/2015 07:29 AM, Simone Bordet wrote: > Hi, > > On Fri, Sep 25, 2015 at 2:15 PM, David M. Lloyd wrote: >> ...why does sorting even matter? Why should selection not be implemented >> 100% in user code, based on both the cipher suites list and application >> protocol, rendering this whole discussion pointless? It's clearly a complex >> enough process (which is highly protocol-specific) that it seems to me quite >> unlikely that the JDK can possibly implement this in a way that will work >> for all use cases. > > Bradford can certainly provide more context here, but the "tuple > selection" approach would have required a (large) rewrite of the > current mechanism, and it was discarded because of resource > constraints. > >> In fact, why not just use the SSLExplorer approach and be done with this >> already? > > You mean this ? > http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/samples/sni/SSLExplorer.java > Can you expand on how such approach would look like ? Seems overkill > to me, and all in the hands of application developers ? Well, SNI already basically works this way, so it's not so great a stretch. I imagine the client code simply specifying a list of protocols along with today's list of cipher suites. The user-space server side logic would go like this: * Receive SSL ServerHello * Examine the packet for ALPN and SNI information * Read the list of cipher suites * Evaluate * Select an SSLContext based on protocol and/or server name * Construct an SSLSocket or SSLEngine as appropriate * Set a property on the SSLSocket/SSLEngine to indicate ALPN protocol name * (optional) Change/sort the cipher suite list on the SSLSocket/SSLEngine as appropriate * Resume negotation by passing the ServerHello in to the SSLSocket/SSLEngine as initial data It's not super elegant but it should work just as well as SNI works, and it would cover 100% of use cases since the user has complete flexibility to make a decision based on any combination of cipher suite selection, protocol name, and host name, even potentially with the option to pretend that ALPN wasn't recognized. -- - DML From xuelei.fan at oracle.com Fri Sep 25 15:08:34 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 25 Sep 2015 23:08:34 +0800 Subject: whether a concrete server can support,both HTTP/2 and HTTP/1.1, or not? In-Reply-To: References: Message-ID: <56056372.9080808@oracle.com> On 9/25/2015 10:28 PM, Simone Bordet wrote: > Hi, > > On Fri, Sep 25, 2015 at 4:19 PM, Xuelei Fan wrote: >> Actually, it was a puzzle to me: whether a concrete server can support >> both HTTP/2 and HTTP/1.1, or not. If HTTP/2 mode of the server does not >> work, is it OK to fall-over to use HTTP/1.1 mode? I did not get the >> answer from the HTTP/2 spec. > > Yes, there was an answer to Bradford's email: > https://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/0160.html. > The answer is "yes". > Thanks! It would be nice to document the specification officially that HTTP2 can be fail-over to HTTP 1.1 (HTTP protocol version negotiation). Xuelei From simone.bordet at gmail.com Fri Sep 25 15:13:46 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Fri, 25 Sep 2015 17:13:46 +0200 Subject: TLS ALPN Proposal v5 In-Reply-To: <56055EBC.9040202@redhat.com> References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> <56055EBC.9040202@redhat.com> Message-ID: Hi, On Fri, Sep 25, 2015 at 4:48 PM, David M. Lloyd wrote: > Yes, you would have to add a method - *one* method - to SSLSocket/SSLEngine > to specify the selected protocol; this would be done during setup before you > initiate handshake (which is why you need to explore the Hello packet in the > first place). You also need to add another method to specify the cipher suite that goes along with the application protocol. We have already discussed this approach: it's the "tuple" approach where the application is given the list of TLS protocols, the list of ciphers, the list of application protocols, the list of aliases and decides what is the right tuple, and return that to the JDK. >> Also, what if the JDK implementation refuses to use the cipher you >> chose along with the application protocol, for whatever reason ? > > Then you'd get an alert, I'd expect. That would be wrong, because you could actually speak another protocol. > But my point is that it's not the > JDK's business to introspect the application protocol! The JDK should only > be looking at (TLS) protocol and cipher suite as it does today. It's up to > the application protocol to determine if there are unacceptable cipher > suites for that protocol. Any other approach is inherently broken! What if > I add a new application protocol, and some cipher suites are unacceptable > for it? Should I just rely on the JDK for half the time? Definitely not - > the protocol implementation *must* be fully responsible for its own security > policy. I don't understand where you got the impression that the JDK has to inspect the application protocol. We are discussing an API exposed by the JDK to applications, exactly because the application decides whether to accept or not the combination of application protocol, cipher, etc. -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From sean.mullan at oracle.com Fri Sep 25 15:44:38 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 25 Sep 2015 11:44:38 -0400 Subject: RFR 8130648: JCK test api/java_security/AuthProvider/ProviderTests_login starts failing after JDK-7191662 In-Reply-To: <5604B15B.3060500@oracle.com> References: <55AEDDCA.9010202@oracle.com> <55FCAE63.7030408@oracle.com> <5601BCEA.5060204@oracle.com> <5601C8AD.3070907@oracle.com> <56043FEB.5070206@oracle.com> <5604B15B.3060500@oracle.com> Message-ID: <56056BE6.4050908@oracle.com> SecurityPermission: Change "login, logout" to "login and logout" All files: Use "@since 9" instead of "1.9" Looks good otherwise. --Sean On 9/24/15 10:28 PM, Valerie Peng wrote: > > Sure, the webrev is updated below with your comments and Joe's > suggestion of adding a query API for provider configuration. > I added a trivial regression test for the uninitialized PKCS11 provider > as well. > > Webrev: http://cr.openjdk.java.net/~valeriep/8130648/webrev.01/ > > Will update CCC once the webrev review is done. > Thanks, > Valerie > > On 9/24/2015 11:24 AM, Sean Mullan wrote: >> Ok, I see now. >> >> I think now that it also makes sense to change setCallbackHandler to >> throw IllegalStateException if a provider that requires configuration >> has not been configured. This is because the permission depends on the >> name of the provider, which (at least in the case of PKCS11) may not >> be able to be determined until the provider is configured (since it is >> part of the configuration data). Thus, then you can assume the handler >> is null and then there is no need to copy it to the new provider object. >> >> Also, while you are fixing this, could you add the "authProvider.{ >> provider name}" permission to the permission table in the >> SecurityPermission class summary? It looks like that was an oversight >> and never got documented there. >> >> --Sean >> >> On 9/22/15 5:31 PM, Valerie Peng wrote: >>> Hi, Sean, >>> >>> Thanks for the comments, I have changed to use the <> for line 110. >>> For line 116-118, the difference is in the security check. With the >>> current changes, the new provider will need to be granted >>> |SecurityPermission("authProvider.name")| for the configuration call to >>> complete and return the new provider. >>> >>> Or, one alternative is to not carrying over the callback handler if the >>> particular permission is not granted for the new provider? >>> Not sure if direct assignment/carryover would lead to anything bad, >>> maybe I am being too paranoid... >>> >>> Thanks, >>> Valerie >>> >>> >>> On 9/22/2015 1:41 PM, Sean Mullan wrote: >>>> On 09/18/2015 08:37 PM, Valerie Peng wrote: >>>>> Sean, >>>>> >>>>> I have updated the webrev based on your suggestions and CCC has also >>>>> been filed: >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8130648/webrev.00/ >>>> >>>> SunPKCS11.java >>>> >>>> 110: can use diamond operator for anon classes now, ex: >>>> PrivilegedExceptionAction<> >>> >>>> >>>> 116-118: wouldn't it be easier to do the following: >>>> >>>> 116 if (this.pHandler != null) { >>>> 117 newOne.pHandler = this.pHandler; >>>> 118 } >>>> >>>> then you don't need the catch block on lines 124-128. >>>> >>>> --Sean >>>> >>>> From david.lloyd at redhat.com Fri Sep 25 15:23:07 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 25 Sep 2015 10:23:07 -0500 Subject: TLS ALPN Proposal v5 In-Reply-To: References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> <56055EBC.9040202@redhat.com> Message-ID: <560566DB.20805@redhat.com> On 09/25/2015 10:13 AM, Simone Bordet wrote: > Hi, > > On Fri, Sep 25, 2015 at 4:48 PM, David M. Lloyd wrote: >> Yes, you would have to add a method - *one* method - to SSLSocket/SSLEngine >> to specify the selected protocol; this would be done during setup before you >> initiate handshake (which is why you need to explore the Hello packet in the >> first place). > > You also need to add another method to specify the cipher suite that > goes along with the application protocol. No you wouldn't, because there already is a method for that: setEnabledCipherSuites(). You can only send one protocol back in the response, so there's nothing else to do. Matching suites to protocols is the responsibility of the application protocol developer and must be done before handshake. > We have already discussed this approach: it's the "tuple" approach > where the application is given the list of TLS protocols, the list of > ciphers, the list of application protocols, the list of aliases and > decides what is the right tuple, and return that to the JDK. > >>> Also, what if the JDK implementation refuses to use the cipher you >>> chose along with the application protocol, for whatever reason ? >> >> Then you'd get an alert, I'd expect. > > That would be wrong, because you could actually speak another protocol. If you could, then the server would have chosen another protocol before handshake even begins. >> But my point is that it's not the >> JDK's business to introspect the application protocol! The JDK should only >> be looking at (TLS) protocol and cipher suite as it does today. It's up to >> the application protocol to determine if there are unacceptable cipher >> suites for that protocol. Any other approach is inherently broken! What if >> I add a new application protocol, and some cipher suites are unacceptable >> for it? Should I just rely on the JDK for half the time? Definitely not - >> the protocol implementation *must* be fully responsible for its own security >> policy. > > I don't understand where you got the impression that the JDK has to > inspect the application protocol. > > We are discussing an API exposed by the JDK to applications, exactly > because the application decides whether to accept or not the > combination of application protocol, cipher, etc. Yes, but doing so by SSLContext is already too late in many cases. Trying to make a hook into handshaking is the wrong way of looking at this. The user needs to make decisions *before* handshaking is even initiated on the server. -- - DML From simone.bordet at gmail.com Fri Sep 25 16:37:25 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Fri, 25 Sep 2015 18:37:25 +0200 Subject: TLS ALPN Proposal v5 In-Reply-To: <560566DB.20805@redhat.com> References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> <56055EBC.9040202@redhat.com> <560566DB.20805@redhat.com> Message-ID: David, sorry, but I don't understand your proposal. Can you please write it down in pseudo code what a server application should do and what the JDK should do to negotiate HTTP/2 with a client ? I don't see how it is even possible for a user to decide anything *before* the handshaking is even initiated, like you say. It obviously does not have enough information. This is the current algorithm (A=app code, J=JDK code): A: sslParameters.setApplicationProtocols(H2, H1); A: (optional, only needed for H2) sort ciphers to favor H2 A: start handshake J: receive ClientHello J: ciphers = intersect client/server ciphers J: aps = intersect client/server application protocols J: for each cipher in ciphers J: for each ap in aps J: if (ap.matches(cipher & other info)) break J end // aps [A: ap.matches() calls into application code to return whether ap is good for the given info] J: if (ap was not selected) continue; // to next cipher J: if (trySetCipherSuite(cipher)) break; // success J: end // ciphers J: send ServerHello J: terminate handshake A: sslEngine/sslSocket.getApplicationProtocol() Note that the JDK provides default implementations for H1 and H2 for ap.matches(), but in general these will be implemented by application code. For an application that wants to support H2, this boils down to the first 2 lines, the rest is in the JDK. 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 david.lloyd at redhat.com Fri Sep 25 16:49:41 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 25 Sep 2015 11:49:41 -0500 Subject: TLS ALPN Proposal v5 In-Reply-To: References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> <56055EBC.9040202@redhat.com> <560566DB.20805@redhat.com> Message-ID: <56057B25.4070103@redhat.com> On 09/25/2015 11:37 AM, Simone Bordet wrote: > David, > > sorry, but I don't understand your proposal. > > Can you please write it down in pseudo code what a server application > should do and what the JDK should do to negotiate HTTP/2 with a client > ? Sure. A: receive raw SSL packet on Socket or SocketChannel A: examine SSL ClientHello, extract SNI, ALPN, cipher suite info A: use whatever algorithm(s) you want to analyze SNI/ALPN/cipher suite info A: either proxy the connection, or obtain or create the relevant SSLContext from the desired provider A: construct server-side SSLSocket/SSLEngine from SSLContext A: setApplicationProtocol(H2) A: setEnabledCipherSuites(only allowed suites in desired order) A: start handshake J: receive ClientHello (buffered from A) J: verify SNI is matched, fail otherwise (as today) J: verify ALPN is matched, fail otherwise (new) J: send ServerHello (with the single, user-selected protocol) ... This is very simple from the JDK perspective, and also much more flexible. > I don't see how it is even possible for a user to decide anything > *before* the handshaking is even initiated, like you say. > It obviously does not have enough information. It has the ClientHello, which should be more than enough. > This is the current algorithm (A=app code, J=JDK code): > > A: sslParameters.setApplicationProtocols(H2, H1); > A: (optional, only needed for H2) sort ciphers to favor H2 > A: start handshake > J: receive ClientHello > J: ciphers = intersect client/server ciphers > J: aps = intersect client/server application protocols > J: for each cipher in ciphers > J: for each ap in aps > J: if (ap.matches(cipher & other info)) break > J end // aps > [A: ap.matches() calls into application code to return whether ap is > good for the given info] > J: if (ap was not selected) continue; // to next cipher > J: if (trySetCipherSuite(cipher)) break; // success > J: end // ciphers > J: send ServerHello > J: terminate handshake > A: sslEngine/sslSocket.getApplicationProtocol() So complex! What if this algorithm is not adequate for new protocols? Is there not a danger associated with assuming HTTP/2 is your only use case? What if the application wants to make a decision that this scheme cannot support? > Note that the JDK provides default implementations for H1 and H2 for > ap.matches(), but in general these will be implemented by application > code. > > For an application that wants to support H2, this boils down to the > first 2 lines, the rest is in the JDK. -- - DML From simone.bordet at gmail.com Fri Sep 25 17:13:53 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Fri, 25 Sep 2015 19:13:53 +0200 Subject: TLS ALPN Proposal v5 In-Reply-To: <56057B25.4070103@redhat.com> References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> <56055EBC.9040202@redhat.com> <560566DB.20805@redhat.com> <56057B25.4070103@redhat.com> Message-ID: Hi, On Fri, Sep 25, 2015 at 6:49 PM, David M. Lloyd wrote: > A: receive raw SSL packet on Socket or SocketChannel > A: examine SSL ClientHello, extract SNI, ALPN, cipher suite info This requires the application to write a TLS parser. This is currently not necessary, nor provided. You think this could be provided via a JDK utility class ? And if so, how can it be extended in the future when more TLS Extensions are defined ? > A: use whatever algorithm(s) you want to analyze SNI/ALPN/cipher suite info The application must intersect the ciphers, application protocols... perhaps again this can be done by some JDK utility class. > A: either proxy the connection, or obtain or create the relevant SSLContext > from the desired provider > A: construct server-side SSLSocket/SSLEngine from SSLContext > A: setApplicationProtocol(H2) > A: setEnabledCipherSuites(only allowed suites in desired order) > A: start handshake > J: receive ClientHello (buffered from A) > J: verify SNI is matched, fail otherwise (as today) > J: verify ALPN is matched, fail otherwise (new) There is a missing step here which is to verify the cipher (trySetCipherSuite() logic). If that fails then we must try another application protocol. We cannot just fail the connection. How do we go from here to the top again to choose another protocol ? > J: send ServerHello (with the single, user-selected protocol) > ... > > This is very simple from the JDK perspective, and also much more flexible. Well, I kinda like it, but I have strong reservations that it cannot really "negotiate" the application protocol, meaning that if one application protocol fails, try the next, and then the next and so forth until one succeeds (or they all fail). 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 david.lloyd at redhat.com Fri Sep 25 17:23:00 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 25 Sep 2015 12:23:00 -0500 Subject: TLS ALPN Proposal v5 In-Reply-To: References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> <56055EBC.9040202@redhat.com> <560566DB.20805@redhat.com> <56057B25.4070103@redhat.com> Message-ID: <560582F4.9000906@redhat.com> On 09/25/2015 12:13 PM, Simone Bordet wrote: > Hi, > > On Fri, Sep 25, 2015 at 6:49 PM, David M. Lloyd wrote: >> A: receive raw SSL packet on Socket or SocketChannel >> A: examine SSL ClientHello, extract SNI, ALPN, cipher suite info > > This requires the application to write a TLS parser. This is currently > not necessary, nor provided. It is already necessary to make many non-trivial SNI decisions. I don't see ALPN as deserving higher treatment than SNI. > You think this could be provided via a JDK utility class ? > And if so, how can it be extended in the future when more TLS > Extensions are defined ? I don't think it's necessary, no. > >> A: use whatever algorithm(s) you want to analyze SNI/ALPN/cipher suite info > > The application must intersect the ciphers, application protocols... > perhaps again this can be done by some JDK utility class. The point of the approach is that it is unlikely that any JDK-driven logic will be adequate for all use cases. It's better to let the application be a black box: ALPN+SNI+Ciphers -> app logic -> one ALPN protocol, one SNI name, only valid ciphers. >> A: either proxy the connection, or obtain or create the relevant SSLContext >> from the desired provider >> A: construct server-side SSLSocket/SSLEngine from SSLContext >> A: setApplicationProtocol(H2) >> A: setEnabledCipherSuites(only allowed suites in desired order) >> A: start handshake >> J: receive ClientHello (buffered from A) >> J: verify SNI is matched, fail otherwise (as today) >> J: verify ALPN is matched, fail otherwise (new) > > There is a missing step here which is to verify the cipher > (trySetCipherSuite() logic). The application protocol implementation chooses only valid cipher suites for the protocol. Why would it choose one that is not valid, considering that the protocol implementation itself is the only thing that "knows" what is valid or not? > If that fails then we must try another application protocol. > We cannot just fail the connection. > How do we go from here to the top again to choose another protocol ? > >> J: send ServerHello (with the single, user-selected protocol) >> ... >> >> This is very simple from the JDK perspective, and also much more flexible. > > Well, I kinda like it, but I have strong reservations that it cannot > really "negotiate" the application protocol, meaning that if one > application protocol fails, try the next, and then the next and so > forth until one succeeds (or they all fail). This validation should have happened before the JDK ever has a chance to be involved. -- - DML From david.lloyd at redhat.com Fri Sep 25 17:53:25 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 25 Sep 2015 12:53:25 -0500 Subject: TLS ALPN Proposal v5 In-Reply-To: <560582F4.9000906@redhat.com> References: <55ED0A6A.3050806@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> <56055EBC.9040202@redhat.com> <560566DB.20805@redhat.com> <56057B25.4070103@redhat.com> <560582F4.9000906@redhat.com> Message-ID: <56058A15.5040309@redhat.com> Here are some solid reasons that this is the best possible approach: * It will work for 100% of foreseeable use cases - i.e. there is 0% risk of permanently baking in flawed logic into the API * It is dead simple - only one new method on SSLSocket/SSLEngine to set the protocol list (client) or selected single protocol (server) * Because it is dead simple, it should be very easy to backport to Java 8 *Example 1*: Add a static org.openjdk.jsse.ALPN#setApplicationProtocol(SSLEngine | SSLSocket s, String[] protocols) method, which calls (maybe even reflectively?) the setApplicationProtocol() method on the SSLEngine/SSLSocket implementation if it is present & public *Example 2*: Add an org.openjdk.jsse.ALPNAware interface with the setApplicationProtocol(String[]) method, which is implemented by JSSE providers * Now Java EE 8 can trivially achieve HTTP/2.0 support with very low risk to either the JDK/SE timeline or the EE timeline * Since most or all of the "hard" logic is on the server side, the majority of API consumers will have an easy time using the API * We server developers can handle the rest! On 09/25/2015 12:23 PM, David M. Lloyd wrote: > On 09/25/2015 12:13 PM, Simone Bordet wrote: >> Hi, >> >> On Fri, Sep 25, 2015 at 6:49 PM, David M. Lloyd >> wrote: >>> A: receive raw SSL packet on Socket or SocketChannel >>> A: examine SSL ClientHello, extract SNI, ALPN, cipher suite info >> >> This requires the application to write a TLS parser. This is currently >> not necessary, nor provided. > > It is already necessary to make many non-trivial SNI decisions. I don't > see ALPN as deserving higher treatment than SNI. > >> You think this could be provided via a JDK utility class ? >> And if so, how can it be extended in the future when more TLS >> Extensions are defined ? > > I don't think it's necessary, no. > >> >>> A: use whatever algorithm(s) you want to analyze SNI/ALPN/cipher >>> suite info >> >> The application must intersect the ciphers, application protocols... >> perhaps again this can be done by some JDK utility class. > > The point of the approach is that it is unlikely that any JDK-driven > logic will be adequate for all use cases. It's better to let the > application be a black box: ALPN+SNI+Ciphers -> app logic -> one ALPN > protocol, one SNI name, only valid ciphers. > >>> A: either proxy the connection, or obtain or create the relevant >>> SSLContext >>> from the desired provider >>> A: construct server-side SSLSocket/SSLEngine from SSLContext >>> A: setApplicationProtocol(H2) >>> A: setEnabledCipherSuites(only allowed suites in desired order) >>> A: start handshake >>> J: receive ClientHello (buffered from A) >>> J: verify SNI is matched, fail otherwise (as today) >>> J: verify ALPN is matched, fail otherwise (new) >> >> There is a missing step here which is to verify the cipher >> (trySetCipherSuite() logic). > > The application protocol implementation chooses only valid cipher suites > for the protocol. Why would it choose one that is not valid, > considering that the protocol implementation itself is the only thing > that "knows" what is valid or not? > >> If that fails then we must try another application protocol. >> We cannot just fail the connection. >> How do we go from here to the top again to choose another protocol ? >> >>> J: send ServerHello (with the single, user-selected protocol) >>> ... >>> >>> This is very simple from the JDK perspective, and also much more >>> flexible. >> >> Well, I kinda like it, but I have strong reservations that it cannot >> really "negotiate" the application protocol, meaning that if one >> application protocol fails, try the next, and then the next and so >> forth until one succeeds (or they all fail). > > This validation should have happened before the JDK ever has a chance to > be involved. -- - DML From simone.bordet at gmail.com Fri Sep 25 19:11:43 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Fri, 25 Sep 2015 21:11:43 +0200 Subject: TLS ALPN Proposal v5 In-Reply-To: <560582F4.9000906@redhat.com> References: <55ED0A6A.3050806@oracle.com> <55FCEF8E.2080608@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> <56055EBC.9040202@redhat.com> <560566DB.20805@redhat.com> <56057B25.4070103@redhat.com> <560582F4.9000906@redhat.com> Message-ID: Hi, On Fri, Sep 25, 2015 at 7:23 PM, David M. Lloyd wrote: > The application protocol implementation chooses only valid cipher suites for > the protocol. Why would it choose one that is not valid, considering that > the protocol implementation itself is the only thing that "knows" what is > valid or not? The cipher could fail for the number of reasons it fails in trySetCipherSuite(), even if the application has chosen the right combination of (application protocol, cipher, whatever else). At that point you have to try another application protocol. > This validation should have happened before the JDK ever has a chance to be > involved. See above. Unless it is verified that trySetCipherSuite() cannot *ever* fail after a cipher has been chosen (but then the method should return void), then I don't see how your proposal could work. Have you written an implementation already ? That would help. -- 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 david.lloyd at redhat.com Fri Sep 25 20:22:32 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 25 Sep 2015 15:22:32 -0500 Subject: TLS ALPN Proposal v5 In-Reply-To: References: <55ED0A6A.3050806@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> <56055EBC.9040202@redhat.com> <560566DB.20805@redhat.com> <56057B25.4070103@redhat.com> <560582F4.9000906@redhat.com> Message-ID: <5605AD08.9070806@redhat.com> On 09/25/2015 02:11 PM, Simone Bordet wrote: > Hi, > > On Fri, Sep 25, 2015 at 7:23 PM, David M. Lloyd wrote: >> The application protocol implementation chooses only valid cipher suites for >> the protocol. Why would it choose one that is not valid, considering that >> the protocol implementation itself is the only thing that "knows" what is >> valid or not? > > The cipher could fail for the number of reasons it fails in > trySetCipherSuite(), even if the application has chosen the right > combination of (application protocol, cipher, whatever else). > At that point you have to try another application protocol. From my reading of that code, it can only fail if you specifically set up invalid combinations of cipher suite, protocol, and credentials. The application code should have all the information it needs to set up a correct configuration though. >> This validation should have happened before the JDK ever has a chance to be >> involved. > > See above. > Unless it is verified that trySetCipherSuite() cannot *ever* fail > after a cipher has been chosen (but then the method should return > void), then I don't see how your proposal could work. The method isn't magical; it is just working off of known inputs. If you give inputs that will ultimately result in a correct negotiation (and nothing leads me to believe that there is any reason that the application protocol user cannot do this), then you will get a successful output. On the other hand, if (for example) the user selects a cipher suite that is incompatible with their credentials, or which is incompatible with the protocol which the user *also* selected, I don't see any good reason to give them another chance. In other words, you're assuming that the only way to know if a configuration is correct is to try it, but that just isn't true. > Have you written an implementation already ? That would help. No. -- - DML From valerie.peng at oracle.com Fri Sep 25 22:09:02 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 25 Sep 2015 15:09:02 -0700 Subject: RFR 8130648: JCK test api/java_security/AuthProvider/ProviderTests_login starts failing after JDK-7191662 In-Reply-To: <56056BE6.4050908@oracle.com> References: <55AEDDCA.9010202@oracle.com> <55FCAE63.7030408@oracle.com> <5601BCEA.5060204@oracle.com> <5601C8AD.3070907@oracle.com> <56043FEB.5070206@oracle.com> <5604B15B.3060500@oracle.com> <56056BE6.4050908@oracle.com> Message-ID: <5605C5FE.1010405@oracle.com> Hi Sean, Thanks! Webrev updated: http://cr.openjdk.java.net/~valeriep/8130648/webrev.02 CCC updated: http://ccc.us.oracle.com/8130648 I will finalize CCC after your review. Thanks & have a great weekend~ Valerie On 9/25/2015 8:44 AM, Sean Mullan wrote: > SecurityPermission: > > Change "login, logout" to "login and logout" > > All files: > > Use "@since 9" instead of "1.9" > > Looks good otherwise. > > --Sean > > On 9/24/15 10:28 PM, Valerie Peng wrote: >> >> Sure, the webrev is updated below with your comments and Joe's >> suggestion of adding a query API for provider configuration. >> I added a trivial regression test for the uninitialized PKCS11 provider >> as well. >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8130648/webrev.01/ >> >> Will update CCC once the webrev review is done. >> Thanks, >> Valerie >> >> On 9/24/2015 11:24 AM, Sean Mullan wrote: >>> Ok, I see now. >>> >>> I think now that it also makes sense to change setCallbackHandler to >>> throw IllegalStateException if a provider that requires configuration >>> has not been configured. This is because the permission depends on the >>> name of the provider, which (at least in the case of PKCS11) may not >>> be able to be determined until the provider is configured (since it is >>> part of the configuration data). Thus, then you can assume the handler >>> is null and then there is no need to copy it to the new provider >>> object. >>> >>> Also, while you are fixing this, could you add the "authProvider.{ >>> provider name}" permission to the permission table in the >>> SecurityPermission class summary? It looks like that was an oversight >>> and never got documented there. >>> >>> --Sean >>> >>> On 9/22/15 5:31 PM, Valerie Peng wrote: >>>> Hi, Sean, >>>> >>>> Thanks for the comments, I have changed to use the <> for line 110. >>>> For line 116-118, the difference is in the security check. With the >>>> current changes, the new provider will need to be granted >>>> |SecurityPermission("authProvider.name")| for the configuration >>>> call to >>>> complete and return the new provider. >>>> >>>> Or, one alternative is to not carrying over the callback handler if >>>> the >>>> particular permission is not granted for the new provider? >>>> Not sure if direct assignment/carryover would lead to anything bad, >>>> maybe I am being too paranoid... >>>> >>>> Thanks, >>>> Valerie >>>> >>>> >>>> On 9/22/2015 1:41 PM, Sean Mullan wrote: >>>>> On 09/18/2015 08:37 PM, Valerie Peng wrote: >>>>>> Sean, >>>>>> >>>>>> I have updated the webrev based on your suggestions and CCC has also >>>>>> been filed: >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8130648/webrev.00/ >>>>> >>>>> SunPKCS11.java >>>>> >>>>> 110: can use diamond operator for anon classes now, ex: >>>>> PrivilegedExceptionAction<> >>>> >>>>> >>>>> 116-118: wouldn't it be easier to do the following: >>>>> >>>>> 116 if (this.pHandler != null) { >>>>> 117 newOne.pHandler = this.pHandler; >>>>> 118 } >>>>> >>>>> then you don't need the catch block on lines 124-128. >>>>> >>>>> --Sean >>>>> >>>>> From bradford.wetmore at oracle.com Sat Sep 26 00:47:19 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 25 Sep 2015 17:47:19 -0700 Subject: TLS ALPN Proposal v5 In-Reply-To: <5605AD08.9070806@redhat.com> References: <55ED0A6A.3050806@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> <56055EBC.9040202@redhat.com> <560566DB.20805@redhat.com> <56057B25.4070103@redhat.com> <560582F4.9000906@redhat.com> <5605AD08.9070806@redhat.com> Message-ID: <5605EB17.4020203@oracle.com> You guys certainly were prolific in your discussions last night. ;) Many comments to touch on, and I definitely won't have time today to respond to everything. Xuelei wrote: > I don't think we really need to re-order the cipher suites. Simone wrote: > Of course you need to re-order in this case. In an iterative implementation like SunJSSE is currently, if you want to have the preference order of H2/H1, you need to try all of the H2-compatible ciphersuites first. Once you try a non-H2-compatible suite, the H2 matcher will fail, and it will then go to the H1 matcher, which will succeed. This particular situation was discussed in RFC 7540. > It might be not customers expected behavior to re-order/sort their > preference of cipher suites or preference. Are we are clear that the intention was never for the JDK to internally resort the ciphersuites, but rather to provide an external helper function (H2BLACKLISTCOMPARATOR) with which applications can do their own sorting and pass the results to setEnabledCiphersuite()? I think maybe the confusion came from the 3 roles you describe later. > If there are three roles, OpenJDK, application, customers, there are > three result: For JDK developers, the line between application/customer is quite blurry. You/I are concerned about the interface between the OpenJDK and (application+customers). The application folks will mainly be handling the customer configuration. > {TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384} BTW, in case anyone was wondering, both of these suites are on the RFC 7540 blacklist. Simone wrote: > for each cipher > for each application protocol > end > end > > All the rest being equal, ciphers dominate application protocol > selection. Correct. That's the current proposal. It's a chicken/egg problem. The KeyManager is part of the ciphersuite selection mechanims, and should have a proposed ALPN value value to use (ala RFC 7301), but the ALPN mechanism needs to have a ciphersuite in mind for it's calculation. I will think over David's proposal over the weekend. Much of the I/O required is already there using the JDK 1.8 method SSLSocketFactory.createSocket(Socket s, InputStream consumed, boolean autoClose), which was added for this very purpose. There's nothing to do for SSLEngine. Just a bit of history, we did consider a ClientHello parser when working on SNI. I don't remember the details as to why we didn't add it, but the SSLCapabilities/SSLExplorer classes in the JSSE sample code came from that attempt. I have a vague recollection that the API was getting too complicated in the time we had. More next week. Have a good weekend, all. Brad From xuelei.fan at oracle.com Sat Sep 26 01:18:10 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 26 Sep 2015 09:18:10 +0800 Subject: TLS ALPN Proposal v5 In-Reply-To: <5605AD08.9070806@redhat.com> References: <55ED0A6A.3050806@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> <56055EBC.9040202@redhat.com> <560566DB.20805@redhat.com> <56057B25.4070103@redhat.com> <560582F4.9000906@redhat.com> <5605AD08.9070806@redhat.com> Message-ID: <5605F252.5060108@oracle.com> I would second David's proposal based on the #1/#A ideas. Here are some background and options. 1. a HTTP2 server should support HTTP2 If a HTTP2 server declare to support HTTP2, it should support HTTP2 protocol. What happens if corner cases happen that the security is not sufficient (client requested cipher suites are all blacklisted)? Two approaches, refuse the connection or complete the connection. It is easy to understand if refusing the connection for corner cases. But why complete the connection with insufficient cipher suite? It's because for HTTP2, the client side need to check the security strength outside of SSL/TLS layer in case the SSL/TLS server uses insufficient security parameters. If the security is insufficient, the client side can request abbreviate handshaking (Section 3.1, RFC 7301) for a low level application protocols (application protocol downgrade), or close the connection. Here is the scenarios: A.1. client requests {HTTP2, HTTP1.1) A.2. server negotiates HTTP2 and HTTP2 blacklisted cipher suite. A.3. client checks the security sufficiency. The negotiated cipher suite is insufficient. A.4. client requests an abbreviated handshaking for {HTTP 1.1} A.5. server negotiates HTTP1.1 A.6. client checks the security sufficiency. The negotiated cipher suite is sufficient for HTTP 1.1. There are might be one question? Should client check the security sufficiency even if OpenJDK can do it pretty well. I would think client need to do so because the client may also want to connect to other TLS vendors, known or unknown. Client need to make sure the negotiated TLS strength is sufficient for the specified application protocol. If the story happens in this way, everything get more simple. 2. a HTTP2 server should support both HTTP2 and HTTP1.1 If an HTTP2 server support both HTTP2 and HTTP1.1, AND it is expected to do HTTP protocol version negotiated by itself internally (fail-over to HTTP 1.1) (I did not find the spec in HTTP2 RFC, but HTTP experts said a server may support both HTTP2 and HTTP1.1), what happens if corner cases happen that the security is not sufficient for HTTP 2? Three approaches: refuse the connection, complete the connection with HTTP2, fail-over to HTTP1.1 in server side. The first two approaches are the same as #1. For the 3rd approach, the server implementation and APIs design get much more complicated. For the 2nd approach, the scenarios is similar to #1.1. The server implementation part may looks like: B.1. receive a ClientHello message. B.2. negotiate the TLS protocol version, independently B.3. negotiate the TLS cipher suite, independently B.4. negotiate the application protocols, independently B.5. sending the ServerHello message. For the 3rd approach, the server implementation may looks like: C.1. receive a ClientHello message. C.2. negotiate the TLS protocol version, independently, get negotiated_protocol C.3. try to negotiate an TLS cipher suite, candidate_cipher_suite C.4. try to negotiate an application protocol with negotiated_protocol and candidate_cipher_suite. If the application protocol does not work for the TLS protocol and cipher suites, goto #3.3 and try again. Otherwise, move forward. C.5. if application protocol can be negotiated, sending the ServerHello message; otherwise, terminated the connection immediately. For the case above, looks like client may not need to do application protocol renegotiation. But actually, it may be able to avoid the coding job because the client may not know whether the server would behavior like #B, or #C. #1/#A do the application protocol version negotiation in client side, and #2/#C do the application protocol version negotiation in server side. And there is no spec about which behavior should be expected as far as I know. #1/#A is simple and straightforward, and #2/#C makes a smart (and complicated) server. OpenJDK now is trying to support both #1 and #2. Thanks, Xuelei On 9/26/2015 4:22 AM, David M. Lloyd wrote: > On 09/25/2015 02:11 PM, Simone Bordet wrote: >> Hi, >> >> On Fri, Sep 25, 2015 at 7:23 PM, David M. Lloyd >> wrote: >>> The application protocol implementation chooses only valid cipher >>> suites for >>> the protocol. Why would it choose one that is not valid, considering >>> that >>> the protocol implementation itself is the only thing that "knows" >>> what is >>> valid or not? >> >> The cipher could fail for the number of reasons it fails in >> trySetCipherSuite(), even if the application has chosen the right >> combination of (application protocol, cipher, whatever else). >> At that point you have to try another application protocol. > > From my reading of that code, it can only fail if you specifically set > up invalid combinations of cipher suite, protocol, and credentials. The > application code should have all the information it needs to set up a > correct configuration though. > >>> This validation should have happened before the JDK ever has a chance >>> to be >>> involved. >> >> See above. >> Unless it is verified that trySetCipherSuite() cannot *ever* fail >> after a cipher has been chosen (but then the method should return >> void), then I don't see how your proposal could work. > > The method isn't magical; it is just working off of known inputs. If > you give inputs that will ultimately result in a correct negotiation > (and nothing leads me to believe that there is any reason that the > application protocol user cannot do this), then you will get a > successful output. On the other hand, if (for example) the user selects > a cipher suite that is incompatible with their credentials, or which is > incompatible with the protocol which the user *also* selected, I don't > see any good reason to give them another chance. > > In other words, you're assuming that the only way to know if a > configuration is correct is to try it, but that just isn't true. > >> Have you written an implementation already ? That would help. > > No. From xuelei.fan at oracle.com Sat Sep 26 01:25:13 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 26 Sep 2015 09:25:13 +0800 Subject: TLS ALPN Proposal v5 In-Reply-To: <5605EB17.4020203@oracle.com> References: <55ED0A6A.3050806@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> <56055EBC.9040202@redhat.com> <560566DB.20805@redhat.com> <56057B25.4070103@redhat.com> <560582F4.9000906@redhat.com> <5605AD08.9070806@redhat.com> <5605EB17.4020203@oracle.com> Message-ID: <5605F3F9.6060601@oracle.com> On 9/26/2015 8:47 AM, Bradford Wetmore wrote: >> {TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384} > > BTW, in case anyone was wondering, both of these suites are on the RFC > 7540 blacklist. Ooops, I meant to use "TLS_ECDHE_" as HTTP2 non-blacklisted cipher suite. Xuelei From xuelei.fan at oracle.com Sat Sep 26 01:49:17 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 26 Sep 2015 09:49:17 +0800 Subject: TLS ALPN Proposal v5 In-Reply-To: <5605EB17.4020203@oracle.com> References: <55ED0A6A.3050806@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> <56055EBC.9040202@redhat.com> <560566DB.20805@redhat.com> <56057B25.4070103@redhat.com> <560582F4.9000906@redhat.com> <5605AD08.9070806@redhat.com> <5605EB17.4020203@oracle.com> Message-ID: <5605F99D.3080807@oracle.com> On 9/26/2015 8:47 AM, Bradford Wetmore wrote: >> It might be not customers expected behavior to re-order/sort their >> preference of cipher suites or preference. > > Are we are clear that the intention was never for the JDK to internally > resort the ciphersuites, but rather to provide an external helper > function (H2BLACKLISTCOMPARATOR) with which applications can do their > own sorting and pass the results to setEnabledCiphersuite()? My points: 1. OpenJDK should not do the re-sort internally. The preference decision should be made before the call to setEnabledCiphersuite(). I think Simone agreed with this point. 2. A handy function to resort the cipher suite is useful. But it is out of the scope of ALPN, or even out of the scope of OpenJDK. Application can do whatever resorting, H2BLACKLISTCOMPARATOR does not belong to OpenJDK. Xuelei From ecki at zusammenkunft.net Sat Sep 26 07:07:27 2015 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Sat, 26 Sep 2015 09:07:27 +0200 Subject: TLS ALPN Proposal v5 In-Reply-To: <5605F252.5060108@oracle.com> References: <55ED0A6A.3050806@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> <56055EBC.9040202@redhat.com> <560566DB.20805@redhat.com> <56057B25.4070103@redhat.com> <560582F4.9000906@redhat.com> <5605AD08.9070806@redhat.com> <5605F252.5060108@oracle.com> Message-ID: <353e6563-e7f6-4f12-8abf-d899045ca973.maildroid@localhost> It is obvious, but I thought I might mention it: it does absolutely not help the user if a server refuses to negotiate a "MAY not use" cipher only to fallback to http/1.1 with exactly that cipher. I can see the motivation for deprecating those ciphers in modern servers (although I am note sure why CBC with TLS 1.2 is such a biggie), but then you must stick to the decision and not fall back and use them anyway. Feels much like overstepping a border in protocol design which causes a lot of interop problems and API grief. Given that it might be a good idea to not do anything special in JSSE and give the client and server developers full control over the use of ciphers. Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: Xuelei Fan To: "David M. Lloyd" , Simone Bordet Cc: OpenJDK , "net-dev at openjdk.java.net >> OpenJDK Network Dev list" Sent: Sa., 26 Sep. 2015 3:19 Subject: Re: TLS ALPN Proposal v5 I would second David's proposal based on the #1/#A ideas. Here are some background and options. 1. a HTTP2 server should support HTTP2 If a HTTP2 server declare to support HTTP2, it should support HTTP2 protocol. What happens if corner cases happen that the security is not sufficient (client requested cipher suites are all blacklisted)? Two approaches, refuse the connection or complete the connection. It is easy to understand if refusing the connection for corner cases. But why complete the connection with insufficient cipher suite? It's because for HTTP2, the client side need to check the security strength outside of SSL/TLS layer in case the SSL/TLS server uses insufficient security parameters. If the security is insufficient, the client side can request abbreviate handshaking (Section 3.1, RFC 7301) for a low level application protocols (application protocol downgrade), or close the connection. Here is the scenarios: A.1. client requests {HTTP2, HTTP1.1) A.2. server negotiates HTTP2 and HTTP2 blacklisted cipher suite. A.3. client checks the security sufficiency. The negotiated cipher suite is insufficient. A.4. client requests an abbreviated handshaking for {HTTP 1.1} A.5. server negotiates HTTP1.1 A.6. client checks the security sufficiency. The negotiated cipher suite is sufficient for HTTP 1.1. There are might be one question? Should client check the security sufficiency even if OpenJDK can do it pretty well. I would think client need to do so because the client may also want to connect to other TLS vendors, known or unknown. Client need to make sure the negotiated TLS strength is sufficient for the specified application protocol. If the story happens in this way, everything get more simple. 2. a HTTP2 server should support both HTTP2 and HTTP1.1 If an HTTP2 server support both HTTP2 and HTTP1.1, AND it is expected to do HTTP protocol version negotiated by itself internally (fail-over to HTTP 1.1) (I did not find the spec in HTTP2 RFC, but HTTP experts said a server may support both HTTP2 and HTTP1.1), what happens if corner cases happen that the security is not sufficient for HTTP 2? Three approaches: refuse the connection, complete the connection with HTTP2, fail-over to HTTP1.1 in server side. The first two approaches are the same as #1. For the 3rd approach, the server implementation and APIs design get much more complicated. For the 2nd approach, the scenarios is similar to #1.1. The server implementation part may looks like: B.1. receive a ClientHello message. B.2. negotiate the TLS protocol version, independently B.3. negotiate the TLS cipher suite, independently B.4. negotiate the application protocols, independently B.5. sending the ServerHello message. For the 3rd approach, the server implementation may looks like: C.1. receive a ClientHello message. C.2. negotiate the TLS protocol version, independently, get negotiated_protocol C.3. try to negotiate an TLS cipher suite, candidate_cipher_suite C.4. try to negotiate an application protocol with negotiated_protocol and candidate_cipher_suite. If the application protocol does not work for the TLS protocol and cipher suites, goto #3.3 and try again. Otherwise, move forward. C.5. if application protocol can be negotiated, sending the ServerHello message; otherwise, terminated the connection immediately. For the case above, looks like client may not need to do application protocol renegotiation. But actually, it may be able to avoid the coding job because the client may not know whether the server would behavior like #B, or #C. #1/#A do the application protocol version negotiation in client side, and #2/#C do the application protocol version negotiation in server side. And there is no spec about which behavior should be expected as far as I know. #1/#A is simple and straightforward, and #2/#C makes a smart (and complicated) server. OpenJDK now is trying to support both #1 and #2. Thanks, Xuelei On 9/26/2015 4:22 AM, David M. Lloyd wrote: > On 09/25/2015 02:11 PM, Simone Bordet wrote: >> Hi, >> >> On Fri, Sep 25, 2015 at 7:23 PM, David M. Lloyd >> wrote: >>> The application protocol implementation chooses only valid cipher >>> suites for >>> the protocol. Why would it choose one that is not valid, considering >>> that >>> the protocol implementation itself is the only thing that "knows" >>> what is >>> valid or not? >> >> The cipher could fail for the number of reasons it fails in >> trySetCipherSuite(), even if the application has chosen the right >> combination of (application protocol, cipher, whatever else). >> At that point you have to try another application protocol. > > From my reading of that code, it can only fail if you specifically set > up invalid combinations of cipher suite, protocol, and credentials. The > application code should have all the information it needs to set up a > correct configuration though. > >>> This validation should have happened before the JDK ever has a chance >>> to be >>> involved. >> >> See above. >> Unless it is verified that trySetCipherSuite() cannot *ever* fail >> after a cipher has been chosen (but then the method should return >> void), then I don't see how your proposal could work. > > The method isn't magical; it is just working off of known inputs. If > you give inputs that will ultimately result in a correct negotiation > (and nothing leads me to believe that there is any reason that the > application protocol user cannot do this), then you will get a > successful output. On the other hand, if (for example) the user selects > a cipher suite that is incompatible with their credentials, or which is > incompatible with the protocol which the user *also* selected, I don't > see any good reason to give them another chance. > > In other words, you're assuming that the only way to know if a > configuration is correct is to try it, but that just isn't true. > >> Have you written an implementation already ? That would help. > > No. From dblack at atlassian.com Sat Sep 26 08:39:21 2015 From: dblack at atlassian.com (David Black) Date: Sat, 26 Sep 2015 18:39:21 +1000 Subject: The fix for JDK-806769 breaks some ldap usages. In-Reply-To: <560558C9.40804@oracle.com> References: <560558C9.40804@oracle.com> Message-ID: On Saturday, 26 September 2015, Sean Mullan wrote: > JDK-806769 doesn't exist, can you double-check what issue you think caused > this? Looks like you are missing a digit. > > Hi Sean, hmm I don't know how I managed that ... the complete issue id is JDK-8067695. > > On 9/24/15 10:46 PM, David Black wrote: > >> As I do not have an account on https://bugs.openjdk.java.net, yes I have >> submitted a standard oracle java bug report, I thought it might be of >> interest to those on this mailing list to forward information on how >> some java ldap users since the JDK-806769 fix may encounter invalid >> ldaps hostname issues. >> >> When an "ldaps" provider url is set in the environment and a custom >> SocketFactory, which sets the SSLSocket endpoint identification >> algorithm to "LDAPS", is set in the ldap environment hostname because of >> the way the fix for JDK-806769 was implemented some clients encounter a >> CertificateException. This occurs because the code inside the >> com.sun.jndi.ldap.Connection class createSocket method[0] "prefers" to >> invoke the socketFactory.createSocket() method instead of >> socketFactory.createSocket(String host, int port) when a connection >> timeout is set, which results in the host not being set in the created >> ssl socket instance. >> >> Steps to reproduce: >> 1. git clone >> https://bitbucket.org/atlassian/cwd-4444-java-bug-reproducer.git >> 2. build the code - `cd src/main/java && javac Broken.java Main.java >> Working.java` >> 3. run the Main class and provide an ldaps url - `java Main >> ldaps://example.java:10636` >> 4. Observe that when the "Broken" SocketFactory is in use a hostname >> verification error occurs. >> >> Workaround: >> Naturally, one can workaround the Connection class's "preference" for >> the no argument createSocket method by not having such a method in the >> SocketFactory set in the ldap environment. >> >> >> Untested potential patch: >> --- Connection.java.orig2015-09-25 11:39:26.323117929 +1000 >> +++ Connection.java2015-09-25 12:41:04.175068697 +1000 >> @@ -33,6 +33,7 @@ >> import java.io.InputStream; >> import java.net.Socket; >> import javax.net.ssl.SSLSocket; >> +import javax.net.ssl.SSLSocketFactory; >> import javax.naming.CommunicationException; >> import javax.naming.ServiceUnavailableException; >> @@ -287,7 +288,40 @@ >> Method createSocket = null; >> - if (connectTimeout > 0) { >> + if (connectTimeout > 0 && socketFactoryClass instanceof >> SSLSocketFactory) { >> + >> + try { >> + Socket sock = null; >> + createSocket = >> socketFactoryClass.getMethod("createSocket", >> + new Class[]{Socket.class, String.class, >> + int.class, boolean.class}); >> + Constructor socketCons = >> + Socket.class.getConstructor(new Class[]{}); >> + >> + Method connect = Socket.class.getMethod("connect", >> + new >> Class[]{Class.forName("java.net.SocketAddress"), >> + int.class}); >> + Object endpoint = createInetSocketAddress(host, >> port); >> + >> + // unconnected underlying socket >> + sock = socketCons.newInstance(new Object[]{}); >> + >> + if (debug) { >> + System.err.println("Connection: creating socket >> with " + >> + "a timeout"); >> + } >> + // connect the underlying socket >> + connect.invoke(sock, new Object[]{ >> + endpoint, new Integer(connectTimeout)}); >> + // connect the ssl socket >> + socket = createSocket(sock, host, port, true); >> + >> + } catch (NoSuchMethodException e) { >> + // continue >> + } >> + } >> + >> + if (connectTimeout > 0 && socket == null) { >> try { >> createSocket = >> socketFactoryClass.getMethod("createSocket", >> >> >> >> [0] >> >> http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/7d1d5f4d019a/src/share/classes/com/sun/jndi/ldap/Connection.java#l272 >> >> -- >> David Black / Security Engineer. >> > -- David Black / Security Engineer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From usha.seshadri at lmco.com Mon Sep 28 15:47:50 2015 From: usha.seshadri at lmco.com (Seshadri, Usha) Date: Mon, 28 Sep 2015 15:47:50 +0000 Subject: JEP 249: OCSP Stapling Message-ID: <0F6322F01158F94EBDA664939D5EA15504F01315@HVXDSP25.us.lmco.com> Hi, I am looking forward to the availability of OCSP stapling in OpenJDK 9. It appears OpenJDK 9 will not become available till September/2016. How will this functionality (OCSP stapling) be made available to the public after the JEP 249 project is resolved (current due date 11/06/15)? Would it be made available as a downloadable JAR file? Thanks, Usha Usha Seshadri Lockheed Martin, IS&GS 301-240-7496 [LM-logo] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3520 bytes Desc: image001.jpg URL: From usha.seshadri at lmco.com Mon Sep 28 15:52:42 2015 From: usha.seshadri at lmco.com (Seshadri, Usha) Date: Mon, 28 Sep 2015 15:52:42 +0000 Subject: JEP 249: OCSP Stapling Message-ID: <0F6322F01158F94EBDA664939D5EA15504F0132B@HVXDSP25.us.lmco.com> Hi, I am looking forward to the availability of OCSP stapling in OpenJDK 9. It appears OpenJDK 9 will not become available till September/2016. How will this functionality (OCSP stapling) be made available to the public after the JEP 249 project is resolved (current due date 11/06/15), and before it's available in OpenJDK 9? Would it be made available as a downloadable JAR file? Thanks for your response! Usha Usha Seshadri Lockheed Martin, IS&GS 301-240-7496 [LM-logo] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 3520 bytes Desc: image002.jpg URL: From jamil.j.nimeh at oracle.com Mon Sep 28 17:14:52 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 28 Sep 2015 10:14:52 -0700 Subject: JEP 249: OCSP Stapling In-Reply-To: <0F6322F01158F94EBDA664939D5EA15504F0132B@HVXDSP25.us.lmco.com> References: <0F6322F01158F94EBDA664939D5EA15504F0132B@HVXDSP25.us.lmco.com> Message-ID: <5609758C.3040703@oracle.com> Hello Usha, I'm glad to hear that you're interested in this feature. As it turns out, this feature is already part of OpenJDK 9. If you were to build the JDK from source you should be able to take advantage of this feature. If you do start using it I would love to hear feedback about how the feature works in your environment. Thank you, --Jamil On 09/28/2015 08:52 AM, Seshadri, Usha wrote: > > Hi, > > I am looking forward to the availability of OCSP stapling in OpenJDK > 9. It appears OpenJDK 9 will not become available till > September/2016. How will this functionality (OCSP stapling) be made > available to the public after the JEP 249 project is resolved (current > due date 11/06/15), and before it?s available in OpenJDK 9? Would it > be made available as a downloadable JAR file? > > Thanks for your response! > > Usha > > Usha Seshadri > > Lockheed Martin, IS&GS > > 301-240-7496 > > LM-logo > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3520 bytes Desc: not available URL: From jason.greene at redhat.com Mon Sep 28 18:06:44 2015 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 28 Sep 2015 13:06:44 -0500 Subject: TLS ALPN Proposal v5 In-Reply-To: <5605AD08.9070806@redhat.com> References: <55ED0A6A.3050806@oracle.com> <560232C0.40903@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> <56055EBC.9040202@redhat.com> <560566DB.20805@redhat.com> <56057B25.4070103@redhat.com> <560582F4.9000906@redhat.com> <560! 5AD08.9070806@redhat.com> Message-ID: <7CC07DE5-778C-428E-9E02-19E7A883CB23@redhat.com> > On Sep 25, 2015, at 3:22 PM, David M. Lloyd wrote: > > On 09/25/2015 02:11 PM, Simone Bordet wrote: >> Hi, >> >> On Fri, Sep 25, 2015 at 7:23 PM, David M. Lloyd wrote: >>> The application protocol implementation chooses only valid cipher suites for >>> the protocol. Why would it choose one that is not valid, considering that >>> the protocol implementation itself is the only thing that "knows" what is >>> valid or not? >> >> The cipher could fail for the number of reasons it fails in >> trySetCipherSuite(), even if the application has chosen the right >> combination of (application protocol, cipher, whatever else). >> At that point you have to try another application protocol. > > From my reading of that code, it can only fail if you specifically set up invalid combinations of cipher suite, protocol, and credentials. The application code should have all the information it needs to set up a correct configuration though. One example approach for a server-side H1 fallback scenario can be achieved using this approach, is to take the desired enabled portion of the supported cipher suite list for TLS 1.2+ (e.g. getSupportedCipherSuites, getSupportedSSLParameters, etc), which in simple scenarios is just the default suites (e.g. getDefaultSSLParameters, etc). Remove the H2 black-list from that and you have the h2 possible cipher-suite list. This list can then be further paired down based on key material (e.g disable ECDSA ciphers if only an RSA cert is present in the keystore). Finally the cipher list in client hello can be compared to find a possible intersection. If there is no intersection then use h1, otherwise configure h2. One additional topic that I see came up on this list is the notion that cipher suite selection using ALPN is a temporary use-case, since H2 loses this problem with TLS 1.3. I think this viewpoint is too limiting. Fundamentally, the key use case that ALPN is achieving, is multiplexing two TLS ports over one. Any TLS policy that was required for a single protocol over a single port is likely to still be needed in a mixed protocol setup. Once you have non-overlapping policies then you need the ability to have logic which is distinguished by ALPN. We shouldn?t just look at H2 here, but think of it more generically. Absent a non-limited TLS stack that does all the heavy lifting, deferring to the application is the next best thing. In some ways it can actually be better, since the portion of the logic on top of the JVM can evolve independently and more expediently than SE schedule allows. I also like David?s point that a simple solution is easier to backport to SE8, which is very important since EE8 is planned to require http2 and SE8 support. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From sean.mullan at oracle.com Mon Sep 28 19:27:21 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 28 Sep 2015 15:27:21 -0400 Subject: RFR 8056174: New APIs for jar signing In-Reply-To: <5600CE49.1020604@oracle.com> References: <55DB22A9.40704@oracle.com> <55E54ACC.6020004@oracle.com> <55E8B010.70905@oracle.com> <5600AAE5.3010009@oracle.com> <5600CE49.1020604@oracle.com> Message-ID: <56099499.1020604@oracle.com> Looks good, just a couple of comments: AlgorithmId: can you use braces around the conditional statements on lines 1008-1017? Function: are you missing an @modules tag for the jarsigner module? Options.java: why not use the JarSigner API here instead of the jarsigner tool? --Sean On 09/21/2015 11:43 PM, Weijun Wang wrote: > Missing from the webrev, some extra lines needed in modules.xml of the > parent repo jdk9/dev: > > > jdk.jartool > java.base > > com.sun.jarsigner > > + > + jdk.security.jarsigner > + > > > Thanks > Max > > On 09/22/2015 09:12 AM, Weijun Wang wrote: >> OK, webrev updated at >> >> http://cr.openjdk.java.net/~weijun/8056174/webrev.05/ >> >> A new method setProperty() is added to JarSigner.Builder (as well as >> getProperty() in JarSigner) to cover all misc settings. JarSignerX and >> BuilderX are removed now. >> >> Thanks >> Max >> From weijun.wang at oracle.com Mon Sep 28 23:34:39 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 29 Sep 2015 07:34:39 +0800 Subject: RFR 8056174: New APIs for jar signing In-Reply-To: <56099499.1020604@oracle.com> References: <55DB22A9.40704@oracle.com> <55E54ACC.6020004@oracle.com> <55E8B010.70905@oracle.com> <5600AAE5.3010009@oracle.com> <5600CE49.1020604@oracle.com> <56099499.1020604@oracle.com> Message-ID: <5609CE8F.2020805@oracle.com> On 9/29/2015 3:27 AM, Sean Mullan wrote: > Looks good, just a couple of comments: > > AlgorithmId: can you use braces around the conditional statements on > lines 1008-1017? OK. > > Function: are you missing an @modules tag for the jarsigner module? Which one? I thought @modules is only used if you want to call non-exported classes. > > Options.java: why not use the JarSigner API here instead of the > jarsigner tool? This test is to make sure jarsigner still behaves correctly after it is modified to be based on the JarSigner API. As for the API itself, I use Function.java to check its function and Spec.java to check it's spec. I'll add some @summary. Thanks Max > > --Sean > > > http://cr.openjdk.java.net/~weijun/8056174/webrev.05/ >> From bradford.wetmore at oracle.com Tue Sep 29 01:40:06 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 28 Sep 2015 18:40:06 -0700 Subject: TLS ALPN Proposal v5 In-Reply-To: <7CC07DE5-778C-428E-9E02-19E7A883CB23@redhat.com> References: <55ED0A6A.3050806@oracle.com> <56048B13.10307@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> <56055EBC.9040202@redhat.com> <560566DB.20805@redhat.com> <56057B25.4070103@redhat.com> <560582F4.9000906@redhat.com> <560! 5AD08.9070806@redhat.com> <7CC07DE5-778C-428E-9E02-19E7A883CB23@redhat.com> Message-ID: <5609EBF6.7080306@oracle.com> Several comments about David's proposal: 1. Only the initial ClientHellos are parsable. =============================================== The biggest problem I have with an Explorer-based design is that only the initial ClientHello on a connection is passed in the clear. Subsequent negotiations on this connection will be completely missed, as the ClientHellos are now encrypted. This seems like a deal breaker for me. Also, and this is moot if the ClientHellos are encrypted, unless you wrap the underlying raw socket in your own "observer" socket wrapper, you won't be able to view the raw data once the SSLSocket starts processing. SSLEngine doesn't have this problem since it's just ByteBuffers. One other comments while on the topic of renegotiations/resumptions as there were some incorrect statements in previous emails. H2 (RFC 7540-Sec 9.2.1) allows for renegotiations/resumptions to occur before the initial connection preface to protect *CLIENT CREDENTIALS* only, but prohibits it once data has started passing. But there is no such restriction on HTTP/1.1, nor on ALPN in general. So in such a case, there's no way you can change it with this proposal, and the ALPN RFC specifically allows for it. 2. "SSLExplorer" or something similar is needed. ================================================= This approach depends on "examining SSLClientHello"s, but there isn't a class for this other than some sample code from a previous attempt. I am assuming that this approach would make such an external API a necessity? Being able to parse possible ClientHello formats is not a straightforward/easy job. This will add a fair amount of complexity, and likely not an easy job in the remaining few weeks. It could be added later for JDK 10 but that means apps would likely need to roll their own for 9. 3. "no_application_protocol" ============================= If the server doesn't support the protocols that the client advertises, the "no_application_protocol" must be thrown. We could add a "no_application_protocol" protocol String that would flag such a condition internally. 4. Much of this is already possible. ===================================== If we were to go with the current API/internal and apps provided their own ClientHello scanner, many of the benefits of what was proposed are already available. Apps can ask for the desired SSLContext, get the SSLSocket/SSLengine, check the SNI/ALPN values, order/set the enabled protocols/ciphers/etc + single ALPN value, then wrap the raw socket using SSLSocketFactory.createSocket(Socket s, InputStream consumed, boolean autoClose), and start the handshake. The internal code would still call matches() but only once. If you want to be sure the internals select the ApplicationProtocol, just put in a permissive ApplicationProtocol. The API is still more complicated unfortunately as ApplicationProtocol is still present, but the overall behavior is quite similar. 5. Other failure mode/fallback. ================================ In the new proposal, suppose you do set a single ALPN value in the application level, and the ServerHandshaker finds some other aspect of the handshake wasn't appropriate (creds were mentioned several times, but maybe a ciphersuite went dark due to new AlgorithmConstraints). This would cause the ServerHandshaker to fail and there's no way to go back to a different version unless you add a "for ALPN" loop into application. 6. "Only one new method on SSLSocket/SSLEngine to set the protocol list (client) or selected single protocol (server)" ============================================================== I think you would need two, "use this value on the next handshake" and "this was last negotiated/currently in effect." One other comment: Simone wrote: > I don't know if all the blacklisted ciphers are actually lower > strength of all the remaining ciphers, Mainly it's about removing support for various algorithms. e.g. static RSA/DH Key Exchange, DSA (draft-09), non-AEAD ciphers, customer DHE groups. https://tlswg.github.io/tls13-spec/#rfc.section.1.2 Unfortunately, this is a big change in direction and is coming very late. I'm getting very significant pushback and schedule pressure from management now, so without an "Aha" moment, we may not be able to go this route. Thanks, Brad On 9/28/2015 11:06 AM, Jason Greene wrote: > >> On Sep 25, 2015, at 3:22 PM, David M. Lloyd wrote: >> >> On 09/25/2015 02:11 PM, Simone Bordet wrote: >>> Hi, >>> >>> On Fri, Sep 25, 2015 at 7:23 PM, David M. Lloyd wrote: >>>> The application protocol implementation chooses only valid cipher suites for >>>> the protocol. Why would it choose one that is not valid, considering that >>>> the protocol implementation itself is the only thing that "knows" what is >>>> valid or not? >>> >>> The cipher could fail for the number of reasons it fails in >>> trySetCipherSuite(), even if the application has chosen the right >>> combination of (application protocol, cipher, whatever else). >>> At that point you have to try another application protocol. >> >> From my reading of that code, it can only fail if you specifically set up invalid combinations of cipher suite, protocol, and credentials. The application code should have all the information it needs to set up a correct configuration though. > > One example approach for a server-side H1 fallback scenario can be achieved using this approach, is to take the desired enabled portion of the supported cipher suite list for TLS 1.2+ (e.g. getSupportedCipherSuites, getSupportedSSLParameters, etc), which in simple scenarios is just the default suites (e.g. getDefaultSSLParameters, etc). Remove the H2 black-list from that and you have the h2 possible cipher-suite list. This list can then be further paired down based on key material (e.g disable ECDSA ciphers if only an RSA cert is present in the keystore). Finally the cipher list in client hello can be compared to find a possible intersection. If there is no intersection then use h1, otherwise configure h2. > > One additional topic that I see came up on this list is the notion that cipher suite selection using ALPN is a temporary use-case, since H2 loses this problem with TLS 1.3. I think this viewpoint is too limiting. Fundamentally, the key use case that ALPN is achieving, is multiplexing two TLS ports over one. Any TLS policy that was required for a single protocol over a single port is likely to still be needed in a mixed protocol setup. Once you have non-overlapping policies then you need the ability to have logic which is distinguished by ALPN. We shouldn?t just look at H2 here, but think of it more generically. > > Absent a non-limited TLS stack that does all the heavy lifting, deferring to the application is the next best thing. In some ways it can actually be better, since the portion of the logic on top of the JVM can evolve independently and more expediently than SE schedule allows. I also like David?s point that a simple solution is easier to backport to SE8, which is very important since EE8 is planned to require http2 and SE8 support. > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > From sean.mullan at oracle.com Tue Sep 29 12:10:55 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 29 Sep 2015 08:10:55 -0400 Subject: RFR 8056174: New APIs for jar signing In-Reply-To: <5609CE8F.2020805@oracle.com> References: <55DB22A9.40704@oracle.com> <55E54ACC.6020004@oracle.com> <55E8B010.70905@oracle.com> <5600AAE5.3010009@oracle.com> <5600CE49.1020604@oracle.com> <56099499.1020604@oracle.com> <5609CE8F.2020805@oracle.com> Message-ID: <560A7FCF.1070502@oracle.com> >> Function: are you missing an @modules tag for the jarsigner module? > > Which one? I thought @modules is only used if you want to call > non-exported classes. Ok, never mind then. >> Options.java: why not use the JarSigner API here instead of the >> jarsigner tool? > > This test is to make sure jarsigner still behaves correctly after it is > modified to be based on the JarSigner API. As for the API itself, I use > Function.java to check its function and Spec.java to check it's spec. > > I'll add some @summary. Ok, thanks. --Sean From usha.seshadri at lmco.com Tue Sep 29 13:49:42 2015 From: usha.seshadri at lmco.com (Seshadri, Usha) Date: Tue, 29 Sep 2015 13:49:42 +0000 Subject: OCSP clock skew configuration Message-ID: <0F6322F01158F94EBDA664939D5EA15504F01580@HVXDSP25.us.lmco.com> Hi, The following bug reports seems to indicate the OCSP validation code should permit clock skew when checking the validity of OCSP responses. 1. JDK-674888 (Bug - affected version 6u11) 2. JDK-2166696 (Backport - fixed version 6u10 (b32) 3. JDK-2186994 (Backport - fixed version OpenJDK6 (b18) 4. JDK-2166740 (Backport - fixed version 7 (b41)) I am using Java8, and would expect it to have all the above fixes. Changing the value of "deployment.security.validation.clockskew" has no impact on the OCSP certification validation. The certificate validation always defaults to 15 minutes. What configurable property (and what file) controls the OCSP validation clock skew? Any answer will be greatly appreciated! Thanks, Usha Seshadri Lockheed Martin, IS&GS 301-240-7496 [LM-logo] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3520 bytes Desc: image001.jpg URL: From artem.smotrakov at oracle.com Tue Sep 29 14:01:24 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 29 Sep 2015 17:01:24 +0300 Subject: [9] RFR 8136600: sun/security/krb5/auto/tools/KinitConfPlusProps.java test intermittently fails because PortUnreachableException is missing Message-ID: <560A99B4.9040706@oracle.com> Hello, Please review this small test fix for https://bugs.openjdk.java.net/browse/JDK-8136600 The test runs kinit, and expects PortUnreachableException because of wrong KDC port number specified. It seems that other exceptions may be thrown as well. That may depend on platform where the test runs, or maybe some other circumstances. The main idea of the test is to check if kinit fails because "java.security.krb5.kdc" and "java.security.krb5.realm" system properties override correct values in krb5 conf file. I think it may be better just to remove a check for PortUnreachableException instead on adding checks for other possible socket exception. diff -r 2bea10d2e78f test/sun/security/krb5/auto/tools/KinitConfPlusProps.java --- a/test/sun/security/krb5/auto/tools/KinitConfPlusProps.java Mon Sep 28 16:39:12 2015 +0300 +++ b/test/sun/security/krb5/auto/tools/KinitConfPlusProps.java Tue Sep 29 16:50:11 2015 +0300 @@ -22,7 +22,6 @@ */ import java.io.File; -import java.net.PortUnreachableException; import java.util.HashMap; import java.util.Map; import jdk.testlibrary.ProcessTools; @@ -86,7 +85,6 @@ try { OutputAnalyzer out = ProcessTools.executeCommand(command); out.shouldHaveExitValue(-1); - out.shouldContain(PortUnreachableException.class.getName()); } catch(Throwable e) { System.out.println("Unexpected exception: " + e); e.printStackTrace(System.out); Artem From weijun.wang at oracle.com Tue Sep 29 14:49:45 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 29 Sep 2015 22:49:45 +0800 Subject: [9] RFR 8136600: sun/security/krb5/auto/tools/KinitConfPlusProps.java test intermittently fails because PortUnreachableException is missing In-Reply-To: <560A99B4.9040706@oracle.com> References: <560A99B4.9040706@oracle.com> Message-ID: Looks fine. Is it Mac or Windows? Is it a SocketTimeoutException? Thanks Max > On 2015?9?29?, at ??10:01, Artem Smotrakov wrote: > > Hello, > > Please review this small test fix for https://bugs.openjdk.java.net/browse/JDK-8136600 > > The test runs kinit, and expects PortUnreachableException because of wrong KDC port number specified. It seems that other exceptions may be thrown as well. That may depend on platform where the test runs, or maybe some other circumstances. The main idea of the test is to check if kinit fails because "java.security.krb5.kdc" and "java.security.krb5.realm" system properties override correct values in krb5 conf file. I think it may be better just to remove a check for PortUnreachableException instead on adding checks for other possible socket exception. > > diff -r 2bea10d2e78f test/sun/security/krb5/auto/tools/KinitConfPlusProps.java > --- a/test/sun/security/krb5/auto/tools/KinitConfPlusProps.java Mon Sep 28 16:39:12 2015 +0300 > +++ b/test/sun/security/krb5/auto/tools/KinitConfPlusProps.java Tue Sep 29 16:50:11 2015 +0300 > @@ -22,7 +22,6 @@ > */ > > import java.io.File; > -import java.net.PortUnreachableException; > import java.util.HashMap; > import java.util.Map; > import jdk.testlibrary.ProcessTools; > @@ -86,7 +85,6 @@ > try { > OutputAnalyzer out = ProcessTools.executeCommand(command); > out.shouldHaveExitValue(-1); > - out.shouldContain(PortUnreachableException.class.getName()); > } catch(Throwable e) { > System.out.println("Unexpected exception: " + e); > e.printStackTrace(System.out); > > Artem From artem.smotrakov at oracle.com Tue Sep 29 14:52:46 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 29 Sep 2015 17:52:46 +0300 Subject: [9] RFR 8136600: sun/security/krb5/auto/tools/KinitConfPlusProps.java test intermittently fails because PortUnreachableException is missing In-Reply-To: References: <560A99B4.9040706@oracle.com> Message-ID: <560AA5BE.8070303@oracle.com> Hi Max, I observed SocketTimeoutException on Windows only, but I suppose it can happen on other platforms. Artem On 09/29/2015 05:49 PM, Wang Weijun wrote: > Looks fine. > > Is it Mac or Windows? Is it a SocketTimeoutException? > > Thanks > Max > >> On 2015?9?29?, at ??10:01, Artem Smotrakov wrote: >> >> Hello, >> >> Please review this small test fix for https://bugs.openjdk.java.net/browse/JDK-8136600 >> >> The test runs kinit, and expects PortUnreachableException because of wrong KDC port number specified. It seems that other exceptions may be thrown as well. That may depend on platform where the test runs, or maybe some other circumstances. The main idea of the test is to check if kinit fails because "java.security.krb5.kdc" and "java.security.krb5.realm" system properties override correct values in krb5 conf file. I think it may be better just to remove a check for PortUnreachableException instead on adding checks for other possible socket exception. >> >> diff -r 2bea10d2e78f test/sun/security/krb5/auto/tools/KinitConfPlusProps.java >> --- a/test/sun/security/krb5/auto/tools/KinitConfPlusProps.java Mon Sep 28 16:39:12 2015 +0300 >> +++ b/test/sun/security/krb5/auto/tools/KinitConfPlusProps.java Tue Sep 29 16:50:11 2015 +0300 >> @@ -22,7 +22,6 @@ >> */ >> >> import java.io.File; >> -import java.net.PortUnreachableException; >> import java.util.HashMap; >> import java.util.Map; >> import jdk.testlibrary.ProcessTools; >> @@ -86,7 +85,6 @@ >> try { >> OutputAnalyzer out = ProcessTools.executeCommand(command); >> out.shouldHaveExitValue(-1); >> - out.shouldContain(PortUnreachableException.class.getName()); >> } catch(Throwable e) { >> System.out.println("Unexpected exception: " + e); >> e.printStackTrace(System.out); >> >> Artem From david.lloyd at redhat.com Tue Sep 29 15:07:16 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 29 Sep 2015 10:07:16 -0500 Subject: TLS ALPN Proposal v5 In-Reply-To: <5609EBF6.7080306@oracle.com> References: <55ED0A6A.3050806@oracle.com> <5604A6F8.7010100@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> <56055EBC.9040202@redhat.com> <560566DB.20805@redhat.com> <56057B25.4070103@redhat.com> <560582F4.9000906@redhat.com> <560! 5AD08.9070806@redhat.com> <7CC07DE5-778C-428E-9E02-19E7A883CB23@redhat.com> <5609EBF6.7080306@oracle.com> Message-ID: <560AA924.1050706@redhat.com> Hi Brad, thanks for replying; comments are inline: On 09/28/2015 08:40 PM, Bradford Wetmore wrote: > > Several comments about David's proposal: > > > 1. Only the initial ClientHellos are parsable. > =============================================== > The biggest problem I have with an Explorer-based design is that only > the initial ClientHello on a connection is passed in the clear. > Subsequent negotiations on this connection will be completely missed, as > the ClientHellos are now encrypted. > > This seems like a deal breaker for me. You are right, I cannot come up with a good solution for this, so that might mean the idea is shot - *however* - I would point out that the latest draft of TLS 1.3 [1] completely kills off the capability of the client to renegotiate a connection, meaning that this will no longer be possible anyway, and given it's a 1% kind of use case, that might be enough to let it slide. Combine this with what I consider to be the unlikelihood of this working with HTTP/2.0, and I would feel very safe assuming that nobody will ever actually do this. I would also note that, as you state later on, it would be possible to combine this solution with any other solution (including the proposed one) to cover both cases. And given that this is still (in my estimation) a "99%" solution, in my opinion it is still a viable candidate for adding this functionality to Java 8 as a first pass or stopgap as I described in my emails, particularly if the method(s) to establish/query the protocol names are a strict subset of the proposed Java 9 API (given that we cannot really overhaul the Java SE 8 API at this point). > [...] > 2. "SSLExplorer" or something similar is needed. > ================================================= > This approach depends on "examining SSLClientHello"s, but there isn't a > class for this other than some sample code from a previous attempt. I > am assuming that this approach would make such an external API a > necessity? Being able to parse possible ClientHello formats is not a > straightforward/easy job. This will add a fair amount of complexity, > and likely not an easy job in the remaining few weeks. It could be > added later for JDK 10 but that means apps would likely need to roll > their own for 9. And 8, yes, you definitely would need to roll your own, though Xuelei Fan already has a nice example up on his blog that was built for SNI (but uses the same principle). If it were me, I wouldn't even bother adding it even in JDK 10, since (a) it applies only to the server side and (b) there are a plethora of third-party server-side network I/O and security libraries which are natural candidates to host this type of logic. > 3. "no_application_protocol" > ============================= > If the server doesn't support the protocols that the client advertises, > the "no_application_protocol" must be thrown. We could add a > "no_application_protocol" protocol String that would flag such a > condition internally. Sure, though if you use the same method on both the client and server to specify the matched protocol, then the method necessarily accepts an array, in which case a null/unset could mean "no ALPN response" and an empty array could mean "no acceptable protocols". But yeah I agree otherwise. > 4. Much of this is already possible. > ===================================== > If we were to go with the current API/internal and apps provided their > own ClientHello scanner, many of the benefits of what was proposed are > already available. Apps can ask for the desired SSLContext, get the > SSLSocket/SSLengine, check the SNI/ALPN values, order/set the enabled > protocols/ciphers/etc + single ALPN value, then wrap the raw socket > using SSLSocketFactory.createSocket(Socket s, InputStream consumed, > boolean autoClose), and start the handshake. The internal code would > still call matches() but only once. If you want to be sure the > internals select the ApplicationProtocol, just put in a permissive > ApplicationProtocol. > > The API is still more complicated unfortunately as ApplicationProtocol > is still present, but the overall behavior is quite similar. +1 yep exactly. I would however turn it around and also say, a more complex API could later be added on top of this simpler proposed solution, especially after more real world data is acquired, which might lower the overall risk as well. > 5. Other failure mode/fallback. > ================================ > In the new proposal, suppose you do set a single ALPN value in the > application level, and the ServerHandshaker finds some other aspect of > the handshake wasn't appropriate (creds were mentioned several times, > but maybe a ciphersuite went dark due to new AlgorithmConstraints). This > would cause the ServerHandshaker to fail and there's no way to go back > to a different version unless you add a "for ALPN" loop into application. Yeah all that validation would have to be done up front or manually in whatever server configuration is relevant. If a cipher suite suddenly stops working, in the very worst case, the administrator would have to manually reconfigure to exclude it. > 6. "Only one new method on SSLSocket/SSLEngine to set the protocol list > (client) or selected single protocol (server)" > ============================================================== > I think you would need two, "use this value on the next handshake" and > "this was last negotiated/currently in effect." Sure, whichever way works best. Thanks for the reply! [1] https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-1.2 -- - DML From jamil.j.nimeh at oracle.com Tue Sep 29 16:35:40 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 29 Sep 2015 09:35:40 -0700 Subject: OCSP clock skew configuration In-Reply-To: <0F6322F01158F94EBDA664939D5EA15504F01580@HVXDSP25.us.lmco.com> References: <0F6322F01158F94EBDA664939D5EA15504F01580@HVXDSP25.us.lmco.com> Message-ID: <560ABDDC.6050705@oracle.com> Hi Usha, you might try setting the System property com.sun.security.ocsp.clockSkew. It takes an integer value for the clock skew in seconds. Give that a try and let me know how that works out. --Jamil On 09/29/2015 06:49 AM, Seshadri, Usha wrote: > > Hi, > > The following bug reports seems to indicate the OCSP validation code > should permit clock skew when checking the validity of OCSP responses. > > 1.JDK-674888 (Bug - affected version 6u11) > > 2.JDK-2166696 (Backport ? fixed version 6u10 (b32) > > 3.JDK-2186994 (Backport ? fixed version OpenJDK6 (b18) > > 4.JDK-2166740 (Backport ? fixed version 7 (b41)) > > I am using Java8, and would expect it to have all the above fixes. > Changing the value of ?deployment.security.validation.clockskew? has > no impact on the OCSP certification validation. The certificate > validation always defaults to 15 minutes. > > What configurable property (and what file) controls the OCSP > validation clock skew? Any answer will be greatly appreciated! > > Thanks, > > Usha Seshadri > > Lockheed Martin, IS&GS > > 301-240-7496 > > LM-logo > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3520 bytes Desc: not available URL: From sean.mullan at oracle.com Tue Sep 29 18:07:15 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 29 Sep 2015 14:07:15 -0400 Subject: RFR: 8129988: JSSE should create a single instance of the cacerts KeyStore Message-ID: <560AD353.1070802@oracle.com> Please review this fix to modify the TrustManagerFactory implementation to create a single instance of the cacerts or jssecacerts KeyStore. This significantly improves performance in a multithreaded environment. The code has been refactored a bit to move common code into a few private methods. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8129988/webrev.00/ Thanks, Sean From mstjohns at comcast.net Tue Sep 29 18:36:22 2015 From: mstjohns at comcast.net (Mike StJohns) Date: Tue, 29 Sep 2015 14:36:22 -0400 Subject: RFR 8056174: New APIs for jar signing In-Reply-To: <5609CE8F.2020805@oracle.com> References: <55DB22A9.40704@oracle.com> <55E54ACC.6020004@oracle.com> <55E8B010.70905@oracle.com> <5600AAE5.3010009@oracle.com> <5600CE49.1020604@oracle.com> <56099499.1020604@oracle.com> <5609CE8F.2020805@oracle.com> Message-ID: <560ADA26.2080908@comcast.net> Sorry for the late comment here - On 9/28/2015 7:34 PM, Weijun Wang wrote: > > > On 9/29/2015 3:27 AM, Sean Mullan wrote: >> Looks good, just a couple of comments: >> >> AlgorithmId: can you use braces around the conditional statements on >> lines 1008-1017? > > OK. I had a few issues with how this was coded. The first and probably most important is that you can't/shouldn't pick the default signature algorithm solely based on the key type, but instead on the key type and strength. The second is that even if you don't fix the above, its probably better to code this as a switch/case grouping rather than a series of if/then/else items. So changing this a bit: public static String getDefaultSigAlg (PrivateKey k) { switch (k.getAlgorithm.toUpperCase()) { case "EC": return ecStrength(((ECKey)k).getParams().getCurve().getField().getFieldSize()) + "withECDSA"; case "DSA": return ifcFfcStrength (((DSAKey)k).getParams().getP().bitLength()) + "withDSA"; case "RSA": return ifcFfcStrength (((RSAKey)k).getModulus().bitLength())+"withRSA"; default: return null; } // Values from SP800-57 part 1 rev 3 tables 2 and three static String ecStrength (int bitLength) { if (bitLength > 384) { // 256 bits of strength return "SHA512"; }else if (bitLength > 256) { // 192 bits of strength return "SHA384"; } else { // 128 bits of strength and less return "SHA256"; } } // same values for RSA and DSA static String ifcFfcStrength (int bitLength) { if (bitLength > 7680) { // 256 bits return "SHA512"; } else if (bitLength > 3072) { // 192 bits return "SHA384"; } else { // 128 bits and less return "SHA256"; } } > >> >> Function: are you missing an @modules tag for the jarsigner module? > > Which one? I thought @modules is only used if you want to call > non-exported classes. > >> >> Options.java: why not use the JarSigner API here instead of the >> jarsigner tool? > > This test is to make sure jarsigner still behaves correctly after it > is modified to be based on the JarSigner API. As for the API itself, I > use Function.java to check its function and Spec.java to check it's spec. > > I'll add some @summary. > > Thanks > Max > >> >> --Sean >> >> > http://cr.openjdk.java.net/~weijun/8056174/webrev.05/ >>> > > From weijun.wang at oracle.com Wed Sep 30 02:32:53 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 30 Sep 2015 10:32:53 +0800 Subject: RFR 8056174: New APIs for jar signing In-Reply-To: <560ADA26.2080908@comcast.net> References: <55DB22A9.40704@oracle.com> <55E54ACC.6020004@oracle.com> <55E8B010.70905@oracle.com> <5600AAE5.3010009@oracle.com> <5600CE49.1020604@oracle.com> <56099499.1020604@oracle.com> <5609CE8F.2020805@oracle.com> <560ADA26.2080908@comcast.net> Message-ID: <1393CFAD-34AC-4A8F-9ABE-DD863ABD54C7@oracle.com> > On 2015?9?30?, at ??2:36, Mike StJohns wrote: > > The first and probably most important is that you can't/shouldn't pick the default signature algorithm solely based on the key type, but instead on the key type and strength. Great. I'll pick up your suggested code. Thanks Max From xuelei.fan at oracle.com Wed Sep 30 02:33:11 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 30 Sep 2015 10:33:11 +0800 Subject: RFR: 8129988: JSSE should create a single instance of the cacerts KeyStore In-Reply-To: <560AD353.1070802@oracle.com> References: <560AD353.1070802@oracle.com> Message-ID: <560B49E7.9090608@oracle.com> private synchronized static KeyStore getDefaultCacertsKeyStore() ================================================================ --------------- private synchronized static KeyStore getDefaultCacertsKeyStore( String javaHome, String type, String provider, String password, String dbgOption) throws Exception { if (defaultCacertsKeyStore != null) { return defaultCacertsKeyStore; } --------------- Looks like the parameters would impact the returned value. However, as defaultCacertsKeyStore is singleton instance, these parameters have no impact any more after the initialization. This is a behavior change. The behavior change is OK to me, but we maybe want to add a comment or twist the method a little bit. For lazy static fields, I would like to use "Lazy initialization holder class idiom" [#71, Effective Java, 2ED], rather than synchronized method, for performance benefits. Thanks, Xuelei On 9/30/2015 2:07 AM, Sean Mullan wrote: > Please review this fix to modify the TrustManagerFactory implementation > to create a single instance of the cacerts or jssecacerts KeyStore. This > significantly improves performance in a multithreaded environment. > > The code has been refactored a bit to move common code into a few > private methods. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8129988/webrev.00/ > > Thanks, > Sean From mandy.chung at oracle.com Wed Sep 30 02:46:56 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 29 Sep 2015 19:46:56 -0700 Subject: RFR 8056174: New APIs for jar signing In-Reply-To: <5609CE8F.2020805@oracle.com> References: <55DB22A9.40704@oracle.com> <55E54ACC.6020004@oracle.com> <55E8B010.70905@oracle.com> <5600AAE5.3010009@oracle.com> <5600CE49.1020604@oracle.com> <56099499.1020604@oracle.com> <5609CE8F.2020805@oracle.com> Message-ID: <8AD69A3C-7F32-42D6-92D2-17050DAA0799@oracle.com> > On Sep 28, 2015, at 4:34 PM, Weijun Wang wrote: > >> >> Function: are you missing an @modules tag for the jarsigner module? > > Which one? I thought @modules is only used if you want to call non-exported classes. @modules can also be used to specify which modules this test requires that will be used for future test selection feature e.g. when running on an image with only specific modules but not all. For test/sun/security/tools/jarsigner/newapi/Function.java, you can add @modules jdk.jartool. BTW, the new tests should be under jdk/test/jdk/security/jarsigner directory following the existing convention (I guess Options.java should be test/sun/security/tools/jarsigner/Options.java). Instead of using sun.tools.jar.Main, can you use the test library (see jdk/test/lib/testlibrary/jdk/testlibrary/JarUtils.java)? Mandy From weijun.wang at oracle.com Wed Sep 30 02:56:47 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 30 Sep 2015 10:56:47 +0800 Subject: RFR 8056174: New APIs for jar signing In-Reply-To: <8AD69A3C-7F32-42D6-92D2-17050DAA0799@oracle.com> References: <55DB22A9.40704@oracle.com> <55E54ACC.6020004@oracle.com> <55E8B010.70905@oracle.com> <5600AAE5.3010009@oracle.com> <5600CE49.1020604@oracle.com> <56099499.1020604@oracle.com> <5609CE8F.2020805@oracle.com> <8AD69A3C-7F32-42D6-92D2-17050DAA0799@oracle.com> Message-ID: <5588F9B7-2971-47E2-A880-299EA8711923@oracle.com> > On 2015?9?30?, at ??10:46, Mandy Chung wrote: > > >> On Sep 28, 2015, at 4:34 PM, Weijun Wang wrote: >> >>> >>> Function: are you missing an @modules tag for the jarsigner module? >> >> Which one? I thought @modules is only used if you want to call non-exported classes. > > @modules can also be used to specify which modules this test requires that will be used for future test selection feature e.g. when running on an image with only specific modules but not all. > > For test/sun/security/tools/jarsigner/newapi/Function.java, you can add @modules jdk.jartool. I see. > > BTW, the new tests should be under jdk/test/jdk/security/jarsigner directory following the existing convention (I guess Options.java should be test/sun/security/tools/jarsigner/Options.java). OK. > > Instead of using sun.tools.jar.Main, can you use the test library (see jdk/test/lib/testlibrary/jdk/testlibrary/JarUtils.java)? Will try. Thanks Max > > Mandy > From weijun.wang at oracle.com Wed Sep 30 03:12:50 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 30 Sep 2015 11:12:50 +0800 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: References: Message-ID: <7659C060-0EBC-4FC2-B20E-9CCB3B93A2C5@oracle.com> Can you describe if there is any effect on signed jars? Including: 1. Will jarsigner be able to sign such a jar? Are all items inside signed? If you sign a jar using jarsigner from different versions of JDK, will there be any difference? 2. Will jarsigner be able to verify such a jar? Will it only verify entries for the current version or all? Will jarsigner from an old JDK verify the new jar? 3. As I know, JarFile has 2 ways to verify a jar file, one using public APIs. One through SharedSecrets.setJavaUtilJarAccess() which can call more methods. Have you confirmed both work? Yes, I'd also like some tests on these. Thanks Max > On 2015?9?30?, at ??2:13, Steve Drach wrote: > > Hi, > > Please review the following webrev that adds support for multi-release jars as specified in JEP-238. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 > JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 > Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ > > A multi-release jar file is a jar file that contains a manifest with a main attribute named "Multi-Release", and also contains a directory "META-INF/versions" with subdirectories that contain versioned entries segregated by the major version of Java platform releases. A versioned entry, with a version n, in the "META-INF/versions/{n}" directory overrides the unversioned root entry as well as any entry with a version number i where i < n. > > The changes in this webrev implement an aliasing mechanism in JarEntry so that when a JarFile client retrieves a JarEntry, the data from the entry pointed to by the alias is returned. There are methods to configure whether or not aliasing is enabled, and if it is, which version of an entry the alias points to. > > When a JarFile is used by a class loader to load class resources, the default version retrieved is the runtime version of the Java platform (i.e. a version 9 entry is returned when the platform is JDK 9). This mechanism can be configured by System properties. > > Thanks, > Steve From sean.mullan at oracle.com Wed Sep 30 13:44:24 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 30 Sep 2015 09:44:24 -0400 Subject: RFR: 8129988: JSSE should create a single instance of the cacerts KeyStore In-Reply-To: <560B49E7.9090608@oracle.com> References: <560AD353.1070802@oracle.com> <560B49E7.9090608@oracle.com> Message-ID: <560BE738.6070003@oracle.com> On 9/29/15 10:33 PM, Xuelei Fan wrote: > private synchronized static KeyStore getDefaultCacertsKeyStore() > ================================================================ > > --------------- > private synchronized static KeyStore getDefaultCacertsKeyStore( > String javaHome, String type, > String provider, String password, > String dbgOption) throws Exception { > if (defaultCacertsKeyStore != null) { > return defaultCacertsKeyStore; > } > --------------- > > Looks like the parameters would impact the returned value. However, as > defaultCacertsKeyStore is singleton instance, these parameters have no > impact any more after the initialization. This is a behavior change. > The behavior change is OK to me, but we maybe want to add a comment or > twist the method a little bit. This is true, but I don't think this is really a legitimate use case. First, changing the system properties while an app is running is not going to work very well in a multithreaded environment. Second, even in a single threaded case, I can't think of a valid use case where you would want to use the jssecacerts/cacerts file (i.e. javax.net.ssl.trustStore is not set) and subsequently change the values of the keystore type, provider or password system properties while the app was running. Note that this behavior is still supported as before if you do set the javax.net.ssl.trustStore property, and the properties are read and used each time to create a new KeyStore instance. I agree a comment would be helpful though, so I will add that. If you think we should also release note this, let me know. > For lazy static fields, I would like to use "Lazy initialization holder > class idiom" [#71, Effective Java, 2ED], rather than synchronized > method, for performance benefits. Good point, although I am a bit wary of using that pattern in this case because it can throw an Exception. See "Only One Chance To Initialize" at https://en.wikipedia.org/wiki/Initialization-on-demand_holder_idiom --Sean > > Thanks, > Xuelei > > On 9/30/2015 2:07 AM, Sean Mullan wrote: >> Please review this fix to modify the TrustManagerFactory implementation >> to create a single instance of the cacerts or jssecacerts KeyStore. This >> significantly improves performance in a multithreaded environment. >> >> The code has been refactored a bit to move common code into a few >> private methods. >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8129988/webrev.00/ >> >> Thanks, >> Sean > From xuelei.fan at oracle.com Wed Sep 30 15:50:31 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 30 Sep 2015 23:50:31 +0800 Subject: RFR: 8129988: JSSE should create a single instance of the cacerts KeyStore In-Reply-To: <560BE738.6070003@oracle.com> References: <560AD353.1070802@oracle.com> <560B49E7.9090608@oracle.com> <560BE738.6070003@oracle.com> Message-ID: <560C04C7.9020005@oracle.com> On 9/30/2015 9:44 PM, Sean Mullan wrote: > On 9/29/15 10:33 PM, Xuelei Fan wrote: >> private synchronized static KeyStore getDefaultCacertsKeyStore() >> ================================================================ >> >> --------------- >> private synchronized static KeyStore getDefaultCacertsKeyStore( >> String javaHome, String type, >> String provider, String password, >> String dbgOption) throws Exception { >> if (defaultCacertsKeyStore != null) { >> return defaultCacertsKeyStore; >> } >> --------------- >> >> Looks like the parameters would impact the returned value. However, as >> defaultCacertsKeyStore is singleton instance, these parameters have no >> impact any more after the initialization. This is a behavior change. >> The behavior change is OK to me, but we maybe want to add a comment or >> twist the method a little bit. > > This is true, but I don't think this is really a legitimate use case. > First, changing the system properties while an app is running is not > going to work very well in a multithreaded environment. Second, even in > a single threaded case, I can't think of a valid use case where you > would want to use the jssecacerts/cacerts file (i.e. > javax.net.ssl.trustStore is not set) and subsequently change the values > of the keystore type, provider or password system properties while the > app was running. Note that this behavior is still supported as before if > you do set the javax.net.ssl.trustStore property, and the properties are > read and used each time to create a new KeyStore instance. > > I agree a comment would be helpful though, so I will add that. If you > think we should also release note this, let me know. > I agree the impact should be very limited in practice, may not worthy a CCC request or release note. Add a comment should be sufficient in case code readers get confused. >> For lazy static fields, I would like to use "Lazy initialization holder >> class idiom" [#71, Effective Java, 2ED], rather than synchronized >> method, for performance benefits. > > Good point, although I am a bit wary of using that pattern in this case > because it can throw an Exception. See "Only One Chance To Initialize" > at https://en.wikipedia.org/wiki/Initialization-on-demand_holder_idiom > Exceptions can be swallowed for "null" value, I think. Xuelei > --Sean > >> >> Thanks, >> Xuelei >> >> On 9/30/2015 2:07 AM, Sean Mullan wrote: >>> Please review this fix to modify the TrustManagerFactory implementation >>> to create a single instance of the cacerts or jssecacerts KeyStore. This >>> significantly improves performance in a multithreaded environment. >>> >>> The code has been refactored a bit to move common code into a few >>> private methods. >>> >>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8129988/webrev.00/ >>> >>> Thanks, >>> Sean >> From andreas.laumann at exceet.de Wed Sep 30 12:41:32 2015 From: andreas.laumann at exceet.de (Laumann Andreas) Date: Wed, 30 Sep 2015 12:41:32 +0000 Subject: Brainpool curves In-Reply-To: <5602C4D5.8040702@primekey.se> References: <84b37f14179b57a34c10d0596b6f7dc0@protonmail.ch> <55FAFE23.1030502@oracle.com> <5602C4D5.8040702@primekey.se> Message-ID: <1443616891.5777.1.camel@seth.inexnet.de> Am Mittwoch, den 23.09.2015, 17:27 +0200 schrieb Tomas Gustavsson: > +1 for this. +1 also from my side. Brainpool is really important in Europe. > > On 2015-09-17 19:53, Sean Mullan wrote: > > On 08/19/2015 05:48 PM, Jiri Stary wrote: > >> Hello, > >> > >> do you plan to support brainpool curves for TLS in Java 9 (RFC 7027) ? > > > > There is no plan to support it in 9. There is an open RFE for supporting > > brainpool in JCE: https://bugs.openjdk.java.net/browse/JDK-7007966 but > > no specific release has been targeted at this time. > > > > --Sean > > > >> > >> Regards > >> Jiri > >> > >> Sent from ProtonMail , encrypted email based in > >> Switzerland. -- How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" ----------------------------------------------------------------------------- Andreas Laumann Phone: +49(0) 211 436 989 0 Head of SW Development Fax: +49(0) 211 436 989 19 Exceet Secure Solutions AG Mail: Andreas.Laumann at exceet.de Rethelstra?e 47 Web: http://www.exceet-secure-solutions.de D - 40237 D?sseldorf/ Germany HR: D?sseldorf 4436 ________________________________ exceet Secure Solutions AG Rethelstra?e 47 40237 D?sseldorf/ Deutschland HR D?sseldorf 44361 www.exceet-secure-solutions.de Vorstand: Christian Methe (CEO), Christian Schmitz Aufsichtsratsvorsitzender: Wolf-G?nter Freese From steve.drach at oracle.com Wed Sep 30 18:30:40 2015 From: steve.drach at oracle.com (Steve Drach) Date: Wed, 30 Sep 2015 11:30:40 -0700 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <7659C060-0EBC-4FC2-B20E-9CCB3B93A2C5@oracle.com> References: <7659C060-0EBC-4FC2-B20E-9CCB3B93A2C5@oracle.com> Message-ID: <3FAC60D0-97D6-46E5-A235-075317989275@oracle.com> Hi Max, > Can you describe if there is any effect on signed jars? Including: > > 1. Will jarsigner be able to sign such a jar? The jarsigner from 1.8.0_51 can sign the jar. The jarsigner from jdk9/dev can not, giving me the error jarsigner: unable to sign jar: javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty I?m unsure what that means, and searching for it has not turned up anything useful except that it might be limited to Mac OS/X. If anyone can help me here, I?d appreciate it. > Are all items inside signed? Yes, according to the manifest and the .sf file > If you sign a jar using jarsigner from different versions of JDK, will there be any difference? Not sure yet due to the previously mentioned error I get with JDK 9 jarsigner > > 2. Will jarsigner be able to verify such a jar? Yes. Both the JDK 8 and JDK 9 jarsigners can verify the file originally signed by JDK 8 jarsigner > Will it only verify entries for the current version or all? It should be all, but of course that depends on how jarsigner accesses the JarFile entries. If it just opens the JarFile and uses the Enumeration returned by JarFile.entries() or the stream returned by JarFile.stream() then it will see all entries including all versions of entries. As a simple test, I modified a versioned entry and then ran both the JDK 8 and JDK 9 jarsigners to verify the jar file. The modified entry was caught (i.e. verification failed) > Will jarsigner from an old JDK verify the new jar? I can?t sign the jar with the JDK 9 jar signer, so I can?t answer that yet. > > 3. As I know, JarFile has 2 ways to verify a jar file, one using public APIs. One through SharedSecrets.setJavaUtilJarAccess() which can call more methods. Have you confirmed both work? I?ve only verified it with the jarsigner tool. Without looking at the code, I suspect the tool uses the public API?s, so I?ll need to come up with something that uses the SharedSecrets API. I will do that. > > Yes, I'd also like some tests on these. Sure. From steve.drach at oracle.com Wed Sep 30 23:53:22 2015 From: steve.drach at oracle.com (Steve Drach) Date: Wed, 30 Sep 2015 16:53:22 -0700 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <7659C060-0EBC-4FC2-B20E-9CCB3B93A2C5@oracle.com> References: <7659C060-0EBC-4FC2-B20E-9CCB3B93A2C5@oracle.com> Message-ID: Hi Max, Here are updated answers to your questions, after I received some help (thank you Sean Mullan). > Can you describe if there is any effect on signed jars? Including: > > 1. Will jarsigner be able to sign such a jar? The jarsigner from 1.8.0_51 can sign the jar. The jarsigner from jdk9/dev can also sign the jar. > Are all items inside signed? Yes, according to the manifest and the .sf file > If you sign a jar using jarsigner from different versions of JDK, will there be any difference? Yes, there is unfortunately. This is what I found out: - JDK 8 jar signer does not work with a JDK 9 created keystore - JDK 8 signed jar with JDK 8 created keystore is not the same size as JDK 9 signed jar with JDK 9 keystore - JDK 8 signed jar with JDK 8 created keystore is not the same size as JDK 9 signed jar with the same JDK 8 keystore I am not sure what factors are in play here, but something certainly depends on what version of keytool is used to create the keystone. The last fact above seems to imply the answer to your question is yes, there is a difference as measured by jar file size. The META-INF/ALIAS.SF and META-INF/ALIAS.DSA files are different sizes in each jar file. If somebody has an idea on how to analyze this, please let me know. I?m a bit clueless at the moment. > > 2. Will jarsigner be able to verify such a jar? Yes. Both the JDK 8 and JDK 9 jarsigners can verify both the signed files, one from JDK 8 and one from JDK 9 > Will it only verify entries for the current version or all? It should be all, but of course that depends on how jarsigner accesses the JarFile entries. If it just opens the JarFile and uses the Enumeration returned by JarFile.entries() or the stream returned by JarFile.stream() then it will see all entries including all versions of entries. As a simple test, I modified a versioned entry and then ran both the JDK 8 and JDK 9 jarsigners to verify the jar file. The modified entry was caught (i.e. verification failed) > Will jarsigner from an old JDK verify the new jar? Yes, see answer to question 2. > > 3. As I know, JarFile has 2 ways to verify a jar file, one using public APIs. One through SharedSecrets.setJavaUtilJarAccess() which can call more methods. Have you confirmed both work? I?ve only verified it with the jarsigner tool. Without looking at the code, I suspect the tool uses the public API?s, so I?ll need to come up with something that uses the SharedSecrets API. I will do that. > > Yes, I'd also like some tests on these. Sure.