From valerie.peng at oracle.com Thu Feb 1 00:07:22 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 31 Jan 2018 16:07:22 -0800 Subject: PKCS#11 provider issues with min and max size In-Reply-To: <97ca28d8-8466-9f9f-c19d-567b38f7a0f7@primekey.se> References: <97ca28d8-8466-9f9f-c19d-567b38f7a0f7@primekey.se> Message-ID: <276cc36a-7967-d4fb-ce98-f0d8b6b43681@oracle.com> Thanks for the feedback. I suppose we can ignore values which obviously don't make sense such as 0 or max being less than min key size. However, if the underlying PKCS11 library vendors forgot to update the max value as in your comment#2, supposedly they should fix it. I am not too keen to add an env var/system property to accommodate this kind of PKCS11 library bugs since this should be rare I hope. Valerie On 1/30/2018 12:22 AM, Tomas Gustavsson wrote: > Hi, > > At some revision in the PKCS#11 provider there was introduced checking > of C_GetMechanismInfo min and max sizes. > > This has turned out to be a bit fragile. Let me give two real world > examples: > > 1. Amazon Cloud HSM report minSize and maxSize for EC keys to 0. The > Java PKCS#11 provider will happily take 0 as maxSize and refuse to > generate any EC keys at all. Needless to say, without the Java check it > would be no problem. > > 131: C_GetMechanismInfo > 2018-01-30 07:52:20.740 > [in] slotID = 0x1 > CKM_EC_KEY_PAIR_GEN > [out] pInfo: > CKM_EC_KEY_PAIR_GEN : min:0 max:0 flags:0x10001 ( Hardware > KeyPair ) > Returned: 0 CKR_OK > > (we are reporting this to Amazon as well) > > 2. Thales HSMs (some?) report maxSize for RSA_PKCS key generation as > 4096, but will happily generate 8192 bit keys. I.e. the reported maxSize > is not true. > We have customers who used to generate 8192 bit RSA keys, but after a > Java update can not do so anymore, because Java compares against this value. > > > * Suggestions: > > 1. In the constructor of P11KeyPairGenerator where minKeyLen and > maxKeyLen are calculated, never allow maxKeyLen to be less than minKeyLen. > > I.e. change the part: > // auto-adjust default keysize in case it's out-of-range > if ((minKeyLen != -1) && (keySize < minKeyLen)) { > keySize = minKeyLen; > } > if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { > keySize = maxKeyLen; > } > > To include something like: > // auto-adjust default keysize in case it's out-of-range > if ((minKeyLen != -1) && (keySize < minKeyLen)) { > keySize = minKeyLen; > } > if ((maxKeyLen != -1) && (maxKeyLen < minKeyLen)) { > maxKeyLen = minKeyLen; > } > if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { > keySize = maxKeyLen; > } > > 2. Allow to ignore checking of maxKeyLen by some means, i.e. allow to > ignore checking against C_GetMechanismInfo if you know that the HSM does > not provide sane values. I.e. an environment variable for example > reverting back to the old behavior when these were ignored. > > Regards, > Tomas Gustavsson > From valerie.peng at oracle.com Thu Feb 1 00:13:29 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 31 Jan 2018 16:13:29 -0800 Subject: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: References: Message-ID: <42dcb5c2-0d98-1ae4-a26d-b79e0a5c9345@oracle.com> Hi Martin, Thanks for providing us with the patch. Recently, JDK workspace has been restructured a bit, do you have an updated webrev? Your changes mostly look fine, but I think we should allow 3rd party providers to have similar support. For this, we need to have more public APIs such as those classes under sun.security.internal.spec package and possibly more. What do you think? Thanks, Valerie On 11/10/2017 6:38 AM, Martin Balao wrote: > Hi, > > I would like to propose a patch for JDK-8029661: JDK-Support TLS v1.2 > algorithm in SunPKCS11 provider [1]. > > ?* > http://cr.openjdk.java.net/~akasko/mbalao/jdk_8029661_tls_12_sunpkcs11/2017_11_09/8029661.webrev.01/ > > (browse online) > ?* > http://cr.openjdk.java.net/~akasko/mbalao/jdk_8029661_tls_12_sunpkcs11/2017_11_09/8029661.webrev.01.zip > > (download) > > The following algorithms have been implemented in SunPKCS11 provider > (based on PKCS#11 v2.40 mechanisms): > > ?* SunTls12RsaPremasterSecret > ?* SunTls12MasterSecret > ?* SunTls12KeyMaterial > ?* SunTls12Prf > > A minor API change is proposed to expose TLS ProtocolVersion constants > (SSL30, TLS10, TLS11, etc.) from java.base to jdk.crypto.cryptoki > module. This allows to remove hardcoded TLS int constants in SunPKCS11 > classes (required when implementing "Tls"-like algorithms). > > A test case is included with the following: > > ?* TLS 1.2 communication using SunPKCS11 + NSS (in FIPS mode) > ?* Algorithms test against SunJCE > > Regards, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8029661 From mbalao at redhat.com Thu Feb 1 18:06:15 2018 From: mbalao at redhat.com (Martin Balao) Date: Thu, 1 Feb 2018 15:06:15 -0300 Subject: RFR JDK-8195607: NSS + Sqlite DB Message-ID: I'd like to propose a fix for JDK-8195607 (sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with "NSS initialization failed" on NSS 3.34.1) [1]: * http://cr.openjdk.java.net/~akasko/mbalao/8195607_nss_sqlite /8195607.webrev.01/ * http://cr.openjdk.java.net/~akasko/mbalao/8195607_nss_sqlite /8195607.webrev.01.zip Kind regards, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8195607 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbalao at redhat.com Thu Feb 1 19:25:05 2018 From: mbalao at redhat.com (Martin Balao) Date: Thu, 1 Feb 2018 16:25:05 -0300 Subject: contribute to the OpenJDK security group In-Reply-To: <344a2d12-9560-e407-39e5-1ec0ed43b285@redhat.com> References: <0100016101db8f7d-19737975-67eb-4dab-ba94-c68d46746ab9-000000@email.amazonses.com> <0100016105867b86-27ab95e1-97ea-4118-bda9-1680dadcf318-000000@email.amazonses.com> <44867b0b-ecde-8037-f48b-b3aa51c44d64@primekey.se> <344a2d12-9560-e407-39e5-1ec0ed43b285@redhat.com> Message-ID: Hi Tomas, As Andrew said, I've been working on some SunPKCS11 improvements related to native memory leaking. You can find details of this work here [1]. Feedback is always welcomed. What do you mean with "more flexibility"? -- [1] - http://mail.openjdk.java.net/pipermail/security-dev/2017-October/016400.html On Wed, Jan 24, 2018 at 8:06 AM, Andrew Haley wrote: > On 24/01/18 10:39, Tomas Gustavsson wrote: > > Imho the P11 layer always needs attention. To work properly we're > > relying on some patches, where parts was recently merged into OpenJDK. > > We just started testing the Amazon CloudHSM, and that requires changes > > to SunPKCS11 as well to work. Not always bad in SunPKCS11 as some P11 > > libraries out there do strange non-conforming stuff, but there's room > > for more flexibility nevertheless. > > Martin Balao has been heavily reworking this layer because it leaks > native memory. I'll let him fill you in on the details. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbalao at redhat.com Mon Feb 5 13:51:05 2018 From: mbalao at redhat.com (Martin Balao) Date: Mon, 5 Feb 2018 10:51:05 -0300 Subject: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: <42dcb5c2-0d98-1ae4-a26d-b79e0a5c9345@oracle.com> References: <42dcb5c2-0d98-1ae4-a26d-b79e0a5c9345@oracle.com> Message-ID: Hi Valerie, Thanks for your review. Here it's the new webrev updated to the new repository structure. I've also updated the testcase to use the new @module jtreg feature: * http://cr.openjdk.java.net/~akasko/mbalao/jdk_8029661_tls_12_sunpkcs11/2018_02_02/8029661.webrev.02 (online) * http://cr.openjdk.java.net/~akasko/mbalao/jdk_8029661_tls_12_sunpkcs11/2018_02_02/8029661.webrev.02.zip (download) A few comments in regards to creating public APIs from sun.security.internal.spec classes. Classes in jdk/src/java.base/share/classes/sun/security/internal/spec: * TlsKeyMaterialParameterSpec.java * TlsMasterSecretParameterSpec.java * TlsRsaPremasterSecretParameterSpec.java * TlsKeyMaterialSpec.java * TlsPrfParameterSpec.java Classes in jdk/src/java.base/share/classes/java/security/spec (which I assume would be the destination): * AlgorithmParameterSpec.java * ECGenParameterSpec.java * InvalidParameterSpecException.java * RSAOtherPrimeInfo.java * DSAGenParameterSpec.java * ECParameterSpec.java * KeySpec.java * ... TlsRsaPremasterSecretParameterSpec class contains information about min and max SSL/TLS version and, optionally, the pre-master encoded key. This information may be useful to any 3rd party class that implements a KeyGenerator to generate RSA pre-master secrets. TlsMasterSecretParameterSpec class contains information (client/server random, pre-master secret, hash algorithm, etc.) to generate a master secret from a pre-master secret. TlsKeyMaterialParameterSpec class contains information (client/server random, master secret, hash algorithm, etc.) to generate keys for a session from a master secret. TlsPrfParameterSpec class contains information (secret key, label, hash algorithm, etc.) to generate handshake authentication codes. TlsKeyMaterialSpec class contains information about session keys. This class inherits from SecretKey class. So, I agree with you: these parameters/specs may be used by a 3rd party and would be better to have them as public interfaces. However, I suggest to address that in a new ticket because: * it is not strictly inherent to SunPKCS11 + TLS 1.2 support we are providing in the context of this ticket; * it would be more clear both in tickets documentation and repository changeset; * this refactoring is going to go through CSR, which SunPKCS11 + TLS 1.2 support does not need; and, * we should also evaluate how TLS 1.3 changes going to impact into this. Would splitting this into a new ticket work for you? Kind regards, Martin.- -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.petcher at oracle.com Mon Feb 5 19:26:31 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 5 Feb 2018 14:26:31 -0500 Subject: RFR 8194251: Deadlock between UsageTracker and System.getProperty() when using a malformed security policy Message-ID: <98dcebbb-545e-0e6f-c21c-4b31a081553d@oracle.com> Please review the following change: JBS: https://bugs.openjdk.java.net/browse/JDK-8194251 Webrev: http://cr.openjdk.java.net/~apetcher/8194251/webrev.00/ We ran into a problem related to loading locale data when a security policy file is malformed. The parse error is localized and printed, which requires the locale data to be loaded, which triggers a security policy check, which results in deadlock or infinite recursion. This change removes localization from all messages during policy file parsing and loading. I believe that this behavior is acceptable according to our localization requirements. I removed the code that tried to determine whether localization would succeed, because making it work reliably would be difficult. Now the client of LocalizedMessage will need to explicitly state whether the message should be localized or not. From mandy.chung at oracle.com Mon Feb 5 23:35:57 2018 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 5 Feb 2018 15:35:57 -0800 Subject: RFR 8194251: Deadlock between UsageTracker and System.getProperty() when using a malformed security policy In-Reply-To: <98dcebbb-545e-0e6f-c21c-4b31a081553d@oracle.com> References: <98dcebbb-545e-0e6f-c21c-4b31a081553d@oracle.com> Message-ID: <607db1f7-2650-ed70-6dfc-f8e5ac2a1217@oracle.com> This looks fine to me. Mandy On 2/5/18 11:26 AM, Adam Petcher wrote: > Please review the following change: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8194251 > Webrev: http://cr.openjdk.java.net/~apetcher/8194251/webrev.00/ > > We ran into a problem related to loading locale data when a security > policy file is malformed. The parse error is localized and printed, > which requires the locale data to be loaded, which triggers a security > policy check, which results in deadlock or infinite recursion. > > This change removes localization from all messages during policy file > parsing and loading. I believe that this behavior is acceptable > according to our localization requirements. I removed the code that > tried to determine whether localization would succeed, because making > it work reliably would be difficult. Now the client of > LocalizedMessage will need to explicitly state whether the message > should be localized or not. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Feb 6 09:39:50 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 6 Feb 2018 17:39:50 +0800 Subject: RFR (fix+CSR) 8196823: jarsigner should not create a signed jar if the signing fails Message-ID: <07A25D37-5D3B-42F5-8063-2520C26DED58@oracle.com> Please review the following JBS: https://bugs.openjdk.java.net/browse/JDK-8196823 CSR: https://bugs.openjdk.java.net/browse/JDK-8196845 Fix: http://cr.openjdk.java.net/~weijun/8196823/webrev.00/ Some note: 1. I copied the spec from InputStream:transferTo. 2. In jarsigner.Main, error() calls exit(1), so the delete call cannot be put inside the finally block. Thanks Max From adam.petcher at oracle.com Tue Feb 6 18:36:11 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 6 Feb 2018 13:36:11 -0500 Subject: RFR 8171277: Elliptic Curves for Security in Crypto Message-ID: Webrev: http://cr.openjdk.java.net/~apetcher/8171277/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8171277 Please review this change that adds key agreement via the X25519 and X448 elliptic curve functions to the JCA API and SunEC provider. These functions and related operations and encodings are described in RFC 7748[1]. This work does not include JSSE integration, which will be done later as a separate task (not part of JEP 324). The webrev does not include the field arithmetic code, which is being reviewed separately[2]. This change is a part of JEP 324, so it will not be integrated into the repo until all work for that JEP is complete and it has been targeted to a release. [1] https://tools.ietf.org/html/rfc7748 [2] http://mail.openjdk.java.net/pipermail/security-dev/2018-January/016756.html From sean.mullan at oracle.com Tue Feb 6 20:46:02 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 6 Feb 2018 15:46:02 -0500 Subject: RFR 8194251: Deadlock between UsageTracker and System.getProperty() when using a malformed security policy In-Reply-To: <98dcebbb-545e-0e6f-c21c-4b31a081553d@oracle.com> References: <98dcebbb-545e-0e6f-c21c-4b31a081553d@oracle.com> Message-ID: Looks good. --Sean On 2/5/18 2:26 PM, Adam Petcher wrote: > Please review the following change: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8194251 > Webrev: http://cr.openjdk.java.net/~apetcher/8194251/webrev.00/ > > We ran into a problem related to loading locale data when a security > policy file is malformed. The parse error is localized and printed, > which requires the locale data to be loaded, which triggers a security > policy check, which results in deadlock or infinite recursion. > > This change removes localization from all messages during policy file > parsing and loading. I believe that this behavior is acceptable > according to our localization requirements. I removed the code that > tried to determine whether localization would succeed, because making it > work reliably would be difficult. Now the client of LocalizedMessage > will need to explicitly state whether the message should be localized or > not. > From sean.mullan at oracle.com Tue Feb 6 21:18:05 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 6 Feb 2018 16:18:05 -0500 Subject: RFR (fix+CSR) 8196823: jarsigner should not create a signed jar if the signing fails In-Reply-To: <07A25D37-5D3B-42F5-8063-2520C26DED58@oracle.com> References: <07A25D37-5D3B-42F5-8063-2520C26DED58@oracle.com> Message-ID: Looks good. --Sean On 2/6/18 4:39 AM, Weijun Wang wrote: > Please review the following > > JBS: https://bugs.openjdk.java.net/browse/JDK-8196823 > CSR: https://bugs.openjdk.java.net/browse/JDK-8196845 > Fix: http://cr.openjdk.java.net/~weijun/8196823/webrev.00/ > > Some note: > > 1. I copied the spec from InputStream:transferTo. > > 2. In jarsigner.Main, error() calls exit(1), so the delete call cannot be put inside the finally block. > > Thanks > Max > From adam.petcher at oracle.com Wed Feb 7 16:19:48 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 7 Feb 2018 11:19:48 -0500 Subject: RFR 8196215: sun/security/util/Resources/customSysClassLoader/MessageFormatting.java failed on ar_SA locale. Message-ID: <7dd39fa5-df86-d2a0-9e65-73232d81068d@oracle.com> Webrev: http://cr.openjdk.java.net/~apetcher/8196215/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8196215 Please review this minor test bug fix. The test in question ensures that the basic message formatting that occurs during policy initialization works correctly. Formatted messages are compared to the ones produced by the MessageFormat class. The basic formatting is intended to mimic the behavior of formatting in the en_US locale, but the MessageFormat object in the test will format messages using the default locale, which may cause the test to fail. This fix sets the locale to en_US in the MessageFormat object used in the test. From sean.mullan at oracle.com Wed Feb 7 17:33:00 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 7 Feb 2018 12:33:00 -0500 Subject: RFR 8196215: sun/security/util/Resources/customSysClassLoader/MessageFormatting.java failed on ar_SA locale. In-Reply-To: <7dd39fa5-df86-d2a0-9e65-73232d81068d@oracle.com> References: <7dd39fa5-df86-d2a0-9e65-73232d81068d@oracle.com> Message-ID: This looks fine although I don't really think you need the othervm on line 36; that seems like something that is done separately as part of testing all of the tests on different locales. --Sean On 2/7/18 11:19 AM, Adam Petcher wrote: > Webrev: http://cr.openjdk.java.net/~apetcher/8196215/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8196215 > > Please review this minor test bug fix. The test in question ensures that > the basic message formatting that occurs during policy initialization > works correctly. Formatted messages are compared to the ones produced by > the MessageFormat class. The basic formatting is intended to mimic the > behavior of formatting in the en_US locale, but the MessageFormat object > in the test will format messages using the default locale, which may > cause the test to fail. This fix sets the locale to en_US in the > MessageFormat object used in the test. > From adam.petcher at oracle.com Wed Feb 7 19:26:48 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 7 Feb 2018 14:26:48 -0500 Subject: RFR 8196215: sun/security/util/Resources/customSysClassLoader/MessageFormatting.java failed on ar_SA locale. In-Reply-To: References: <7dd39fa5-df86-d2a0-9e65-73232d81068d@oracle.com> Message-ID: <5574c200-c65d-a165-c512-457e3ee8697a@oracle.com> On 2/7/2018 12:33 PM, Sean Mullan wrote: > This looks fine although I don't really think you need the othervm on > line 36; that seems like something that is done separately as part of > testing all of the tests on different locales. I included that line as a regression test for this bug. I would prefer to keep it, because it uses a locale that is known to cause problems for (earlier versions of) this test. I don't know how common these problematic locales are, and how often the test suite is run under them. If there is a regression here, it would be nice to know about it before release testing. Do you expect this @run line to cause any problems (other than being unnecessary)? > > --Sean > From xuelei.fan at oracle.com Wed Feb 7 19:37:26 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 7 Feb 2018 11:37:26 -0800 Subject: RFR 8196215: sun/security/util/Resources/customSysClassLoader/MessageFormatting.java failed on ar_SA locale. In-Reply-To: <7dd39fa5-df86-d2a0-9e65-73232d81068d@oracle.com> References: <7dd39fa5-df86-d2a0-9e65-73232d81068d@oracle.com> Message-ID: Looks fine to me. Maybe, you can use the constructor of: MessageFormat(String pattern, Locale locale) // Locale.ENGLISH Xuelei On 2/7/2018 8:19 AM, Adam Petcher wrote: > Webrev: http://cr.openjdk.java.net/~apetcher/8196215/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8196215 > > Please review this minor test bug fix. The test in question ensures that > the basic message formatting that occurs during policy initialization > works correctly. Formatted messages are compared to the ones produced by > the MessageFormat class. The basic formatting is intended to mimic the > behavior of formatting in the en_US locale, but the MessageFormat object > in the test will format messages using the default locale, which may > cause the test to fail. This fix sets the locale to en_US in the > MessageFormat object used in the test. > From adam.petcher at oracle.com Wed Feb 7 20:01:00 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 7 Feb 2018 15:01:00 -0500 Subject: RFR 8196215: sun/security/util/Resources/customSysClassLoader/MessageFormatting.java failed on ar_SA locale. In-Reply-To: References: <7dd39fa5-df86-d2a0-9e65-73232d81068d@oracle.com> Message-ID: <98fdf21d-1e3b-d33d-f69e-ffb1d30e9ac6@oracle.com> On 2/7/2018 2:37 PM, Xuelei Fan wrote: > Looks fine to me. > > Maybe, you can use the constructor of: > ??? MessageFormat(String pattern, Locale locale) > ??? // Locale.ENGLISH I use that constructor of MessageFormat, but I don't use one of the constants because there doesn't appear to be a constant for en_US. As far as I know, I can't use Locale.ENGLISH because it doesn't necessarily specify US English. I suppose I could use constants like this: Locale loc = new Locale(Locale.ENGLISH.getLanguage(), Locale.US.getCountry()); MessageFormat format = new MessageFormat(str, loc) But that doesn't seem like much of an improvement. > > Xuelei > From sean.mullan at oracle.com Wed Feb 7 20:01:21 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 7 Feb 2018 15:01:21 -0500 Subject: RFR 8196215: sun/security/util/Resources/customSysClassLoader/MessageFormatting.java failed on ar_SA locale. In-Reply-To: <5574c200-c65d-a165-c512-457e3ee8697a@oracle.com> References: <7dd39fa5-df86-d2a0-9e65-73232d81068d@oracle.com> <5574c200-c65d-a165-c512-457e3ee8697a@oracle.com> Message-ID: <88b263a9-b98f-a046-50a8-791e28302321@oracle.com> On 2/7/18 2:26 PM, Adam Petcher wrote: > On 2/7/2018 12:33 PM, Sean Mullan wrote: > >> This looks fine although I don't really think you need the othervm on >> line 36; that seems like something that is done separately as part of >> testing all of the tests on different locales. > > I included that line as a regression test for this bug. I would prefer > to keep it, because it uses a locale that is known to cause problems for > (earlier versions of) this test. I don't know how common these > problematic locales are, and how often the test suite is run under them. > If there is a regression here, it would be nice to know about it before > release testing. > > Do you expect this @run line to cause any problems (other than being > unnecessary)? I guess it's fine; it is just that I have seen default locale test bugs filed in other places (do a search on the i18n label), so it seems like there is some overall broader test coverage on this already. Maybe ask the submitter for more info as to how this came about. Either way, it was a minor comment, so I am ok if you want to keep it. --Sean From weijun.wang at oracle.com Wed Feb 7 23:53:54 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 8 Feb 2018 07:53:54 +0800 Subject: RFR 8196215: sun/security/util/Resources/customSysClassLoader/MessageFormatting.java failed on ar_SA locale. In-Reply-To: <88b263a9-b98f-a046-50a8-791e28302321@oracle.com> References: <7dd39fa5-df86-d2a0-9e65-73232d81068d@oracle.com> <5574c200-c65d-a165-c512-457e3ee8697a@oracle.com> <88b263a9-b98f-a046-50a8-791e28302321@oracle.com> Message-ID: <9C4E6A56-9AAC-43EA-922A-C4E34E2ADA5A@oracle.com> Can you use Locale.ROOT? > On Feb 8, 2018, at 4:01 AM, Sean Mullan wrote: > > On 2/7/18 2:26 PM, Adam Petcher wrote: >> On 2/7/2018 12:33 PM, Sean Mullan wrote: >>> This looks fine although I don't really think you need the othervm on line 36; that seems like something that is done separately as part of testing all of the tests on different locales. >> I included that line as a regression test for this bug. I would prefer to keep it, because it uses a locale that is known to cause problems for (earlier versions of) this test. I don't know how common these problematic locales are, and how often the test suite is run under them. If there is a regression here, it would be nice to know about it before release testing. >> Do you expect this @run line to cause any problems (other than being unnecessary)? > > I guess it's fine; it is just that I have seen default locale test bugs filed in other places (do a search on the i18n label), so it seems like there is some overall broader test coverage on this already. Maybe ask the submitter for more info as to how this came about. Either way, it was a minor comment, so I am ok if you want to keep it. > > --Sean > From adam.petcher at oracle.com Thu Feb 8 15:17:19 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 8 Feb 2018 10:17:19 -0500 Subject: RFR 8196215: sun/security/util/Resources/customSysClassLoader/MessageFormatting.java failed on ar_SA locale. In-Reply-To: <9C4E6A56-9AAC-43EA-922A-C4E34E2ADA5A@oracle.com> References: <7dd39fa5-df86-d2a0-9e65-73232d81068d@oracle.com> <5574c200-c65d-a165-c512-457e3ee8697a@oracle.com> <88b263a9-b98f-a046-50a8-791e28302321@oracle.com> <9C4E6A56-9AAC-43EA-922A-C4E34E2ADA5A@oracle.com> Message-ID: <0bec65d3-d771-64c4-3384-8f5b13ba3ee0@oracle.com> On 2/7/2018 6:53 PM, Weijun Wang wrote: > Can you use Locale.ROOT? > Thanks for the suggestion, but from looking at the spec of Locale.ROOT, it's not clear that it will always cause the behavior that I want. I pushed the change as it is in the webrev. Perhaps there are better ways to express the locale, but the test should work fine the way it is. From valerie.peng at oracle.com Fri Feb 9 01:03:05 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 8 Feb 2018 17:03:05 -0800 Subject: [PATCH]: Support for brainpool curves from CurveDB in SunEC In-Reply-To: References: Message-ID: Hi Tobias, Just curious, which PKCS11 library did you use to test your patch? After I applied your patch and ran the regression tests, I noticed that both the Solaris PKCS11 library and NSS skipped testing Brainpool curves with different error codes which may be due to lack of support... Regards, Valerie On 1/17/2018 3:02 PM, Tobias Wagner wrote: > -----Urspr?ngliche Nachricht----- >> Von:Adam Petcher >> Gesendet: Die 16 Januar 2018 18:38 >> An: security-dev at openjdk.java.net >> Betreff: Re: [PATCH]: Support for brainpool curves from CurveDB in SunEC >> >> Great! I took a look at the patch, and I have some comments, the first >> of which probably needs to be addressed before I can test the change: >> >> 1) Is this patch against the http://hg.openjdk.java.net/jdk/jdk >> repository? I suspect it isn't because some of the paths are different >> than what I expect. We have made a lot of changes to the repositories in >> the last few months. If this patch is against an older repo, please send >> a patch against http://hg.openjdk.java.net/jdk/jdk . > I switched to that repository now. As described on http://openjdk.java.net/contribute/, I was > working with the http://hg.openjdk.java.net/jdk9/jdk9 repository. > >> 2) TestECDH.java: It's probably better to remove the provider name check >> on line 116 and test on any providers that support the curve. > OK, it's removed. I was thinking the same. > >> 3) oid.c: I think you can remove the comments that say "XXX bounds >> check" (e.g. line 362). If I am interpreting these comments correctly, >> they are saying that memcmp may read out of bounds, but you fixed that >> problem by using oideql. > I left them in place - my interpretation is, that they are meant for a check > before accessing the *_oids arrays, as C arrays have no implicit check for that. > As long as only oids from CurveDB are used, there would be no problems. > The least significant byte of the requested oid is used as index. If that index > exeeds the defined array length, something odd from the memory there is returned. > At least that's my understynding of C and the comment there. > >> 4) Is there an existing test that exercises ECDSA with the new curves? >> Maybe there is something in the PKCS11 tests that does this already, but >> I didn't find it. I think we should have an ECDSA test to make sure that >> we didn't forget anything. ECDSA test vectors probably aren't >> necessary---a simple test that signs and verifies using the new curves >> should be sufficient. > Yes, there are tests in TestCurves, which runs through TestEC. TestCurves gets a List > of all supported ECParameterSpec by the Provider and runs ECDSA signatures and verifications > with all of them. The results of all curves are logged in the jtreg report of TestEC. > > I also changed the InvalidCurve test to use brainpoolP160r1 now, as brainpoolP256r1 is supported > by using this patch. > >> On 1/12/2018 9:12 AM, Tobias Wagner wrote: >>> Hi, >>> >>> here is the next patch for brainpool curve support in SunEC. >>> >>> Differences from the first patch: >>> >>> * Brainpool curves with less than 256 bits are removed. Subsequently, the curve oid check is made more robust to avoid null >>> pointer caused Segmentation Faults in memcmp calls. >>> >>> * Bug JDK-8189594 is fixed. >>> >>> * Known answer tests for each new curve are added to sun.security.pkcs11.ec.TestECDH. The tests are only executed, if the >>> tested provider's name is "SunEC" and the tested provider claims to support the respective curve. For SunEC, these tests are >>> executed during sun.security.ec.TestEC. >>> >>> I decided to add these test vectors to TestECDH to avoid code duplications, as TestECDH is describes exactly the test >>> for that kind of test vectors. >>> The superclass to TestECDH, TestPKCS11, is also adapted to provide a method to check, whether one particular curve is >>> supported. >>> >>> While the test vectors for the 256, 384 and 512 bit curve are taken from [1], the test vector for brainpoolP320r1 comes from [2]. >>> The latter one is a draft version of RFC 6954. >>> >>> Regards, >>> Tobias >>> >>> [1] https://tools.ietf.org/html/rfc7027#appendix-A >>> [2] https://tools.ietf.org/html/draft-merkle-ikev2-ke-brainpool-00#appendix-A.5 >>> >>> From tomas at primekey.se Fri Feb 9 08:55:12 2018 From: tomas at primekey.se (Tomas Gustavsson) Date: Fri, 9 Feb 2018 09:55:12 +0100 Subject: PKCS#11 provider issues with min and max size In-Reply-To: <276cc36a-7967-d4fb-ce98-f0d8b6b43681@oracle.com> References: <97ca28d8-8466-9f9f-c19d-567b38f7a0f7@primekey.se> <276cc36a-7967-d4fb-ce98-f0d8b6b43681@oracle.com> Message-ID: <3d323e74-b60c-cb2d-466f-345b16f6e368@primekey.se> Hi, Thanks for the answer. (sorry I was out with the flu for a week) > I am not too keen to add an env var/system property to accommodate this > kind of PKCS11 library bugs since this should be rare I hope. > Valerie Unfortunately I don't see it as rare and the impact is huge due to the slow turnaround of HSM firmware. Due to FIPS certification and whatnot HSM vendors do not fix simple things like this sometimes in years. This puts customers to a complete halt in the meantime. These are heavily certified environments where re-certification alone takes at least 6 months. Having worked with all major HSM vendors for many years I know that PKCS11 library bugs are not rare at all. If we'd be using PKCS#11 natively, you can hack around by ignoring bad values, but when using SunPKCS#11 you are stuck with Java's rules unless you patch SunPKCS11 which is not for everyone. Due to the strictness of using SunPKCS11 compared to native PKCS#11, some more flexibility in configuration would help a lot. For many years SunPKCS11 have worked great. But also the HSM world is moving faster than they did 5 years ago, and unfortunately this means that we're seeing a huge rise in PKCS#11 issues in the last year, requiring quite a lot of hacking in SunPKCS11 to workaround. In theory it should not be needed, but in practice it is. Faster evolution = more bugs. I just showed two real world use cases that you really need to be able to work around. And these will not be the last. PKCS#11 is a complex standard and implementors will rarely get it exactly right. Increased flexibility and more control around PKCS#11 will be needed in the future imho, or users will be forced to move to other solutions like JackNJI11. We'd much rather use SunPKCS11 but customers (end users) can't get stuck between Java and HSM vendors in a fight who does PKCS#11 right or wrong. Cheers, Tomas On 2018-02-01 01:07, Valerie Peng wrote: > > Thanks for the feedback. I suppose we can ignore values which obviously > don't make sense such as 0 or max being less than min key size. > However, if the underlying PKCS11 library vendors forgot to update the > max value as in your comment#2, supposedly they should fix it. > I am not too keen to add an env var/system property to accommodate this > kind of PKCS11 library bugs since this should be rare I hope. > Valerie > > On 1/30/2018 12:22 AM, Tomas Gustavsson wrote: >> Hi, >> >> At some revision in the PKCS#11 provider there was introduced checking >> of C_GetMechanismInfo min and max sizes. >> >> This has turned out to be a bit fragile. Let me give two real world >> examples: >> >> 1. Amazon Cloud HSM report minSize and maxSize for EC keys to 0. The >> Java PKCS#11 provider will happily take 0 as maxSize and refuse to >> generate any EC keys at all. Needless to say, without the Java check it >> would be no problem. >> >> 131: C_GetMechanismInfo >> 2018-01-30 07:52:20.740 >> [in] slotID = 0x1 >> ? CKM_EC_KEY_PAIR_GEN >> [out] pInfo: >> CKM_EC_KEY_PAIR_GEN?????????? : min:0 max:0 flags:0x10001 ( Hardware >> KeyPair ) >> Returned:? 0 CKR_OK >> >> (we are reporting this to Amazon as well) >> >> 2. Thales HSMs (some?) report maxSize for RSA_PKCS key generation as >> 4096, but will happily generate 8192 bit keys. I.e. the reported maxSize >> is not true. >> We have customers who used to generate 8192 bit RSA keys, but after a >> Java update can not do so anymore, because Java compares against this >> value. >> >> >> * Suggestions: >> >> 1. In the constructor of P11KeyPairGenerator where minKeyLen and >> maxKeyLen are calculated, never allow maxKeyLen to be less than >> minKeyLen. >> >> I.e. change the part: >> ???????? // auto-adjust default keysize in case it's out-of-range >> ???????? if ((minKeyLen != -1) && (keySize < minKeyLen)) { >> ???????????? keySize = minKeyLen; >> ???????? } >> ???????? if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { >> ???????????? keySize = maxKeyLen; >> ???????? } >> >> To include something like: >> ???????? // auto-adjust default keysize in case it's out-of-range >> ???????? if ((minKeyLen != -1) && (keySize < minKeyLen)) { >> ???????????? keySize = minKeyLen; >> ???????? } >> ???????? if ((maxKeyLen != -1) && (maxKeyLen < minKeyLen)) { >> ???????????? maxKeyLen = minKeyLen; >> ???????? } >> ???????? if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { >> ???????????? keySize = maxKeyLen; >> ???????? } >> >> 2. Allow to ignore checking of maxKeyLen by some means, i.e. allow to >> ignore checking against C_GetMechanismInfo if you know that the HSM does >> not provide sane values. I.e. an environment variable for example >> reverting back to the old behavior when these were ignored. >> >> Regards, >> Tomas Gustavsson >> > From tomas at primekey.se Fri Feb 9 09:14:55 2018 From: tomas at primekey.se (Tomas Gustavsson) Date: Fri, 9 Feb 2018 10:14:55 +0100 Subject: contribute to the OpenJDK security group In-Reply-To: References: <0100016101db8f7d-19737975-67eb-4dab-ba94-c68d46746ab9-000000@email.amazonses.com> <0100016105867b86-27ab95e1-97ea-4118-bda9-1680dadcf318-000000@email.amazonses.com> <44867b0b-ecde-8037-f48b-b3aa51c44d64@primekey.se> <344a2d12-9560-e407-39e5-1ec0ed43b285@redhat.com> Message-ID: Awesome. I just posted in another thread to the mailing list with some examples where more flexibility would be needed. "PKCS#11 provider issues with min and max size". Another example would be to add flexibility to be more crypto "agile". I.e. when new algorithms come out, for example SHA3. It will be included in the PKCS#11 spec eventually, and then it takes a decent round-trip time before it's possible to use through SunPKCS#11. So an example would be to be able to configure new mechanisms, that does not affect any other code in SunPKCS11, dynamically. Yet another example, AWS CloudHSM requires you to use CKM_RSA_X9_31_KEY_PAIR_GEN instead of CKM_RSA_PKCS_KEY_PAIR_GEN. Patching SunPKCS11 to use it is trivial (for java programmers that is), just replace one string with another. If it could be done dynamically without patching java files it would be much nicer...and more stable as it survives JDK upgrades. Cheers, Tomas On 2018-02-01 20:25, Martin Balao wrote: > Hi Tomas, > > As Andrew said, I've been working on some SunPKCS11 improvements related > to native memory leaking. You can find details of this work here [1]. > Feedback is always welcomed. > > What do you mean with "more flexibility"? > > -- > [1] > -?http://mail.openjdk.java.net/pipermail/security-dev/2017-October/016400.html > > On Wed, Jan 24, 2018 at 8:06 AM, Andrew Haley > wrote: > > On 24/01/18 10:39, Tomas Gustavsson wrote: > > Imho the P11 layer always needs attention. To work properly we're > > relying on some patches, where parts was recently merged into OpenJDK. > > We just started testing the Amazon CloudHSM, and that requires changes > > to SunPKCS11 as well to work. Not always bad in SunPKCS11 as some P11 > > libraries out there do strange non-conforming stuff, but there's room > > for more flexibility nevertheless. > > Martin Balao has been heavily reworking this layer because it leaks > native memory.? I'll let him fill you in on the details. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > From weijun.wang at oracle.com Fri Feb 9 09:10:28 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 9 Feb 2018 17:10:28 +0800 Subject: RFR 8191438: jarsigner should print when a timestamp will expire In-Reply-To: <64196240-CBBA-4A85-9A1C-BE60B2BB38B1@oracle.com> References: <64196240-CBBA-4A85-9A1C-BE60B2BB38B1@oracle.com> Message-ID: Updated again at http://cr.openjdk.java.net/~weijun/8191438/webrev.05/. --Max > On Jan 4, 2018, at 8:48 AM, Weijun Wang wrote: > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8191438/webrev.04/ > > Major changes: > > 1. Warnings on TSA cert chain: expired or expiring > > 2. No more check on trusted certs > > 3. More output at signing when -verbose is on > > 4. Fine tune messages when TSA cert expires earlier than signer cert > > 5. New test cases > > 6. Existing tests modification so signer is not trusted > > Thanks > Max > From tomas at primekey.se Fri Feb 9 09:22:20 2018 From: tomas at primekey.se (Tomas Gustavsson) Date: Fri, 9 Feb 2018 10:22:20 +0100 Subject: [PATCH]: Support for brainpool curves from CurveDB in SunEC In-Reply-To: References: Message-ID: <5e13ed7c-99d2-1bb7-4f0d-8a0ac594e57f@primekey.se> Just FYI. SoftHSM2 from the OpenDNSSec project is a good P11 to test with, and I believe it supports brainpool in recent versions. https://github.com/opendnssec/SoftHSMv2 It works really good) Regards, Tomas On 2018-02-09 02:03, Valerie Peng wrote: > Hi Tobias, > > Just curious, which PKCS11 library did you use to test your patch? After > I applied your patch and ran the regression tests, I noticed that both > the Solaris PKCS11 library and NSS skipped testing Brainpool curves with > different error codes which may be due to lack of support... > > Regards, > Valerie > > On 1/17/2018 3:02 PM, Tobias Wagner wrote: >> -----Urspr?ngliche Nachricht----- >>> Von:Adam Petcher >>> Gesendet: Die 16 Januar 2018 18:38 >>> An: security-dev at openjdk.java.net >>> Betreff: Re: [PATCH]: Support for brainpool curves from CurveDB in SunEC >>> >>> Great! I took a look at the patch, and I have some comments, the first >>> of which probably needs to be addressed before I can test the change: >>> >>> 1) Is this patch against the http://hg.openjdk.java.net/jdk/jdk >>> repository? I suspect it isn't because some of the paths are different >>> than what I expect. We have made a lot of changes to the repositories in >>> the last few months. If this patch is against an older repo, please send >>> a patch against http://hg.openjdk.java.net/jdk/jdk . >> I switched to that repository now. As described on >> http://openjdk.java.net/contribute/, I was >> working with the http://hg.openjdk.java.net/jdk9/jdk9 repository. >> >>> 2) TestECDH.java: It's probably better to remove the provider name check >>> on line 116 and test on any providers that support the curve. >> OK, it's removed. I was thinking the same. >> >>> 3) oid.c: I think you can remove the comments that say "XXX bounds >>> check" (e.g. line 362). If I am interpreting these comments correctly, >>> they are saying that memcmp may read out of bounds, but you fixed that >>> problem by using oideql. >> I left them in place - my interpretation is, that they are meant for a >> check >> before accessing the *_oids arrays, as C arrays have no implicit check >> for that. >> As long as only oids from CurveDB are used, there would be no problems. >> The least significant byte of the requested oid is used as index. If >> that index >> exeeds the defined array length, something odd from the memory there >> is returned. >> At least that's my understynding of C and the comment there. >> >>> 4) Is there an existing test that exercises ECDSA with the new curves? >>> Maybe there is something in the PKCS11 tests that does this already, but >>> I didn't find it. I think we should have an ECDSA test to make sure that >>> we didn't forget anything. ECDSA test vectors probably aren't >>> necessary---a simple test that signs and verifies using the new curves >>> should be sufficient. >> Yes, there are tests in TestCurves, which runs through TestEC. >> TestCurves gets a List >> of all supported ECParameterSpec by the Provider and runs ECDSA >> signatures and verifications >> with all of them. The results of all curves are logged in the jtreg >> report of TestEC. >> >> I also changed the InvalidCurve test to use brainpoolP160r1 now, as >> brainpoolP256r1 is supported >> by using this patch. >> >>> On 1/12/2018 9:12 AM, Tobias Wagner wrote: >>>> Hi, >>>> >>>> here is the next patch for brainpool curve support in SunEC. >>>> >>>> Differences from the first patch: >>>> >>>> * Brainpool curves with less than 256 bits are removed. >>>> Subsequently, the curve oid check is made more robust to avoid null >>>> pointer caused Segmentation Faults in memcmp calls. >>>> >>>> * Bug JDK-8189594 is fixed. >>>> >>>> * Known answer tests for each new curve are added to >>>> sun.security.pkcs11.ec.TestECDH. The tests are only executed, if the >>>> tested provider's name is "SunEC" and the tested provider claims to >>>> support the respective curve. For SunEC, these tests are >>>> executed during sun.security.ec.TestEC. >>>> >>>> I decided to add these test vectors to TestECDH to avoid code >>>> duplications, as TestECDH is describes exactly the test >>>> for that kind of test vectors. >>>> The superclass to TestECDH, TestPKCS11, is also adapted to provide a >>>> method to check, whether one particular curve is >>>> supported. >>>> >>>> While the test vectors for the 256, 384 and 512 bit curve are taken >>>> from [1], the test vector for brainpoolP320r1 comes from [2]. >>>> The latter one is a draft version of RFC 6954. >>>> >>>> Regards, >>>> Tobias >>>> >>>> [1] https://tools.ietf.org/html/rfc7027#appendix-A >>>> [2] >>>> https://tools.ietf.org/html/draft-merkle-ikev2-ke-brainpool-00#appendix-A.5 >>>> >>>> >>>> > From tomas at primekey.se Fri Feb 9 10:16:05 2018 From: tomas at primekey.se (Tomas Gustavsson) Date: Fri, 9 Feb 2018 11:16:05 +0100 Subject: PKCS#11 provider issues with min and max size In-Reply-To: <3d323e74-b60c-cb2d-466f-345b16f6e368@primekey.se> References: <97ca28d8-8466-9f9f-c19d-567b38f7a0f7@primekey.se> <276cc36a-7967-d4fb-ce98-f0d8b6b43681@oracle.com> <3d323e74-b60c-cb2d-466f-345b16f6e368@primekey.se> Message-ID: <041b119f-8341-2ddb-9347-dfcc552059c2@primekey.se> I just realized that a natural place to configure provider behavior is in the provider construction, which is also per provider, so you can have multiple ones with different configuration. We are already using an InputStream to construct SunPKCS11, and adding more parameters to configure/override defaults would be natural. I.e.: ----- name = library = ; slot = slot rsakeygenmech = CKM_RSA_X9_31_KEY_PAIR_GEN rsakeygenmechminsize = 1024 rsakeygenmechmaxsize = 8192 attributes(*, CKO_PUBLIC_KEY, *) = { CKA_TOKEN = false CKA_ENCRYPT = true CKA_VERIFY = true CKA_WRAP = true } attributes(*, CKO_PRIVATE_KEY, *) = { CKA_DERIVE = false CKA_TOKEN = true CKA_PRIVATE = true CKA_SENSITIVE = true CKA_EXTRACTABLE = false CKA_DECRYPT = true CKA_SIGN = true CKA_UNWRAP = true } attributes(*, CKO_SECRET_KEY, *) = { CKA_SENSITIVE = true CKA_EXTRACTABLE = false CKA_ENCRYPT = true CKA_DECRYPT = true CKA_SIGN = true CKA_VERIFY = true CKA_WRAP = true CKA_UNWRAP = true } ----- Cheers, Tomas On 2018-02-09 09:55, Tomas Gustavsson wrote: > > Hi, > > Thanks for the answer. (sorry I was out with the flu for a week) > >> I am not too keen to add an env var/system property to accommodate this >> kind of PKCS11 library bugs since this should be rare I hope. >> Valerie > > Unfortunately I don't see it as rare and the impact is huge due to the > slow turnaround of HSM firmware. Due to FIPS certification and whatnot > HSM vendors do not fix simple things like this sometimes in years. This > puts customers to a complete halt in the meantime. These are heavily > certified environments where re-certification alone takes at least 6 months. > > Having worked with all major HSM vendors for many years I know that > PKCS11 library bugs are not rare at all. If we'd be using PKCS#11 > natively, you can hack around by ignoring bad values, but when using > SunPKCS#11 you are stuck with Java's rules unless you patch SunPKCS11 > which is not for everyone. > > Due to the strictness of using SunPKCS11 compared to native PKCS#11, > some more flexibility in configuration would help a lot. > > For many years SunPKCS11 have worked great. But also the HSM world is > moving faster than they did 5 years ago, and unfortunately this means > that we're seeing a huge rise in PKCS#11 issues in the last year, > requiring quite a lot of hacking in SunPKCS11 to workaround. In theory > it should not be needed, but in practice it is. Faster evolution = more > bugs. > > I just showed two real world use cases that you really need to be able > to work around. And these will not be the last. PKCS#11 is a complex > standard and implementors will rarely get it exactly right. > > Increased flexibility and more control around PKCS#11 will be needed in > the future imho, or users will be forced to move to other solutions like > JackNJI11. We'd much rather use SunPKCS11 but customers (end users) > can't get stuck between Java and HSM vendors in a fight who does PKCS#11 > right or wrong. > > Cheers, > Tomas > > On 2018-02-01 01:07, Valerie Peng wrote: >> >> Thanks for the feedback. I suppose we can ignore values which obviously >> don't make sense such as 0 or max being less than min key size. >> However, if the underlying PKCS11 library vendors forgot to update the >> max value as in your comment#2, supposedly they should fix it. >> I am not too keen to add an env var/system property to accommodate this >> kind of PKCS11 library bugs since this should be rare I hope. >> Valerie >> >> On 1/30/2018 12:22 AM, Tomas Gustavsson wrote: >>> Hi, >>> >>> At some revision in the PKCS#11 provider there was introduced checking >>> of C_GetMechanismInfo min and max sizes. >>> >>> This has turned out to be a bit fragile. Let me give two real world >>> examples: >>> >>> 1. Amazon Cloud HSM report minSize and maxSize for EC keys to 0. The >>> Java PKCS#11 provider will happily take 0 as maxSize and refuse to >>> generate any EC keys at all. Needless to say, without the Java check it >>> would be no problem. >>> >>> 131: C_GetMechanismInfo >>> 2018-01-30 07:52:20.740 >>> [in] slotID = 0x1 >>> ? CKM_EC_KEY_PAIR_GEN >>> [out] pInfo: >>> CKM_EC_KEY_PAIR_GEN?????????? : min:0 max:0 flags:0x10001 ( Hardware >>> KeyPair ) >>> Returned:? 0 CKR_OK >>> >>> (we are reporting this to Amazon as well) >>> >>> 2. Thales HSMs (some?) report maxSize for RSA_PKCS key generation as >>> 4096, but will happily generate 8192 bit keys. I.e. the reported maxSize >>> is not true. >>> We have customers who used to generate 8192 bit RSA keys, but after a >>> Java update can not do so anymore, because Java compares against this >>> value. >>> >>> >>> * Suggestions: >>> >>> 1. In the constructor of P11KeyPairGenerator where minKeyLen and >>> maxKeyLen are calculated, never allow maxKeyLen to be less than >>> minKeyLen. >>> >>> I.e. change the part: >>> ???????? // auto-adjust default keysize in case it's out-of-range >>> ???????? if ((minKeyLen != -1) && (keySize < minKeyLen)) { >>> ???????????? keySize = minKeyLen; >>> ???????? } >>> ???????? if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { >>> ???????????? keySize = maxKeyLen; >>> ???????? } >>> >>> To include something like: >>> ???????? // auto-adjust default keysize in case it's out-of-range >>> ???????? if ((minKeyLen != -1) && (keySize < minKeyLen)) { >>> ???????????? keySize = minKeyLen; >>> ???????? } >>> ???????? if ((maxKeyLen != -1) && (maxKeyLen < minKeyLen)) { >>> ???????????? maxKeyLen = minKeyLen; >>> ???????? } >>> ???????? if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { >>> ???????????? keySize = maxKeyLen; >>> ???????? } >>> >>> 2. Allow to ignore checking of maxKeyLen by some means, i.e. allow to >>> ignore checking against C_GetMechanismInfo if you know that the HSM does >>> not provide sane values. I.e. an environment variable for example >>> reverting back to the old behavior when these were ignored. >>> >>> Regards, >>> Tomas Gustavsson >>> >> From tobias.wagner at n-design.de Fri Feb 9 12:38:09 2018 From: tobias.wagner at n-design.de (=?utf-8?Q?Tobias_Wagner?=) Date: Fri, 9 Feb 2018 13:38:09 +0100 Subject: AW: [PATCH]: Support for brainpool curves from CurveDB in SunEC Message-ID: Hi Valerie, these tests were initally meant for the new curves in SunEC, but the SunEC tests are using the PKCS#11 tests. Even though I made these known answer tests for SunEC, I think it might be a good idea not to limit them to SunEC but run them on tests using TestECDH with any provider, which claims to support these curves. The supported/unsupported statements come from getSupportedECParameterSpec in PKCS11Test and depend on the exception a provider throws. I moved that code to this method from the getKnowCurves method, to check if one particular curve is available. So, yes, I think it lack of support in these providers, and the log message depends on the exception type and the execptions message. I executed the with an unpatched and a patched build of the OpenJDK. In both cases it was the SunEC provider. The output for the unpatched reference build for sun.security.ec.TestEC using sun.security.pkcs11.ec.TestECDH: ... >Running tests with SunEC provider... > >libsoftokn3 version = 3.16.? ECC Basic. >Testing using parameters secp192r1 [NIST P-192, X9.62 prime192v1] (1.2.840.10045.3.1.1)... >Testing using parameters sect163r2 [NIST B-163] (1.3.132.0.15)... > brainpoolP256r1: Unsupported: Key Length: Unsupported curve: brainpoolP256r1 (1.3.36.3.3.2.8.1.1.7) > brainpoolP320r1: Unsupported: Key Length: Unsupported curve: brainpoolP320r1 (1.3.36.3.3.2.8.1.1.9) > brainpoolP384r1: Unsupported: Key Length: Unsupported curve: brainpoolP384r1 (1.3.36.3.3.2.8.1.1.11) > brainpoolP512r1: Unsupported: Key Length: Unsupported curve: brainpoolP512r1 (1.3.36.3.3.2.8.1.1.13) >OK ... and for the patched build: ... >Running tests with SunEC provider... > >libsoftokn3 version = 3.16.? ECC Basic. >Testing using parameters secp192r1 [NIST P-192, X9.62 prime192v1] (1.2.840.10045.3.1.1)... >Testing using parameters sect163r2 [NIST B-163] (1.3.132.0.15)... > brainpoolP256r1: Supported >Testing using parameters brainpoolP256r1 (1.3.36.3.3.2.8.1.1.7)... > brainpoolP320r1: Supported >Testing using parameters brainpoolP320r1 (1.3.36.3.3.2.8.1.1.9)... > brainpoolP384r1: Supported >Testing using parameters brainpoolP384r1 (1.3.36.3.3.2.8.1.1.11)... > brainpoolP512r1: Supported >Testing using parameters brainpoolP512r1 (1.3.36.3.3.2.8.1.1.13)... >OK ... When running sun.security.pkcs11.ec.TestECDH directly, I get the following: ... >libsoftokn3 version = 3.16.? ECC Basic. >Beginning test run TestECDH... >Running test with provider SunPKCS11-NSS (security manager enabled) ... >NSS only supports Basic ECC.? Skipping.. >Completed test with provider SunPKCS11-NSS (28 ms). ... Regards, Tobias -----Urspr?ngliche Nachricht----- > Von:Valerie Peng > Gesendet: Fre 9 Februar 2018 02:03 > An: Tobias Wagner ; security-dev at openjdk.java.net > Betreff: Re: [PATCH]: Support for brainpool curves from CurveDB in SunEC > > Hi Tobias, > > Just curious, which PKCS11 library did you use to test your patch? After > I applied your patch and ran the regression tests, I noticed that both > the Solaris PKCS11 library and NSS skipped testing Brainpool curves with > different error codes which may be due to lack of support... > > Regards, > Valerie > From sean.coffey at oracle.com Fri Feb 9 16:25:37 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 9 Feb 2018 16:25:37 +0000 Subject: RFR: 8193892: Impact of noncloneable MessageDigest implementation Message-ID: <9a2be852-bd0c-d025-0278-ab266a4ced66@oracle.com> Looking to push a new test which helps test CloneableDigest code. It's something that arose during JDK-8193683 fix. The test was contributed by Brad Wetmore. I've converted it to use the SSLSocketTemplate. JBS : https://bugs.openjdk.java.net/browse/JDK-8193892 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8193892/webrev/ -- Regards, Sean. From valerie.peng at oracle.com Fri Feb 9 18:57:31 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 9 Feb 2018 10:57:31 -0800 Subject: PKCS#11 provider issues with min and max size In-Reply-To: <3d323e74-b60c-cb2d-466f-345b16f6e368@primekey.se> References: <97ca28d8-8466-9f9f-c19d-567b38f7a0f7@primekey.se> <276cc36a-7967-d4fb-ce98-f0d8b6b43681@oracle.com> <3d323e74-b60c-cb2d-466f-345b16f6e368@primekey.se> Message-ID: Oh-well, I suppose that we are all humans. ;) Let me take a closer look on this and see if there are other ways to relax this constraint than adding env var which should be the very last resort in my opinion. BTW, is there a bug filed for this? Thanks for the feedback, Valerie On 2/9/2018 12:55 AM, Tomas Gustavsson wrote: > Hi, > > Thanks for the answer. (sorry I was out with the flu for a week) > >> I am not too keen to add an env var/system property to accommodate this >> kind of PKCS11 library bugs since this should be rare I hope. >> Valerie > Unfortunately I don't see it as rare and the impact is huge due to the > slow turnaround of HSM firmware. Due to FIPS certification and whatnot > HSM vendors do not fix simple things like this sometimes in years. This > puts customers to a complete halt in the meantime. These are heavily > certified environments where re-certification alone takes at least 6 months. > > Having worked with all major HSM vendors for many years I know that > PKCS11 library bugs are not rare at all. If we'd be using PKCS#11 > natively, you can hack around by ignoring bad values, but when using > SunPKCS#11 you are stuck with Java's rules unless you patch SunPKCS11 > which is not for everyone. > > Due to the strictness of using SunPKCS11 compared to native PKCS#11, > some more flexibility in configuration would help a lot. > > For many years SunPKCS11 have worked great. But also the HSM world is > moving faster than they did 5 years ago, and unfortunately this means > that we're seeing a huge rise in PKCS#11 issues in the last year, > requiring quite a lot of hacking in SunPKCS11 to workaround. In theory > it should not be needed, but in practice it is. Faster evolution = more > bugs. > > I just showed two real world use cases that you really need to be able > to work around. And these will not be the last. PKCS#11 is a complex > standard and implementors will rarely get it exactly right. > > Increased flexibility and more control around PKCS#11 will be needed in > the future imho, or users will be forced to move to other solutions like > JackNJI11. We'd much rather use SunPKCS11 but customers (end users) > can't get stuck between Java and HSM vendors in a fight who does PKCS#11 > right or wrong. > > Cheers, > Tomas > > On 2018-02-01 01:07, Valerie Peng wrote: >> Thanks for the feedback. I suppose we can ignore values which obviously >> don't make sense such as 0 or max being less than min key size. >> However, if the underlying PKCS11 library vendors forgot to update the >> max value as in your comment#2, supposedly they should fix it. >> I am not too keen to add an env var/system property to accommodate this >> kind of PKCS11 library bugs since this should be rare I hope. >> Valerie >> >> On 1/30/2018 12:22 AM, Tomas Gustavsson wrote: >>> Hi, >>> >>> At some revision in the PKCS#11 provider there was introduced checking >>> of C_GetMechanismInfo min and max sizes. >>> >>> This has turned out to be a bit fragile. Let me give two real world >>> examples: >>> >>> 1. Amazon Cloud HSM report minSize and maxSize for EC keys to 0. The >>> Java PKCS#11 provider will happily take 0 as maxSize and refuse to >>> generate any EC keys at all. Needless to say, without the Java check it >>> would be no problem. >>> >>> 131: C_GetMechanismInfo >>> 2018-01-30 07:52:20.740 >>> [in] slotID = 0x1 >>> ? CKM_EC_KEY_PAIR_GEN >>> [out] pInfo: >>> CKM_EC_KEY_PAIR_GEN?????????? : min:0 max:0 flags:0x10001 ( Hardware >>> KeyPair ) >>> Returned:? 0 CKR_OK >>> >>> (we are reporting this to Amazon as well) >>> >>> 2. Thales HSMs (some?) report maxSize for RSA_PKCS key generation as >>> 4096, but will happily generate 8192 bit keys. I.e. the reported maxSize >>> is not true. >>> We have customers who used to generate 8192 bit RSA keys, but after a >>> Java update can not do so anymore, because Java compares against this >>> value. >>> >>> >>> * Suggestions: >>> >>> 1. In the constructor of P11KeyPairGenerator where minKeyLen and >>> maxKeyLen are calculated, never allow maxKeyLen to be less than >>> minKeyLen. >>> >>> I.e. change the part: >>> ???????? // auto-adjust default keysize in case it's out-of-range >>> ???????? if ((minKeyLen != -1) && (keySize < minKeyLen)) { >>> ???????????? keySize = minKeyLen; >>> ???????? } >>> ???????? if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { >>> ???????????? keySize = maxKeyLen; >>> ???????? } >>> >>> To include something like: >>> ???????? // auto-adjust default keysize in case it's out-of-range >>> ???????? if ((minKeyLen != -1) && (keySize < minKeyLen)) { >>> ???????????? keySize = minKeyLen; >>> ???????? } >>> ???????? if ((maxKeyLen != -1) && (maxKeyLen < minKeyLen)) { >>> ???????????? maxKeyLen = minKeyLen; >>> ???????? } >>> ???????? if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { >>> ???????????? keySize = maxKeyLen; >>> ???????? } >>> >>> 2. Allow to ignore checking of maxKeyLen by some means, i.e. allow to >>> ignore checking against C_GetMechanismInfo if you know that the HSM does >>> not provide sane values. I.e. an environment variable for example >>> reverting back to the old behavior when these were ignored. >>> >>> Regards, >>> Tomas Gustavsson >>> From valerie.peng at oracle.com Fri Feb 9 19:04:49 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 9 Feb 2018 11:04:49 -0800 Subject: PKCS#11 provider issues with min and max size In-Reply-To: <041b119f-8341-2ddb-9347-dfcc552059c2@primekey.se> References: <97ca28d8-8466-9f9f-c19d-567b38f7a0f7@primekey.se> <276cc36a-7967-d4fb-ce98-f0d8b6b43681@oracle.com> <3d323e74-b60c-cb2d-466f-345b16f6e368@primekey.se> <041b119f-8341-2ddb-9347-dfcc552059c2@primekey.se> Message-ID: <4d8eccbc-9f2a-e42c-665f-a09be1626a94@oracle.com> Hmm, seems reasonable to support this in the provider configuration file. Or, on a similar note, but slightly different approach is to just add an configuration option for disabling checking the supported key size range. Regards, Valerie On 2/9/2018 2:16 AM, Tomas Gustavsson wrote: > I just realized that a natural place to configure provider behavior is > in the provider construction, which is also per provider, so you can > have multiple ones with different configuration. We are already using an > InputStream to construct SunPKCS11, and adding more parameters to > configure/override defaults would be natural. > > I.e.: > ----- > name = > library = ; > slot = slot > rsakeygenmech = CKM_RSA_X9_31_KEY_PAIR_GEN > rsakeygenmechminsize = 1024 > rsakeygenmechmaxsize = 8192 > > attributes(*, CKO_PUBLIC_KEY, *) = { > CKA_TOKEN = false > CKA_ENCRYPT = true > CKA_VERIFY = true > CKA_WRAP = true > } > attributes(*, CKO_PRIVATE_KEY, *) = { > CKA_DERIVE = false > CKA_TOKEN = true > CKA_PRIVATE = true > CKA_SENSITIVE = true > CKA_EXTRACTABLE = false > CKA_DECRYPT = true > CKA_SIGN = true > CKA_UNWRAP = true > } > attributes(*, CKO_SECRET_KEY, *) = { > CKA_SENSITIVE = true > CKA_EXTRACTABLE = false > CKA_ENCRYPT = true > CKA_DECRYPT = true > CKA_SIGN = true > CKA_VERIFY = true > CKA_WRAP = true > CKA_UNWRAP = true > } > ----- > > Cheers, > Tomas > > On 2018-02-09 09:55, Tomas Gustavsson wrote: >> Hi, >> >> Thanks for the answer. (sorry I was out with the flu for a week) >> >>> I am not too keen to add an env var/system property to accommodate this >>> kind of PKCS11 library bugs since this should be rare I hope. >>> Valerie >> Unfortunately I don't see it as rare and the impact is huge due to the >> slow turnaround of HSM firmware. Due to FIPS certification and whatnot >> HSM vendors do not fix simple things like this sometimes in years. This >> puts customers to a complete halt in the meantime. These are heavily >> certified environments where re-certification alone takes at least 6 months. >> >> Having worked with all major HSM vendors for many years I know that >> PKCS11 library bugs are not rare at all. If we'd be using PKCS#11 >> natively, you can hack around by ignoring bad values, but when using >> SunPKCS#11 you are stuck with Java's rules unless you patch SunPKCS11 >> which is not for everyone. >> >> Due to the strictness of using SunPKCS11 compared to native PKCS#11, >> some more flexibility in configuration would help a lot. >> >> For many years SunPKCS11 have worked great. But also the HSM world is >> moving faster than they did 5 years ago, and unfortunately this means >> that we're seeing a huge rise in PKCS#11 issues in the last year, >> requiring quite a lot of hacking in SunPKCS11 to workaround. In theory >> it should not be needed, but in practice it is. Faster evolution = more >> bugs. >> >> I just showed two real world use cases that you really need to be able >> to work around. And these will not be the last. PKCS#11 is a complex >> standard and implementors will rarely get it exactly right. >> >> Increased flexibility and more control around PKCS#11 will be needed in >> the future imho, or users will be forced to move to other solutions like >> JackNJI11. We'd much rather use SunPKCS11 but customers (end users) >> can't get stuck between Java and HSM vendors in a fight who does PKCS#11 >> right or wrong. >> >> Cheers, >> Tomas >> >> On 2018-02-01 01:07, Valerie Peng wrote: >>> Thanks for the feedback. I suppose we can ignore values which obviously >>> don't make sense such as 0 or max being less than min key size. >>> However, if the underlying PKCS11 library vendors forgot to update the >>> max value as in your comment#2, supposedly they should fix it. >>> I am not too keen to add an env var/system property to accommodate this >>> kind of PKCS11 library bugs since this should be rare I hope. >>> Valerie >>> >>> On 1/30/2018 12:22 AM, Tomas Gustavsson wrote: >>>> Hi, >>>> >>>> At some revision in the PKCS#11 provider there was introduced checking >>>> of C_GetMechanismInfo min and max sizes. >>>> >>>> This has turned out to be a bit fragile. Let me give two real world >>>> examples: >>>> >>>> 1. Amazon Cloud HSM report minSize and maxSize for EC keys to 0. The >>>> Java PKCS#11 provider will happily take 0 as maxSize and refuse to >>>> generate any EC keys at all. Needless to say, without the Java check it >>>> would be no problem. >>>> >>>> 131: C_GetMechanismInfo >>>> 2018-01-30 07:52:20.740 >>>> [in] slotID = 0x1 >>>> ? CKM_EC_KEY_PAIR_GEN >>>> [out] pInfo: >>>> CKM_EC_KEY_PAIR_GEN?????????? : min:0 max:0 flags:0x10001 ( Hardware >>>> KeyPair ) >>>> Returned:? 0 CKR_OK >>>> >>>> (we are reporting this to Amazon as well) >>>> >>>> 2. Thales HSMs (some?) report maxSize for RSA_PKCS key generation as >>>> 4096, but will happily generate 8192 bit keys. I.e. the reported maxSize >>>> is not true. >>>> We have customers who used to generate 8192 bit RSA keys, but after a >>>> Java update can not do so anymore, because Java compares against this >>>> value. >>>> >>>> >>>> * Suggestions: >>>> >>>> 1. In the constructor of P11KeyPairGenerator where minKeyLen and >>>> maxKeyLen are calculated, never allow maxKeyLen to be less than >>>> minKeyLen. >>>> >>>> I.e. change the part: >>>> ???????? // auto-adjust default keysize in case it's out-of-range >>>> ???????? if ((minKeyLen != -1) && (keySize < minKeyLen)) { >>>> ???????????? keySize = minKeyLen; >>>> ???????? } >>>> ???????? if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { >>>> ???????????? keySize = maxKeyLen; >>>> ???????? } >>>> >>>> To include something like: >>>> ???????? // auto-adjust default keysize in case it's out-of-range >>>> ???????? if ((minKeyLen != -1) && (keySize < minKeyLen)) { >>>> ???????????? keySize = minKeyLen; >>>> ???????? } >>>> ???????? if ((maxKeyLen != -1) && (maxKeyLen < minKeyLen)) { >>>> ???????????? maxKeyLen = minKeyLen; >>>> ???????? } >>>> ???????? if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { >>>> ???????????? keySize = maxKeyLen; >>>> ???????? } >>>> >>>> 2. Allow to ignore checking of maxKeyLen by some means, i.e. allow to >>>> ignore checking against C_GetMechanismInfo if you know that the HSM does >>>> not provide sane values. I.e. an environment variable for example >>>> reverting back to the old behavior when these were ignored. >>>> >>>> Regards, >>>> Tomas Gustavsson >>>> From sean.mullan at oracle.com Mon Feb 12 22:01:20 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 12 Feb 2018 17:01:20 -0500 Subject: RFR 8191438: jarsigner should print when a timestamp will expire In-Reply-To: References: <64196240-CBBA-4A85-9A1C-BE60B2BB38B1@oracle.com> Message-ID: <120b56ae-bcb9-6c40-76d6-d20d24175149@oracle.com> Just a few comments: - Update copyrights to include 2018 - I think you should also open a jarsigner docs issue to add new warnings for expired TSA and expiring signer and TSA certs * Main.java l1740, typo: s/singer/signer/ --Sean On 2/9/18 4:10 AM, Weijun Wang wrote: > Updated again at http://cr.openjdk.java.net/~weijun/8191438/webrev.05/. > > --Max > >> On Jan 4, 2018, at 8:48 AM, Weijun Wang wrote: >> >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8191438/webrev.04/ >> >> Major changes: >> >> 1. Warnings on TSA cert chain: expired or expiring >> >> 2. No more check on trusted certs >> >> 3. More output at signing when -verbose is on >> >> 4. Fine tune messages when TSA cert expires earlier than signer cert >> >> 5. New test cases >> >> 6. Existing tests modification so signer is not trusted >> >> Thanks >> Max >> > From weijun.wang at oracle.com Tue Feb 13 04:14:07 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 13 Feb 2018 12:14:07 +0800 Subject: RFR 8191438: jarsigner should print when a timestamp will expire In-Reply-To: <120b56ae-bcb9-6c40-76d6-d20d24175149@oracle.com> References: <64196240-CBBA-4A85-9A1C-BE60B2BB38B1@oracle.com> <120b56ae-bcb9-6c40-76d6-d20d24175149@oracle.com> Message-ID: <6016BF34-6358-4414-B1AB-8151214E8D7A@oracle.com> > On Feb 13, 2018, at 6:01 AM, Sean Mullan wrote: > > Just a few comments: > > - Update copyrights to include 2018 OK. > - I think you should also open a jarsigner docs issue to add new warnings for expired TSA and expiring signer and TSA certs https://bugs.openjdk.java.net/browse/JDK-8197784 filed. Please also review the release note subtask at https://bugs.openjdk.java.net/browse/JDK-8197783. Thanks Max > > * Main.java > > l1740, typo: s/singer/signer/ > > --Sean > > > On 2/9/18 4:10 AM, Weijun Wang wrote: >> Updated again at http://cr.openjdk.java.net/~weijun/8191438/webrev.05/. >> --Max >>> On Jan 4, 2018, at 8:48 AM, Weijun Wang wrote: >>> >>> Please take a review at >>> >>> http://cr.openjdk.java.net/~weijun/8191438/webrev.04/ >>> >>> Major changes: >>> >>> 1. Warnings on TSA cert chain: expired or expiring >>> >>> 2. No more check on trusted certs >>> >>> 3. More output at signing when -verbose is on >>> >>> 4. Fine tune messages when TSA cert expires earlier than signer cert >>> >>> 5. New test cases >>> >>> 6. Existing tests modification so signer is not trusted >>> >>> Thanks >>> Max >>> From tomas at primekey.se Tue Feb 13 14:00:29 2018 From: tomas at primekey.se (Tomas Gustavsson) Date: Tue, 13 Feb 2018 15:00:29 +0100 Subject: PKCS#11 provider issues with min and max size In-Reply-To: <4d8eccbc-9f2a-e42c-665f-a09be1626a94@oracle.com> References: <97ca28d8-8466-9f9f-c19d-567b38f7a0f7@primekey.se> <276cc36a-7967-d4fb-ce98-f0d8b6b43681@oracle.com> <3d323e74-b60c-cb2d-466f-345b16f6e368@primekey.se> <041b119f-8341-2ddb-9347-dfcc552059c2@primekey.se> <4d8eccbc-9f2a-e42c-665f-a09be1626a94@oracle.com> Message-ID: Thanks for taking a look. I haven't created a bug for this (yet) Let me know if that would help. Regards, Tomas On 2018-02-09 20:04, Valerie Peng wrote: > > Hmm, seems reasonable to support this in the provider configuration file. > Or, on a similar note, but slightly different approach is to just add an > configuration option for disabling checking the supported key size range. > Regards, > Valerie > > On 2/9/2018 2:16 AM, Tomas Gustavsson wrote: >> I just realized that a natural place to configure provider behavior is >> in the provider construction, which is also per provider, so you can >> have multiple ones with different configuration. We are already using an >> InputStream to construct SunPKCS11, and adding more parameters to >> configure/override defaults would be natural. >> >> I.e.: >> ----- >> name =? >> library = ; >> slot = slot >> rsakeygenmech = CKM_RSA_X9_31_KEY_PAIR_GEN >> rsakeygenmechminsize = 1024 >> rsakeygenmechmaxsize = 8192 >> >> attributes(*, CKO_PUBLIC_KEY, *) = { >> ?? CKA_TOKEN = false >> ?? CKA_ENCRYPT = true >> ?? CKA_VERIFY = true >> ?? CKA_WRAP = true >> } >> attributes(*, CKO_PRIVATE_KEY, *) = { >> ?? CKA_DERIVE = false >> ?? CKA_TOKEN = true >> ?? CKA_PRIVATE = true >> ?? CKA_SENSITIVE = true >> ?? CKA_EXTRACTABLE = false >> ?? CKA_DECRYPT = true >> ?? CKA_SIGN = true >> ?? CKA_UNWRAP = true >> } >> attributes(*, CKO_SECRET_KEY, *) = { >> ?? CKA_SENSITIVE = true >> ?? CKA_EXTRACTABLE = false >> ?? CKA_ENCRYPT = true >> ?? CKA_DECRYPT = true >> ?? CKA_SIGN = true >> ?? CKA_VERIFY = true >> ?? CKA_WRAP = true >> ?? CKA_UNWRAP = true >> } >> ----- >> >> Cheers, >> Tomas >> >> On 2018-02-09 09:55, Tomas Gustavsson wrote: >>> Hi, >>> >>> Thanks for the answer. (sorry I was out with the flu for a week) >>> >>>> I am not too keen to add an env var/system property to accommodate this >>>> kind of PKCS11 library bugs since this should be rare I hope. >>>> Valerie >>> Unfortunately I don't see it as rare and the impact is huge due to the >>> slow turnaround of HSM firmware. Due to FIPS certification and whatnot >>> HSM vendors do not fix simple things like this sometimes in years. This >>> puts customers to a complete halt in the meantime. These are heavily >>> certified environments where re-certification alone takes at least 6 >>> months. >>> >>> Having worked with all major HSM vendors for many years I know that >>> PKCS11 library bugs are not rare at all. If we'd be using PKCS#11 >>> natively, you can hack around by ignoring bad values, but when using >>> SunPKCS#11 you are stuck with Java's rules unless you patch SunPKCS11 >>> which is not for everyone. >>> >>> Due to the strictness of using SunPKCS11 compared to native PKCS#11, >>> some more flexibility in configuration would help a lot. >>> >>> For many years SunPKCS11 have worked great. But also the HSM world is >>> moving faster than they did 5 years ago, and unfortunately this means >>> that we're seeing a huge rise in PKCS#11 issues in the last year, >>> requiring quite a lot of hacking in SunPKCS11 to workaround. In theory >>> it should not be needed, but in practice it is. Faster evolution = more >>> bugs. >>> >>> I just showed two real world use cases that you really need to be able >>> to work around. And these will not be the last. PKCS#11 is a complex >>> standard and implementors will rarely get it exactly right. >>> >>> Increased flexibility and more control around PKCS#11 will be needed in >>> the future imho, or users will be forced to move to other solutions like >>> JackNJI11. We'd much rather use SunPKCS11 but customers (end users) >>> can't get stuck between Java and HSM vendors in a fight who does PKCS#11 >>> right or wrong. >>> >>> Cheers, >>> Tomas >>> >>> On 2018-02-01 01:07, Valerie Peng wrote: >>>> Thanks for the feedback. I suppose we can ignore values which obviously >>>> don't make sense such as 0 or max being less than min key size. >>>> However, if the underlying PKCS11 library vendors forgot to update the >>>> max value as in your comment#2, supposedly they should fix it. >>>> I am not too keen to add an env var/system property to accommodate this >>>> kind of PKCS11 library bugs since this should be rare I hope. >>>> Valerie >>>> >>>> On 1/30/2018 12:22 AM, Tomas Gustavsson wrote: >>>>> Hi, >>>>> >>>>> At some revision in the PKCS#11 provider there was introduced checking >>>>> of C_GetMechanismInfo min and max sizes. >>>>> >>>>> This has turned out to be a bit fragile. Let me give two real world >>>>> examples: >>>>> >>>>> 1. Amazon Cloud HSM report minSize and maxSize for EC keys to 0. The >>>>> Java PKCS#11 provider will happily take 0 as maxSize and refuse to >>>>> generate any EC keys at all. Needless to say, without the Java >>>>> check it >>>>> would be no problem. >>>>> >>>>> 131: C_GetMechanismInfo >>>>> 2018-01-30 07:52:20.740 >>>>> [in] slotID = 0x1 >>>>> ?? CKM_EC_KEY_PAIR_GEN >>>>> [out] pInfo: >>>>> CKM_EC_KEY_PAIR_GEN?????????? : min:0 max:0 flags:0x10001 ( Hardware >>>>> KeyPair ) >>>>> Returned:? 0 CKR_OK >>>>> >>>>> (we are reporting this to Amazon as well) >>>>> >>>>> 2. Thales HSMs (some?) report maxSize for RSA_PKCS key generation as >>>>> 4096, but will happily generate 8192 bit keys. I.e. the reported >>>>> maxSize >>>>> is not true. >>>>> We have customers who used to generate 8192 bit RSA keys, but after a >>>>> Java update can not do so anymore, because Java compares against this >>>>> value. >>>>> >>>>> >>>>> * Suggestions: >>>>> >>>>> 1. In the constructor of P11KeyPairGenerator where minKeyLen and >>>>> maxKeyLen are calculated, never allow maxKeyLen to be less than >>>>> minKeyLen. >>>>> >>>>> I.e. change the part: >>>>> ????????? // auto-adjust default keysize in case it's out-of-range >>>>> ????????? if ((minKeyLen != -1) && (keySize < minKeyLen)) { >>>>> ????????????? keySize = minKeyLen; >>>>> ????????? } >>>>> ????????? if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { >>>>> ????????????? keySize = maxKeyLen; >>>>> ????????? } >>>>> >>>>> To include something like: >>>>> ????????? // auto-adjust default keysize in case it's out-of-range >>>>> ????????? if ((minKeyLen != -1) && (keySize < minKeyLen)) { >>>>> ????????????? keySize = minKeyLen; >>>>> ????????? } >>>>> ????????? if ((maxKeyLen != -1) && (maxKeyLen < minKeyLen)) { >>>>> ????????????? maxKeyLen = minKeyLen; >>>>> ????????? } >>>>> ????????? if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { >>>>> ????????????? keySize = maxKeyLen; >>>>> ????????? } >>>>> >>>>> 2. Allow to ignore checking of maxKeyLen by some means, i.e. allow to >>>>> ignore checking against C_GetMechanismInfo if you know that the HSM >>>>> does >>>>> not provide sane values. I.e. an environment variable for example >>>>> reverting back to the old behavior when these were ignored. >>>>> >>>>> Regards, >>>>> Tomas Gustavsson >>>>> > From mbalao at redhat.com Wed Feb 14 15:00:27 2018 From: mbalao at redhat.com (Martin Balao) Date: Wed, 14 Feb 2018 12:00:27 -0300 Subject: RFR JDK-8195607: NSS + Sqlite DB In-Reply-To: References: Message-ID: Hi, Can someone review this proposal? Thanks, Martin.- On Thu, Feb 1, 2018 at 3:06 PM, Martin Balao wrote: > I'd like to propose a fix for JDK-8195607 (sun/security/ > pkcs11/Secmod/TestNssDbSqlite.java failed with "NSS initialization > failed" on NSS 3.34.1) [1]: > > * http://cr.openjdk.java.net/~akasko/mbalao/8195607_nss_ > sqlite/8195607.webrev.01/ > * http://cr.openjdk.java.net/~akasko/mbalao/8195607_nss_ > sqlite/8195607.webrev.01.zip > > Kind regards, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8195607 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Thu Feb 15 09:04:28 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 15 Feb 2018 09:04:28 +0000 Subject: RFR: 8193892: Impact of noncloneable MessageDigest implementation In-Reply-To: <9a2be852-bd0c-d025-0278-ab266a4ced66@oracle.com> References: <9a2be852-bd0c-d025-0278-ab266a4ced66@oracle.com> Message-ID: A reminder for this review.. regards, Sean. On 09/02/2018 16:25, Se?n Coffey wrote: > Looking to push a new test which helps test CloneableDigest code. It's > something that arose during JDK-8193683 fix. > > The test was contributed by Brad Wetmore. I've converted it to use the > SSLSocketTemplate. > > JBS : https://bugs.openjdk.java.net/browse/JDK-8193892 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8193892/webrev/ > From xuelei.fan at oracle.com Thu Feb 15 15:40:08 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 15 Feb 2018 07:40:08 -0800 Subject: RFR: 8193892: Impact of noncloneable MessageDigest implementation In-Reply-To: References: <9a2be852-bd0c-d025-0278-ab266a4ced66@oracle.com> Message-ID: Looks fine to me. Thanks! Xuelei On 2/15/2018 1:04 AM, Se?n Coffey wrote: > A reminder for this review.. > > regards, > Sean. > > > On 09/02/2018 16:25, Se?n Coffey wrote: >> Looking to push a new test which helps test CloneableDigest code. It's >> something that arose during JDK-8193683 fix. >> >> The test was contributed by Brad Wetmore. I've converted it to use the >> SSLSocketTemplate. >> >> JBS : https://bugs.openjdk.java.net/browse/JDK-8193892 >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8193892/webrev/ >> > From valerie.peng at oracle.com Thu Feb 15 20:10:16 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 15 Feb 2018 12:10:16 -0800 Subject: RFR: 8193892: Impact of noncloneable MessageDigest implementation In-Reply-To: References: <9a2be852-bd0c-d025-0278-ab266a4ced66@oracle.com> Message-ID: <6709835e-e584-84a6-1638-b04df5110e6f@oracle.com> Looks fine to me. Thanks, Valerie On 2/15/2018 1:04 AM, Se?n Coffey wrote: > A reminder for this review.. > > regards, > Sean. > > > On 09/02/2018 16:25, Se?n Coffey wrote: >> Looking to push a new test which helps test CloneableDigest code. >> It's something that arose during JDK-8193683 fix. >> >> The test was contributed by Brad Wetmore. I've converted it to use >> the SSLSocketTemplate. >> >> JBS : https://bugs.openjdk.java.net/browse/JDK-8193892 >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8193892/webrev/ >> > From valerie.peng at oracle.com Thu Feb 15 22:51:44 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 15 Feb 2018 14:51:44 -0800 Subject: PKCS#11 provider issues with min and max size In-Reply-To: References: <97ca28d8-8466-9f9f-c19d-567b38f7a0f7@primekey.se> <276cc36a-7967-d4fb-ce98-f0d8b6b43681@oracle.com> <3d323e74-b60c-cb2d-466f-345b16f6e368@primekey.se> <041b119f-8341-2ddb-9347-dfcc552059c2@primekey.se> <4d8eccbc-9f2a-e42c-665f-a09be1626a94@oracle.com> Message-ID: <0e20f50b-1830-67cc-ecad-f7adab14d0b9@oracle.com> Yes, please go ahead and file a bug for this. Thanks! Valerie On 2/13/2018 6:00 AM, Tomas Gustavsson wrote: > Thanks for taking a look. > > I haven't created a bug for this (yet) Let me know if that would help. > > Regards, > Tomas > On 2018-02-09 20:04, Valerie Peng wrote: >> Hmm, seems reasonable to support this in the provider configuration file. >> Or, on a similar note, but slightly different approach is to just add an >> configuration option for disabling checking the supported key size range. >> Regards, >> Valerie >> >> On 2/9/2018 2:16 AM, Tomas Gustavsson wrote: >>> I just realized that a natural place to configure provider behavior is >>> in the provider construction, which is also per provider, so you can >>> have multiple ones with different configuration. We are already using an >>> InputStream to construct SunPKCS11, and adding more parameters to >>> configure/override defaults would be natural. >>> >>> I.e.: >>> ----- >>> name =? >>> library = ; >>> slot = slot >>> rsakeygenmech = CKM_RSA_X9_31_KEY_PAIR_GEN >>> rsakeygenmechminsize = 1024 >>> rsakeygenmechmaxsize = 8192 >>> >>> attributes(*, CKO_PUBLIC_KEY, *) = { >>> ?? CKA_TOKEN = false >>> ?? CKA_ENCRYPT = true >>> ?? CKA_VERIFY = true >>> ?? CKA_WRAP = true >>> } >>> attributes(*, CKO_PRIVATE_KEY, *) = { >>> ?? CKA_DERIVE = false >>> ?? CKA_TOKEN = true >>> ?? CKA_PRIVATE = true >>> ?? CKA_SENSITIVE = true >>> ?? CKA_EXTRACTABLE = false >>> ?? CKA_DECRYPT = true >>> ?? CKA_SIGN = true >>> ?? CKA_UNWRAP = true >>> } >>> attributes(*, CKO_SECRET_KEY, *) = { >>> ?? CKA_SENSITIVE = true >>> ?? CKA_EXTRACTABLE = false >>> ?? CKA_ENCRYPT = true >>> ?? CKA_DECRYPT = true >>> ?? CKA_SIGN = true >>> ?? CKA_VERIFY = true >>> ?? CKA_WRAP = true >>> ?? CKA_UNWRAP = true >>> } >>> ----- >>> >>> Cheers, >>> Tomas >>> >>> On 2018-02-09 09:55, Tomas Gustavsson wrote: >>>> Hi, >>>> >>>> Thanks for the answer. (sorry I was out with the flu for a week) >>>> >>>>> I am not too keen to add an env var/system property to accommodate this >>>>> kind of PKCS11 library bugs since this should be rare I hope. >>>>> Valerie >>>> Unfortunately I don't see it as rare and the impact is huge due to the >>>> slow turnaround of HSM firmware. Due to FIPS certification and whatnot >>>> HSM vendors do not fix simple things like this sometimes in years. This >>>> puts customers to a complete halt in the meantime. These are heavily >>>> certified environments where re-certification alone takes at least 6 >>>> months. >>>> >>>> Having worked with all major HSM vendors for many years I know that >>>> PKCS11 library bugs are not rare at all. If we'd be using PKCS#11 >>>> natively, you can hack around by ignoring bad values, but when using >>>> SunPKCS#11 you are stuck with Java's rules unless you patch SunPKCS11 >>>> which is not for everyone. >>>> >>>> Due to the strictness of using SunPKCS11 compared to native PKCS#11, >>>> some more flexibility in configuration would help a lot. >>>> >>>> For many years SunPKCS11 have worked great. But also the HSM world is >>>> moving faster than they did 5 years ago, and unfortunately this means >>>> that we're seeing a huge rise in PKCS#11 issues in the last year, >>>> requiring quite a lot of hacking in SunPKCS11 to workaround. In theory >>>> it should not be needed, but in practice it is. Faster evolution = more >>>> bugs. >>>> >>>> I just showed two real world use cases that you really need to be able >>>> to work around. And these will not be the last. PKCS#11 is a complex >>>> standard and implementors will rarely get it exactly right. >>>> >>>> Increased flexibility and more control around PKCS#11 will be needed in >>>> the future imho, or users will be forced to move to other solutions like >>>> JackNJI11. We'd much rather use SunPKCS11 but customers (end users) >>>> can't get stuck between Java and HSM vendors in a fight who does PKCS#11 >>>> right or wrong. >>>> >>>> Cheers, >>>> Tomas >>>> >>>> On 2018-02-01 01:07, Valerie Peng wrote: >>>>> Thanks for the feedback. I suppose we can ignore values which obviously >>>>> don't make sense such as 0 or max being less than min key size. >>>>> However, if the underlying PKCS11 library vendors forgot to update the >>>>> max value as in your comment#2, supposedly they should fix it. >>>>> I am not too keen to add an env var/system property to accommodate this >>>>> kind of PKCS11 library bugs since this should be rare I hope. >>>>> Valerie >>>>> >>>>> On 1/30/2018 12:22 AM, Tomas Gustavsson wrote: >>>>>> Hi, >>>>>> >>>>>> At some revision in the PKCS#11 provider there was introduced checking >>>>>> of C_GetMechanismInfo min and max sizes. >>>>>> >>>>>> This has turned out to be a bit fragile. Let me give two real world >>>>>> examples: >>>>>> >>>>>> 1. Amazon Cloud HSM report minSize and maxSize for EC keys to 0. The >>>>>> Java PKCS#11 provider will happily take 0 as maxSize and refuse to >>>>>> generate any EC keys at all. Needless to say, without the Java >>>>>> check it >>>>>> would be no problem. >>>>>> >>>>>> 131: C_GetMechanismInfo >>>>>> 2018-01-30 07:52:20.740 >>>>>> [in] slotID = 0x1 >>>>>> ?? CKM_EC_KEY_PAIR_GEN >>>>>> [out] pInfo: >>>>>> CKM_EC_KEY_PAIR_GEN?????????? : min:0 max:0 flags:0x10001 ( Hardware >>>>>> KeyPair ) >>>>>> Returned:? 0 CKR_OK >>>>>> >>>>>> (we are reporting this to Amazon as well) >>>>>> >>>>>> 2. Thales HSMs (some?) report maxSize for RSA_PKCS key generation as >>>>>> 4096, but will happily generate 8192 bit keys. I.e. the reported >>>>>> maxSize >>>>>> is not true. >>>>>> We have customers who used to generate 8192 bit RSA keys, but after a >>>>>> Java update can not do so anymore, because Java compares against this >>>>>> value. >>>>>> >>>>>> >>>>>> * Suggestions: >>>>>> >>>>>> 1. In the constructor of P11KeyPairGenerator where minKeyLen and >>>>>> maxKeyLen are calculated, never allow maxKeyLen to be less than >>>>>> minKeyLen. >>>>>> >>>>>> I.e. change the part: >>>>>> ????????? // auto-adjust default keysize in case it's out-of-range >>>>>> ????????? if ((minKeyLen != -1) && (keySize < minKeyLen)) { >>>>>> ????????????? keySize = minKeyLen; >>>>>> ????????? } >>>>>> ????????? if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { >>>>>> ????????????? keySize = maxKeyLen; >>>>>> ????????? } >>>>>> >>>>>> To include something like: >>>>>> ????????? // auto-adjust default keysize in case it's out-of-range >>>>>> ????????? if ((minKeyLen != -1) && (keySize < minKeyLen)) { >>>>>> ????????????? keySize = minKeyLen; >>>>>> ????????? } >>>>>> ????????? if ((maxKeyLen != -1) && (maxKeyLen < minKeyLen)) { >>>>>> ????????????? maxKeyLen = minKeyLen; >>>>>> ????????? } >>>>>> ????????? if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { >>>>>> ????????????? keySize = maxKeyLen; >>>>>> ????????? } >>>>>> >>>>>> 2. Allow to ignore checking of maxKeyLen by some means, i.e. allow to >>>>>> ignore checking against C_GetMechanismInfo if you know that the HSM >>>>>> does >>>>>> not provide sane values. I.e. an environment variable for example >>>>>> reverting back to the old behavior when these were ignored. >>>>>> >>>>>> Regards, >>>>>> Tomas Gustavsson >>>>>> From valerie.peng at oracle.com Fri Feb 16 00:40:40 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 15 Feb 2018 16:40:40 -0800 Subject: [11] RFR: JDK-8197441: Signature#initSign/initVerify for an invalid private/public key fails with ClassCastException for SunPKCS11 provider Message-ID: <52a042e1-fc1b-7b82-362c-81aff1a6b285@oracle.com> Anyone can help review this trivial fix? It'll just take a minute or so. Essentially, the fix is to re-throw with InvalidKeyException when the casting failed. Bug: https://bugs.openjdk.java.net/browse/JDK-8197441 Webrev: http://cr.openjdk.java.net/~valeriep/8197441/webrev.00/ Thanks, Valerie From anthony.scarpino at oracle.com Fri Feb 16 00:46:23 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 15 Feb 2018 16:46:23 -0800 Subject: [11] RFR: JDK-8197441: Signature#initSign/initVerify for an invalid private/public key fails with ClassCastException for SunPKCS11 provider In-Reply-To: <52a042e1-fc1b-7b82-362c-81aff1a6b285@oracle.com> References: <52a042e1-fc1b-7b82-362c-81aff1a6b285@oracle.com> Message-ID: On 02/15/2018 04:40 PM, Valerie Peng wrote: > > Anyone can help review this trivial fix? It'll just take a minute or so. > Essentially, the fix is to re-throw with InvalidKeyException when the > casting failed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8197441 > Webrev: http://cr.openjdk.java.net/~valeriep/8197441/webrev.00/ > > Thanks, > Valerie > > I think "correct type" is better, but the word choice is up to you. Consider it reviewed. Tony From valerie.peng at oracle.com Fri Feb 16 00:53:59 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 15 Feb 2018 16:53:59 -0800 Subject: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: References: <42dcb5c2-0d98-1ae4-a26d-b79e0a5c9345@oracle.com> Message-ID: <22b6c79c-dffd-2f2d-414b-d8a543bbc96c@oracle.com> I am ok with the idea of putting the public API refactoring under a separate RFE. Let me apply your updated patch below and run existing regressions again. Thanks, Valerie On 2/5/2018 5:51 AM, Martin Balao wrote: > Hi Valerie, > > Thanks for your review. > > Here it's the new webrev updated to the new repository structure. I've > also updated the testcase to use the new @module jtreg feature: > > ?* > http://cr.openjdk.java.net/~akasko/mbalao/jdk_8029661_tls_12_sunpkcs11/2018_02_02/8029661.webrev.02 > > (online) > ?* > http://cr.openjdk.java.net/~akasko/mbalao/jdk_8029661_tls_12_sunpkcs11/2018_02_02/8029661.webrev.02.zip > > (download) > > A few comments in regards to creating public APIs from > sun.security.internal.spec classes. > > Classes in jdk/src/java.base/share/classes/sun/security/internal/spec: > ?* TlsKeyMaterialParameterSpec.java > ?* TlsMasterSecretParameterSpec.java > ?* TlsRsaPremasterSecretParameterSpec.java > ?* TlsKeyMaterialSpec.java > ?* TlsPrfParameterSpec.java > > Classes in jdk/src/java.base/share/classes/java/security/spec (which I > assume would be the destination): > ?* AlgorithmParameterSpec.java > ?* ECGenParameterSpec.java > ?* InvalidParameterSpecException.java > ?* RSAOtherPrimeInfo.java > ?* DSAGenParameterSpec.java > ?* ECParameterSpec.java > ?* KeySpec.java > ?* ... > > TlsRsaPremasterSecretParameterSpec class contains information about > min and max SSL/TLS version and, optionally, the pre-master encoded > key. This information may be useful to any 3rd party class that > implements a KeyGenerator to generate RSA pre-master secrets. > > TlsMasterSecretParameterSpec class contains information (client/server > random, pre-master secret, hash algorithm, etc.) to generate a master > secret from a pre-master secret. > > TlsKeyMaterialParameterSpec class contains information (client/server > random, master secret, hash algorithm, etc.) to generate keys for a > session from a master secret. > > TlsPrfParameterSpec class contains information (secret key, label, > hash algorithm, etc.) to generate handshake authentication codes. > > TlsKeyMaterialSpec class contains information about session keys. This > class inherits from SecretKey class. > > So, I agree with you: these parameters/specs may be used by a 3rd > party and would be better to have them as public interfaces. > > However, I suggest to address that in a new ticket because: > ?* it is not strictly inherent to SunPKCS11 + TLS 1.2 support we are > providing in the context of this ticket; > ?* it would be more clear both in tickets documentation and repository > changeset; > ?* this refactoring is going to go through CSR, which SunPKCS11 + TLS > 1.2 support does not need; and, > ?* we should also evaluate how TLS 1.3 changes going to impact into this. > > Would splitting this into a new ticket work for you? > > Kind regards, > Martin.- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Fri Feb 16 02:11:10 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 15 Feb 2018 18:11:10 -0800 Subject: [11] RFR: JDK-8197441: Signature#initSign/initVerify for an invalid private/public key fails with ClassCastException for SunPKCS11 provider In-Reply-To: References: <52a042e1-fc1b-7b82-362c-81aff1a6b285@oracle.com> Message-ID: <83762c99-fc7e-d172-a932-8ed9a3187cca@oracle.com> Sure, I'll change it to "correct type". Thanks, Valerie On 2/15/2018 4:46 PM, Anthony Scarpino wrote: > On 02/15/2018 04:40 PM, Valerie Peng wrote: >> >> Anyone can help review this trivial fix? It'll just take a minute or so. >> Essentially, the fix is to re-throw with InvalidKeyException when the >> casting failed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8197441 >> Webrev: http://cr.openjdk.java.net/~valeriep/8197441/webrev.00/ >> >> Thanks, >> Valerie >> >> > > I think "correct type" is better, but the word choice is up to you. > Consider it reviewed. > > Tony From xuelei.fan at oracle.com Tue Feb 20 19:57:20 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 20 Feb 2018 11:57:20 -0800 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) Message-ID: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> Hi, I'd like to invite you to review the TLS 1.3 full handshake implementation. I appreciate it if I could have feedback before March 9, 2018. In the "JDK-8185576: New handshake implementation" [1] code review around, I was trying to re-org the TLS handshaking implementation in the SunJSSE provider. If you had reviewed that part, you can start from the following webrev that based on the update of JDK-8185576: http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.00 If you would like start from earlier, here is the webrev that contains the handshaking implementation re-org in JDK-8185576: http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 This changeset only implements the full handshake of TLS 1.3, rather then a fully implementation of the latest TLS 1.3 draft [2]. In this implementation, I removed: 1. the KRB5 cipher suite implementation. Please let me know if you are still using KRB5 cipher suite. I may not add them back if no objections. 2. OCSP stapling. This feature will be added back later. Resumption and key update, and more features may be added later. Thanks & Regards, Xuelei [1]: http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016642.html [2]: https://tools.ietf.org/html/draft-ietf-tls-tls13-24 From david.lloyd at redhat.com Wed Feb 21 13:06:25 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Wed, 21 Feb 2018 07:06:25 -0600 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> Message-ID: On Tue, Feb 20, 2018 at 1:57 PM, Xuelei Fan wrote: > In this implementation, I removed: > 1. the KRB5 cipher suite implementation. > Please let me know if you are still using KRB5 cipher suite. I may not add > them back if no objections. I am given to understand that we have multiple users using the KRB5 cipher suite. -- - DML From xuelei.fan at oracle.com Wed Feb 21 15:32:05 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 21 Feb 2018 07:32:05 -0800 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> Message-ID: Thanks for the feed back. It's good enough to get KRB5 cipher suites back. Regards, Xuelei On 2/21/2018 5:06 AM, David Lloyd wrote: > On Tue, Feb 20, 2018 at 1:57 PM, Xuelei Fan wrote: >> In this implementation, I removed: >> 1. the KRB5 cipher suite implementation. >> Please let me know if you are still using KRB5 cipher suite. I may not add >> them back if no objections. > > I am given to understand that we have multiple users using the KRB5 > cipher suite. > From jkalina at redhat.com Wed Feb 21 16:39:49 2018 From: jkalina at redhat.com (Jan Kalina) Date: Wed, 21 Feb 2018 17:39:49 +0100 Subject: [PATCH] JDK-8194630: Uninitialized initiator_address in native GSS Message-ID: I has prepared fix for bug related to using native GSS API. Uninitialized fields causes JVM crash or authentication failing. Bug consequences are more described in bugreport: https://bugs.openjdk.java.net/browse/JDK-8194630 Reproducer is attached to bugreport too. Would anyone be interested in reviewing/sponsoring this change? It would be really great to get this into JDK 9 and above. (I am covered by Red Hat OCA.) Thanks for your response! PATCH: ---------------------------------------------- diff --git a/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c b/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c --- a/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c +++ b/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c @@ -169,6 +169,11 @@ // initialize addrtype in CB first cb->initiator_addrtype = GSS_C_AF_NULLADDR; cb->acceptor_addrtype = GSS_C_AF_NULLADDR; + // addresses needs to be initialized to empty + cb->initiator_address.length = 0; + cb->initiator_address.value = NULL; + cb->acceptor_address.length = 0; + cb->acceptor_address.value = NULL; /* set up initiator address */ jinetAddr = (*env)->CallObjectMethod(env, jcb, ---------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Wed Feb 21 18:16:27 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 21 Feb 2018 10:16:27 -0800 Subject: [PATCH] JDK-8194630: Uninitialized initiator_address in native GSS In-Reply-To: References: Message-ID: <13091827-2a66-e87d-d634-97b4d77ed1ca@oracle.com> I have this on my to-do-list and will include this for the next release, JDK 11, whose release date is Nov this year. Thanks, Valerie On 2/21/2018 8:39 AM, Jan Kalina wrote: > I has prepared fix for bug related to using native GSS API. > Uninitialized fields causes JVM crash or authentication failing. > > Bug consequences are more described in bugreport: > https://bugs.openjdk.java.net/browse/JDK-8194630 > Reproducer is attached to bugreport too. > > Would anyone be interested in reviewing/sponsoring this change? > It would be really great to get this into JDK 9 and above. > (I am covered by Red Hat OCA.) > > Thanks for your response! > > PATCH: > ---------------------------------------------- > diff --git a/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c > b/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c > --- a/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c > +++ b/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c > @@ -169,6 +169,11 @@ > ?? // initialize addrtype in CB first > ?? cb->initiator_addrtype = GSS_C_AF_NULLADDR; > ?? cb->acceptor_addrtype = GSS_C_AF_NULLADDR; > +? // addresses needs to be initialized to empty > +? cb->initiator_address.length = 0; > +? cb->initiator_address.value = NULL; > +? cb->acceptor_address.length = 0; > +? cb->acceptor_address.value = NULL; > > ?? /* set up initiator address */ > ?? jinetAddr = (*env)->CallObjectMethod(env, jcb, > ---------------------------------------------- > From mbalao at redhat.com Wed Feb 21 18:26:59 2018 From: mbalao at redhat.com (Martin Balao) Date: Wed, 21 Feb 2018 15:26:59 -0300 Subject: [PATCH] JDK-8194630: Uninitialized initiator_address in native GSS In-Reply-To: References: Message-ID: Have you considered zeroizing the whole "gss_channel_bindings_t" structure with memset? So we don't have problem if new fields are eventually added. On Wed, Feb 21, 2018 at 1:39 PM, Jan Kalina wrote: > I has prepared fix for bug related to using native GSS API. > Uninitialized fields causes JVM crash or authentication failing. > > Bug consequences are more described in bugreport: > https://bugs.openjdk.java.net/browse/JDK-8194630 > Reproducer is attached to bugreport too. > > Would anyone be interested in reviewing/sponsoring this change? > It would be really great to get this into JDK 9 and above. > (I am covered by Red Hat OCA.) > > Thanks for your response! > > PATCH: > ---------------------------------------------- > diff --git a/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c > b/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c > --- a/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c > +++ b/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c > @@ -169,6 +169,11 @@ > // initialize addrtype in CB first > cb->initiator_addrtype = GSS_C_AF_NULLADDR; > cb->acceptor_addrtype = GSS_C_AF_NULLADDR; > + // addresses needs to be initialized to empty > + cb->initiator_address.length = 0; > + cb->initiator_address.value = NULL; > + cb->acceptor_address.length = 0; > + cb->acceptor_address.value = NULL; > > /* set up initiator address */ > jinetAddr = (*env)->CallObjectMethod(env, jcb, > ---------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnu.andrew at redhat.com Thu Feb 22 04:09:52 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 22 Feb 2018 04:09:52 +0000 Subject: [8u] [RFR] Request for Review of JDK-8196952: Bad primeCertainty value setting in DSAParameterGenerator Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8196952 Webrev: http://cr.openjdk.java.net/~andrew/openjdk8/8196952/webrev.01/ Review thread: N/A When merging the recent 8u161 update into IcedTea, I came across a merge issue related to the ordering of changes to DSAParameterGenerator. It's an issue only relevant to OpenJDK 8 and any further backports that use the version from that repository. In OpenJDK 9 and up, the work in 8072452 was done in April 2016, and 8181048 in July 2017. However, in OpenJDK 8, 8072452 was not present when 8181048 was backported in July 2017, and was only added in the last CPU. As a result, the two changes were applied there in the opposite order and 8072452 ended up reverting parts of 8181048. The main issue is that 8181048 has this change: - int primeCertainty = 80; // for 1024-bit prime P - if (valueL == 2048) { + int primeCertainty = -1; + if (valueL <= 1024) { + primeCertainty = 80; + } else if (valueL == 2048) { But then the backport of 8072452 reverts part of it: @@ -205,11 +206,13 @@ int b = (valueL - 1) % outLen; byte[] seedBytes = new byte[seedLen/8]; BigInteger twoSl = TWO.pow(seedLen); - int primeCertainty = -1; + int primeCertainty = 80; // for 1024-bit prime P if (valueL <= 1024) { primeCertainty = 80; } else if (valueL == 2048) { primeCertainty = 112; + } else if (valueL == 3072) { + primeCertainty = 128; } if (primeCertainty < 0) { So primeCertainty is never going to be < 0. The other differences are minor, but help keep the code in sync with OpenJDK 9 and slightly more efficient; we don't bother setting valueN in the if block as it will be reset by the call to getDefDSASubprimeSize anyway, and we use BigInteger.ONE instead of creating our own version. Sadly, BigInteger.TWO is not public in OpenJDK 8 so we still need a local variable for that. As stated above, the patch is inapplicable for 9 and up, so needs a review and approval for OpenJDK 8. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From weijun.wang at oracle.com Thu Feb 22 08:36:55 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 22 Feb 2018 16:36:55 +0800 Subject: RFR 8197518: Kerberos krb5 authentication: AuthList's put method leads to performance issue Message-ID: Please take a review at http://cr.openjdk.java.net/~weijun/8197518/webrev.00/ Two notes: 1. I tried list.subList(here, end).clear() but it's not faster. 2. I have looked at ConcurrentHashMap + ConcurrentSkipListMap but will need more time to verify its correctness and measure the performance gain. Since the bug is reported on 8u, a safer fix looks better. Noreg-perf. Thanks Max From jkalina at redhat.com Thu Feb 22 10:49:18 2018 From: jkalina at redhat.com (Jan Kalina) Date: Thu, 22 Feb 2018 11:49:18 +0100 Subject: [PATCH] JDK-8194630: Uninitialized initiator_address in native GSS In-Reply-To: References: Message-ID: Ok, thanks Valerie! Sorry for spam, I has supposed my previous email was not considered to be patch. Martin: As this is way how it is initialized in other places, I has not considered it. http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/59e88d3b9b17/src/share/native/sun/security/jgss/wrapper/GSSLibStub.c#l132 Follows fixed version - tested and works ok - keeping on Valerie which version will be used: --------------------------------------------- diff --git a/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c b/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c --- a/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c +++ b/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c @@ -169,6 +169,9 @@ // initialize addrtype in CB first cb->initiator_addrtype = GSS_C_AF_NULLADDR; cb->acceptor_addrtype = GSS_C_AF_NULLADDR; + // addresses needs to be initialized to empty + memset(&cb->initiator_address, 0, sizeof(cb->initiator_address)); + memset(&cb->acceptor_address, 0, sizeof(cb->acceptor_address)); /* set up initiator address */ jinetAddr = (*env)->CallObjectMethod(env, jcb, --------------------------------------------- On Wed, Feb 21, 2018 at 7:26 PM, Martin Balao wrote: > Have you considered zeroizing the whole "gss_channel_bindings_t" structure > with memset? So we don't have problem if new fields are eventually added. > > On Wed, Feb 21, 2018 at 1:39 PM, Jan Kalina wrote: > >> I has prepared fix for bug related to using native GSS API. >> Uninitialized fields causes JVM crash or authentication failing. >> >> Bug consequences are more described in bugreport: >> https://bugs.openjdk.java.net/browse/JDK-8194630 >> Reproducer is attached to bugreport too. >> >> Would anyone be interested in reviewing/sponsoring this change? >> It would be really great to get this into JDK 9 and above. >> (I am covered by Red Hat OCA.) >> >> Thanks for your response! >> >> PATCH: >> ---------------------------------------------- >> diff --git a/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c >> b/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c >> --- a/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c >> +++ b/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c >> @@ -169,6 +169,11 @@ >> // initialize addrtype in CB first >> cb->initiator_addrtype = GSS_C_AF_NULLADDR; >> cb->acceptor_addrtype = GSS_C_AF_NULLADDR; >> + // addresses needs to be initialized to empty >> + cb->initiator_address.length = 0; >> + cb->initiator_address.value = NULL; >> + cb->acceptor_address.length = 0; >> + cb->acceptor_address.value = NULL; >> >> /* set up initiator address */ >> jinetAddr = (*env)->CallObjectMethod(env, jcb, >> ---------------------------------------------- >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Thu Feb 22 12:14:37 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 22 Feb 2018 12:14:37 +0000 Subject: RFR 8197518: Kerberos krb5 authentication: AuthList's put method leads to performance issue In-Reply-To: References: Message-ID: <4b8bf526-bbd8-b288-ac7b-607e0185eb3f@oracle.com> This looks good to me Max. I think it'll solve the issue reported. line 109 : I guess this could turn negative if timeLimit was value < 60. I don't think that's possible unless we're dealing with a strange config! For the code comment, may a minor edit : 111 // Only trigger a cleanup when very old entries exist 112 // (lifespan + 1 min ago). This ensures a cleanup is done 113 // at most every minute. Regards, Sean. On 22/02/18 08:36, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8197518/webrev.00/ > > Two notes: > > 1. I tried list.subList(here, end).clear() but it's not faster. > > 2. I have looked at ConcurrentHashMap + ConcurrentSkipListMap but will need more time to verify its correctness and measure the performance gain. Since the bug is reported on 8u, a safer fix looks better. > > Noreg-perf. > > Thanks > Max > From david.lloyd at redhat.com Thu Feb 22 12:41:26 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 22 Feb 2018 06:41:26 -0600 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> Message-ID: I have an update. :) I've spoken with everyone I could find who deals with user configurations which may include these cipher suites, and they all agree that users are no longer using TLS KRB5 and that it is no longer recommended either. So, from our perspective, it would be OK to drop these after all. On Wed, Feb 21, 2018 at 9:32 AM, Xuelei Fan wrote: > Thanks for the feed back. It's good enough to get KRB5 cipher suites back. > > Regards, > Xuelei > > > On 2/21/2018 5:06 AM, David Lloyd wrote: >> >> On Tue, Feb 20, 2018 at 1:57 PM, Xuelei Fan wrote: >>> >>> In this implementation, I removed: >>> 1. the KRB5 cipher suite implementation. >>> Please let me know if you are still using KRB5 cipher suite. I may not >>> add >>> them back if no objections. >> >> >> I am given to understand that we have multiple users using the KRB5 >> cipher suite. >> > -- - DML From weijun.wang at oracle.com Thu Feb 22 12:55:22 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 22 Feb 2018 20:55:22 +0800 Subject: RFR 8197518: Kerberos krb5 authentication: AuthList's put method leads to performance issue In-Reply-To: <4b8bf526-bbd8-b288-ac7b-607e0185eb3f@oracle.com> References: <4b8bf526-bbd8-b288-ac7b-607e0185eb3f@oracle.com> Message-ID: <58EB8586-0AF0-4AD7-843A-8DE455052201@oracle.com> > On Feb 22, 2018, at 8:14 PM, Se?n Coffey wrote: > > This looks good to me Max. I think it'll solve the issue reported. > > line 109 : I guess this could turn negative if timeLimit was value < 60. I don't think that's possible unless we're dealing with a strange config! Negative time might still work. In fact, time() values before the epoch are also comparable, unless less than -2^32. > > For the code comment, may a minor edit : > > 111 // Only trigger a cleanup when very old entries exist > 112 // (lifespan + 1 min ago). This ensures a cleanup is done > 113 // at most every minute. Accepted. Thanks Max > > Regards, > Sean. > > On 22/02/18 08:36, Weijun Wang wrote: >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8197518/webrev.00/ >> >> Two notes: >> >> 1. I tried list.subList(here, end).clear() but it's not faster. >> >> 2. I have looked at ConcurrentHashMap + ConcurrentSkipListMap but will need more time to verify its correctness and measure the performance gain. Since the bug is reported on 8u, a safer fix looks better. >> >> Noreg-perf. >> >> Thanks >> Max >> > From sean.coffey at oracle.com Thu Feb 22 14:38:50 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 22 Feb 2018 14:38:50 +0000 Subject: [8u] [RFR] Request for Review of JDK-8196952: Bad primeCertainty value setting in DSAParameterGenerator In-Reply-To: References: Message-ID: Thanks for looking at this one Andrew. I've had it on my to-do list. The patch looks fine. Regards, Sean. On 22/02/18 04:09, Andrew Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8196952 > Webrev: http://cr.openjdk.java.net/~andrew/openjdk8/8196952/webrev.01/ > Review thread: N/A > > When merging the recent 8u161 update into IcedTea, I came across > a merge issue related to the ordering of changes to DSAParameterGenerator. > > It's an issue only relevant to OpenJDK 8 and any further backports that > use the version from that repository. > > In OpenJDK 9 and up, the work in 8072452 was done in April 2016, > and 8181048 in July 2017. > > However, in OpenJDK 8, 8072452 was not present when 8181048 > was backported in July 2017, and was only added in the last CPU. > As a result, the two changes were applied there in the opposite order > and 8072452 ended up reverting parts of 8181048. > > The main issue is that 8181048 has this change: > > - int primeCertainty = 80; // for 1024-bit prime P > - if (valueL == 2048) { > + int primeCertainty = -1; > + if (valueL <= 1024) { > + primeCertainty = 80; > + } else if (valueL == 2048) { > > But then the backport of 8072452 reverts part of it: > > @@ -205,11 +206,13 @@ > int b = (valueL - 1) % outLen; > byte[] seedBytes = new byte[seedLen/8]; > BigInteger twoSl = TWO.pow(seedLen); > - int primeCertainty = -1; > + int primeCertainty = 80; // for 1024-bit prime P > if (valueL <= 1024) { > primeCertainty = 80; > } else if (valueL == 2048) { > primeCertainty = 112; > + } else if (valueL == 3072) { > + primeCertainty = 128; > } > > if (primeCertainty < 0) { > > So primeCertainty is never going to be < 0. > > The other differences are minor, but help keep the code in > sync with OpenJDK 9 and slightly more efficient; we don't > bother setting valueN in the if block as it will be reset by > the call to getDefDSASubprimeSize anyway, and we > use BigInteger.ONE instead of creating our own version. > Sadly, BigInteger.TWO is not public in OpenJDK 8 so we > still need a local variable for that. > > As stated above, the patch is inapplicable for 9 and up, > so needs a review and approval for OpenJDK 8. > > Thanks, From xuelei.fan at oracle.com Thu Feb 22 17:45:04 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 22 Feb 2018 09:45:04 -0800 Subject: RFR 8197518: Kerberos krb5 authentication: AuthList's put method leads to performance issue In-Reply-To: References: Message-ID: Looks like list synchronization is a factor of the performance impact. Maybe, you can have a private time for the oldest entry so don't access/iterate/cleanup entries list until necessary. The "at most every minute" may be not a good strategy in some situations. Xuelei On 2/22/2018 12:36 AM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8197518/webrev.00/ > > Two notes: > > 1. I tried list.subList(here, end).clear() but it's not faster. > > 2. I have looked at ConcurrentHashMap + ConcurrentSkipListMap but will need more time to verify its correctness and measure the performance gain. Since the bug is reported on 8u, a safer fix looks better. > > Noreg-perf. > > Thanks > Max > From xuelei.fan at oracle.com Thu Feb 22 20:29:25 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 22 Feb 2018 12:29:25 -0800 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> Message-ID: <0419f803-e67c-074c-ff02-f0d45326d3b4@oracle.com> Updated to use package private HKDF implementation. webrev (based on JDK-8185576): http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.01 webrev (including JDK-8185576): http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 Thanks, Xuelei On 2/20/2018 11:57 AM, Xuelei Fan wrote: > Hi, > > I'd like to invite you to review the TLS 1.3 full handshake > implementation.? I appreciate it if I could have feedback before March > 9, 2018. > > In the "JDK-8185576: New handshake implementation" [1] code review > around, I was trying to re-org the TLS handshaking implementation in the > SunJSSE provider.? If you had reviewed that part, you can start from the > following webrev that based on the update of JDK-8185576: > ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.00 > > If you would like start from earlier, here is the webrev that contains > the handshaking implementation re-org in JDK-8185576: > ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 > > > This changeset only implements the full handshake of TLS 1.3, rather > then a fully implementation of the latest TLS 1.3 draft [2]. > > In this implementation, I removed: > 1. the KRB5 cipher suite implementation. > Please let me know if you are still using KRB5 cipher suite.? I may not > add them back if no objections. > > 2. OCSP stapling. > This feature will be added back later. > > Resumption and key update, and more features may be added later. > > Thanks & Regards, > Xuelei > > [1]: > http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016642.html > > [2]: https://tools.ietf.org/html/draft-ietf-tls-tls13-24 From weijun.wang at oracle.com Fri Feb 23 01:02:13 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 23 Feb 2018 09:02:13 +0800 Subject: RFR 8197518: Kerberos krb5 authentication: AuthList's put method leads to performance issue In-Reply-To: References: Message-ID: You mean I can save it somewhere and only update it when a cleanup is performed? This should be better. Now there will be only isEmpty(), getFirst() and addFirst(), and one less getLast(). Thanks Max > On Feb 23, 2018, at 1:45 AM, Xuelei Fan wrote: > > Looks like list synchronization is a factor of the performance impact. Maybe, you can have a private time for the oldest entry so don't access/iterate/cleanup entries list until necessary. The "at most every minute" may be not a good strategy in some situations. > > Xuelei > > On 2/22/2018 12:36 AM, Weijun Wang wrote: >> Please take a review at >> http://cr.openjdk.java.net/~weijun/8197518/webrev.00/ >> Two notes: >> 1. I tried list.subList(here, end).clear() but it's not faster. >> 2. I have looked at ConcurrentHashMap + ConcurrentSkipListMap but will need more time to verify its correctness and measure the performance gain. Since the bug is reported on 8u, a safer fix looks better. >> Noreg-perf. >> Thanks >> Max From weijun.wang at oracle.com Fri Feb 23 01:55:12 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 23 Feb 2018 09:55:12 +0800 Subject: RFR 8197518: Kerberos krb5 authentication: AuthList's put method leads to performance issue In-Reply-To: References: Message-ID: Updated webrev at http://cr.openjdk.java.net/~weijun/8197518/webrev.01/. > On Feb 23, 2018, at 9:02 AM, Weijun Wang wrote: > > You mean I can save it somewhere and only update it when a cleanup is performed? > > This should be better. Now there will be only isEmpty(), getFirst() and addFirst(), and one less getLast(). > > Thanks > Max > >> On Feb 23, 2018, at 1:45 AM, Xuelei Fan wrote: >> >> Looks like list synchronization is a factor of the performance impact. Maybe, you can have a private time for the oldest entry so don't access/iterate/cleanup entries list until necessary. The "at most every minute" may be not a good strategy in some situations. In fact, it's now almost "exactly every minute". What situations do you think it's not good? I cannot use size() because I have to remember all entries with lifespan to be correct. Thanks Max >> >> Xuelei >> >> On 2/22/2018 12:36 AM, Weijun Wang wrote: >>> Please take a review at >>> http://cr.openjdk.java.net/~weijun/8197518/webrev.00/ >>> Two notes: >>> 1. I tried list.subList(here, end).clear() but it's not faster. >>> 2. I have looked at ConcurrentHashMap + ConcurrentSkipListMap but will need more time to verify its correctness and measure the performance gain. Since the bug is reported on 8u, a safer fix looks better. >>> Noreg-perf. >>> Thanks >>> Max > From xuelei.fan at oracle.com Fri Feb 23 03:25:14 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 22 Feb 2018 19:25:14 -0800 Subject: RFR 8197518: Kerberos krb5 authentication: AuthList's put method leads to performance issue In-Reply-To: References: Message-ID: <7fbfed72-c9c0-6186-6c62-1a51a678c337@oracle.com> Hi Weijun, I thought more about the performance impact. The impact may mainly come from the big size of the cached entries. The current implementation needs to go over the full list: find the 1st expired item and then remove the rest. The previous one have an additional round with entries.indexOf(). Could we just start from the end of the list? while (true) { E e = entries.removeLast(); if e not expired { add it back and break; } }; If the list is really big, and the lifetime is significant big as well (>> 1 minute), iterate from the oldest item (backward from the end of the list) may be much more effective. LinkedList itself is not synchronized, so as if there is not too much items to go over, the performance should be fine. I'm hesitate to hard code a cleanup every 1 minute strategy. If we clean often, there may be not too much items to go over in the list. So we might be able to remove the "at most every minute" strategy. Xuelei On 2/22/2018 5:55 PM, Weijun Wang wrote: > Updated webrev at http://cr.openjdk.java.net/~weijun/8197518/webrev.01/. > >> On Feb 23, 2018, at 9:02 AM, Weijun Wang wrote: >> >> You mean I can save it somewhere and only update it when a cleanup is performed? >> >> This should be better. Now there will be only isEmpty(), getFirst() and addFirst(), and one less getLast(). >> >> Thanks >> Max >> >>> On Feb 23, 2018, at 1:45 AM, Xuelei Fan wrote: >>> >>> Looks like list synchronization is a factor of the performance impact. Maybe, you can have a private time for the oldest entry so don't access/iterate/cleanup entries list until necessary. The "at most every minute" may be not a good strategy in some situations. > > In fact, it's now almost "exactly every minute". What situations do you think it's not good? I cannot use size() because I have to remember all entries with lifespan to be correct. > > Thanks > Max > >>> >>> Xuelei >>> >>> On 2/22/2018 12:36 AM, Weijun Wang wrote: >>>> Please take a review at >>>> http://cr.openjdk.java.net/~weijun/8197518/webrev.00/ >>>> Two notes: >>>> 1. I tried list.subList(here, end).clear() but it's not faster. >>>> 2. I have looked at ConcurrentHashMap + ConcurrentSkipListMap but will need more time to verify its correctness and measure the performance gain. Since the bug is reported on 8u, a safer fix looks better. >>>> Noreg-perf. >>>> Thanks >>>> Max >> > From gnu.andrew at redhat.com Fri Feb 23 05:38:25 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 23 Feb 2018 05:38:25 +0000 Subject: [8u] [RFR] Request for Review of JDK-8196952: Bad primeCertainty value setting in DSAParameterGenerator In-Reply-To: References: Message-ID: On 22 February 2018 at 14:38, Se?n Coffey wrote: > Thanks for looking at this one Andrew. I've had it on my to-do list. > > The patch looks fine. > > Regards, > Sean. > Thanks. I had the patch around from fixing it in OpenJDK 7 so thought I may as well post it. Pushed: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/f940e7a48b72 Regards, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From jai.forums2013 at gmail.com Fri Feb 23 05:58:15 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 23 Feb 2018 11:28:15 +0530 Subject: [PATCH] JDK-8190917 : SSL session resumption, through handshake, in SSLEngine is broken for any protocols lesser than TLSv1.2 In-Reply-To: References: <427ca55d-e619-21e5-d803-4e829007da43@gmail.com> <9f283fd1-f014-b1f6-5b03-d73f18048415@oracle.com> Message-ID: <11662f00-0c06-27fa-f4a0-350c846c9da6@gmail.com> Given some recent changes to the class involved in this patch, in the jdk repo (http://hg.openjdk.java.net/jdk/jdk), I noticed some merge conflicts to this patch today. So I've now attached an updated patch which resolves those merge issues. This has been tested with latest jtreg (tip). -Jaikiran On 06/12/17 9:35 PM, Jaikiran Pai wrote: > Thank you Xuelei. Please take your time. > > -Jaikiran > > > > On Wednesday, December 6, 2017, Xuelei Fan > wrote: > > Hi Jaikiran, > > I will sponsor this contribution.? I need more time for the review > and testing. > > Thanks, > Xuelei > > On 11/23/2017 9:22 PM, Jaikiran Pai wrote: > > As noted in [1], there's a regression in Java 9, where SSL > session resumption no longer works for SSL protocols other > than TLSv1.2. The code which is responsible for session > resumption resides in the ServerHandshaker[2], in the > clientHello method. This method, in its logic to decide > whether or not to resume a (previously) cached session, checks > if the client hello message has a session id associated. If it > does, it then fetches a session from the cache. If it does > find a previously cached session for that id, it then goes > ahead to check if the SSL protocol associated with the cached > session matches with the protocol version that's > "applicable/selected" of the incoming client hello message. > However, a relatively recent change[3] has, IMO, > unintentionally caused the protocol version check logic to > fail for protocols other than TLSv1.2. The protocol version > check looks like: > > > // cannot resume session with different > > if (oldVersion != protocolVersion) { > resumingSession = false; > } > > The `protocolVersion` variable in this case happens to be a > _default initialized value_ (TLSv1.2) instead of the one > that's "selected" based on the incoming client hello message. > As a result the `protocolVersion` value is always TLSv1.2 and > thus for any other protocols, this comparison fails, even when > the client hello message uses the right session id and the > right protocol that matches the previous session. > > The attached patch, includes a potential fix to this issue. > The change makes sure that the protocol selection, based on > the client hello message, is done before this session > resumption check and also makes sure it uses that "selected" > protocol in the version comparison check instead of the class > member `protocolVersion` (which gets set when the server hello > message is finally being sent). > > The attached patch also contains a (jtreg) test case which > reproduces this bug and verifies this fix. The test case tests > the session resumption against TLSv1, TLSv1.1 and TLSv1.2. The > test code itself is a minor modification of the SSL demo > that's available here [4]. > > This is my first OpenJDK patch and my OCA got approved a few > days back. Could someone please help with the review of this > patch? > > P.S: I noticed that the JIRA got assigned a few days back. I > am not sure if that means the fix is already being worked upon > by someone else from the team. If that's the case, then let me > know and I'll let it be handled by them. > > [1] https://bugs.openjdk.java.net/browse/JDK-8190917 > > > [2] > http://hg.openjdk.java.net/jdk/jdk/file/b7ae1437111b/src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java > > > > [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/42268eb6e04e > > > [4] > https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/samples/sslengine/SSLEngineSimpleDemo.java > > > > -Jaikiran > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- # HG changeset patch # User Jaikiran Pai # Date 1511499148 -19800 # Fri Nov 24 10:22:28 2017 +0530 # Node ID ddfa1ea49b5a0316988eb8b218f19a6c20ca529c # Parent 03ae177c26b016353e5ea1cab6ffd051dfa086ca JDK-8190917 Make sure SSL session resumption works (not just for TLSv1.2) diff --git a/src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java b/src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java --- a/src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java +++ b/src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java @@ -589,6 +589,18 @@ } // Otherwise, applicationProtocol will be set by the callback. session = null; // forget about the current session + clientRequestedVersion = mesg.protocolVersion; + + // select a proper protocol version. + final ProtocolVersion selectedVersion = + selectProtocolVersion(clientRequestedVersion); + if (selectedVersion == null || + selectedVersion.v == ProtocolVersion.SSL20Hello.v) { + fatalSE(Alerts.alert_handshake_failure, + "Client requested protocol " + clientRequestedVersion + + " not enabled or not supported"); + } + // // Here we go down either of two paths: (a) the fast one, where // the client's asked to rejoin an existing session, and the server @@ -613,7 +625,7 @@ if (resumingSession) { ProtocolVersion oldVersion = previous.getProtocolVersion(); // cannot resume session with different version - if (oldVersion != mesg.protocolVersion) { + if (oldVersion != selectedVersion) { resumingSession = false; } } @@ -764,18 +776,6 @@ */ ServerHello m1 = new ServerHello(); - clientRequestedVersion = mesg.protocolVersion; - - // select a proper protocol version. - ProtocolVersion selectedVersion = - selectProtocolVersion(clientRequestedVersion); - if (selectedVersion == null || - selectedVersion.v == ProtocolVersion.SSL20Hello.v) { - fatalSE(Alerts.alert_handshake_failure, - "Client requested protocol " + clientRequestedVersion + - " not enabled or not supported"); - } - handshakeHash.protocolDetermined(selectedVersion); setVersion(selectedVersion); diff --git a/test/jdk/sun/security/ssl/SessionResumption/SSLSessionResumption.java b/test/jdk/sun/security/ssl/SessionResumption/SSLSessionResumption.java new file mode 100644 --- /dev/null +++ b/test/jdk/sun/security/ssl/SessionResumption/SSLSessionResumption.java @@ -0,0 +1,371 @@ +/* + * Copyright (c) 2015, 2017, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +import javax.net.ssl.KeyManagerFactory; +import javax.net.ssl.SSLContext; +import javax.net.ssl.SSLEngine; +import javax.net.ssl.SSLEngineResult; +import javax.net.ssl.SSLEngineResult.HandshakeStatus; +import javax.net.ssl.SSLSession; +import javax.net.ssl.TrustManagerFactory; +import java.io.FileInputStream; +import java.nio.ByteBuffer; +import java.security.KeyStore; +import java.util.Arrays; +import java.util.HashSet; +import java.util.Set; + +/* + * @test + * @bug 8190917 + * @summary Verify that SSL session resumption works for all SSL protocols + * @run main SSLSessionResumption + */ +public class SSLSessionResumption { + + private static final boolean debug = false; + private static String pathToStores = "../../../../javax/net/ssl/etc"; + private static String keyStoreFile = "keystore"; + private static String trustStoreFile = "truststore"; + private static String passwd = "passphrase"; + + private static String keyFilename = + System.getProperty("test.src", "./") + "/" + pathToStores + + "/" + keyStoreFile; + private static String trustFilename = + System.getProperty("test.src", "./") + "/" + pathToStores + + "/" + trustStoreFile; + + + private final String sslProtocol; + private final SSLContext sslc; + + private SSLEngine clientEngine; // client Engine + private ByteBuffer clientOut; // write side of clientEngine + private ByteBuffer clientIn; // read side of clientEngine + + private SSLEngine serverEngine; // server Engine + private ByteBuffer serverOut; // write side of serverEngine + private ByteBuffer serverIn; // read side of serverEngine + + private ByteBuffer cTOs; // client->server + private ByteBuffer sTOc; // server->client + + + private byte[] previousSessionId; // session id of a previous established SSL session + + + private SSLSessionResumption(final String sslProtocol) throws Exception { + this.sslProtocol = sslProtocol; + + final KeyStore ks = KeyStore.getInstance("JKS"); + final KeyStore ts = KeyStore.getInstance("JKS"); + final char[] passphrase = passwd.toCharArray(); + + ks.load(new FileInputStream(keyFilename), passphrase); + ts.load(new FileInputStream(trustFilename), passphrase); + + final KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509"); + kmf.init(ks, passphrase); + + final TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509"); + tmf.init(ts); + + final SSLContext sslCtx = SSLContext.getInstance(this.sslProtocol); + sslCtx.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null); + + this.sslc = sslCtx; + } + + public static void main(final String[] args) throws Exception { + // for each of these protocols we run the session resumption test + // individually + final String[] protocols = new String[]{"TLSv1", "TLSv1.1", "TLSv1.2"}; + final Set failedProtocols = new HashSet(); + for (final String protocol : protocols) { + final SSLSessionResumption test = new SSLSessionResumption(protocol); + // verify that the session resumption works + if (!test.verifySessionResumption()) { + failedProtocols.add(protocol); + } + } + if (!failedProtocols.isEmpty()) { + throw new Exception("SSL session resumption failed for protocols " + failedProtocols); + } + } + + /** + * Uses {@link SSLEngine} in the context of a {@link SSLContext} to do some SSL backed + * communication and verifies that the communication reuses a session + * + * @return Returns true if the SSL session was reused. False otherwise + * @throws Exception + */ + private boolean verifySessionResumption() throws Exception { + try { + for (int i = 0; i < 2; i++) { + log("Starting SSL communication " + (i + 1) + " using protocol " + this.sslProtocol); + this.doSSLCommunication(); + } + } catch (SessionIdMisMatchException e) { + return false; + } + return true; + } + + + private void doSSLCommunication() throws Exception { + boolean dataDone = false; + + createSSLEngines(); + createBuffers(); + + SSLEngineResult clientResult; // results from client's last operation + SSLEngineResult serverResult; // results from server's last operation + + /* + * Examining the SSLEngineResults could be much more involved, + * and may alter the overall flow of the application. + * + * For example, if we received a BUFFER_OVERFLOW when trying + * to write to the output pipe, we could reallocate a larger + * pipe, but instead we wait for the peer to drain it. + */ + while (!isEngineClosed(clientEngine) || + !isEngineClosed(serverEngine)) { + + log("================"); + + clientResult = clientEngine.wrap(clientOut, cTOs); + if (clientResult.getHandshakeStatus() == HandshakeStatus.FINISHED) { + assertSessionId(this.previousSessionId, clientEngine); + this.previousSessionId = clientEngine.getSession().getId(); + } + log("client wrap: ", clientResult); + runDelegatedTasks(clientResult, clientEngine); + + serverResult = serverEngine.wrap(serverOut, sTOc); + log("server wrap: ", serverResult); + runDelegatedTasks(serverResult, serverEngine); + + cTOs.flip(); + sTOc.flip(); + + log("----"); + + clientResult = clientEngine.unwrap(sTOc, clientIn); + if (clientResult.getHandshakeStatus() == HandshakeStatus.FINISHED) { + assertSessionId(this.previousSessionId, clientEngine); + this.previousSessionId = clientEngine.getSession().getId(); + } + log("client unwrap: ", clientResult); + runDelegatedTasks(clientResult, clientEngine); + + serverResult = serverEngine.unwrap(cTOs, serverIn); + log("server unwrap: ", serverResult); + runDelegatedTasks(serverResult, serverEngine); + + cTOs.compact(); + sTOc.compact(); + + /* + * After we've transfered all application data between the client + * and server, we close the clientEngine's outbound stream. + * This generates a close_notify handshake message, which the + * server engine receives and responds by closing itself. + * + * In normal operation, each SSLEngine should call + * closeOutbound(). To protect against truncation attacks, + * SSLEngine.closeInbound() should be called whenever it has + * determined that no more input data will ever be + * available (say a closed input stream). + */ + if (!dataDone && (clientOut.limit() == serverIn.position()) && + (serverOut.limit() == clientIn.position())) { + + /* + * A sanity check to ensure we got what was sent. + */ + checkTransfer(serverOut, clientIn); + checkTransfer(clientOut, serverIn); + + log("\tClosing clientEngine's *OUTBOUND*..."); + clientEngine.closeOutbound(); + // serverEngine.closeOutbound(); + dataDone = true; + } + } + } + + /* + * Using the SSLContext created during object creation, + * create/configure the SSLEngines we'll use for this demo. + */ + private void createSSLEngines() throws Exception { + /* + * Configure the serverEngine to act as a server in the SSL/TLS + * handshake. + */ + serverEngine = sslc.createSSLEngine(); + serverEngine.setUseClientMode(false); + serverEngine.setNeedClientAuth(false); + + /* + * Similar to above, but using client mode instead. + */ + clientEngine = sslc.createSSLEngine("client", 80); + clientEngine.setUseClientMode(true); + } + + /* + * Create and size the buffers appropriately. + */ + private void createBuffers() { + + /* + * We'll assume the buffer sizes are the same + * between client and server. + */ + SSLSession session = clientEngine.getSession(); + int appBufferMax = session.getApplicationBufferSize(); + int netBufferMax = session.getPacketBufferSize(); + + /* + * We'll make the input buffers a bit bigger than the max needed + * size, so that unwrap()s following a successful data transfer + * won't generate BUFFER_OVERFLOWS. + * + * We'll use a mix of direct and indirect ByteBuffers for + * tutorial purposes only. In reality, only use direct + * ByteBuffers when they give a clear performance enhancement. + */ + clientIn = ByteBuffer.allocate(appBufferMax + 50); + serverIn = ByteBuffer.allocate(appBufferMax + 50); + + cTOs = ByteBuffer.allocateDirect(netBufferMax); + sTOc = ByteBuffer.allocateDirect(netBufferMax); + + clientOut = ByteBuffer.wrap("JDK-8190917 : Hi Server, I'm Client".getBytes()); + serverOut = ByteBuffer.wrap("JDK-8190917 : Hello Client, I'm Server".getBytes()); + } + + /* + * If the result indicates that we have outstanding tasks to do, + * go ahead and run them in this thread. + */ + private static void runDelegatedTasks(final SSLEngineResult result, + final SSLEngine engine) throws Exception { + + if (result.getHandshakeStatus() == HandshakeStatus.NEED_TASK) { + Runnable runnable; + while ((runnable = engine.getDelegatedTask()) != null) { + log("\trunning delegated task..."); + runnable.run(); + } + final HandshakeStatus hsStatus = engine.getHandshakeStatus(); + if (hsStatus == HandshakeStatus.NEED_TASK) { + throw new Exception( + "handshake shouldn't need additional tasks"); + } + log("\tnew HandshakeStatus: " + hsStatus); + } + } + + private static boolean isEngineClosed(SSLEngine engine) { + return (engine.isOutboundDone() && engine.isInboundDone()); + } + + /* + * Simple check to make sure everything came across as expected. + */ + private static void checkTransfer(ByteBuffer a, ByteBuffer b) + throws Exception { + a.flip(); + b.flip(); + + if (!a.equals(b)) { + throw new Exception("Data didn't transfer cleanly"); + } else { + log("\tData transferred cleanly"); + } + + a.position(a.limit()); + b.position(b.limit()); + a.limit(a.capacity()); + b.limit(b.capacity()); + } + + private static void assertSessionId(final byte[] expected, final SSLEngine engine) throws SessionIdMisMatchException { + if (expected == null) { + // we haven't yet created a session previously, so there isn't any + // session to be expected to resume + return; + } + final byte[] sessionId = engine.getSession().getId(); + // compare and verify if they are same + if (!java.util.Arrays.equals(expected, sessionId)) { + throw new SessionIdMisMatchException(expected, sessionId); + } + } + + private static boolean resultOnce = true; + + private static void log(final String str, final SSLEngineResult result) { + if (!debug) { + return; + } + if (resultOnce) { + resultOnce = false; + log("The format of the SSLEngineResult is: \n" + + "\t\"getStatus() / getHandshakeStatus()\" +\n" + + "\t\"bytesConsumed() / bytesProduced()\"\n"); + } + final HandshakeStatus hsStatus = result.getHandshakeStatus(); + log(str + + result.getStatus() + "/" + hsStatus + ", " + + result.bytesConsumed() + "/" + result.bytesProduced() + + " bytes"); + if (hsStatus == HandshakeStatus.FINISHED) { + log("\t...ready for application data"); + } + } + + private static void log(final String message) { + if (debug) { + System.out.println(message); + } + } + + private static final class SessionIdMisMatchException extends Exception { + + private final byte[] expected; + private final byte[] actual; + + private SessionIdMisMatchException(final byte[] expected, final byte[] actual) { + super("SSL session id mismatch - expected " + Arrays.toString(expected) + " actual " + Arrays.toString(actual)); + this.expected = expected; + this.actual = actual; + } + } + +} \ No newline at end of file From weijun.wang at oracle.com Fri Feb 23 08:57:12 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 23 Feb 2018 16:57:12 +0800 Subject: RFR 8197518: Kerberos krb5 authentication: AuthList's put method leads to performance issue In-Reply-To: <7fbfed72-c9c0-6186-6c62-1a51a678c337@oracle.com> References: <7fbfed72-c9c0-6186-6c62-1a51a678c337@oracle.com> Message-ID: <1A4F8EE4-60FA-4E9B-ACF9-23EFA5A98A33@oracle.com> Brilliant idea. I will do more experiment. Thanks Max > On Feb 23, 2018, at 11:25 AM, Xuelei Fan wrote: > > Hi Weijun, > > I thought more about the performance impact. The impact may mainly come from the big size of the cached entries. > > The current implementation needs to go over the full list: find the 1st expired item and then remove the rest. The previous one have an additional round with entries.indexOf(). Could we just start from the end of the list? > > while (true) { > E e = entries.removeLast(); > if e not expired { > add it back and break; > } > }; > > If the list is really big, and the lifetime is significant big as well (>> 1 minute), iterate from the oldest item (backward from the end of the list) may be much more effective. LinkedList itself is not synchronized, so as if there is not too much items to go over, the performance should be fine. I'm hesitate to hard code a cleanup every 1 minute strategy. If we clean often, there may be not too much items to go over in the list. So we might be able to remove the "at most every minute" strategy. > > Xuelei > > On 2/22/2018 5:55 PM, Weijun Wang wrote: >> Updated webrev at http://cr.openjdk.java.net/~weijun/8197518/webrev.01/. >>> On Feb 23, 2018, at 9:02 AM, Weijun Wang wrote: >>> >>> You mean I can save it somewhere and only update it when a cleanup is performed? >>> >>> This should be better. Now there will be only isEmpty(), getFirst() and addFirst(), and one less getLast(). >>> >>> Thanks >>> Max >>> >>>> On Feb 23, 2018, at 1:45 AM, Xuelei Fan wrote: >>>> >>>> Looks like list synchronization is a factor of the performance impact. Maybe, you can have a private time for the oldest entry so don't access/iterate/cleanup entries list until necessary. The "at most every minute" may be not a good strategy in some situations. >> In fact, it's now almost "exactly every minute". What situations do you think it's not good? I cannot use size() because I have to remember all entries with lifespan to be correct. >> Thanks >> Max >>>> >>>> Xuelei >>>> >>>> On 2/22/2018 12:36 AM, Weijun Wang wrote: >>>>> Please take a review at >>>>> http://cr.openjdk.java.net/~weijun/8197518/webrev.00/ >>>>> Two notes: >>>>> 1. I tried list.subList(here, end).clear() but it's not faster. >>>>> 2. I have looked at ConcurrentHashMap + ConcurrentSkipListMap but will need more time to verify its correctness and measure the performance gain. Since the bug is reported on 8u, a safer fix looks better. >>>>> Noreg-perf. >>>>> Thanks >>>>> Max >>> From xuelei.fan at oracle.com Fri Feb 23 15:21:37 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 23 Feb 2018 07:21:37 -0800 Subject: RFR 8197518: Kerberos krb5 authentication: AuthList's put method leads to performance issue In-Reply-To: References: <7fbfed72-c9c0-6186-6c62-1a51a678c337@oracle.com> <1A4F8EE4-60FA-4E9B-ACF9-23EFA5A98A33@oracle.com> Message-ID: <7d44ab67-99a0-b120-ee5f-c8bec6621247@oracle.com> Looks fine to me. Xuelei On 2/23/2018 6:13 AM, Weijun Wang wrote: > Updated at http://cr.openjdk.java.net/~weijun/8197518/webrev.02/. > > 1. ConcurrentHashMap used in MemoryCache. No more "content.remove(key)" but it's actually useless because rc.isEmpty() will not be true normally. I'll think about how to clean up unused AuthList objects in another RFE. > > 2. AuthList now removes entries from tail backwards until one is within lifespan. I still kept an oldestTime field. In my experiment it is useful but a bigger value does not help much, so I just hardcoded it to 5 seconds. > > Thanks > Max > >> On Feb 23, 2018, at 4:57 PM, Weijun Wang wrote: >> >> Brilliant idea. I will do more experiment. >> >> Thanks >> Max >> >>> On Feb 23, 2018, at 11:25 AM, Xuelei Fan wrote: >>> >>> Hi Weijun, >>> >>> I thought more about the performance impact. The impact may mainly come from the big size of the cached entries. >>> >>> The current implementation needs to go over the full list: find the 1st expired item and then remove the rest. The previous one have an additional round with entries.indexOf(). Could we just start from the end of the list? >>> >>> while (true) { >>> E e = entries.removeLast(); >>> if e not expired { >>> add it back and break; >>> } >>> }; >>> >>> If the list is really big, and the lifetime is significant big as well (>> 1 minute), iterate from the oldest item (backward from the end of the list) may be much more effective. LinkedList itself is not synchronized, so as if there is not too much items to go over, the performance should be fine. I'm hesitate to hard code a cleanup every 1 minute strategy. If we clean often, there may be not too much items to go over in the list. So we might be able to remove the "at most every minute" strategy. >>> >>> Xuelei >>> >>> On 2/22/2018 5:55 PM, Weijun Wang wrote: >>>> Updated webrev at http://cr.openjdk.java.net/~weijun/8197518/webrev.01/. >>>>> On Feb 23, 2018, at 9:02 AM, Weijun Wang wrote: >>>>> >>>>> You mean I can save it somewhere and only update it when a cleanup is performed? >>>>> >>>>> This should be better. Now there will be only isEmpty(), getFirst() and addFirst(), and one less getLast(). >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>>> On Feb 23, 2018, at 1:45 AM, Xuelei Fan wrote: >>>>>> >>>>>> Looks like list synchronization is a factor of the performance impact. Maybe, you can have a private time for the oldest entry so don't access/iterate/cleanup entries list until necessary. The "at most every minute" may be not a good strategy in some situations. >>>> In fact, it's now almost "exactly every minute". What situations do you think it's not good? I cannot use size() because I have to remember all entries with lifespan to be correct. >>>> Thanks >>>> Max >>>>>> >>>>>> Xuelei >>>>>> >>>>>> On 2/22/2018 12:36 AM, Weijun Wang wrote: >>>>>>> Please take a review at >>>>>>> http://cr.openjdk.java.net/~weijun/8197518/webrev.00/ >>>>>>> Two notes: >>>>>>> 1. I tried list.subList(here, end).clear() but it's not faster. >>>>>>> 2. I have looked at ConcurrentHashMap + ConcurrentSkipListMap but will need more time to verify its correctness and measure the performance gain. Since the bug is reported on 8u, a safer fix looks better. >>>>>>> Noreg-perf. >>>>>>> Thanks >>>>>>> Max >>>>> >> > From daniel.fuchs at oracle.com Fri Feb 23 16:38:01 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 23 Feb 2018 16:38:01 +0000 Subject: RFR 8197518: Kerberos krb5 authentication: AuthList's put method leads to performance issue In-Reply-To: <7d44ab67-99a0-b120-ee5f-c8bec6621247@oracle.com> References: <7fbfed72-c9c0-6186-6c62-1a51a678c337@oracle.com> <1A4F8EE4-60FA-4E9B-ACF9-23EFA5A98A33@oracle.com> <7d44ab67-99a0-b120-ee5f-c8bec6621247@oracle.com> Message-ID: Hi Max, 85 // has larger timestamp. 86 entries.addFirst(t); shouldn't you set oldestTime here as well? best regards, -- daniel On 23/02/2018 15:21, Xuelei Fan wrote: > Looks fine to me. > > Xuelei > > On 2/23/2018 6:13 AM, Weijun Wang wrote: >> Updated at http://cr.openjdk.java.net/~weijun/8197518/webrev.02/. >> >> 1. ConcurrentHashMap used in MemoryCache. No more >> "content.remove(key)" but it's actually useless because rc.isEmpty() >> will not be true normally. I'll think about how to clean up unused >> AuthList objects in another RFE. >> >> 2. AuthList now removes entries from tail backwards until one is >> within lifespan. I still kept an oldestTime field. In my experiment it >> is useful but a bigger value does not help much, so I just hardcoded >> it to 5 seconds. >> >> Thanks >> Max >> >>> On Feb 23, 2018, at 4:57 PM, Weijun Wang wrote: >>> >>> Brilliant idea. I will do more experiment. >>> >>> Thanks >>> Max >>> >>>> On Feb 23, 2018, at 11:25 AM, Xuelei Fan wrote: >>>> >>>> Hi Weijun, >>>> >>>> I thought more about the performance impact.? The impact may mainly >>>> come from the big size of the cached entries. >>>> >>>> The current implementation needs to go over the full list: find the >>>> 1st expired item and then remove the rest.? The previous one have an >>>> additional round with entries.indexOf().? Could we just start from >>>> the end of the list? >>>> >>>> ?? while (true) { >>>> ????? E e = entries.removeLast(); >>>> ????? if e not expired { >>>> ???????? add it back and break; >>>> ????? } >>>> ?? }; >>>> >>>> If the list is really big, and the lifetime is significant big as >>>> well (>> 1 minute), iterate from the oldest item (backward from the >>>> end of the list) may be much more effective.? LinkedList itself is >>>> not synchronized, so as if there is not too much items to go over, >>>> the performance should be fine.? I'm hesitate to hard code a cleanup >>>> every 1 minute strategy.? If we clean often, there may be not too >>>> much items to go over in the list.? So we might be able to remove >>>> the "at most every minute" strategy. >>>> >>>> Xuelei >>>> >>>> On 2/22/2018 5:55 PM, Weijun Wang wrote: >>>>> Updated webrev at >>>>> http://cr.openjdk.java.net/~weijun/8197518/webrev.01/. >>>>>> On Feb 23, 2018, at 9:02 AM, Weijun Wang >>>>>> wrote: >>>>>> >>>>>> You mean I can save it somewhere and only update it when a cleanup >>>>>> is performed? >>>>>> >>>>>> This should be better. Now there will be only isEmpty(), >>>>>> getFirst() and addFirst(), and one less getLast(). >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>>> On Feb 23, 2018, at 1:45 AM, Xuelei Fan >>>>>>> wrote: >>>>>>> >>>>>>> Looks like list synchronization is a factor of the performance >>>>>>> impact. Maybe, you can have a private time for the oldest entry >>>>>>> so don't access/iterate/cleanup entries list until necessary. >>>>>>> The "at most every minute" may be not a good strategy in some >>>>>>> situations. >>>>> In fact, it's now almost "exactly every minute". What situations do >>>>> you think it's not good? I cannot use size() because I have to >>>>> remember all entries with lifespan to be correct. >>>>> Thanks >>>>> Max >>>>>>> >>>>>>> Xuelei >>>>>>> >>>>>>> On 2/22/2018 12:36 AM, Weijun Wang wrote: >>>>>>>> Please take a review at >>>>>>>> ? http://cr.openjdk.java.net/~weijun/8197518/webrev.00/ >>>>>>>> Two notes: >>>>>>>> 1. I tried list.subList(here, end).clear() but it's not faster. >>>>>>>> 2. I have looked at ConcurrentHashMap + ConcurrentSkipListMap >>>>>>>> but will need more time to verify its correctness and measure >>>>>>>> the performance gain. Since the bug is reported on 8u, a safer >>>>>>>> fix looks better. >>>>>>>> Noreg-perf. >>>>>>>> Thanks >>>>>>>> Max >>>>>> >>> >> From weijun.wang at oracle.com Fri Feb 23 14:13:32 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 23 Feb 2018 22:13:32 +0800 Subject: RFR 8197518: Kerberos krb5 authentication: AuthList's put method leads to performance issue In-Reply-To: <1A4F8EE4-60FA-4E9B-ACF9-23EFA5A98A33@oracle.com> References: <7fbfed72-c9c0-6186-6c62-1a51a678c337@oracle.com> <1A4F8EE4-60FA-4E9B-ACF9-23EFA5A98A33@oracle.com> Message-ID: Updated at http://cr.openjdk.java.net/~weijun/8197518/webrev.02/. 1. ConcurrentHashMap used in MemoryCache. No more "content.remove(key)" but it's actually useless because rc.isEmpty() will not be true normally. I'll think about how to clean up unused AuthList objects in another RFE. 2. AuthList now removes entries from tail backwards until one is within lifespan. I still kept an oldestTime field. In my experiment it is useful but a bigger value does not help much, so I just hardcoded it to 5 seconds. Thanks Max > On Feb 23, 2018, at 4:57 PM, Weijun Wang wrote: > > Brilliant idea. I will do more experiment. > > Thanks > Max > >> On Feb 23, 2018, at 11:25 AM, Xuelei Fan wrote: >> >> Hi Weijun, >> >> I thought more about the performance impact. The impact may mainly come from the big size of the cached entries. >> >> The current implementation needs to go over the full list: find the 1st expired item and then remove the rest. The previous one have an additional round with entries.indexOf(). Could we just start from the end of the list? >> >> while (true) { >> E e = entries.removeLast(); >> if e not expired { >> add it back and break; >> } >> }; >> >> If the list is really big, and the lifetime is significant big as well (>> 1 minute), iterate from the oldest item (backward from the end of the list) may be much more effective. LinkedList itself is not synchronized, so as if there is not too much items to go over, the performance should be fine. I'm hesitate to hard code a cleanup every 1 minute strategy. If we clean often, there may be not too much items to go over in the list. So we might be able to remove the "at most every minute" strategy. >> >> Xuelei >> >> On 2/22/2018 5:55 PM, Weijun Wang wrote: >>> Updated webrev at http://cr.openjdk.java.net/~weijun/8197518/webrev.01/. >>>> On Feb 23, 2018, at 9:02 AM, Weijun Wang wrote: >>>> >>>> You mean I can save it somewhere and only update it when a cleanup is performed? >>>> >>>> This should be better. Now there will be only isEmpty(), getFirst() and addFirst(), and one less getLast(). >>>> >>>> Thanks >>>> Max >>>> >>>>> On Feb 23, 2018, at 1:45 AM, Xuelei Fan wrote: >>>>> >>>>> Looks like list synchronization is a factor of the performance impact. Maybe, you can have a private time for the oldest entry so don't access/iterate/cleanup entries list until necessary. The "at most every minute" may be not a good strategy in some situations. >>> In fact, it's now almost "exactly every minute". What situations do you think it's not good? I cannot use size() because I have to remember all entries with lifespan to be correct. >>> Thanks >>> Max >>>>> >>>>> Xuelei >>>>> >>>>> On 2/22/2018 12:36 AM, Weijun Wang wrote: >>>>>> Please take a review at >>>>>> http://cr.openjdk.java.net/~weijun/8197518/webrev.00/ >>>>>> Two notes: >>>>>> 1. I tried list.subList(here, end).clear() but it's not faster. >>>>>> 2. I have looked at ConcurrentHashMap + ConcurrentSkipListMap but will need more time to verify its correctness and measure the performance gain. Since the bug is reported on 8u, a safer fix looks better. >>>>>> Noreg-perf. >>>>>> Thanks >>>>>> Max >>>> > From xuelei.fan at oracle.com Fri Feb 23 17:46:45 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 23 Feb 2018 09:46:45 -0800 Subject: RFR 8181594: Efficient and constant-time modular arithmetic In-Reply-To: <7bd6c1ae-4173-4384-fc57-66d1b185ba56@oracle.com> References: <7bd6c1ae-4173-4384-fc57-66d1b185ba56@oracle.com> Message-ID: ArrayUtil.java: =============== I'm not very sure how widely this utilities will be used in the future. Looks like only BigIntegerModuloP uses this classes. I may prefer to define private methods for byte array swap in BigIntegerModuloP. BigIntegerModuloP.java: ======================= As this is a class for testing or ptototype purpose, it might not be a part of JDK products, like JRE. Would you mind move it to a test package if you want to keep it? IntegerModuloP, IntegerModuloP_Base and MutableIntegerModuloP ============================================================= In the security package/context, it may make sense to use "IntegerModulo" for the referring to "integers modulo a prime value". The class name of "IntegerModuloP_Base" is not a general Java coding style. I may prefer a little bit name changes like: IntegerModuloP_Base -> IntegerModulo IntegerModuloP -> ImmutableIntegerModulo MutableIntegerModuloP -> MutableIntegerModulo IntegerFieldModuloP -> IntegerModuloField (?) MutableIntegerModuloP.java ========================== void conditionalSwapWith(MutableIntegerModuloP b, int swap); As the 'swap' parameter can only be 0 or 1, could it be a boolean parameter? Except the conditionalSwapWith() method, I did not get the points why we need a mutable version. Would you please have more description of this requirement? IntegerModuloP_Base.java ======================== default byte[] addModPowerTwo(IntegerModuloP_Base b, int len) void addModPowerTwo(IntegerModuloP_Base b, byte[] result); For the first sign of the method names, I thought it is to calculate as "(this + b) ^ 2 mod m". Besides, what's the benefits of the two methods? Could we just use: this.add(b).asByteArray() I guess, but not very sure, it is for constant time calculation. If the function is required, could it be renamed as: // the result is inside of the size range IntegerModuloP addModSize(IntegerModuloP_Base b, int size) Or // the result is wrapped if outside of the size range IntegerModuloP addOnWrap(IntegerModuloP_Base b, int size) and the use may look like: this.addModSize(b, size).asByteArray() Will review the rest when I understand more about the interfaces design. Thanks, Xuelei On 1/30/2018 8:52 AM, Adam Petcher wrote: > +core-libs-dev > > > On 1/26/2018 4:06 PM, Adam Petcher wrote: >> JBS: https://bugs.openjdk.java.net/browse/JDK-8181594 >> Webrev: http://cr.openjdk.java.net/~apetcher/8181594/webrev.00/ >> >> This is a code review for the field arithmetic that will be used in >> implementations of X25519/X448 key agreement, the Poly1305 >> authenticator, and EdDSA signatures. I believe that the library has >> all the features necessary for X25519/X448 and Poly1305, and I expect >> at most a couple of minor enhancements will be required to support >> EdDSA. There is no public API for this library, so we can change it in >> the future to suit the needs of new algorithms without breaking >> compatibility with external code. Still, I made an attempt to clearly >> structure and document the (internal) API, and I want to make sure it >> is understandable and easy to use. >> >> This is not a general-purpose modular arithmetic library. It will only >> work well in circumstances where the sequence of operations is >> restricted, and where the prime that defines the field has some useful >> structure. Moreover, each new field will require some field-specific >> code that takes into account the structure of the prime and the way >> the field is used in the application. The initial implementation >> includes a field for Poly1305 and the fields for X25519/X448 which >> should also work for EdDSA. >> >> The benefits of using this library are that it is much more efficient >> than using similar operations in BigInteger. Also, many operations are >> branch-free, making them suitable for use in a side-channel resistant >> implementation that does not branch on secrets. >> >> To provide some context, I have attached a code snippet describing how >> this library can be used. The snippet is the constant-time Montgomery >> ladder from my X25519/X448 implementation, which I expect to be out >> for review soon. X25519/X448 only uses standard arithmetic operations, >> and the more unusual features (e.g. add modulo a power of 2) are >> needed by Poly1305. >> >> The field arithmetic (for all fields) is implemented using a 32-bit >> representation similar to the one described in the Ed448 paper[1] (in >> the "Implementation on 32-bit platforms" section). Though my >> implementation uses signed limbs, and grade-school multiplication >> instead of Karatsuba. The argument for correctness is essentially the >> same for all three fields: the magnitude of each 64-bit limb is at >> most 2^(k-1) after reduction, except for the last limb which may have >> a magnitude of up to 2^k. The values of k are between 26 to 28 >> (depending on the field), and we can calculate that the maximum >> magnitude for any limb during an add-multiply-carry-reduce sequence is >> always less than 2^63. Therefore, no overflow occurs and all >> operations are correct. >> >> Process note: this enhancement is part of JEP 324 (Key Agreement with >> Curve25519 and Curve448). When this code review is complete, nothing >> will happen until all other work for this JEP is complete, and the JEP >> is accepted as part of some release. This means that this code will be >> pushed to the repo along with the X25519/X448 code that uses it. >> >> [1] https://eprint.iacr.org/2015/625.pdf >> >> >> > From fotisl at ssl.com Fri Feb 23 18:04:36 2018 From: fotisl at ssl.com (Fotis Loukos) Date: Fri, 23 Feb 2018 20:04:36 +0200 Subject: Update mechanism for the upcoming trust store In-Reply-To: <700b828c-694e-31ef-7dfe-c88fe33df6a8@ssl.com> References: <6cd7d58a-c233-cf45-b80c-2c48fdd5b69e@ssl.com> <6254fadc-06f0-c96a-0abd-69021cbd341d@ssl.com> <700b828c-694e-31ef-7dfe-c88fe33df6a8@ssl.com> Message-ID: Hello Sean, On 29/01/2018 04:30 ??, Fotis Loukos wrote: > On 26/01/2018 11:31 ??, Sean Mullan wrote: >> On 1/24/18 5:39 AM, Fotis Loukos wrote: >>>> You may not be aware, but the JDK does currently support a mechanism for >>>> blacklisting certificates. The lib/security/blacklisted.certs file >>>> contains a list of the fingerprints of certificates that are explicitly >>>> distrusted. If a root was compromised and added to this file it would no >>>> longer be trusted. >>> My biggest concern is what you describe below, the dynamic update. >>> >>>> However, currently there is no mechanism in OpenJDK to dynamically >>>> update that file. While I think there is merit in implementing something >>>> like that, many challenges would need to be addressed as part of that, >>>> for example, where and how does this file get updated, how is it >>>> verified, etc. >>> The verification step can be implemented as described above. I think >>> that the update step requires some design, but I don't think it is that >>> difficult. For example, a naive algorithm such as every Monday plus a >>> random number of days/hours/minutes in order to avoid heavy traffic >>> during the update period would be good for starters. As a first step to >>> try a new format, you could even fetch it once during installation and >>> provide a means for the user to update it manually. >> >> One thing we could potentially do initially is to provide a stable https >> URL where an updated blacklist could be downloaded, something like what >> Mozilla does for OneCRL [1]. This would be an initial step, not the >> whole solution of course, but it at least would allow someone to quickly >> update their JDK should a certificate need to be distrusted ASAP. >> >> Let me look into that a bit. >> >> I think implementing a dynamic solution is more challenging and would >> require more design/review, etc but feel free to provide more details on >> any additional thoughts or design sketches you might have. > > I find it pretty important to ensure that the file is also signed and > not just served over https. I was wondering if the community runs a > private CA, or has access to an HSM that can be used to generate and > store a private key that will sign these files. > Do you have any info on this? Is there a way to sign these files securely, or should we find a different method of packaging them? Regards, Fotis > Regards, > Fotis > >> >> --Sean >> >> [1] >> https://firefox.settings.services.mozilla.com/v1/buckets/blocklists/collections/certificates/records >> >> >> > > -- Fotis Loukos, PhD Director of Security Architecture SSL Corp e: fotisl at ssl.com w: https://www.ssl.com From xuelei.fan at oracle.com Fri Feb 23 18:51:00 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 23 Feb 2018 10:51:00 -0800 Subject: [PATCH] JDK-8190917 : SSL session resumption, through handshake, in SSLEngine is broken for any protocols lesser than TLSv1.2 In-Reply-To: <11662f00-0c06-27fa-f4a0-350c846c9da6@gmail.com> References: <427ca55d-e619-21e5-d803-4e829007da43@gmail.com> <9f283fd1-f014-b1f6-5b03-d73f18048415@oracle.com> <11662f00-0c06-27fa-f4a0-350c846c9da6@gmail.com> Message-ID: Hi Jaikiran, Thanks a lot for the update. Your code looks fine to me. As we are working on the re-org of the implementation[1] now, I may integrate your contribution shortly after the re-org changes. Thanks, Xuelei [1]: http://mail.openjdk.java.net/pipermail/security-dev/2018-February/016815.html On 2/22/2018 9:58 PM, Jaikiran Pai wrote: > Given some recent changes to the class involved in this patch, in the > jdk repo (http://hg.openjdk.java.net/jdk/jdk), I noticed some merge > conflicts to this patch today. So I've now attached an updated patch > which resolves those merge issues. This has been tested with latest > jtreg (tip). > > -Jaikiran > > > On 06/12/17 9:35 PM, Jaikiran Pai wrote: >> Thank you Xuelei. Please take your time. >> >> -Jaikiran >> >> >> >> On Wednesday, December 6, 2017, Xuelei Fan > > wrote: >> >> Hi Jaikiran, >> >> I will sponsor this contribution.? I need more time for the review >> and testing. >> >> Thanks, >> Xuelei >> >> On 11/23/2017 9:22 PM, Jaikiran Pai wrote: >> >> As noted in [1], there's a regression in Java 9, where SSL >> session resumption no longer works for SSL protocols other >> than TLSv1.2. The code which is responsible for session >> resumption resides in the ServerHandshaker[2], in the >> clientHello method. This method, in its logic to decide >> whether or not to resume a (previously) cached session, checks >> if the client hello message has a session id associated. If it >> does, it then fetches a session from the cache. If it does >> find a previously cached session for that id, it then goes >> ahead to check if the SSL protocol associated with the cached >> session matches with the protocol version that's >> "applicable/selected" of the incoming client hello message. >> However, a relatively recent change[3] has, IMO, >> unintentionally caused the protocol version check logic to >> fail for protocols other than TLSv1.2. The protocol version >> check looks like: >> >> >> // cannot resume session with different >> >> if (oldVersion != protocolVersion) { >> resumingSession = false; >> } >> >> The `protocolVersion` variable in this case happens to be a >> _default initialized value_ (TLSv1.2) instead of the one >> that's "selected" based on the incoming client hello message. >> As a result the `protocolVersion` value is always TLSv1.2 and >> thus for any other protocols, this comparison fails, even when >> the client hello message uses the right session id and the >> right protocol that matches the previous session. >> >> The attached patch, includes a potential fix to this issue. >> The change makes sure that the protocol selection, based on >> the client hello message, is done before this session >> resumption check and also makes sure it uses that "selected" >> protocol in the version comparison check instead of the class >> member `protocolVersion` (which gets set when the server hello >> message is finally being sent). >> >> The attached patch also contains a (jtreg) test case which >> reproduces this bug and verifies this fix. The test case tests >> the session resumption against TLSv1, TLSv1.1 and TLSv1.2. The >> test code itself is a minor modification of the SSL demo >> that's available here [4]. >> >> This is my first OpenJDK patch and my OCA got approved a few >> days back. Could someone please help with the review of this >> patch? >> >> P.S: I noticed that the JIRA got assigned a few days back. I >> am not sure if that means the fix is already being worked upon >> by someone else from the team. If that's the case, then let me >> know and I'll let it be handled by them. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8190917 >> >> >> [2] >> http://hg.openjdk.java.net/jdk/jdk/file/b7ae1437111b/src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java >> >> >> >> [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/42268eb6e04e >> >> >> [4] >> https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/samples/sslengine/SSLEngineSimpleDemo.java >> >> >> >> -Jaikiran >> >> >> > From Roger.Riggs at Oracle.com Fri Feb 23 19:39:07 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 23 Feb 2018 14:39:07 -0500 Subject: RFR 8198645 Use System.lineSeparator() instead of getProperty("line.separator") Message-ID: Please review cleanup replacements of System.getProperty("line.separator") with System.lineSeparator(). It uses the line separator from System instead of looking it up in the properties each time. Also fixed one javadoc @see reference. The affected files are in several packages: com/sun/crypto/provider/ java/util/regex/ jdk/internal/util/xml/impl/ Webrev: ? http://cr.openjdk.java.net/~rriggs/webrev-line-separator-8198645/ Thanks, Roger From lance.andersen at oracle.com Fri Feb 23 19:42:26 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 23 Feb 2018 14:42:26 -0500 Subject: RFR 8198645 Use System.lineSeparator() instead of getProperty("line.separator") In-Reply-To: References: Message-ID: <98AC376E-5DDF-4E21-B198-0A3DE4777CAF@oracle.com> Looks good Roger > On Feb 23, 2018, at 2:39 PM, Roger Riggs wrote: > > Please review cleanup replacements of System.getProperty("line.separator") with System.lineSeparator(). > It uses the line separator from System instead of looking it up in the properties each time. > Also fixed one javadoc @see reference. > > The affected files are in several packages: > > com/sun/crypto/provider/ > java/util/regex/ > jdk/internal/util/xml/impl/ > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-line-separator-8198645/ > > Thanks, Roger > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From xuelei.fan at oracle.com Fri Feb 23 19:46:02 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 23 Feb 2018 11:46:02 -0800 Subject: RFR 8198645 Use System.lineSeparator() instead of getProperty("line.separator") In-Reply-To: References: Message-ID: <6e3c1ae2-5f3b-8cc5-4ab3-6c1cfda7d790@oracle.com> Looks fine to me. Thanks! Xuelei On 2/23/2018 11:39 AM, Roger Riggs wrote: > Please review cleanup replacements of > System.getProperty("line.separator") with System.lineSeparator(). > It uses the line separator from System instead of looking it up in the > properties each time. > Also fixed one javadoc @see reference. > > The affected files are in several packages: > > ?? com/sun/crypto/provider/ > ?? java/util/regex/ > ?? jdk/internal/util/xml/impl/ > > Webrev: > ? http://cr.openjdk.java.net/~rriggs/webrev-line-separator-8198645/ > > Thanks, Roger > > From bradford.wetmore at oracle.com Fri Feb 23 20:14:27 2018 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Fri, 23 Feb 2018 12:14:27 -0800 Subject: RFR: 8193892: Impact of noncloneable MessageDigest implementation In-Reply-To: References: <9a2be852-bd0c-d025-0278-ab266a4ced66@oracle.com> Message-ID: <7465773c-c402-a648-fbc6-4faab164d617@oracle.com> Minor comments. I'm ok with leaving as is, but this seems cleaner. MyProvider.java --------------- Would prefer to use the non-deprecated super call. *Digest.java ------------ Would you consider making these 3 duplicate classes into a single class, with the three public derived classes within? And then update the MyProvider entries with DigestBase${MD5,SHA,SHA256}. i.e. import java.security.*; class DigestBase extends MessageDigestSpi { private MessageDigest digest = null; public DigestBase(String alg, String provider) throws Exception { digest = MessageDigest.getInstance(alg, provider); } @Override protected void engineUpdate(byte input) { digest.update(input); } @Override protected void engineUpdate(byte[] input, int offset, int len) { digest.update(input, offset, len); } @Override protected byte[] engineDigest() { return digest.digest(); } @Override protected void engineReset() { digest.reset(); } public static final class MD5 extends DigestBase { public MD5() throws Exception { super("MD5", "SUN"); } } public static final class SHA extends DigestBase { public SHA() throws Exception { super("SHA", "SUN"); } } public static final class SHA256 extends DigestBase { public SHA256() throws Exception { super("SHA-256", "SUN"); } } } Thanks, sorry for the delay. Brad On 2/15/2018 7:40 AM, Xuelei Fan wrote: > Looks fine to me.? Thanks! > > Xuelei > > On 2/15/2018 1:04 AM, Se?n Coffey wrote: >> A reminder for this review.. >> >> regards, >> Sean. >> >> >> On 09/02/2018 16:25, Se?n Coffey wrote: >>> Looking to push a new test which helps test CloneableDigest code. >>> It's something that arose during JDK-8193683 fix. >>> >>> The test was contributed by Brad Wetmore. I've converted it to use >>> the SSLSocketTemplate. >>> >>> JBS : https://bugs.openjdk.java.net/browse/JDK-8193892 >>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8193892/webrev/ >>> >> From sean.coffey at oracle.com Fri Feb 23 21:30:14 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 23 Feb 2018 21:30:14 +0000 Subject: RFR: 8193892: Impact of noncloneable MessageDigest implementation In-Reply-To: <7465773c-c402-a648-fbc6-4faab164d617@oracle.com> References: <9a2be852-bd0c-d025-0278-ab266a4ced66@oracle.com> <7465773c-c402-a648-fbc6-4faab164d617@oracle.com> Message-ID: Thanks for the review Brad. Yes - I'll make those changes before pushing. regards, Sean. On 23/02/2018 20:14, Brad Wetmore wrote: > Minor comments.? I'm ok with leaving as is, but this seems cleaner. > > MyProvider.java > --------------- > Would prefer to use the non-deprecated super call. > > *Digest.java > ------------ > Would you consider making these 3 duplicate classes into a single > class, with the three public derived classes within?? And then update > the MyProvider entries with DigestBase${MD5,SHA,SHA256}. i.e. > > import java.security.*; > > class DigestBase extends MessageDigestSpi { > > ??? private MessageDigest digest = null; > > ??? public DigestBase(String alg, String provider) throws Exception { > ??????? digest = MessageDigest.getInstance(alg, provider); > ??? } > > ??? @Override > ??? protected void engineUpdate(byte input) { > ??????? digest.update(input); > ??? } > > ??? @Override > ??? protected void engineUpdate(byte[] input, int offset, int len) { > ??????? digest.update(input, offset, len); > ??? } > > ??? @Override > ??? protected byte[] engineDigest() { > ??????? return digest.digest(); > ??? } > > ??? @Override > ??? protected void engineReset() { > ??????? digest.reset(); > ??? } > > ??? public static final class MD5 extends DigestBase { > ??????? public MD5() throws Exception { > ??????????? super("MD5", "SUN"); > ??????? } > ??? } > > ??? public static final class SHA extends DigestBase { > ??????? public SHA() throws Exception { > ??????????? super("SHA", "SUN"); > ??????? } > ??? } > > ??? public static final class SHA256 extends DigestBase { > ??????? public SHA256() throws Exception { > ??????????? super("SHA-256", "SUN"); > ??????? } > ??? } > } > > Thanks, sorry for the delay. > > Brad > > > > On 2/15/2018 7:40 AM, Xuelei Fan wrote: >> Looks fine to me.? Thanks! >> >> Xuelei >> >> On 2/15/2018 1:04 AM, Se?n Coffey wrote: >>> A reminder for this review.. >>> >>> regards, >>> Sean. >>> >>> >>> On 09/02/2018 16:25, Se?n Coffey wrote: >>>> Looking to push a new test which helps test CloneableDigest code. >>>> It's something that arose during JDK-8193683 fix. >>>> >>>> The test was contributed by Brad Wetmore. I've converted it to use >>>> the SSLSocketTemplate. >>>> >>>> JBS : https://bugs.openjdk.java.net/browse/JDK-8193892 >>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8193892/webrev/ >>>> >>> From weijun.wang at oracle.com Sat Feb 24 02:20:51 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 24 Feb 2018 10:20:51 +0800 Subject: RFR 8197518: Kerberos krb5 authentication: AuthList's put method leads to performance issue In-Reply-To: References: <7fbfed72-c9c0-6186-6c62-1a51a678c337@oracle.com> <1A4F8EE4-60FA-4E9B-ACF9-23EFA5A98A33@oracle.com> <7d44ab67-99a0-b120-ee5f-c8bec6621247@oracle.com> Message-ID: <9FE18067-2614-4D5D-9DDD-DC3482463DBC@oracle.com> > On Feb 24, 2018, at 12:38 AM, Daniel Fuchs wrote: > > Hi Max, > > 85 // has larger timestamp. > 86 entries.addFirst(t); > > shouldn't you set oldestTime here as well? The order might be a little misleading, you addFirst() the latest entry and the oldest one is at getLast(). oldestTime is set on line 78 because it's the only entry. But for line 86, there are already existing entries. --Max > > best regards, > > -- daniel > > On 23/02/2018 15:21, Xuelei Fan wrote: >> Looks fine to me. >> Xuelei >> On 2/23/2018 6:13 AM, Weijun Wang wrote: >>> Updated at http://cr.openjdk.java.net/~weijun/8197518/webrev.02/. From jai.forums2013 at gmail.com Sat Feb 24 05:17:03 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 24 Feb 2018 10:47:03 +0530 Subject: [PATCH] JDK-8190917 : SSL session resumption, through handshake, in SSLEngine is broken for any protocols lesser than TLSv1.2 In-Reply-To: References: <427ca55d-e619-21e5-d803-4e829007da43@gmail.com> <9f283fd1-f014-b1f6-5b03-d73f18048415@oracle.com> <11662f00-0c06-27fa-f4a0-350c846c9da6@gmail.com> Message-ID: <967d659e-1130-24f6-382c-cfdbf3dd63e1@gmail.com> Sounds fine, thank you Xuelei. Would this later be backported to Java 9 too? -Jaikiran On 24/02/18 12:21 AM, Xuelei Fan wrote: > Hi Jaikiran, > > Thanks a lot for the update.? Your code looks fine to me. > > As we are working on the re-org of the implementation[1] now, I may > integrate your contribution shortly after the re-org changes. > > Thanks, > Xuelei > > [1]: > http://mail.openjdk.java.net/pipermail/security-dev/2018-February/016815.html > > On 2/22/2018 9:58 PM, Jaikiran Pai wrote: >> Given some recent changes to the class involved in this patch, in the >> jdk repo (http://hg.openjdk.java.net/jdk/jdk), I noticed some merge >> conflicts to this patch today. So I've now attached an updated patch >> which resolves those merge issues. This has been tested with latest >> jtreg (tip). >> >> -Jaikiran >> >> >> On 06/12/17 9:35 PM, Jaikiran Pai wrote: >>> Thank you Xuelei. Please take your time. >>> >>> -Jaikiran >>> >>> >>> >>> On Wednesday, December 6, 2017, Xuelei Fan >> > wrote: >>> >>> ??? Hi Jaikiran, >>> >>> ??? I will sponsor this contribution.? I need more time for the review >>> ??? and testing. >>> >>> ??? Thanks, >>> ??? Xuelei >>> >>> ??? On 11/23/2017 9:22 PM, Jaikiran Pai wrote: >>> >>> ??????? As noted in [1], there's a regression in Java 9, where SSL >>> ??????? session resumption no longer works for SSL protocols other >>> ??????? than TLSv1.2. The code which is responsible for session >>> ??????? resumption resides in the ServerHandshaker[2], in the >>> ??????? clientHello method. This method, in its logic to decide >>> ??????? whether or not to resume a (previously) cached session, checks >>> ??????? if the client hello message has a session id associated. If it >>> ??????? does, it then fetches a session from the cache. If it does >>> ??????? find a previously cached session for that id, it then goes >>> ??????? ahead to check if the SSL protocol associated with the cached >>> ??????? session matches with the protocol version that's >>> ??????? "applicable/selected" of the incoming client hello message. >>> ??????? However, a relatively recent change[3] has, IMO, >>> ??????? unintentionally caused the protocol version check logic to >>> ??????? fail for protocols other than TLSv1.2. The protocol version >>> ??????? check looks like: >>> >>> >>> ??????? // cannot resume session with different >>> >>> ??????? if (oldVersion != protocolVersion) { >>> ??????? resumingSession = false; >>> ??????? } >>> >>> ??????? The `protocolVersion` variable in this case happens to be a >>> ??????? _default initialized value_ (TLSv1.2) instead of the one >>> ??????? that's "selected" based on the incoming client hello message. >>> ??????? As a result the `protocolVersion` value is always TLSv1.2 and >>> ??????? thus for any other protocols, this comparison fails, even when >>> ??????? the client hello message uses the right session id and the >>> ??????? right protocol that matches the previous session. >>> >>> ??????? The attached patch, includes a potential fix to this issue. >>> ??????? The change makes sure that the protocol selection, based on >>> ??????? the client hello message, is done before this session >>> ??????? resumption check and also makes sure it uses that "selected" >>> ??????? protocol in the version comparison check instead of the class >>> ??????? member `protocolVersion` (which gets set when the server hello >>> ??????? message is finally being sent). >>> >>> ??????? The attached patch also contains a (jtreg) test case which >>> ??????? reproduces this bug and verifies this fix. The test case tests >>> ??????? the session resumption against TLSv1, TLSv1.1 and TLSv1.2. The >>> ??????? test code itself is a minor modification of the SSL demo >>> ??????? that's available here [4]. >>> >>> ??????? This is my first OpenJDK patch and my OCA got approved a few >>> ??????? days back. Could someone please help with the review of this >>> ??????? patch? >>> >>> ??????? P.S: I noticed that the JIRA got assigned a few days back. I >>> ??????? am not sure if that means the fix is already being worked upon >>> ??????? by someone else from the team. If that's the case, then let me >>> ??????? know and I'll let it be handled by them. >>> >>> ??????? [1] https://bugs.openjdk.java.net/browse/JDK-8190917 >>> >>> >>> ??????? [2] >>> http://hg.openjdk.java.net/jdk/jdk/file/b7ae1437111b/src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java >>> >>> >>> >>> ??????? [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/42268eb6e04e >>> >>> >>> ??????? [4] >>> https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/samples/sslengine/SSLEngineSimpleDemo.java >>> >>> >>> >>> ??????? -Jaikiran >>> >>> >>> >> From weijun.wang at oracle.com Sat Feb 24 09:15:08 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 24 Feb 2018 17:15:08 +0800 Subject: RFR 8191139: Remove deprecated javax.security.auth.Policy API Message-ID: Please take a review at 8191139: Remove deprecated javax.security.auth.Policy API http://cr.openjdk.java.net/~weijun/8191139/webrev.00/ Thanks Max From weijun.wang at oracle.com Sat Feb 24 14:49:16 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 24 Feb 2018 22:49:16 +0800 Subject: RFR 8193262: JNI array not released in libsunmscapi convertToLittleEndian Message-ID: <97EF5417-C37E-49BC-ABB3-3159DBA03A70@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8193262/webrev.00/ Noreg-hard. I modified my own JDK a little to directly call convertToLittleEndian() using bad input and I can see my debug line before the ReleaseByteArrayElements() call is always printed. Thanks Max From daniel.fuchs at oracle.com Mon Feb 26 10:59:24 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 26 Feb 2018 10:59:24 +0000 Subject: RFR 8197518: Kerberos krb5 authentication: AuthList's put method leads to performance issue In-Reply-To: <9FE18067-2614-4D5D-9DDD-DC3482463DBC@oracle.com> References: <7fbfed72-c9c0-6186-6c62-1a51a678c337@oracle.com> <1A4F8EE4-60FA-4E9B-ACF9-23EFA5A98A33@oracle.com> <7d44ab67-99a0-b120-ee5f-c8bec6621247@oracle.com> <9FE18067-2614-4D5D-9DDD-DC3482463DBC@oracle.com> Message-ID: On 24/02/2018 02:20, Weijun Wang wrote: > The order might be a little misleading, you addFirst() the latest entry and the oldest one is at getLast(). oldestTime is set on line 78 because it's the only entry. But for line 86, there are already existing entries. Oh, right, that's my mistake! Thanks Max, and best regards, -- daniel On 24/02/2018 02:20, Weijun Wang wrote: >> On Feb 24, 2018, at 12:38 AM, Daniel Fuchs wrote: >> >> Hi Max, >> >> 85 // has larger timestamp. >> 86 entries.addFirst(t); >> >> shouldn't you set oldestTime here as well? > The order might be a little misleading, you addFirst() the latest entry and the oldest one is at getLast(). oldestTime is set on line 78 because it's the only entry. But for line 86, there are already existing entries. > > --Max > From adam.petcher at oracle.com Mon Feb 26 18:39:52 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 26 Feb 2018 13:39:52 -0500 Subject: RFR 8181594: Efficient and constant-time modular arithmetic In-Reply-To: References: <7bd6c1ae-4173-4384-fc57-66d1b185ba56@oracle.com> Message-ID: <9021dd99-4ac1-f7a1-fc91-ab0a9cf1685b@oracle.com> Thanks for the initial feedback. Here is the latest webrev: http://cr.openjdk.java.net/~apetcher/8181594/webrev.01/ See inline below. On 2/23/2018 12:46 PM, Xuelei Fan wrote: > ArrayUtil.java: > =============== > I'm not very sure how widely this utilities will be used in the > future. Looks like only BigIntegerModuloP uses this classes.? I may > prefer to define private methods for byte array swap in > BigIntegerModuloP. It is also used by XDHPublicKeyImpl (in the XDH code review). XDH public keys are represented as BigInteger, and I use the array reverse method to convert encoded keys to BigInteger. > > BigIntegerModuloP.java: > ======================= > As this is a class for testing or ptototype purpose,? it might not be > a part of JDK products, like JRE.? Would you mind move it to a test > package if you want to keep it? Good idea. I moved it into the same directory as TestIntegerModuloP.java. > > IntegerModuloP, IntegerModuloP_Base and MutableIntegerModuloP > ============================================================= > In the security package/context, it may make sense to use > "IntegerModulo" for the referring to "integers modulo a prime value". In ECC, we also have curves over binary fields, and some methods in these interfaces/classes will not work correctly if the number of field elements is not prime (e.g. Fermat's little theorem is used to calculate a multiplicative inverse). So I would prefer that the names of these interfaces contain some string (e.g. "Prime" or "P") to make it clear that they only represent prime fields. > The class name of "IntegerModuloP_Base" is not a general Java coding > style.? I may prefer a little bit name changes like: > ???? IntegerModuloP_Base?? -> IntegerModulo > ???? IntegerModuloP??????? -> ImmutableIntegerModulo > ???? MutableIntegerModuloP -> MutableIntegerModulo > > ???? IntegerFieldModuloP?? -> IntegerModuloField (?) > I'm not fond of the current names, either. My goal with the naming was to indicate that "IntegerModuloP_Base" shouldn't be used in most cases, because you don't know whether it is mutable or not. So the typical interface to use is the immutable one, and the mutable one should only be used when mutability is necessary. Your suggested naming is more conventional, but I think it loses this aspect of my naming system. It's only an internal API, so I'm not too picky about the names, and I have no problem changing it as you suggest. But I'd like to see if anyone else has any suggestions about the names, first. > > MutableIntegerModuloP.java > ========================== > void conditionalSwapWith(MutableIntegerModuloP b, int swap); > As the 'swap' parameter can only be 0 or 1, could it be a boolean > parameter? I couldn't come up with a way to implement this without branching when the swap parameter is boolean. See IntegerPolynomial.conditionalSwap to see how this is implemented in arithmetic with an int swap argument. If you (or anyone) can think of a way to do this with boolean, let me know. I added a sentence to the comment above conditionalSwapWith that describes why it is an int instead of a boolean. > > Except the conditionalSwapWith() method, I did not get the points why > we need a mutable version.? Would you please have more description of > this requirement? The comment above the class definition has this sentence: "This interface can be used to improve performance and avoid the allocation of a large number of temporary objects." Do you need more information than this in the comments? The performance motivation is so that a.add(b).multiply(c)... can be done without allocating a new buffer for each operation. For example, without mutable field elements, an X25519 point multiplication would allocate around 4,300 temporary arrays totaling 350,000 bytes. If I remember correctly, switching the X25519 implementation to mutable field elements reduced the point multiplication time by about half. > > > IntegerModuloP_Base.java > ======================== > default byte[] addModPowerTwo(IntegerModuloP_Base b, int len) > void addModPowerTwo(IntegerModuloP_Base b, byte[] result); > > For the first sign of the method names, I thought it is to calculate > as "(this + b) ^ 2 mod m". To be precise, it calculates "((this % p) + (b % p)) % 2^m" (where p is the prime that defines the field, and m is the desired length, in bits). Note that the addition here is normal integer addition (not addition in GF(p)). This operation is not used in XDH, but it is used in Poly1305 to add the AES encryption of a nonce to a field element. So you can get more information about this operation by reading the Poly1305 paper/RFC. > Besides, what's the benefits of the two methods?? Could we just use: > ????? this.add(b).asByteArray() No, because that would calculate "((this + b) mod p) mod 2^m". The value of (this + b) can be larger than p, so this would not produce the desired result. > > I guess, but not very sure, it is for constant time calculation. If > the function is required, could it be renamed as: > > ????? // the result is inside of the size range > ????? IntegerModuloP addModSize(IntegerModuloP_Base b, int size) > Or > ????? // the result is wrapped if outside of the size range > ????? IntegerModuloP addOnWrap(IntegerModuloP_Base b, int size) > > and the use may look like: > ????? this.addModSize(b, size).asByteArray() > Any attempt to perform the addition in IntegerModuloP and then pull out the byte array will not work. This class can only represent field elements, so the sum would be in the field, which is not what we want. > > Will review the rest when I understand more about the interfaces design. > > Thanks, > Xuelei > > On 1/30/2018 8:52 AM, Adam Petcher wrote: >> +core-libs-dev >> >> >> On 1/26/2018 4:06 PM, Adam Petcher wrote: >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8181594 >>> Webrev: http://cr.openjdk.java.net/~apetcher/8181594/webrev.00/ >>> >>> This is a code review for the field arithmetic that will be used in >>> implementations of X25519/X448 key agreement, the Poly1305 >>> authenticator, and EdDSA signatures. I believe that the library has >>> all the features necessary for X25519/X448 and Poly1305, and I >>> expect at most a couple of minor enhancements will be required to >>> support EdDSA. There is no public API for this library, so we can >>> change it in the future to suit the needs of new algorithms without >>> breaking compatibility with external code. Still, I made an attempt >>> to clearly structure and document the (internal) API, and I want to >>> make sure it is understandable and easy to use. >>> >>> This is not a general-purpose modular arithmetic library. It will >>> only work well in circumstances where the sequence of operations is >>> restricted, and where the prime that defines the field has some >>> useful structure. Moreover, each new field will require some >>> field-specific code that takes into account the structure of the >>> prime and the way the field is used in the application. The initial >>> implementation includes a field for Poly1305 and the fields for >>> X25519/X448 which should also work for EdDSA. >>> >>> The benefits of using this library are that it is much more >>> efficient than using similar operations in BigInteger. Also, many >>> operations are branch-free, making them suitable for use in a >>> side-channel resistant implementation that does not branch on secrets. >>> >>> To provide some context, I have attached a code snippet describing >>> how this library can be used. The snippet is the constant-time >>> Montgomery ladder from my X25519/X448 implementation, which I expect >>> to be out for review soon. X25519/X448 only uses standard arithmetic >>> operations, and the more unusual features (e.g. add modulo a power >>> of 2) are needed by Poly1305. >>> >>> The field arithmetic (for all fields) is implemented using a 32-bit >>> representation similar to the one described in the Ed448 paper[1] >>> (in the "Implementation on 32-bit platforms" section). Though my >>> implementation uses signed limbs, and grade-school multiplication >>> instead of Karatsuba. The argument for correctness is essentially >>> the same for all three fields: the magnitude of each 64-bit limb is >>> at most 2^(k-1) after reduction, except for the last limb which may >>> have a magnitude of up to 2^k. The values of k are between 26 to 28 >>> (depending on the field), and we can calculate that the maximum >>> magnitude for any limb during an add-multiply-carry-reduce sequence >>> is always less than 2^63. Therefore, no overflow occurs and all >>> operations are correct. >>> >>> Process note: this enhancement is part of JEP 324 (Key Agreement >>> with Curve25519 and Curve448). When this code review is complete, >>> nothing will happen until all other work for this JEP is complete, >>> and the JEP is accepted as part of some release. This means that >>> this code will be pushed to the repo along with the X25519/X448 code >>> that uses it. >>> >>> [1] https://eprint.iacr.org/2015/625.pdf >>> >>> >>> >> From valerie.peng at oracle.com Wed Feb 28 02:47:33 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 27 Feb 2018 18:47:33 -0800 Subject: [PATCH] JDK-8194630: Uninitialized initiator_address in native GSS In-Reply-To: References: Message-ID: The later version looks good and I will use this one. Thanks, Valerie On 2/22/2018 2:49 AM, Jan Kalina wrote: > Ok, thanks Valerie! > Sorry for spam, I has supposed my previous email was not considered to > be patch. > > Martin: > As this is way how it is initialized in other places, I has not > considered it. > http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/59e88d3b9b17/src/share/native/sun/security/jgss/wrapper/GSSLibStub.c#l132 > > Follows fixed version - tested and works ok - keeping on Valerie which > version will be used: > > --------------------------------------------- > diff --git a/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c > b/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c > --- a/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c > +++ b/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c > @@ -169,6 +169,9 @@ > ?? // initialize addrtype in CB first > ?? cb->initiator_addrtype = GSS_C_AF_NULLADDR; > ?? cb->acceptor_addrtype = GSS_C_AF_NULLADDR; > +? // addresses needs to be initialized to empty > +? memset(&cb->initiator_address, 0, sizeof(cb->initiator_address)); > +? memset(&cb->acceptor_address, 0, sizeof(cb->acceptor_address)); > > ?? /* set up initiator address */ > ?? jinetAddr = (*env)->CallObjectMethod(env, jcb, > --------------------------------------------- > > On Wed, Feb 21, 2018 at 7:26 PM, Martin Balao > wrote: > > Have you considered zeroizing the whole "gss_channel_bindings_t" > structure with memset? So we don't have problem if new fields are > eventually added. > > On Wed, Feb 21, 2018 at 1:39 PM, Jan Kalina > wrote: > > I has prepared fix for bug related to using native GSS API. > Uninitialized fields causes JVM crash or authentication failing. > > Bug consequences are more described in bugreport: > https://bugs.openjdk.java.net/browse/JDK-8194630 > > Reproducer is attached to bugreport too. > > Would anyone be interested in reviewing/sponsoring this change? > It would be really great to get this into JDK 9 and above. > (I am covered by Red Hat OCA.) > > Thanks for your response! > > PATCH: > ---------------------------------------------- > diff --git > a/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c > b/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c > --- a/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c > +++ b/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c > @@ -169,6 +169,11 @@ > ?? // initialize addrtype in CB first > ?? cb->initiator_addrtype = GSS_C_AF_NULLADDR; > ?? cb->acceptor_addrtype = GSS_C_AF_NULLADDR; > +? // addresses needs to be initialized to empty > +? cb->initiator_address.length = 0; > +? cb->initiator_address.value = NULL; > +? cb->acceptor_address.length = 0; > +? cb->acceptor_address.value = NULL; > > ?? /* set up initiator address */ > ?? jinetAddr = (*env)->CallObjectMethod(env, jcb, > ---------------------------------------------- > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Wed Feb 28 16:36:59 2018 From: ecki at zusammenkunft.net (Bernd) Date: Wed, 28 Feb 2018 17:36:59 +0100 Subject: provider registration Message-ID: Hello, there was a thread on BouncyCastle's crypto-dev mailing list how to use a custom JCA provider with Java 9+. Since there is no alternative for the lib/ext extension mechanism this is a bit tricky (if you do want to make the extension in the java.security file permanent). There are multiple alternatives (adding to module path, to classpath, using service loader or programmatic registration). Those are described in the actual documentation. However expanding the java.security list does not mention explicitely that without the extension mechanism this produces a java home which wont start without modifying the module path. Not sure if there is actually a default way to storesuch a "security provider module" without using for example jlink to build a new image (or add the -mp argument). Maybe this should be stated explicite? "Starting with Java 9 there is no extension mechanism where you could install the provider JAR permanently. Therefore expanding the java.security leaves typically a incomplete java home and should be avoided. Permanently installing an additional module could be done with a custom jlink image." (I havent tested if JLink works, BCProv is not yet modularized or service loader enabled. Classpath and programmatic registration works fine). Is that correct? Gruss Bernd -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Wed Feb 28 16:39:01 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 28 Feb 2018 08:39:01 -0800 Subject: [PATCH] JDK-8190917 : SSL session resumption, through handshake, in SSLEngine is broken for any protocols lesser than TLSv1.2 In-Reply-To: <967d659e-1130-24f6-382c-cfdbf3dd63e1@gmail.com> References: <427ca55d-e619-21e5-d803-4e829007da43@gmail.com> <9f283fd1-f014-b1f6-5b03-d73f18048415@oracle.com> <11662f00-0c06-27fa-f4a0-350c846c9da6@gmail.com> <967d659e-1130-24f6-382c-cfdbf3dd63e1@gmail.com> Message-ID: <1b7e0677-d92e-8f20-1abf-05134558fd3e@oracle.com> Hi Jaikiran, As you noticed, we updated to use the ClientHello.client_version and session version for version negotiation during resumption. It's not the best option for performance, but it is a safer option for compatibility before I'm able to make further evaluation. I need more time to think about the impact if backporting t0 JDK 9. Thanks, Xuelei On 2/23/2018 9:17 PM, Jaikiran Pai wrote: > Sounds fine, thank you Xuelei. Would this later be backported to Java 9 > too? > > -Jaikiran > > > On 24/02/18 12:21 AM, Xuelei Fan wrote: >> Hi Jaikiran, >> >> Thanks a lot for the update.? Your code looks fine to me. >> >> As we are working on the re-org of the implementation[1] now, I may >> integrate your contribution shortly after the re-org changes. >> >> Thanks, >> Xuelei >> >> [1]: >> http://mail.openjdk.java.net/pipermail/security-dev/2018-February/016815.html >> >> >> On 2/22/2018 9:58 PM, Jaikiran Pai wrote: >>> Given some recent changes to the class involved in this patch, in the >>> jdk repo (http://hg.openjdk.java.net/jdk/jdk), I noticed some merge >>> conflicts to this patch today. So I've now attached an updated patch >>> which resolves those merge issues. This has been tested with latest >>> jtreg (tip). >>> >>> -Jaikiran >>> >>> >>> On 06/12/17 9:35 PM, Jaikiran Pai wrote: >>>> Thank you Xuelei. Please take your time. >>>> >>>> -Jaikiran >>>> >>>> >>>> >>>> On Wednesday, December 6, 2017, Xuelei Fan >>> > wrote: >>>> >>>> ??? Hi Jaikiran, >>>> >>>> ??? I will sponsor this contribution.? I need more time for the review >>>> ??? and testing. >>>> >>>> ??? Thanks, >>>> ??? Xuelei >>>> >>>> ??? On 11/23/2017 9:22 PM, Jaikiran Pai wrote: >>>> >>>> ??????? As noted in [1], there's a regression in Java 9, where SSL >>>> ??????? session resumption no longer works for SSL protocols other >>>> ??????? than TLSv1.2. The code which is responsible for session >>>> ??????? resumption resides in the ServerHandshaker[2], in the >>>> ??????? clientHello method. This method, in its logic to decide >>>> ??????? whether or not to resume a (previously) cached session, checks >>>> ??????? if the client hello message has a session id associated. If it >>>> ??????? does, it then fetches a session from the cache. If it does >>>> ??????? find a previously cached session for that id, it then goes >>>> ??????? ahead to check if the SSL protocol associated with the cached >>>> ??????? session matches with the protocol version that's >>>> ??????? "applicable/selected" of the incoming client hello message. >>>> ??????? However, a relatively recent change[3] has, IMO, >>>> ??????? unintentionally caused the protocol version check logic to >>>> ??????? fail for protocols other than TLSv1.2. The protocol version >>>> ??????? check looks like: >>>> >>>> >>>> ??????? // cannot resume session with different >>>> >>>> ??????? if (oldVersion != protocolVersion) { >>>> ??????? resumingSession = false; >>>> ??????? } >>>> >>>> ??????? The `protocolVersion` variable in this case happens to be a >>>> ??????? _default initialized value_ (TLSv1.2) instead of the one >>>> ??????? that's "selected" based on the incoming client hello message. >>>> ??????? As a result the `protocolVersion` value is always TLSv1.2 and >>>> ??????? thus for any other protocols, this comparison fails, even when >>>> ??????? the client hello message uses the right session id and the >>>> ??????? right protocol that matches the previous session. >>>> >>>> ??????? The attached patch, includes a potential fix to this issue. >>>> ??????? The change makes sure that the protocol selection, based on >>>> ??????? the client hello message, is done before this session >>>> ??????? resumption check and also makes sure it uses that "selected" >>>> ??????? protocol in the version comparison check instead of the class >>>> ??????? member `protocolVersion` (which gets set when the server hello >>>> ??????? message is finally being sent). >>>> >>>> ??????? The attached patch also contains a (jtreg) test case which >>>> ??????? reproduces this bug and verifies this fix. The test case tests >>>> ??????? the session resumption against TLSv1, TLSv1.1 and TLSv1.2. The >>>> ??????? test code itself is a minor modification of the SSL demo >>>> ??????? that's available here [4]. >>>> >>>> ??????? This is my first OpenJDK patch and my OCA got approved a few >>>> ??????? days back. Could someone please help with the review of this >>>> ??????? patch? >>>> >>>> ??????? P.S: I noticed that the JIRA got assigned a few days back. I >>>> ??????? am not sure if that means the fix is already being worked upon >>>> ??????? by someone else from the team. If that's the case, then let me >>>> ??????? know and I'll let it be handled by them. >>>> >>>> ??????? [1] https://bugs.openjdk.java.net/browse/JDK-8190917 >>>> >>>> >>>> ??????? [2] >>>> http://hg.openjdk.java.net/jdk/jdk/file/b7ae1437111b/src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java >>>> >>>> >>>> >>>> >>>> >>>> ??????? [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/42268eb6e04e >>>> >>>> >>>> ??????? [4] >>>> https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/samples/sslengine/SSLEngineSimpleDemo.java >>>> >>>> >>>> >>>> >>>> >>>> ??????? -Jaikiran >>>> >>>> >>>> >>> >