From weijun.wang at oracle.com Wed Jul 1 02:02:08 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 1 Jul 2020 10:02:08 +0800 Subject: RFR: 8218021: Have jarsigner preserve posix permission attributes In-Reply-To: <9903a925-a93e-d712-1d6c-80db047e2907@oracle.com> References: <6a34a99c-ed06-5e38-0932-788e944a70df@oracle.com> <22AD74BE-6E90-45CA-AEEF-73E5FCCC0BF5@oracle.com> <60ef9824-bb1c-9ff1-11a8-76290f8f8882@oracle.com> <9903a925-a93e-d712-1d6c-80db047e2907@oracle.com> Message-ID: <9D6C8F4C-3FC2-4B56-A506-51DA6E907EAF@oracle.com> --------------------- src/java.base/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java @@ -248,7 +248,7 @@ private static X509CRL getCRL(URIName name) throws CertStoreException { debug.println("Trying to fetch CRL from DP " + uri); } Event.report("event.crl.check", uri.toString()); Event.report(Event.ReporterCategory.CRLCHECK,"event.crl.check", uri.toString()); Please add a whitespace after CRLCHECK. --------------------- src/java.base/share/classes/sun/security/provider/certpath/OCSP.java @@ -234,7 +234,7 @@ static OCSPResponse check(List certIds, URI responderURI, debug.println("connecting to OCSP service at: " + url); } Event.report("event.ocsp.check", url.toString()); Event.report(Event.ReporterCategory.CRLCHECK,"event.ocsp.check", url.toString()); White space after CRLCHECK. --------------------- src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java int perms = JUZFA.getPosixPerms(ze); if (!posixPermsDetected && perms != -1) { posixPermsDetected = true; Event.report(Event.ReporterCategory.POSIXPERMS, "true"); The method signature is "report(category, type, values...)". There is no need to define a type or value here but I feel like more normal to call 'report(POSIXPERMS, "detected")' because the 2nd argument is type instead of value. --------------------- src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java @@ -1054,7 +1063,7 @@ private void displayMessagesAndResult(boolean isSigning) { notYetValidCert || chainNotValidated || hasExpiredCert || hasUnsignedEntry || signerSelfSigned || (legacyAlg != 0) || (disabledAlg != 0) || aliasNotInStore || notSignedByAlias || tsaChainNotValidated || permsDetected || I'd prefer move the permsDetected check and the if block for it out of this big block, since it's not a fatal warning and just informational. You can move it into "if (hasExpiringCert....". --------------------- src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java @@ -1805,6 +1820,7 @@ void signJar(String jarName, String alias) fos.close(); } Event.clearReportListener(Event.ReporterCategory.POSIXPERMS); Maybe in a final block? --------------------- test/jdk/sun/security/util/Resources/Usages.java @@ -75,7 +75,7 @@ "(?m)rb[ \\n]*\\.getString[ \\n]*\\([ \\n]*\"(.*?)\"\\)"); static Pattern EVENT_OCSP_CRL = Pattern.compile( "Event\\.report\\(.*,\"(.*?)\","); If you agree to add a whitespace in the calls in OSCP.java and DistributionFetcher.java, you might want to add a whitespace (or "\s*") here as well. Thanks, Max > On Jun 30, 2020, at 9:51 PM, Se?n Coffey wrote: > > Thanks Lance. > > During the CSR review, a suggestion was made to have jarsigner preserve such attributes by default. Warnings about these attributes will also be added during signing and verify operations (if detected). > > webrev: https://cr.openjdk.java.net/~coffeys/webrev.8218021.v4/webrev/ > > regards, > Sean. > > On 22/06/2020 17:17, Lance Andersen wrote: >> HI Sean, >> >> Looks OK based on our exchanges. Thank you for your time on this one! >> >> Best >> Lance >> >>> On Jun 22, 2020, at 7:22 AM, Se?n Coffey wrote: >>> >>> Thanks Lance. >>> >>> I've updated the patch with some extra offline feedback from yourself and Max. >>> A new warning is printed with use of the new flag. A warning is also printed when file posix permissions are detected on resources being signed. Test updated for that also. >>> >>> https://cr.openjdk.java.net/~coffeys/webrev.8218021.v3/webrev/ >>> >>> regards, >>> Sean. >>> >>> On 12/06/2020 17:05, Lance Andersen wrote: >>>> Hi Sean, >>>> >>>> I think your changes look fine so all good FMPOV. >>>> >>>> Best >>>> Lance >>>> >>>>> On Jun 12, 2020, at 6:21 AM, Se?n Coffey wrote: >>>>> >>>>> Hi, >>>>> >>>>> I'd like to reboot this jarsigner enhancement request[1]. I've removed the problem references to zip file name extensions. Instead, there's a new JDK implementation specific jarsigner option: -keepposixperms >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8218021 >>>>> https://cr.openjdk.java.net/~coffeys/webrev.8218021.v2/webrev/ >>>>> >>>>> regards, >>>>> Sean. >>>>> >>>>> [1] http://mail.openjdk.java.net/pipermail/security-dev/2020-January/021141.html >>>>> >>>> >>>> >>>> >>>> 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 >>>> >>>> >>>> >> >> >> >> 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 >> >> >> From weijun.wang at oracle.com Wed Jul 1 03:31:54 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 1 Jul 2020 11:31:54 +0800 Subject: RFR 8243592: Subject$SecureSet::contains(null) is suboptimal In-Reply-To: References: <45F36569-C6F0-4827-ACF4-6A7B69890559@oracle.com> <40F07BEA-6C60-4D80-B1C1-86402FD67E57@oracle.com> <1dfd1e84-d1ea-6162-970e-f061373e8fa7@oracle.com> <1cb283c7-2047-bbd1-05a2-c852b19f67f8@oracle.com> Message-ID: <8B5D455B-0FBF-4C17-8FAD-55465F162AE2@oracle.com> Please review an updated fix at https://cr.openjdk.java.net/~weijun/8243592/webrev.03 After some discussion, we think there is no need to call contains(null) at all since it might not be reliable (see the new test). Now, collectionNullClean inspects all items in the input collection and create a new LinkedList. Since there is no need to repopulate a list inside "new SecureSet", the new implementation is not slower than the original proposal from Tigran. And there is no need for a CSR because there will be no behavior change. Thanks, Max p.s. Welcome to the github playground at https://github.com/openjdk/playground/pull/9, but formal code review should stay in this mail thread. > On Apr 30, 2020, at 9:50 PM, Weijun Wang wrote: > > Webrev updated at > > http://cr.openjdk.java.net/~weijun/8243592/webrev.02/ > > I removed my old test and rewrite the existing SubjectNullTests.java test in TestNG with quite some new test cases. > > There are so many behavior changes (although we might say good programs are not affected) that I decided to add a CSR and a release note. Please also take a look. > > CSR : https://bugs.openjdk.java.net/browse/JDK-8244165 > release note : https://bugs.openjdk.java.net/browse/JDK-8244169 > > Thanks, > Max > > >> On Apr 29, 2020, at 2:57 AM, Sean Mullan wrote: >> >> I don't think containsAll and retainsAll need to call collectionNullClean either because SecureSet.contains(null) returns false now. >> >> --Sean >> >> On 4/28/20 9:58 AM, Weijun Wang wrote: >>> A new webrev is at >>> http://cr.openjdk.java.net/~weijun/8243592/webrev.01/ >>> I take this chance to do some formatting and add a new test. My first testng test! >>> Thanks, >>> Max >>>> On Apr 28, 2020, at 8:16 PM, Sean Mullan wrote: >>>> >>>> On 4/27/20 10:39 PM, Weijun Wang wrote: >>>>> Reading the Set spec, it looks like an NPE is still needed for add(), but remove() can be modified. >>>> >>>> Good point, I agree. >>>> >>>> --Sean >>>> >>>>> --Max >>>>>> On Apr 27, 2020, at 10:27 PM, Sean Mullan wrote: >>>>>> >>>>>> The fix looks fine to me. For consistency, you could make the same change for null elements in the other SecureSet methods: add, remove. >>>>>> >>>>>> --Sean >>>>>> >>>>>> On 4/25/20 3:39 AM, Weijun Wang wrote: >>>>>>> Please take a review at >>>>>>> http://cr.openjdk.java.net/~weijun/8243592/webrev.00/ >>>>>>> This is helpful if we do any set arithmetic between 2 Subject objects. >>>>>>> No new regression test, I intend to add a noreg-trivial label. >>>>>>> *Tigran*: Please confirm you are OK with the "Contributed-by" line. >>>>>>> Thanks, >>>>>>> Max > From tigran.mkrtchyan at desy.de Wed Jul 1 08:37:07 2020 From: tigran.mkrtchyan at desy.de (Mkrtchyan, Tigran) Date: Wed, 1 Jul 2020 10:37:07 +0200 (CEST) Subject: RFR 8243592: Subject$SecureSet::contains(null) is suboptimal In-Reply-To: <8B5D455B-0FBF-4C17-8FAD-55465F162AE2@oracle.com> References: <45F36569-C6F0-4827-ACF4-6A7B69890559@oracle.com> <40F07BEA-6C60-4D80-B1C1-86402FD67E57@oracle.com> <1dfd1e84-d1ea-6162-970e-f061373e8fa7@oracle.com> <1cb283c7-2047-bbd1-05a2-c852b19f67f8@oracle.com> <8B5D455B-0FBF-4C17-8FAD-55465F162AE2@oracle.com> Message-ID: <1069534417.521678.1593592627297.JavaMail.zimbra@desy.de> Hi Max, Thanks for following up on that. I like your approach - it doesn't introduce confusion or behaviour changes. I re-run the benchmark: Benchmark Mode Cnt Score Error Units SubjectBenchmark.jdkOriginalSubject thrpt 20 360202.816 ? 4071.762 ops/s SubjectBenchmark.maxPatchSubject thrpt 20 1609248.338 ? 48137.227 ops/s SubjectBenchmark.tigranPatchSubject thrpt 20 1973207.564 ? 89670.297 ops/s The performance difference can be ignored. Best regards, Tigran. P.S. Thanks for the pointer to the github repo! ----- Original Message ----- > From: "Weijun Wang" > To: "Sean Mullan" > Cc: "security-dev" > Sent: Wednesday, July 1, 2020 5:31:54 AM > Subject: Re: RFR 8243592: Subject$SecureSet::contains(null) is suboptimal > Please review an updated fix at > > https://cr.openjdk.java.net/~weijun/8243592/webrev.03 > > After some discussion, we think there is no need to call contains(null) at all > since it might not be reliable (see the new test). Now, collectionNullClean > inspects all items in the input collection and create a new LinkedList. > > Since there is no need to repopulate a list inside "new SecureSet", the new > implementation is not slower than the original proposal from Tigran. > > And there is no need for a CSR because there will be no behavior change. > > Thanks, > Max > > p.s. Welcome to the github playground at > https://github.com/openjdk/playground/pull/9, but formal code review should > stay in this mail thread. > >> On Apr 30, 2020, at 9:50 PM, Weijun Wang wrote: >> >> Webrev updated at >> >> http://cr.openjdk.java.net/~weijun/8243592/webrev.02/ >> >> I removed my old test and rewrite the existing SubjectNullTests.java test in >> TestNG with quite some new test cases. >> >> There are so many behavior changes (although we might say good programs are not >> affected) that I decided to add a CSR and a release note. Please also take a >> look. >> >> CSR : https://bugs.openjdk.java.net/browse/JDK-8244165 >> release note : https://bugs.openjdk.java.net/browse/JDK-8244169 >> >> Thanks, >> Max >> >> >>> On Apr 29, 2020, at 2:57 AM, Sean Mullan wrote: >>> >>> I don't think containsAll and retainsAll need to call collectionNullClean either >>> because SecureSet.contains(null) returns false now. >>> >>> --Sean >>> >>> On 4/28/20 9:58 AM, Weijun Wang wrote: >>>> A new webrev is at >>>> http://cr.openjdk.java.net/~weijun/8243592/webrev.01/ >>>> I take this chance to do some formatting and add a new test. My first testng >>>> test! >>>> Thanks, >>>> Max >>>>> On Apr 28, 2020, at 8:16 PM, Sean Mullan wrote: >>>>> >>>>> On 4/27/20 10:39 PM, Weijun Wang wrote: >>>>>> Reading the Set spec, it looks like an NPE is still needed for add(), but >>>>>> remove() can be modified. >>>>> >>>>> Good point, I agree. >>>>> >>>>> --Sean >>>>> >>>>>> --Max >>>>>>> On Apr 27, 2020, at 10:27 PM, Sean Mullan wrote: >>>>>>> >>>>>>> The fix looks fine to me. For consistency, you could make the same change for >>>>>>> null elements in the other SecureSet methods: add, remove. >>>>>>> >>>>>>> --Sean >>>>>>> >>>>>>> On 4/25/20 3:39 AM, Weijun Wang wrote: >>>>>>>> Please take a review at >>>>>>>> http://cr.openjdk.java.net/~weijun/8243592/webrev.00/ >>>>>>>> This is helpful if we do any set arithmetic between 2 Subject objects. >>>>>>>> No new regression test, I intend to add a noreg-trivial label. >>>>>>>> *Tigran*: Please confirm you are OK with the "Contributed-by" line. >>>>>>>> Thanks, >>>>>>>> Max From sean.coffey at oracle.com Thu Jul 2 07:05:40 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 2 Jul 2020 08:05:40 +0100 Subject: RFR: 8218021: Have jarsigner preserve posix permission attributes In-Reply-To: <9D6C8F4C-3FC2-4B56-A506-51DA6E907EAF@oracle.com> References: <6a34a99c-ed06-5e38-0932-788e944a70df@oracle.com> <22AD74BE-6E90-45CA-AEEF-73E5FCCC0BF5@oracle.com> <60ef9824-bb1c-9ff1-11a8-76290f8f8882@oracle.com> <9903a925-a93e-d712-1d6c-80db047e2907@oracle.com> <9D6C8F4C-3FC2-4B56-A506-51DA6E907EAF@oracle.com> Message-ID: Thanks for the review Max. All edits made bar the "Event.clearReportListener(Event.ReporterCategory.POSIXPERMS);" suggested edit. That's already in a finally block. latest webrev: https://cr.openjdk.java.net/~coffeys/webrev.8218021.v5/webrev/ I plan to push once I have a clean test run. regards, Sean. On 01/07/2020 03:02, Weijun Wang wrote: > --------------------- > src/java.base/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java > @@ -248,7 +248,7 @@ private static X509CRL getCRL(URIName name) throws CertStoreException { > debug.println("Trying to fetch CRL from DP " + uri); > } > > Event.report("event.crl.check", uri.toString()); > Event.report(Event.ReporterCategory.CRLCHECK,"event.crl.check", uri.toString()); > > Please add a whitespace after CRLCHECK. > --------------------- > src/java.base/share/classes/sun/security/provider/certpath/OCSP.java > @@ -234,7 +234,7 @@ static OCSPResponse check(List certIds, URI responderURI, > debug.println("connecting to OCSP service at: " + url); > } > > Event.report("event.ocsp.check", url.toString()); > Event.report(Event.ReporterCategory.CRLCHECK,"event.ocsp.check", url.toString()); > > White space after CRLCHECK. > --------------------- > src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java > int perms = JUZFA.getPosixPerms(ze); > if (!posixPermsDetected && perms != -1) { > posixPermsDetected = true; > Event.report(Event.ReporterCategory.POSIXPERMS, "true"); > > The method signature is "report(category, type, values...)". There is no need to define a type or value here but I feel like more normal to call 'report(POSIXPERMS, "detected")' because the 2nd argument is type instead of value. > --------------------- > src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java > @@ -1054,7 +1063,7 @@ private void displayMessagesAndResult(boolean isSigning) { > notYetValidCert || chainNotValidated || hasExpiredCert || > hasUnsignedEntry || signerSelfSigned || (legacyAlg != 0) || > (disabledAlg != 0) || aliasNotInStore || notSignedByAlias || > tsaChainNotValidated || permsDetected || > > I'd prefer move the permsDetected check and the if block for it out of this big block, since it's not a fatal warning and just informational. You can move it into "if (hasExpiringCert....". > --------------------- > src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java > @@ -1805,6 +1820,7 @@ void signJar(String jarName, String alias) > fos.close(); > } > > Event.clearReportListener(Event.ReporterCategory.POSIXPERMS); > > Maybe in a final block? > --------------------- > test/jdk/sun/security/util/Resources/Usages.java > @@ -75,7 +75,7 @@ > "(?m)rb[ \\n]*\\.getString[ \\n]*\\([ \\n]*\"(.*?)\"\\)"); > > static Pattern EVENT_OCSP_CRL = Pattern.compile( > "Event\\.report\\(.*,\"(.*?)\","); > > If you agree to add a whitespace in the calls in OSCP.java and DistributionFetcher.java, you might want to add a whitespace (or "\s*") here as well. > > Thanks, > Max > > >> On Jun 30, 2020, at 9:51 PM, Se?n Coffey wrote: >> >> Thanks Lance. >> >> During the CSR review, a suggestion was made to have jarsigner preserve such attributes by default. Warnings about these attributes will also be added during signing and verify operations (if detected). >> >> webrev: https://cr.openjdk.java.net/~coffeys/webrev.8218021.v4/webrev/ >> >> regards, >> Sean. >> >> On 22/06/2020 17:17, Lance Andersen wrote: >>> HI Sean, >>> >>> Looks OK based on our exchanges. Thank you for your time on this one! >>> >>> Best >>> Lance >>> >>>> On Jun 22, 2020, at 7:22 AM, Se?n Coffey wrote: >>>> >>>> Thanks Lance. >>>> >>>> I've updated the patch with some extra offline feedback from yourself and Max. >>>> A new warning is printed with use of the new flag. A warning is also printed when file posix permissions are detected on resources being signed. Test updated for that also. >>>> >>>> https://cr.openjdk.java.net/~coffeys/webrev.8218021.v3/webrev/ >>>> >>>> regards, >>>> Sean. >>>> >>>> On 12/06/2020 17:05, Lance Andersen wrote: >>>>> Hi Sean, >>>>> >>>>> I think your changes look fine so all good FMPOV. >>>>> >>>>> Best >>>>> Lance >>>>> >>>>>> On Jun 12, 2020, at 6:21 AM, Se?n Coffey wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I'd like to reboot this jarsigner enhancement request[1]. I've removed the problem references to zip file name extensions. Instead, there's a new JDK implementation specific jarsigner option: -keepposixperms >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8218021 >>>>>> https://cr.openjdk.java.net/~coffeys/webrev.8218021.v2/webrev/ >>>>>> >>>>>> regards, >>>>>> Sean. >>>>>> >>>>>> [1] http://mail.openjdk.java.net/pipermail/security-dev/2020-January/021141.html >>>>>> >>>>> >>>>> >>>>> 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 >>>>> >>>>> >>>>> >>> >>> >>> 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 >>> >>> >>> From Alan.Bateman at oracle.com Thu Jul 2 07:59:41 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 2 Jul 2020 08:59:41 +0100 Subject: RFR: 8218021: Have jarsigner preserve posix permission attributes In-Reply-To: <9903a925-a93e-d712-1d6c-80db047e2907@oracle.com> References: <6a34a99c-ed06-5e38-0932-788e944a70df@oracle.com> <22AD74BE-6E90-45CA-AEEF-73E5FCCC0BF5@oracle.com> <60ef9824-bb1c-9ff1-11a8-76290f8f8882@oracle.com> <9903a925-a93e-d712-1d6c-80db047e2907@oracle.com> Message-ID: <1fd1604e-812a-c887-3abc-47e9eb531c25@oracle.com> On 30/06/2020 14:51, Se?n Coffey wrote: > > : > > During the CSR review, a suggestion was made to have jarsigner > preserve such attributes by default. Warnings about these attributes > will also be added during signing and verify operations (if detected). > Yes, signing should be additive so the original proposal to drop information from the UNIX extra block would be surprising. The intersection of those using zip/other tools to create zip files and then signing them with jarsigner is probably small but it would still be confusing for signing to loose information. Having jarsigner refuse to sign these zip files by default, with an option to override, would be a reasonable approach. The current proposal to printing a warning seems okay too. I've skimmed through webrev.8218021.v5 which has this warning: "POSIX file permission attributes detected. Note that these attributes are unsigned and not protected by the signature." I realize you've agreed this with the other Reviewers but I think that "Note that these attributes are unsigned ..." is confusing as it could be interpreted to mean that they have to be signed by some other means, or even that the warning is because they are using unsigned values. It might be better to tweak the second part to make it a bit clearer, up to you but something like "These attributes are ignored when signing and are not protected by the signature". -Alan From sean.coffey at oracle.com Thu Jul 2 08:10:53 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 2 Jul 2020 09:10:53 +0100 Subject: RFR: 8218021: Have jarsigner preserve posix permission attributes In-Reply-To: <1fd1604e-812a-c887-3abc-47e9eb531c25@oracle.com> References: <6a34a99c-ed06-5e38-0932-788e944a70df@oracle.com> <22AD74BE-6E90-45CA-AEEF-73E5FCCC0BF5@oracle.com> <60ef9824-bb1c-9ff1-11a8-76290f8f8882@oracle.com> <9903a925-a93e-d712-1d6c-80db047e2907@oracle.com> <1fd1604e-812a-c887-3abc-47e9eb531c25@oracle.com> Message-ID: <2b363448-8790-75f0-4834-64b9e2e4af01@oracle.com> Thanks for the review Alan. I'm in contact with Max already about possible follow up enhancements in this area. It would be worked via a follow on JBS record. Regarding the error message, I'm fine with your suggestion. We can go with this then: "POSIX file permission attributes detected. These attributes are ignored when signing and are not protected by the signature." regards, Sean. On 02/07/2020 08:59, Alan Bateman wrote: > On 30/06/2020 14:51, Se?n Coffey wrote: >> >> : >> >> During the CSR review, a suggestion was made to have jarsigner >> preserve such attributes by default. Warnings about these attributes >> will also be added during signing and verify operations (if detected). >> > Yes, signing should be additive so the original proposal to drop > information from the UNIX extra block would be surprising. The > intersection of those using zip/other tools to create zip files and > then signing them with jarsigner is probably small but it would still > be confusing for signing to loose information. Having jarsigner refuse > to sign these zip files by default, with an option to override, would > be a reasonable approach. The current proposal to printing a warning > seems okay too. > > I've skimmed through webrev.8218021.v5 which has this warning: > > "POSIX file permission attributes detected. Note that these attributes > are unsigned and not protected by the signature." > > I realize you've agreed this with the other Reviewers but I think that > "Note that these attributes are unsigned ..." is confusing as it could > be interpreted to mean that they have to be signed by some other > means, or even that the warning is because they are using unsigned > values. > > It might be better to tweak the second part to make it a bit clearer, > up to you but something like "These attributes are ignored when > signing and are not protected by the signature". > > -Alan From LANCE.ANDERSEN at ORACLE.COM Thu Jul 2 12:12:59 2020 From: LANCE.ANDERSEN at ORACLE.COM (Lance Andersen) Date: Thu, 2 Jul 2020 08:12:59 -0400 Subject: RFR: 8218021: Have jarsigner preserve posix permission attributes In-Reply-To: <2b363448-8790-75f0-4834-64b9e2e4af01@oracle.com> References: <6a34a99c-ed06-5e38-0932-788e944a70df@oracle.com> <22AD74BE-6E90-45CA-AEEF-73E5FCCC0BF5@oracle.com> <60ef9824-bb1c-9ff1-11a8-76290f8f8882@oracle.com> <9903a925-a93e-d712-1d6c-80db047e2907@oracle.com> <1fd1604e-812a-c887-3abc-47e9eb531c25@oracle.com> <2b363448-8790-75f0-4834-64b9e2e4af01@oracle.com> Message-ID: <99AEF0BF-8D9D-408A-A569-1206A7C5E927@ORACLE.COM> Hi Sean, I think the changes look good including the proposed tweaks to the message suggested by Alan. Best Lance > On Jul 2, 2020, at 4:10 AM, Se?n Coffey wrote: > > Thanks for the review Alan. I'm in contact with Max already about possible follow up enhancements in this area. It would be worked via a follow on JBS record. > > Regarding the error message, I'm fine with your suggestion. We can go with this then: > "POSIX file permission attributes detected. These attributes are ignored when signing and are not protected by the signature." > > regards, > Sean. > > On 02/07/2020 08:59, Alan Bateman wrote: >> On 30/06/2020 14:51, Se?n Coffey wrote: >>> >>> : >>> >>> During the CSR review, a suggestion was made to have jarsigner preserve such attributes by default. Warnings about these attributes will also be added during signing and verify operations (if detected). >>> >> Yes, signing should be additive so the original proposal to drop information from the UNIX extra block would be surprising. The intersection of those using zip/other tools to create zip files and then signing them with jarsigner is probably small but it would still be confusing for signing to loose information. Having jarsigner refuse to sign these zip files by default, with an option to override, would be a reasonable approach. The current proposal to printing a warning seems okay too. >> >> I've skimmed through webrev.8218021.v5 which has this warning: >> >> "POSIX file permission attributes detected. Note that these attributes are unsigned and not protected by the signature." >> >> I realize you've agreed this with the other Reviewers but I think that "Note that these attributes are unsigned ..." is confusing as it could be interpreted to mean that they have to be signed by some other means, or even that the warning is because they are using unsigned values. >> >> It might be better to tweak the second part to make it a bit clearer, up to you but something like "These attributes are ignored when signing and are not protected by the signature". >> >> -Alan Best Lance ------------------ 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 John.Gray at entrustdatacard.com Thu Jul 2 16:11:09 2020 From: John.Gray at entrustdatacard.com (John Gray) Date: Thu, 2 Jul 2020 16:11:09 +0000 Subject: [EXTERNAL]Re: SecureRandom regression with certain security providers In-Reply-To: <85ac45ca-28c7-a17b-57cb-b7f35d1ce731@oracle.com> References: <2HnXazk66-nxoiS5rxih3yQnqfj2EePRDjdw0P7z8YN4Dr3iqR5WBcHoIM7U8ZIquneZ60ridpBTRPjuYaAmTvTZ11lOT2twH2PlEwzBfm8=@protonmail.com> <85ac45ca-28c7-a17b-57cb-b7f35d1ce731@oracle.com> Message-ID: Hi Valerie, I noticed this looked related to the Secure Random issue (https://bugs.openjdk.java.net/browse/JDK-8246383) and I noticed you had ported back the work-around you mentioned to me a few weeks ago. So I thought I would give it a try with the 11.08 pre-release since you had listed it backported to that stream. I get a different error that looks like the identical error to (https://bugs.openjdk.java.net/browse/JDK-8248505) and the stack trace looks almost identical: Caused by: java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Service not registered with Provider Entrust: Entrust: SecureRandom.DRBGusingSHA512 -> com.entrust.toolkit.security.crypto.random.DRBGusingSHA512 at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:294) at java.base/java.security.SecureRandom.(SecureRandom.java:219) at java.base/javax.crypto.JceSecurity.(JceSecurity.java:80) ... 8 more Caused by: java.security.NoSuchAlgorithmException: Service not registered with Provider Entrust: Entrust: SecureRandom.DRBGusingSHA512 -> com.entrust.toolkit.security.crypto.random.DRBGusingSHA512 at java.base/java.security.Provider$Service.newInstance(Provider.java:1855) at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:290) ... 10 more It looks like you are already looking at the issue, so I just thought I would let you know that it is affecting us as well. Cheers, John Gray -----Original Message----- From: security-dev [mailto:security-dev-retn at openjdk.java.net] On Behalf Of Valerie Peng Sent: Monday, June 29, 2020 4:56 PM To: security-dev at openjdk.java.net Subject: [EXTERNAL]Re: SecureRandom regression with certain security providers WARNING: This email originated outside of Entrust Datacard. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. Hi Ioannis, Thanks for reporting this issue and the detailed info. I've filed https://bugs.openjdk.java.net/browse/JDK-8248505 for this. It seems that this is mostly due to the mixing of both legacy and service-based registration in the BC provider not working well with the fix in JDK-8246613. Another possible fix may be to prefer the SecureRandom service object from the putService call. Anyway, I will take a look. Regards, Valerie On 6/28/2020 10:14 PM, Ioannis Kakavas wrote: > Hi folks, > > Since the latest changes to SecureRandom[0], using certain ( I can reproduce with one but others might have the same issue, see below ) security providers, it is impossible to get an instance of SecurityRandom. The following is reproducible with the BouncyCastle FIPS 140-2 provider [1]: > > public class TestSecureRandom { > > public static void main(String[] args){ > assert Security.getProviders()[0].getName().equals("BCFIPS"); > SecureRandom random = new SecureRandom(); > } > } > > will fail with > > Exception in thread "main" java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom > attributes: {ImplementedIn=Software} > > at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:294) > at java.base/java.security.SecureRandom.(SecureRandom.java:219) > at TestSecureRandomBug.main(TestSecureRandomBug.java:8) > Caused by: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom > attributes: {ImplementedIn=Software} > > at java.base/java.security.Provider$Service.newInstance(Provider.java:1857) > at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:290) > ... 2 more > > > I reported this to the authors of the security provider [2] and I will share part of the analysis on why this fails here for the sake of completeness of the report. > > The BCFIPS security provider overrides getService() and getServices() of Provider and it has its own extension of the Provider.Service which getService() returns. > However, getDefaultSecureRandomService() will always return a > java.security.Provider.Service and since we are calling newInstance > [3] on it, this fails as the > > if (provider.getService(type, algorithm) != this) { > throw new NoSuchAlgorithmException("Service not registered with > Provider " + provider.getName() + ": " + this); } > > can not be true. getService will return a org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider.BcService and `this` is a java.security.Provider.Service. > > > I am not aware of other providers being affected by this ( the non FIPS BouncyCastle Provider is not, since it's a legacy style security provider ) but given the reason for the issue, I think there might be others affected. With [0] being backported to all supported versions and BCFIPS being one of the few available security providers that is FIPS 140-2 approved, this introduces a significant issue for folks with fips compliance requirements. > > One potential fix that was proposed in [2] was to replace > > if (prngServices != null && !prngServices.isEmpty()) { > return prngServices.iterator().next(); > } > > with: > > if (prngServices != null && !prngServices.isEmpty()) { > Service rng = prngServices.iterator().next(); > return getService(rng.getType(), rng.getAlgorithm()); > } > > so that any provider extending Service, could work fine. > > Best Regards > Ioannis > > > [0] https://hg.openjdk.java.net/jdk/jdk15/rev/6eeaa40131ff > [1] https://www.bouncycastle.org/fips-java/ > [2] > http://bouncy-castle.1462172.n4.nabble.com/Default-SecureRandom-issue- > in-BCFIPS-and-latest-JDK15-td4659964.html > [3] https://hg.openjdk.java.net/jdk/jdk15/rev/6eeaa40131ff#l2.55 From sean.mullan at oracle.com Thu Jul 2 18:33:57 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 2 Jul 2020 14:33:57 -0400 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com> <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com> <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> Message-ID: <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com> On 6/24/20 2:56 PM, Daniel Fuchs wrote: > The JNDI/LDAP part looks mostly good. You will need someone > from the security libs to review the security lib part of the > changes. I have previously reviewed it but I would like to give it another once over. Max should also review the final version as he is the expert in JGSS. Given we are around US holidays/vacation, expect some delay. I suppose this is a bit of a grey area, but given the scope and the introduction of new properties and initial support for TLS channel binding, it seems more like an Enhancement than a Bug to me. That would kind of rule it out for JDK 15, but I suspect that what is more important is backporting this to prior releases, and that can be figured out later. So, JDK 16 as an initial target seems ok to me. Thanks, Sean From valerie.peng at oracle.com Thu Jul 2 20:36:45 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 2 Jul 2020 13:36:45 -0700 Subject: [EXTERNAL]Re: SecureRandom regression with certain security providers In-Reply-To: References: <2HnXazk66-nxoiS5rxih3yQnqfj2EePRDjdw0P7z8YN4Dr3iqR5WBcHoIM7U8ZIquneZ60ridpBTRPjuYaAmTvTZ11lOT2twH2PlEwzBfm8=@protonmail.com> <85ac45ca-28c7-a17b-57cb-b7f35d1ce731@oracle.com> Message-ID: <8840c02b-cec6-1ef9-4b5d-1649b1d93bba@oracle.com> Hi John, Thanks for the feedback, it certainly helps to know which providers are affected to help us give this the right priority and the right fix. So, does Entrust provider also override Provider.putService()/getService() calls like BCFIPS provider does? I am about to send out the webrev on this issue now and would like to make sure the current fix would work with Entrust's scenario. Is it possible that you can help verifying it? Or I can do it too if it does not require hardware setup. Regards, Valerie On 7/2/2020 9:11 AM, John Gray wrote: > Hi Valerie, > > I noticed this looked related to the Secure Random issue (https://bugs.openjdk.java.net/browse/JDK-8246383) and I noticed you had ported back the work-around you mentioned to me a few weeks ago. So I thought I would give it a try with the 11.08 pre-release since you had listed it backported to that stream. > > I get a different error that looks like the identical error to (https://bugs.openjdk.java.net/browse/JDK-8248505) and the stack trace looks almost identical: > > > Caused by: java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Service not registered with Provider Entrust: Entrust: SecureRandom.DRBGusingSHA512 -> com.entrust.toolkit.security.crypto.random.DRBGusingSHA512 > > at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:294) > at java.base/java.security.SecureRandom.(SecureRandom.java:219) > at java.base/javax.crypto.JceSecurity.(JceSecurity.java:80) > ... 8 more > Caused by: java.security.NoSuchAlgorithmException: Service not registered with Provider Entrust: Entrust: SecureRandom.DRBGusingSHA512 -> com.entrust.toolkit.security.crypto.random.DRBGusingSHA512 > > at java.base/java.security.Provider$Service.newInstance(Provider.java:1855) > at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:290) > ... 10 more > > > It looks like you are already looking at the issue, so I just thought I would let you know that it is affecting us as well. > > > Cheers, > > John Gray > > > -----Original Message----- > From: security-dev [mailto:security-dev-retn at openjdk.java.net] On Behalf Of Valerie Peng > Sent: Monday, June 29, 2020 4:56 PM > To: security-dev at openjdk.java.net > Subject: [EXTERNAL]Re: SecureRandom regression with certain security providers > > WARNING: This email originated outside of Entrust Datacard. > DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. > > Hi Ioannis, > > Thanks for reporting this issue and the detailed info. > > I've filed https://bugs.openjdk.java.net/browse/JDK-8248505 for this. It seems that this is mostly due to the mixing of both legacy and service-based registration in the BC provider not working well with the fix in JDK-8246613. Another possible fix may be to prefer the SecureRandom service object from the putService call. Anyway, I will take a look. > > Regards, > Valerie > On 6/28/2020 10:14 PM, Ioannis Kakavas wrote: >> Hi folks, >> >> Since the latest changes to SecureRandom[0], using certain ( I can reproduce with one but others might have the same issue, see below ) security providers, it is impossible to get an instance of SecurityRandom. The following is reproducible with the BouncyCastle FIPS 140-2 provider [1]: >> >> public class TestSecureRandom { >> >> public static void main(String[] args){ >> assert Security.getProviders()[0].getName().equals("BCFIPS"); >> SecureRandom random = new SecureRandom(); >> } >> } >> >> will fail with >> >> Exception in thread "main" java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom >> attributes: {ImplementedIn=Software} >> >> at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:294) >> at java.base/java.security.SecureRandom.(SecureRandom.java:219) >> at TestSecureRandomBug.main(TestSecureRandomBug.java:8) >> Caused by: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom >> attributes: {ImplementedIn=Software} >> >> at java.base/java.security.Provider$Service.newInstance(Provider.java:1857) >> at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:290) >> ... 2 more >> >> >> I reported this to the authors of the security provider [2] and I will share part of the analysis on why this fails here for the sake of completeness of the report. >> >> The BCFIPS security provider overrides getService() and getServices() of Provider and it has its own extension of the Provider.Service which getService() returns. >> However, getDefaultSecureRandomService() will always return a >> java.security.Provider.Service and since we are calling newInstance >> [3] on it, this fails as the >> >> if (provider.getService(type, algorithm) != this) { >> throw new NoSuchAlgorithmException("Service not registered with >> Provider " + provider.getName() + ": " + this); } >> >> can not be true. getService will return a org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider.BcService and `this` is a java.security.Provider.Service. >> >> >> I am not aware of other providers being affected by this ( the non FIPS BouncyCastle Provider is not, since it's a legacy style security provider ) but given the reason for the issue, I think there might be others affected. With [0] being backported to all supported versions and BCFIPS being one of the few available security providers that is FIPS 140-2 approved, this introduces a significant issue for folks with fips compliance requirements. >> >> One potential fix that was proposed in [2] was to replace >> >> if (prngServices != null && !prngServices.isEmpty()) { >> return prngServices.iterator().next(); >> } >> >> with: >> >> if (prngServices != null && !prngServices.isEmpty()) { >> Service rng = prngServices.iterator().next(); >> return getService(rng.getType(), rng.getAlgorithm()); >> } >> >> so that any provider extending Service, could work fine. >> >> Best Regards >> Ioannis >> >> >> [0] https://hg.openjdk.java.net/jdk/jdk15/rev/6eeaa40131ff >> [1] https://www.bouncycastle.org/fips-java/ >> [2] >> http://bouncy-castle.1462172.n4.nabble.com/Default-SecureRandom-issue- >> in-BCFIPS-and-latest-JDK15-td4659964.html >> [3] https://hg.openjdk.java.net/jdk/jdk15/rev/6eeaa40131ff#l2.55 From valerie.peng at oracle.com Thu Jul 2 20:52:41 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 2 Jul 2020 13:52:41 -0700 Subject: RFR[15] 8248505: Unexpected NoSuchAlgorithmException when using secure random impl from BCFIPS provider Message-ID: <2a4a0b62-b6ab-85c0-c47a-6fe7aea87c5f@oracle.com> Hi Max and Sean, Can you help reviewing this fix for JDK-8248505? This is the followup fix for JDK-8246613 "Choose the default SecureRandom algo based on registration ordering" which you reviewed earlier. Based on the feedback, BCFIPS provider overrides putService/getService() calls which does not work well with the fix for JDK-8246613. Thus, I adapted to store the SecureRandom algorithm names internally and then return the result from getService(...) when Provider.getDefaultSecureRandomService() is called. Updated the regression test to include a custom provider which simulates the BCFIPS provider behavior. Bug: https://bugs.openjdk.java.net/browse/JDK-8248505 Webrev: http://cr.openjdk.java.net/~valeriep/8248505/webrev.00/ Thanks, Valerie From John.Gray at entrustdatacard.com Thu Jul 2 20:57:13 2020 From: John.Gray at entrustdatacard.com (John Gray) Date: Thu, 2 Jul 2020 20:57:13 +0000 Subject: [EXTERNAL]Re: SecureRandom regression with certain security providers In-Reply-To: <8840c02b-cec6-1ef9-4b5d-1649b1d93bba@oracle.com> References: <2HnXazk66-nxoiS5rxih3yQnqfj2EePRDjdw0P7z8YN4Dr3iqR5WBcHoIM7U8ZIquneZ60ridpBTRPjuYaAmTvTZ11lOT2twH2PlEwzBfm8=@protonmail.com> <85ac45ca-28c7-a17b-57cb-b7f35d1ce731@oracle.com> <8840c02b-cec6-1ef9-4b5d-1649b1d93bba@oracle.com> Message-ID: Thanks for the quick reply! We don't override the putService() or getService() calls in our Entrust provider. Our provider has been around for a very long time (since JDK 1.2 days). We use the key value mapping via put(): For example, your newer code must pick it up by looking at this mapping: put("SecureRandom.DRBGusingSHA512","com.entrust.toolkit.security.crypto.random.DRBGusingSHA512"); I guess this is considered the "old style" from what I see in the e-mail thread below. Our provider is FIPS certified and in the FIPS boundary, so having to make changes to it breaks our FIPS certification which is always a pain. I can certainly help you verify the fix. Let me know how I can help verify it for you. ?? Note: I will be on vacation next week, so I'll be back July 13th... Cheers, John Gray -----Original Message----- From: Valerie Peng Sent: Thursday, July 2, 2020 4:37 PM To: John Gray ; security-dev at openjdk.java.net Cc: John Mahoney ; Muthu Kannappan Subject: Re: [EXTERNAL]Re: SecureRandom regression with certain security providers Hi John, Thanks for the feedback, it certainly helps to know which providers are affected to help us give this the right priority and the right fix. So, does Entrust provider also override Provider.putService()/getService() calls like BCFIPS provider does? I am about to send out the webrev on this issue now and would like to make sure the current fix would work with Entrust's scenario. Is it possible that you can help verifying it? Or I can do it too if it does not require hardware setup. Regards, Valerie On 7/2/2020 9:11 AM, John Gray wrote: > Hi Valerie, > > I noticed this looked related to the Secure Random issue (https://bugs.openjdk.java.net/browse/JDK-8246383) and I noticed you had ported back the work-around you mentioned to me a few weeks ago. So I thought I would give it a try with the 11.08 pre-release since you had listed it backported to that stream. > > I get a different error that looks like the identical error to (https://bugs.openjdk.java.net/browse/JDK-8248505) and the stack trace looks almost identical: > > > Caused by: java.lang.RuntimeException: > java.security.NoSuchAlgorithmException: Service not registered with > Provider Entrust: Entrust: SecureRandom.DRBGusingSHA512 -> > com.entrust.toolkit.security.crypto.random.DRBGusingSHA512 > > at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:294) > at java.base/java.security.SecureRandom.(SecureRandom.java:219) > at java.base/javax.crypto.JceSecurity.(JceSecurity.java:80) > ... 8 more > Caused by: java.security.NoSuchAlgorithmException: Service not > registered with Provider Entrust: Entrust: > SecureRandom.DRBGusingSHA512 -> > com.entrust.toolkit.security.crypto.random.DRBGusingSHA512 > > at java.base/java.security.Provider$Service.newInstance(Provider.java:1855) > at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:290) > ... 10 more > > > It looks like you are already looking at the issue, so I just thought I would let you know that it is affecting us as well. > > > Cheers, > > John Gray > > > -----Original Message----- > From: security-dev [mailto:security-dev-retn at openjdk.java.net] On > Behalf Of Valerie Peng > Sent: Monday, June 29, 2020 4:56 PM > To: security-dev at openjdk.java.net > Subject: [EXTERNAL]Re: SecureRandom regression with certain security > providers > > WARNING: This email originated outside of Entrust Datacard. > DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. > > Hi Ioannis, > > Thanks for reporting this issue and the detailed info. > > I've filed https://bugs.openjdk.java.net/browse/JDK-8248505 for this. It seems that this is mostly due to the mixing of both legacy and service-based registration in the BC provider not working well with the fix in JDK-8246613. Another possible fix may be to prefer the SecureRandom service object from the putService call. Anyway, I will take a look. > > Regards, > Valerie > On 6/28/2020 10:14 PM, Ioannis Kakavas wrote: >> Hi folks, >> >> Since the latest changes to SecureRandom[0], using certain ( I can reproduce with one but others might have the same issue, see below ) security providers, it is impossible to get an instance of SecurityRandom. The following is reproducible with the BouncyCastle FIPS 140-2 provider [1]: >> >> public class TestSecureRandom { >> >> public static void main(String[] args){ >> assert Security.getProviders()[0].getName().equals("BCFIPS"); >> SecureRandom random = new SecureRandom(); >> } >> } >> >> will fail with >> >> Exception in thread "main" java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom >> attributes: {ImplementedIn=Software} >> >> at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:294) >> at java.base/java.security.SecureRandom.(SecureRandom.java:219) >> at TestSecureRandomBug.main(TestSecureRandomBug.java:8) >> Caused by: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom >> attributes: {ImplementedIn=Software} >> >> at java.base/java.security.Provider$Service.newInstance(Provider.java:1857) >> at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:290) >> ... 2 more >> >> >> I reported this to the authors of the security provider [2] and I will share part of the analysis on why this fails here for the sake of completeness of the report. >> >> The BCFIPS security provider overrides getService() and getServices() of Provider and it has its own extension of the Provider.Service which getService() returns. >> However, getDefaultSecureRandomService() will always return a >> java.security.Provider.Service and since we are calling newInstance >> [3] on it, this fails as the >> >> if (provider.getService(type, algorithm) != this) { >> throw new NoSuchAlgorithmException("Service not registered with >> Provider " + provider.getName() + ": " + this); } >> >> can not be true. getService will return a org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider.BcService and `this` is a java.security.Provider.Service. >> >> >> I am not aware of other providers being affected by this ( the non FIPS BouncyCastle Provider is not, since it's a legacy style security provider ) but given the reason for the issue, I think there might be others affected. With [0] being backported to all supported versions and BCFIPS being one of the few available security providers that is FIPS 140-2 approved, this introduces a significant issue for folks with fips compliance requirements. >> >> One potential fix that was proposed in [2] was to replace >> >> if (prngServices != null && !prngServices.isEmpty()) { >> return prngServices.iterator().next(); >> } >> >> with: >> >> if (prngServices != null && !prngServices.isEmpty()) { >> Service rng = prngServices.iterator().next(); >> return getService(rng.getType(), rng.getAlgorithm()); >> } >> >> so that any provider extending Service, could work fine. >> >> Best Regards >> Ioannis >> >> >> [0] https://hg.openjdk.java.net/jdk/jdk15/rev/6eeaa40131ff >> [1] https://www.bouncycastle.org/fips-java/ >> [2] >> http://bouncy-castle.1462172.n4.nabble.com/Default-SecureRandom-issue >> - in-BCFIPS-and-latest-JDK15-td4659964.html >> [3] https://hg.openjdk.java.net/jdk/jdk15/rev/6eeaa40131ff#l2.55 From valerie.peng at oracle.com Thu Jul 2 22:17:13 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 2 Jul 2020 15:17:13 -0700 Subject: [EXTERNAL]Re: SecureRandom regression with certain security providers In-Reply-To: References: <2HnXazk66-nxoiS5rxih3yQnqfj2EePRDjdw0P7z8YN4Dr3iqR5WBcHoIM7U8ZIquneZ60ridpBTRPjuYaAmTvTZ11lOT2twH2PlEwzBfm8=@protonmail.com> <85ac45ca-28c7-a17b-57cb-b7f35d1ce731@oracle.com> <8840c02b-cec6-1ef9-4b5d-1649b1d93bba@oracle.com> Message-ID: Hmm, there must be something else which Entrust provider does besides the usual sequence of put(String, String) calls? The regression test DefaultAlgo.java covers both the cases of pure legacy, i.e. put(String, String) calls, and pure service providers, i.e. putService(...) calls. Is there anything special that Entrust provider does which may lead to this NSAE? This NSAE is thrown when the service mismatches what returned by calling getService(...) on Entrust provider. Regards, Valerie On 7/2/2020 1:57 PM, John Gray wrote: > Thanks for the quick reply! > > We don't override the putService() or getService() calls in our Entrust provider. Our provider has been around for a very long time (since JDK 1.2 days). > > We use the key value mapping via put(): > > For example, your newer code must pick it up by looking at this mapping: > put("SecureRandom.DRBGusingSHA512","com.entrust.toolkit.security.crypto.random.DRBGusingSHA512"); > > I guess this is considered the "old style" from what I see in the e-mail thread below. Our provider is FIPS certified and in the FIPS boundary, so having to make changes to it breaks our FIPS certification which is always a pain. > > I can certainly help you verify the fix. Let me know how I can help verify it for you. ?? > > Note: I will be on vacation next week, so I'll be back July 13th... > > Cheers, > > John Gray > > > -----Original Message----- > From: Valerie Peng > Sent: Thursday, July 2, 2020 4:37 PM > To: John Gray ; security-dev at openjdk.java.net > Cc: John Mahoney ; Muthu Kannappan > Subject: Re: [EXTERNAL]Re: SecureRandom regression with certain security providers > > Hi John, > > Thanks for the feedback, it certainly helps to know which providers are affected to help us give this the right priority and the right fix. > > So, does Entrust provider also override > Provider.putService()/getService() calls like BCFIPS provider does? > > I am about to send out the webrev on this issue now and would like to make sure the current fix would work with Entrust's scenario. Is it possible that you can help verifying it? Or I can do it too if it does not require hardware setup. > > Regards, > Valerie > On 7/2/2020 9:11 AM, John Gray wrote: >> Hi Valerie, >> >> I noticed this looked related to the Secure Random issue (https://bugs.openjdk.java.net/browse/JDK-8246383) and I noticed you had ported back the work-around you mentioned to me a few weeks ago. So I thought I would give it a try with the 11.08 pre-release since you had listed it backported to that stream. >> >> I get a different error that looks like the identical error to (https://bugs.openjdk.java.net/browse/JDK-8248505) and the stack trace looks almost identical: >> >> >> Caused by: java.lang.RuntimeException: >> java.security.NoSuchAlgorithmException: Service not registered with >> Provider Entrust: Entrust: SecureRandom.DRBGusingSHA512 -> >> com.entrust.toolkit.security.crypto.random.DRBGusingSHA512 >> >> at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:294) >> at java.base/java.security.SecureRandom.(SecureRandom.java:219) >> at java.base/javax.crypto.JceSecurity.(JceSecurity.java:80) >> ... 8 more >> Caused by: java.security.NoSuchAlgorithmException: Service not >> registered with Provider Entrust: Entrust: >> SecureRandom.DRBGusingSHA512 -> >> com.entrust.toolkit.security.crypto.random.DRBGusingSHA512 >> >> at java.base/java.security.Provider$Service.newInstance(Provider.java:1855) >> at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:290) >> ... 10 more >> >> >> It looks like you are already looking at the issue, so I just thought I would let you know that it is affecting us as well. >> >> >> Cheers, >> >> John Gray >> >> >> -----Original Message----- >> From: security-dev [mailto:security-dev-retn at openjdk.java.net] On >> Behalf Of Valerie Peng >> Sent: Monday, June 29, 2020 4:56 PM >> To: security-dev at openjdk.java.net >> Subject: [EXTERNAL]Re: SecureRandom regression with certain security >> providers >> >> WARNING: This email originated outside of Entrust Datacard. >> DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. >> >> Hi Ioannis, >> >> Thanks for reporting this issue and the detailed info. >> >> I've filed https://bugs.openjdk.java.net/browse/JDK-8248505 for this. It seems that this is mostly due to the mixing of both legacy and service-based registration in the BC provider not working well with the fix in JDK-8246613. Another possible fix may be to prefer the SecureRandom service object from the putService call. Anyway, I will take a look. >> >> Regards, >> Valerie >> On 6/28/2020 10:14 PM, Ioannis Kakavas wrote: >>> Hi folks, >>> >>> Since the latest changes to SecureRandom[0], using certain ( I can reproduce with one but others might have the same issue, see below ) security providers, it is impossible to get an instance of SecurityRandom. The following is reproducible with the BouncyCastle FIPS 140-2 provider [1]: >>> >>> public class TestSecureRandom { >>> >>> public static void main(String[] args){ >>> assert Security.getProviders()[0].getName().equals("BCFIPS"); >>> SecureRandom random = new SecureRandom(); >>> } >>> } >>> >>> will fail with >>> >>> Exception in thread "main" java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom >>> attributes: {ImplementedIn=Software} >>> >>> at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:294) >>> at java.base/java.security.SecureRandom.(SecureRandom.java:219) >>> at TestSecureRandomBug.main(TestSecureRandomBug.java:8) >>> Caused by: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom >>> attributes: {ImplementedIn=Software} >>> >>> at java.base/java.security.Provider$Service.newInstance(Provider.java:1857) >>> at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:290) >>> ... 2 more >>> >>> >>> I reported this to the authors of the security provider [2] and I will share part of the analysis on why this fails here for the sake of completeness of the report. >>> >>> The BCFIPS security provider overrides getService() and getServices() of Provider and it has its own extension of the Provider.Service which getService() returns. >>> However, getDefaultSecureRandomService() will always return a >>> java.security.Provider.Service and since we are calling newInstance >>> [3] on it, this fails as the >>> >>> if (provider.getService(type, algorithm) != this) { >>> throw new NoSuchAlgorithmException("Service not registered with >>> Provider " + provider.getName() + ": " + this); } >>> >>> can not be true. getService will return a org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider.BcService and `this` is a java.security.Provider.Service. >>> >>> >>> I am not aware of other providers being affected by this ( the non FIPS BouncyCastle Provider is not, since it's a legacy style security provider ) but given the reason for the issue, I think there might be others affected. With [0] being backported to all supported versions and BCFIPS being one of the few available security providers that is FIPS 140-2 approved, this introduces a significant issue for folks with fips compliance requirements. >>> >>> One potential fix that was proposed in [2] was to replace >>> >>> if (prngServices != null && !prngServices.isEmpty()) { >>> return prngServices.iterator().next(); >>> } >>> >>> with: >>> >>> if (prngServices != null && !prngServices.isEmpty()) { >>> Service rng = prngServices.iterator().next(); >>> return getService(rng.getType(), rng.getAlgorithm()); >>> } >>> >>> so that any provider extending Service, could work fine. >>> >>> Best Regards >>> Ioannis >>> >>> >>> [0] https://hg.openjdk.java.net/jdk/jdk15/rev/6eeaa40131ff >>> [1] https://www.bouncycastle.org/fips-java/ >>> [2] >>> http://bouncy-castle.1462172.n4.nabble.com/Default-SecureRandom-issue >>> - in-BCFIPS-and-latest-JDK15-td4659964.html >>> [3] https://hg.openjdk.java.net/jdk/jdk15/rev/6eeaa40131ff#l2.55 From valerie.peng at oracle.com Fri Jul 3 00:33:45 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 2 Jul 2020 17:33:45 -0700 Subject: [EXTERNAL]Re: SecureRandom regression with certain security providers In-Reply-To: References: <2HnXazk66-nxoiS5rxih3yQnqfj2EePRDjdw0P7z8YN4Dr3iqR5WBcHoIM7U8ZIquneZ60ridpBTRPjuYaAmTvTZ11lOT2twH2PlEwzBfm8=@protonmail.com> <85ac45ca-28c7-a17b-57cb-b7f35d1ce731@oracle.com> <8840c02b-cec6-1ef9-4b5d-1649b1d93bba@oracle.com> Message-ID: <684222be-3b19-937e-9066-c53c69474cb8@oracle.com> Hi John, Unfortunately this cannot wait til July 13th if this issue needs to be fixed for jdk 15. Maybe you can try the webrev out or share more details on how Entrust provider does its registration and what Provider APIs it overrides. I need more info to help identifying the trigger for the NSAE in Entrust's case. I have verified that the current webrev works with BCFIPS provider. Regards and an early happy July 4th, Valerie On 7/2/2020 3:17 PM, Valerie Peng wrote: > I can certainly help you verify the fix.?? Let me know how I can help > verify it for you.? ?? > > Note:?? I will be on vacation next week, so I'll be back July 13th... From weijun.wang at oracle.com Fri Jul 3 04:05:53 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 3 Jul 2020 12:05:53 +0800 Subject: RFR[15] 8248505: Unexpected NoSuchAlgorithmException when using secure random impl from BCFIPS provider In-Reply-To: <2a4a0b62-b6ab-85c0-c47a-6fe7aea87c5f@oracle.com> References: <2a4a0b62-b6ab-85c0-c47a-6fe7aea87c5f@oracle.com> Message-ID: Hi Valerie, How about the suggested fix from the bug reporter? Thanks, Max > On Jul 3, 2020, at 4:52 AM, Valerie Peng wrote: > > Hi Max and Sean, > > Can you help reviewing this fix for JDK-8248505? This is the followup fix for JDK-8246613 "Choose the default SecureRandom algo based on registration ordering" which you reviewed earlier. Based on the feedback, BCFIPS provider overrides putService/getService() calls which does not work well with the fix for JDK-8246613. Thus, I adapted to store the SecureRandom algorithm names internally and then return the result from getService(...) when Provider.getDefaultSecureRandomService() is called. Updated the regression test to include a custom provider which simulates the BCFIPS provider behavior. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8248505 > > Webrev: http://cr.openjdk.java.net/~valeriep/8248505/webrev.00/ > > Thanks, > Valerie > > From weijun.wang at oracle.com Fri Jul 3 08:08:32 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 3 Jul 2020 16:08:32 +0800 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com> <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com> <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com> Message-ID: <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com> The GSS and SASL changes look fine to me. Two small questions: 1. If the change in java.security.jgss/share/classes/module-info.java is unavoidable, can we create a sub-package for this single class so that we only need to export it? Or, do you think we can define the sub-class inside GssKrb5Client and directly check its class name in InitialToken? This is a little ugly so you're free to ignore it. 2. Is GSSContextImpl::setChannelBinding really necessary? I don't know if there are people using null to erase a CB set earlier. Thanks, Max > On Jul 3, 2020, at 2:33 AM, Sean Mullan wrote: > > On 6/24/20 2:56 PM, Daniel Fuchs wrote: >> The JNDI/LDAP part looks mostly good. You will need someone >> from the security libs to review the security lib part of the >> changes. > > I have previously reviewed it but I would like to give it another once over. Max should also review the final version as he is the expert in JGSS. > > Given we are around US holidays/vacation, expect some delay. > > I suppose this is a bit of a grey area, but given the scope and the introduction of new properties and initial support for TLS channel binding, it seems more like an Enhancement than a Bug to me. That would kind of rule it out for JDK 15, but I suspect that what is more important is backporting this to prior releases, and that can be figured out later. So, JDK 16 as an initial target seems ok to me. > > Thanks, > Sean From alexey at azul.com Fri Jul 3 11:32:50 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Fri, 3 Jul 2020 11:32:50 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com> <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com> <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com> <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com> Message-ID: <2267CBC7-85A9-4105-B405-E7499440B985@azul.com> Hello All, Thank you for review. > 1. If the change in java.security.jgss/share/classes/module-info.java is unavoidable, can we create a sub-package for this single class so that we only need to export it? As suggested by Max I?ve moved TlsChannelBindingImpl class into sub-package, so module-info.java exports TlsChannelBindingImpl only. > > 2. Is GSSContextImpl::setChannelBinding really necessary? I don't know if there are people using null to erase a CB set earlier. I think these changes could be useful to exclude situations when application trying to set Channel Binding with GSSContext::setChannelBinding and ?com.sun.jndi.ldap.tls.cbtype? property altogether. I can remove it, if you think it is not necessary. Also, I've fixed Exception text and parseType(String prop) parameter name as suggested by Michael. Unfortunately, I can not completely exclude usage of the literal names because of module import issues. Fixed in the TlsChannelBinding class only. Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v10/ Regards Alexey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From weijun.wang at oracle.com Fri Jul 3 15:11:11 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 3 Jul 2020 23:11:11 +0800 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <2267CBC7-85A9-4105-B405-E7499440B985@azul.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com> <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com> <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com> <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com> <2267CBC7-85A9-4105-B405-E7499440B985@azul.com> Message-ID: <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com> > On Jul 3, 2020, at 7:32 PM, Alexey Bakhtin wrote: > > Hello All, > > Thank you for review. > >> 1. If the change in java.security.jgss/share/classes/module-info.java is unavoidable, can we create a sub-package for this single class so that we only need to export it? > > As suggested by Max I?ve moved TlsChannelBindingImpl class into sub-package, so module-info.java exports TlsChannelBindingImpl only. Thanks. > >> >> 2. Is GSSContextImpl::setChannelBinding really necessary? I don't know if there are people using null to erase a CB set earlier. > > I think these changes could be useful to exclude situations when application trying to set Channel Binding with GSSContext::setChannelBinding and ?com.sun.jndi.ldap.tls.cbtype? property altogether. I can remove it, if you think it is not necessary. I would suggest removing it. At least for the SASL GSS-API mech, it seems the GSSContext object will not be leaked and no one has a chance to call setChannelBinding again on it. There is no spec saying setChannelBinding() can only be called once, so I'd rather we don't enforce that, although you might say there is no need to call it twice. > > Also, I've fixed Exception text and parseType(String prop) parameter name as suggested by Michael. > Unfortunately, I can not completely exclude usage of the literal names because of module import issues. Fixed in the TlsChannelBinding class only. > > Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v10/ Thanks, Max > > Regards > Alexey > From alexey at azul.com Fri Jul 3 15:31:22 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Fri, 3 Jul 2020 15:31:22 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com> <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com> <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com> <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com> <2267CBC7-85A9-4105-B405-E7499440B985@azul.com> <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com> Message-ID: > I would suggest removing it. At least for the SASL GSS-API mech, it seems the GSSContext object will not be leaked and no one has a chance to call setChannelBinding again on it. > > There is no spec saying setChannelBinding() can only be called once, so I'd rather we don't enforce that, although you might say there is no need to call it twice. OK. GSSContextImpl class is removed from patch. Webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v11 Thank you Alexey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From John.Gray at entrustdatacard.com Fri Jul 3 20:13:33 2020 From: John.Gray at entrustdatacard.com (John Gray) Date: Fri, 3 Jul 2020 20:13:33 +0000 Subject: [EXTERNAL]Re: SecureRandom regression with certain security providers In-Reply-To: <684222be-3b19-937e-9066-c53c69474cb8@oracle.com> References: <2HnXazk66-nxoiS5rxih3yQnqfj2EePRDjdw0P7z8YN4Dr3iqR5WBcHoIM7U8ZIquneZ60ridpBTRPjuYaAmTvTZ11lOT2twH2PlEwzBfm8=@protonmail.com> <85ac45ca-28c7-a17b-57cb-b7f35d1ce731@oracle.com> <8840c02b-cec6-1ef9-4b5d-1649b1d93bba@oracle.com> <684222be-3b19-937e-9066-c53c69474cb8@oracle.com> Message-ID: Hi Valerie, Thanks for your comments! They sparked off a lot more investigation on my end. I created a test provider and could not reproduce the issue. That led me to investigate how our provider was being installed. We use our own internal Initializer() class to install providers in various orders (we have had to work around bugs in different JVM's in the past). That work-around required we remove the provider from the Security provider list (basically to clean it out), then we run a simple crypto test with a new instantiation, and then install that provider in 1st position. For example, here is the provider installation code that fails with 11.08. It fails differently with 11.07 (I believe you fixed that issue) and it worked with 11.06. // Remove Entrust JCA/JCE CSP Security.removeProvider("Entrust"); //work around for IBM JDK 1.4 issue Provider entrustCsp = new Entrust(); try { MessageDigest digestAlg = MessageDigest.getInstance("SHA-1", entrustCsp); digestAlg.digest(); } catch (NoSuchAlgorithmException e) { throw new EntrustProviderTamperedException("MessageDigest", e); } // Install the Entrust and IAIK JCA/JCE CSP in the first two // positions Security.insertProviderAt(entrustCsp, 1); If I change the highlighted line above (the last line) to the following, it works. Security.insertProviderAt(new Entrust(), 1); Having to make such a change seems strange. It seems that creating a new provider, using it to get an instance of an algorithm, and then adding that same provider into first position doesn?t work. I'm guessing because of the recent changes you made the provider can?t be used before it is inserted into the provider order because it may hold onto some data from the previous usage? So this led me to investigate some more?.. I debugged and found in fails in the SecureRandom and Provider.java classese: SecureRandom: // per javadoc, if none of the Providers support a RNG algorithm, // then an implementation-specific default is returned. if (prngService == null) { prngAlgorithm = "SHA1PRNG"; this.secureRandomSpi = new sun.security.provider.SecureRandom(); this.provider = Providers.getSunProvider(); } else { try { this.secureRandomSpi = (SecureRandomSpi) prngService.newInstance(null); this.provider = prngService.getProvider(); Provider: public Object newInstance(Object constructorParameter) throws NoSuchAlgorithmException { if (registered == false) { if (provider.getService(type, algorithm) != this) { throw new NoSuchAlgorithmException ("Service not registered with Provider " + provider.getName() + ": " + this); } registered = true; } Class ctrParamClz; When it fails, the type and algorithm are ?SecureRandom? and ?DRBGUsingSHA512? The Provider.getService() code fails to match the ?previousKey? ServiceKey type and algorithms. In my test code I was testing an AES algorithm, so the previous key type and Algorithm is ?Cipher? and ?AES/CBC/PKCS5PADDING? in the getService() call which doesn?t match the type ?SecureRandom? and ?DRBGUsingSHA512?. So it looks like there is a bug caused by holding on to existing data. Provider.getService(): public Service getService(String type, String algorithm) { checkInitialized(); // avoid allocating a new ServiceKey object if possible ServiceKey key = previousKey; if (key.matches(type, algorithm) == false) { key = new ServiceKey(type, algorithm, false); previousKey = key; } if (!serviceMap.isEmpty()) { Service s = serviceMap.get(key); if (s != null) { return s; } } synchronized (this) { ensureLegacyParsed(); if (legacyMap != null && !legacyMap.isEmpty()) { return legacyMap.get(key); } } return null; } // ServiceKey from previous getService() call // by re-using it if possible we avoid allocating a new object // and the toUpperCase() call. // re-use will occur e.g. as the framework traverses the provider // list and queries each provider with the same values until it finds // a matching service private static volatile ServiceKey previousKey = new ServiceKey("", "", false); So I think when I create a brand new Entrust() instance it works because the previous ServiceKey() contains the correct data and it matches. Debugging showed it to work that way. So I think using a provider before installing it in the provider order is what is causing the issue because of internal data in the Provider class. It looks like I *could* put in this weird work-around (just create a fresh instance of Entrust()) when installing the provider to work around the issue, but I wonder if there will be other consequences because of the way this previousKey is used? I can make the simple change to our toolkit without breaking FIPS (the initialization class is not in the FIPS boundary). In fact, I assume I don?t need to keep that old work-around for the old IBM JVM anymore either.. Thanks for your help! Happy July 4th (I live in Ottawa Canada, so we had our muted Canada day celebrations a couple days ago on July 1st). John Gray -----Original Message----- From: Valerie Peng [mailto:valerie.peng at oracle.com] Sent: Thursday, July 2, 2020 8:34 PM To: John Gray ; security-dev at openjdk.java.net Cc: John Mahoney ; Muthu Kannappan Subject: Re: [EXTERNAL]Re: SecureRandom regression with certain security providers Hi John, Unfortunately this cannot wait til July 13th if this issue needs to be fixed for jdk 15. Maybe you can try the webrev out or share more details on how Entrust provider does its registration and what Provider APIs it overrides. I need more info to help identifying the trigger for the NSAE in Entrust's case. I have verified that the current webrev works with BCFIPS provider. Regards and an early happy July 4th, Valerie On 7/2/2020 3:17 PM, Valerie Peng wrote: > I can certainly help you verify the fix. Let me know how I can help > verify it for you. ?? > > Note: I will be on vacation next week, so I'll be back July 13th... -------------- next part -------------- An HTML attachment was scrubbed... URL: From sha.jiang at oracle.com Mon Jul 6 02:28:26 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Mon, 6 Jul 2020 10:28:26 +0800 Subject: RFR[15] JDK-8242538: java/security/SecureRandom/ThreadSafe.java failed on windows Message-ID: <37954588-6219-32e2-48f0-8d4745a4769f@oracle.com> Hi, This test failed due to the expected concurrency issue didn't raise. This patch may mitigate this test failure. diff -r 7a61a943ce9d test/jdk/java/security/SecureRandom/ThreadSafe.java --- a/test/jdk/java/security/SecureRandom/ThreadSafe.java??? Sat Jul 04 01:06:07 2020 -0700 +++ b/test/jdk/java/security/SecureRandom/ThreadSafe.java??? Mon Jul 06 10:15:55 2020 +0800 @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2016, 2020, 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 @@ -87,7 +87,7 @@ ???????????? } ???????????? inCall = true; ???????????? try { -??????????????? Thread.sleep(100); +??????????????? Thread.sleep(500); ???????????? } catch (Exception e) { ???????????????? // OK ???????????? } Best regards, John Jiang From valerie.peng at oracle.com Mon Jul 6 16:33:54 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 6 Jul 2020 09:33:54 -0700 Subject: RFR[15] 8248505: Unexpected NoSuchAlgorithmException when using secure random impl from BCFIPS provider In-Reply-To: References: <2a4a0b62-b6ab-85c0-c47a-6fe7aea87c5f@oracle.com> Message-ID: Hi Max, The suggested fix is not much different than the suggested webrev. The essential change is to call getService(...) for the returned service in Provider.getDefaultSecureRandomService(). The only difference here is using the hardcoded type "SecureRandom" vs the one returned by getType() call. Is this what you are referring to? I re-write the rest to store String instead of Service as it may seem strange why the stored Service is not used but re-queried through getService(...). Also, looks cleaner to me this way. Thanks, Valerie On 7/2/2020 9:05 PM, Weijun Wang wrote: > Hi Valerie, > > How about the suggested fix from the bug reporter? > > Thanks, > Max > >> On Jul 3, 2020, at 4:52 AM, Valerie Peng wrote: >> >> Hi Max and Sean, >> >> Can you help reviewing this fix for JDK-8248505? This is the followup fix for JDK-8246613 "Choose the default SecureRandom algo based on registration ordering" which you reviewed earlier. Based on the feedback, BCFIPS provider overrides putService/getService() calls which does not work well with the fix for JDK-8246613. Thus, I adapted to store the SecureRandom algorithm names internally and then return the result from getService(...) when Provider.getDefaultSecureRandomService() is called. Updated the regression test to include a custom provider which simulates the BCFIPS provider behavior. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8248505 >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8248505/webrev.00/ >> >> Thanks, >> Valerie >> >> From sean.mullan at oracle.com Mon Jul 6 16:56:25 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 6 Jul 2020 12:56:25 -0400 Subject: RFR[15] JDK-8242538: java/security/SecureRandom/ThreadSafe.java failed on windows In-Reply-To: <37954588-6219-32e2-48f0-8d4745a4769f@oracle.com> References: <37954588-6219-32e2-48f0-8d4745a4769f@oracle.com> Message-ID: Looks ok to me. Please add a noreg-self label. --Sean On 7/5/20 10:28 PM, sha.jiang at oracle.com wrote: > Hi, > This test failed due to the expected concurrency issue didn't raise. > This patch may mitigate this test failure. > > diff -r 7a61a943ce9d test/jdk/java/security/SecureRandom/ThreadSafe.java > --- a/test/jdk/java/security/SecureRandom/ThreadSafe.java??? Sat Jul 04 > 01:06:07 2020 -0700 > +++ b/test/jdk/java/security/SecureRandom/ThreadSafe.java??? Mon Jul 06 > 10:15:55 2020 +0800 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2016, 2020, 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 > @@ -87,7 +87,7 @@ > ???????????? } > ???????????? inCall = true; > ???????????? try { > -??????????????? Thread.sleep(100); > +??????????????? Thread.sleep(500); > ???????????? } catch (Exception e) { > ???????????????? // OK > ???????????? } > > Best regards, > John Jiang > From valerie.peng at oracle.com Mon Jul 6 19:07:07 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 6 Jul 2020 12:07:07 -0700 Subject: [EXTERNAL]Re: SecureRandom regression with certain security providers In-Reply-To: References: <2HnXazk66-nxoiS5rxih3yQnqfj2EePRDjdw0P7z8YN4Dr3iqR5WBcHoIM7U8ZIquneZ60ridpBTRPjuYaAmTvTZ11lOT2twH2PlEwzBfm8=@protonmail.com> <85ac45ca-28c7-a17b-57cb-b7f35d1ce731@oracle.com> <8840c02b-cec6-1ef9-4b5d-1649b1d93bba@oracle.com> <684222be-3b19-937e-9066-c53c69474cb8@oracle.com> Message-ID: <405c49ec-8295-49a2-f7e4-002b393a05c3@oracle.com> Hi John, Thanks for looking into this on your end. It's interesting how Entrust has to do this deletion/re-insertion of providers and it's interesting that adding a new instance of Entrust provider inside the Security.insertProviderAt() call makes this problem go away. Please find my questions and comments in line below. On 7/3/2020 1:13 PM, John Gray wrote: > > Thanks for your comments!? They sparked off a lot more investigation > on my end.?? I created a test provider and could not reproduce the > issue.?? That led me to investigate how our provider was being > installed.?? We use our own internal Initializer() class to install > providers in various orders (we have had to work around bugs in > different JVM's in the past).?? That work-around required we remove > the provider from the Security provider list (basically to clean it > out), then we run a simple crypto test with a new instantiation, and > then install that provider in 1st position. > Does this Initializer() class does all this before the new SecureRandom() call? Does the Entrust provider remove or changes its registrations ever, i.e. is the provider mutable? One possible scenario for legacy provider which add/remove registrations is that every update to the legacy map will leads to new re-parsing and new service being created as a result which may leads to failing the check inside Service.newInstance() call and thus the NSAE. > If I change the highlighted line above (the last line) to the > following, it works. > > Security.insertProviderAt(new Entrust(), 1); > > Having to make such a change seems strange.? ??It seems that creating > a new provider, using it to get an instance of an algorithm, and then > adding that same provider into first position doesn?t work.?? I'm > guessing because of the recent changes you made the provider can?t be > used before it is inserted into the provider order because it may hold > onto some data from the previous usage??? So this led me to > investigate some more?.. > Yes, it's indeed strange. Is the "entrustCsp" instance being modified in anyway after its creation? > When it fails, the type and algorithm are ?SecureRandom? and > ?DRBGUsingSHA512? > Is ?DRBGUsingSHA512" the expected default algorithm for Entrust provider? Is it being picked up as expected if basing on registration ordering? > The Provider.getService() code fails to match the ?previousKey? > ServiceKey type and algorithms.?? In my test code I was testing an AES > algorithm, so the previous key type and Algorithm is ?Cipher? and > ?AES/CBC/PKCS5PADDING? in the getService() call which doesn?t match > the type ?SecureRandom? and ?DRBGUsingSHA512?.?? So it looks like > there is a bug caused by holding on to existing data. > The previousKey is just an optimization to avoid repetitive allocation on the same type and algorithm. If either of these two does not match, it will be discarded and new key object created for subsequent calls. So, this should not be the root cause. > > So I think when I create a brand new Entrust() instance it works > because the previous ServiceKey() contains the correct data and it > matches.?? Debugging showed it to work that way.?? So I think using a > provider before installing it in the provider order is what is causing > the issue because of internal data in the Provider class. > There is something deeper for the Entrust NSAE problem instead of the previousKey usage per my comment above. Could you please double check the Initializer class and whether the Entrust provider entries are modified after it's constructed and when new SecureRandom() is called? Thanks for looking into this~ Valerie > It looks like I **could** put in this weird work-around (just create a > fresh instance of Entrust()) when installing the provider to work > around the issue, but I wonder if there will be other consequences > because of the way this previousKey is used???? I can make the simple > change to our toolkit without breaking FIPS (the initialization class > is not in the FIPS boundary).? ?In fact, I assume I don?t need to keep > that old work-around for the old IBM JVM anymore either.. > > Thanks for your help! > > Happy July 4^th ? (I live in Ottawa Canada, so we had our muted Canada > day celebrations a couple days ago on July 1^st ). > > John Gray > > -----Original Message----- > From: Valerie Peng [mailto:valerie.peng at oracle.com] > Sent: Thursday, July 2, 2020 8:34 PM > To: John Gray ; > security-dev at openjdk.java.net > Cc: John Mahoney ; Muthu Kannappan > > Subject: Re: [EXTERNAL]Re: SecureRandom regression with certain > security providers > > Hi John, > > Unfortunately this cannot wait til July 13th if this issue needs to be > fixed for jdk 15. > > Maybe you can try the webrev out or share more details on how Entrust > provider does its registration and what Provider APIs it overrides. I > need more info to help identifying the trigger for the NSAE in > Entrust's case. I have verified that the current webrev works with > BCFIPS provider. > > Regards and an early happy July 4th, > > Valerie > > On 7/2/2020 3:17 PM, Valerie Peng wrote: > > > I can certainly help you verify the fix.?? Let me know how I can help > > > verify it for you. ?? > > > > > > Note:?? I will be on vacation next week, so I'll be back July 13th... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Mon Jul 6 19:20:45 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 6 Jul 2020 20:20:45 +0100 Subject: RFR[15] 8248505: Unexpected NoSuchAlgorithmException when using secure random impl from BCFIPS provider In-Reply-To: References: <2a4a0b62-b6ab-85c0-c47a-6fe7aea87c5f@oracle.com> Message-ID: <73effe36-8bd4-e75a-90c8-09e1790c9b15@oracle.com> Your patch looks ok to me Valerie. I note that John mentions an anomaly with your patch - I'm thinking that may need further investigation. regards, Sean. On 06/07/2020 17:33, Valerie Peng wrote: > Hi Max, > > The suggested fix is not much different than the suggested webrev. > > The essential change is to call getService(...) for the returned > service in Provider.getDefaultSecureRandomService(). The only > difference here is using the hardcoded type "SecureRandom" vs the one > returned by getType() call. Is this what you are referring to? > > I re-write the rest to store String instead of Service as it may seem > strange why the stored Service is not used but re-queried through > getService(...). Also, looks cleaner to me this way. > > Thanks, > Valerie > On 7/2/2020 9:05 PM, Weijun Wang wrote: >> Hi Valerie, >> >> How about the suggested fix from the bug reporter? >> >> Thanks, >> Max >> >>> On Jul 3, 2020, at 4:52 AM, Valerie Peng >>> wrote: >>> >>> Hi Max and Sean, >>> >>> Can you help reviewing this fix for JDK-8248505? This is the >>> followup fix for JDK-8246613 "Choose the default SecureRandom algo >>> based on registration ordering" which you reviewed earlier. Based on >>> the feedback, BCFIPS provider overrides putService/getService() >>> calls which does not work well with the fix for JDK-8246613. Thus, I >>> adapted to store the SecureRandom algorithm names internally and >>> then return the result from getService(...) when >>> Provider.getDefaultSecureRandomService() is called. Updated the >>> regression test to include a custom provider which simulates the >>> BCFIPS provider behavior. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8248505 >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8248505/webrev.00/ >>> >>> Thanks, >>> Valerie >>> >>> From valerie.peng at oracle.com Mon Jul 6 19:51:21 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 6 Jul 2020 12:51:21 -0700 Subject: RFR[15] 8248505: Unexpected NoSuchAlgorithmException when using secure random impl from BCFIPS provider In-Reply-To: <73effe36-8bd4-e75a-90c8-09e1790c9b15@oracle.com> References: <2a4a0b62-b6ab-85c0-c47a-6fe7aea87c5f@oracle.com> <73effe36-8bd4-e75a-90c8-09e1790c9b15@oracle.com> Message-ID: <8b7f691b-6660-a698-6782-7393b1c0190c@oracle.com> Thanks for taking a look, Sean. Agree that we need to get to the root cause for the NSAE which John at Entrust also observed. One possibility is to file another bug for Entrust NSAE and deliver more fix later if this current fix for BCFIPS provider does not resolve Entrust's NSAE. Valerie On 7/6/2020 12:20 PM, Se?n Coffey wrote: > Your patch looks ok to me Valerie. I note that John mentions an > anomaly with your patch - I'm thinking that may need further > investigation. > > regards, > Sean. > > On 06/07/2020 17:33, Valerie Peng wrote: >> Hi Max, >> >> The suggested fix is not much different than the suggested webrev. >> >> The essential change is to call getService(...) for the returned >> service in Provider.getDefaultSecureRandomService(). The only >> difference here is using the hardcoded type "SecureRandom" vs the one >> returned by getType() call. Is this what you are referring to? >> >> I re-write the rest to store String instead of Service as it may seem >> strange why the stored Service is not used but re-queried through >> getService(...). Also, looks cleaner to me this way. >> >> Thanks, >> Valerie >> On 7/2/2020 9:05 PM, Weijun Wang wrote: >>> Hi Valerie, >>> >>> How about the suggested fix from the bug reporter? >>> >>> Thanks, >>> Max >>> >>>> On Jul 3, 2020, at 4:52 AM, Valerie Peng >>>> wrote: >>>> >>>> Hi Max and Sean, >>>> >>>> Can you help reviewing this fix for JDK-8248505? This is the >>>> followup fix for JDK-8246613 "Choose the default SecureRandom algo >>>> based on registration ordering" which you reviewed earlier. Based >>>> on the feedback, BCFIPS provider overrides putService/getService() >>>> calls which does not work well with the fix for JDK-8246613. Thus, >>>> I adapted to store the SecureRandom algorithm names internally and >>>> then return the result from getService(...) when >>>> Provider.getDefaultSecureRandomService() is called. Updated the >>>> regression test to include a custom provider which simulates the >>>> BCFIPS provider behavior. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8248505 >>>> >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8248505/webrev.00/ >>>> >>>> Thanks, >>>> Valerie >>>> >>>> From sean.mullan at oracle.com Mon Jul 6 20:11:47 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 6 Jul 2020 16:11:47 -0400 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com> <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com> <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com> <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com> <2267CBC7-85A9-4105-B405-E7499440B985@azul.com> <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com> Message-ID: Hi Alexey, This may have been discussed already, but can you explain why the "com.sun.jndi.ldap.connect.timeout" property needs to be set in order to use this feature? That property is mostly used in tests to avoid long socket timeouts, etc. Why does that need to be set? What problem are you trying to solve? --Sean On 7/3/20 11:31 AM, Alexey Bakhtin wrote: > >> I would suggest removing it. At least for the SASL GSS-API mech, it seems the GSSContext object will not be leaked and no one has a chance to call setChannelBinding again on it. >> >> There is no spec saying setChannelBinding() can only be called once, so I'd rather we don't enforce that, although you might say there is no need to call it twice. > > OK. > GSSContextImpl class is removed from patch. > > Webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v11 > > Thank you > Alexey > From aleksej.efimov at oracle.com Mon Jul 6 22:06:52 2020 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Mon, 6 Jul 2020 23:06:52 +0100 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com> <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com> <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com> <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com> <2267CBC7-85A9-4105-B405-E7499440B985@azul.com> <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com> Message-ID: <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com> Hi Sean, Alexey answered the same question for me: > I mean ?com.sun.jndi.ldap.connect.timeout? property. > The positive value forces to start TLS handshake and wait for it completion during the connectTimeout milliseconds: > Connection.java >>> if (connectTimeout > 0) { >>> int socketTimeout = sslSocket.getSoTimeout(); >>> sslSocket.setSoTimeout(connectTimeout); // reuse full timeout value >>> sslSocket.startHandshake(); >>> sslSocket.setSoTimeout(socketTimeout); >>> } > Without this property handshake is started later asynchronously. > As result >>> certs = ssock.getSession().getPeerCertificates(); > in the LdapClient.java could return SSLPeerUnverifiedException(). > This exception will be wrapped to NamingException and thrown to application. > > This is not usually happens but I saw it on the slow connection The full context of LDAP Connection code that initiates the SSL handshake could be viewed here: https://github.com/openjdk/jdk/blob/master/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L345 -- Aleksei On 06/07/2020 21:11, Sean Mullan wrote: > Hi Alexey, > > This may have been discussed already, but can you explain why the > "com.sun.jndi.ldap.connect.timeout" property needs to be set in order > to use this feature? That property is mostly used in tests to avoid > long socket timeouts, etc. > > Why does that need to be set? What problem are you trying to solve? > > --Sean > > > On 7/3/20 11:31 AM, Alexey Bakhtin wrote: >> >>> I would suggest removing it. At least for the SASL GSS-API mech, it >>> seems the GSSContext object will not be leaked and no one has a >>> chance to call setChannelBinding again on it. >>> >>> There is no spec saying setChannelBinding() can only be called once, >>> so I'd rather we don't enforce that, although you might say there is >>> no need to call it twice. >> >> OK. >> GSSContextImpl class is removed from patch. >> >> Webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v11 >> >> Thank you >> Alexey >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Jul 6 23:30:28 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 6 Jul 2020 19:30:28 -0400 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com> References: <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com> <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com> <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com> <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com> <2267CBC7-85A9-4105-B405-E7499440B985@azul.com> <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com> <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com> Message-ID: <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com> Thanks for that extra info. I think it would be much cleaner to avoid having to set that property and instead start the handshake synchronously if the "com.sun.jndi.ldap.tls.cbtype" property is set. This way only one property needs to be set and you don't need to guess what an acceptable value is for the timeout property, which could also cause the connection to be interrupted before the TLS handshake is complete if you use too small of a value. Or better yet, there may be another way to do this with JSSE where you wait for the TLS connection to complete. I'll ask my team and get back to you. --Sean On 7/6/20 6:06 PM, Aleks Efimov wrote: > Hi Sean, > > Alexey answered the same question for me: > >> I mean ?com.sun.jndi.ldap.connect.timeout? property. >> The positive value forces to start TLS handshake and wait for it completion during the connectTimeout milliseconds: >> Connection.java >>>> if (connectTimeout > 0) { >>>> int socketTimeout = sslSocket.getSoTimeout(); >>>> sslSocket.setSoTimeout(connectTimeout); // reuse full timeout value >>>> sslSocket.startHandshake(); >>>> sslSocket.setSoTimeout(socketTimeout); >>>> } >> Without this property handshake is started later asynchronously. >> As result >>>> certs = ssock.getSession().getPeerCertificates(); >> in the LdapClient.java could return SSLPeerUnverifiedException(). >> This exception will be wrapped to NamingException and thrown to application. >> >> This is not usually happens but I saw it on the slow connection > > The full context of LDAP Connection code that initiates the SSL > handshake could be viewed here: > https://github.com/openjdk/jdk/blob/master/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L345 > > -- Aleksei > > On 06/07/2020 21:11, Sean Mullan wrote: >> Hi Alexey, >> >> This may have been discussed already, but can you explain why the >> "com.sun.jndi.ldap.connect.timeout" property needs to be set in order >> to use this feature? That property is mostly used in tests to avoid >> long socket timeouts, etc. >> >> Why does that need to be set? What problem are you trying to solve? >> >> --Sean >> >> >> On 7/3/20 11:31 AM, Alexey Bakhtin wrote: >>> >>>> I would suggest removing it. At least for the SASL GSS-API mech, it >>>> seems the GSSContext object will not be leaked and no one has a >>>> chance to call setChannelBinding again on it. >>>> >>>> There is no spec saying setChannelBinding() can only be called once, >>>> so I'd rather we don't enforce that, although you might say there is >>>> no need to call it twice. >>> >>> OK. >>> GSSContextImpl class is removed from patch. >>> >>> Webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v11 >>> >>> Thank you >>> Alexey >>> > From valerie.peng at oracle.com Mon Jul 6 23:49:30 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 6 Jul 2020 16:49:30 -0700 Subject: RFR[15] 8248505: Unexpected NoSuchAlgorithmException when using secure random impl from BCFIPS provider In-Reply-To: <8b7f691b-6660-a698-6782-7393b1c0190c@oracle.com> References: <2a4a0b62-b6ab-85c0-c47a-6fe7aea87c5f@oracle.com> <73effe36-8bd4-e75a-90c8-09e1790c9b15@oracle.com> <8b7f691b-6660-a698-6782-7393b1c0190c@oracle.com> Message-ID: <444c134a-7b48-fd57-0b1e-e3cf345954c6@oracle.com> Updated the webrev to webrev.01 http://cr.openjdk.java.net/~valeriep/8248505/webrev.01/ No changes to source, just test cleanup. Thanks, Valerie On 7/6/2020 12:51 PM, Valerie Peng wrote: > Thanks for taking a look, Sean. > > Agree that we need to get to the root cause for the NSAE which > John at Entrust also observed. One possibility is to file another bug for > Entrust NSAE and deliver more fix later if this current fix for BCFIPS > provider does not resolve Entrust's NSAE. > > Valerie > > On 7/6/2020 12:20 PM, Se?n Coffey wrote: >> Your patch looks ok to me Valerie. I note that John mentions an >> anomaly with your patch - I'm thinking that may need further >> investigation. >> >> regards, >> Sean. >> >> On 06/07/2020 17:33, Valerie Peng wrote: >>> Hi Max, >>> >>> The suggested fix is not much different than the suggested webrev. >>> >>> The essential change is to call getService(...) for the returned >>> service in Provider.getDefaultSecureRandomService(). The only >>> difference here is using the hardcoded type "SecureRandom" vs the >>> one returned by getType() call. Is this what you are referring to? >>> >>> I re-write the rest to store String instead of Service as it may >>> seem strange why the stored Service is not used but re-queried >>> through getService(...). Also, looks cleaner to me this way. >>> >>> Thanks, >>> Valerie >>> On 7/2/2020 9:05 PM, Weijun Wang wrote: >>>> Hi Valerie, >>>> >>>> How about the suggested fix from the bug reporter? >>>> >>>> Thanks, >>>> Max >>>> >>>>> On Jul 3, 2020, at 4:52 AM, Valerie Peng >>>>> wrote: >>>>> >>>>> Hi Max and Sean, >>>>> >>>>> Can you help reviewing this fix for JDK-8248505? This is the >>>>> followup fix for JDK-8246613 "Choose the default SecureRandom algo >>>>> based on registration ordering" which you reviewed earlier. Based >>>>> on the feedback, BCFIPS provider overrides putService/getService() >>>>> calls which does not work well with the fix for JDK-8246613. Thus, >>>>> I adapted to store the SecureRandom algorithm names internally and >>>>> then return the result from getService(...) when >>>>> Provider.getDefaultSecureRandomService() is called. Updated the >>>>> regression test to include a custom provider which simulates the >>>>> BCFIPS provider behavior. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8248505 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8248505/webrev.00/ >>>>> >>>>> Thanks, >>>>> Valerie >>>>> >>>>> From valerie.peng at oracle.com Tue Jul 7 00:01:35 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 6 Jul 2020 17:01:35 -0700 Subject: [EXTERNAL]Re: SecureRandom regression with certain security providers In-Reply-To: <405c49ec-8295-49a2-f7e4-002b393a05c3@oracle.com> References: <2HnXazk66-nxoiS5rxih3yQnqfj2EePRDjdw0P7z8YN4Dr3iqR5WBcHoIM7U8ZIquneZ60ridpBTRPjuYaAmTvTZ11lOT2twH2PlEwzBfm8=@protonmail.com> <85ac45ca-28c7-a17b-57cb-b7f35d1ce731@oracle.com> <8840c02b-cec6-1ef9-4b5d-1649b1d93bba@oracle.com> <684222be-3b19-937e-9066-c53c69474cb8@oracle.com> <405c49ec-8295-49a2-f7e4-002b393a05c3@oracle.com> Message-ID: BTW, I have tentatively filed https://bugs.openjdk.java.net/browse/JDK-8248885 for Entrust NSAE problem. Just FYI. Valerie On 7/6/2020 12:07 PM, Valerie Peng wrote: > > Hi John, > > Thanks for looking into this on your end. It's interesting how Entrust > has to do this deletion/re-insertion of providers and it's interesting > that adding a new instance of Entrust provider inside the > Security.insertProviderAt() call makes this problem go away. > > Please find my questions and comments in line below. > > On 7/3/2020 1:13 PM, John Gray wrote: >> >> Thanks for your comments!? They sparked off a lot more investigation >> on my end.?? I created a test provider and could not reproduce the >> issue.?? That led me to investigate how our provider was being >> installed.?? We use our own internal Initializer() class to install >> providers in various orders (we have had to work around bugs in >> different JVM's in the past).?? That work-around required we remove >> the provider from the Security provider list (basically to clean it >> out), then we run a simple crypto test with a new instantiation, and >> then install that provider in 1st position. >> > Does this Initializer() class does all this before the new > SecureRandom() call? Does the Entrust provider remove or changes its > registrations ever, i.e. is the provider mutable? One possible > scenario for legacy provider which add/remove registrations is that > every update to the legacy map will leads to new re-parsing and new > service being created as a result which may leads to failing the check > inside Service.newInstance() call and thus the NSAE. > >> If I change the highlighted line above (the last line) to the >> following, it works. >> >> Security.insertProviderAt(new Entrust(), 1); >> >> Having to make such a change seems strange.? ??It seems that creating >> a new provider, using it to get an instance of an algorithm, and then >> adding that same provider into first position doesn?t work.?? I'm >> guessing because of the recent changes you made the provider can?t be >> used before it is inserted into the provider order because it may >> hold onto some data from the previous usage??? So this led me to >> investigate some more?.. >> > Yes, it's indeed strange. Is the "entrustCsp" instance being modified > in anyway after its creation? > >> When it fails, the type and algorithm are ?SecureRandom? and >> ?DRBGUsingSHA512? >> > Is ?DRBGUsingSHA512" the expected default algorithm for Entrust > provider? Is it being picked up as expected if basing on registration > ordering? > >> The Provider.getService() code fails to match the ?previousKey? >> ServiceKey type and algorithms. In my test code I was testing an AES >> algorithm, so the previous key type and Algorithm is ?Cipher? and >> ?AES/CBC/PKCS5PADDING? in the getService() call which doesn?t match >> the type ?SecureRandom? and ?DRBGUsingSHA512?.?? So it looks like >> there is a bug caused by holding on to existing data. >> > The previousKey is just an optimization to avoid repetitive allocation > on the same type and algorithm. If either of these two does not match, > it will be discarded and new key object created for subsequent calls. > So, this should not be the root cause. >> >> So I think when I create a brand new Entrust() instance it works >> because the previous ServiceKey() contains the correct data and it >> matches. Debugging showed it to work that way.?? So I think using a >> provider before installing it in the provider order is what is >> causing the issue because of internal data in the Provider class. >> > There is something deeper for the Entrust NSAE problem instead of the > previousKey usage per my comment above. Could you please double check > the Initializer class and whether the Entrust provider entries are > modified after it's constructed and when new SecureRandom() is called? > > Thanks for looking into this~ > > Valerie > >> It looks like I **could** put in this weird work-around (just create >> a fresh instance of Entrust()) when installing the provider to work >> around the issue, but I wonder if there will be other consequences >> because of the way this previousKey is used???? I can make the simple >> change to our toolkit without breaking FIPS (the initialization class >> is not in the FIPS boundary).? ?In fact, I assume I don?t need to >> keep that old work-around for the old IBM JVM anymore either.. >> >> Thanks for your help! >> >> Happy July 4^th ? (I live in Ottawa Canada, so we had our muted >> Canada day celebrations a couple days ago on July 1^st ). >> >> John Gray >> >> -----Original Message----- >> From: Valerie Peng [mailto:valerie.peng at oracle.com] >> Sent: Thursday, July 2, 2020 8:34 PM >> To: John Gray ; >> security-dev at openjdk.java.net >> Cc: John Mahoney ; Muthu Kannappan >> >> Subject: Re: [EXTERNAL]Re: SecureRandom regression with certain >> security providers >> >> Hi John, >> >> Unfortunately this cannot wait til July 13th if this issue needs to >> be fixed for jdk 15. >> >> Maybe you can try the webrev out or share more details on how Entrust >> provider does its registration and what Provider APIs it overrides. I >> need more info to help identifying the trigger for the NSAE in >> Entrust's case. I have verified that the current webrev works with >> BCFIPS provider. >> >> Regards and an early happy July 4th, >> >> Valerie >> >> On 7/2/2020 3:17 PM, Valerie Peng wrote: >> >> > I can certainly help you verify the fix.?? Let me know how I can help >> >> > verify it for you. ?? >> >> > >> >> > Note:?? I will be on vacation next week, so I'll be back July 13th... >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Tue Jul 7 01:14:26 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 6 Jul 2020 18:14:26 -0700 Subject: [EXTERNAL]Re: SecureRandom regression with certain security providers In-Reply-To: References: <2HnXazk66-nxoiS5rxih3yQnqfj2EePRDjdw0P7z8YN4Dr3iqR5WBcHoIM7U8ZIquneZ60ridpBTRPjuYaAmTvTZ11lOT2twH2PlEwzBfm8=@protonmail.com> <85ac45ca-28c7-a17b-57cb-b7f35d1ce731@oracle.com> <8840c02b-cec6-1ef9-4b5d-1649b1d93bba@oracle.com> <684222be-3b19-937e-9066-c53c69474cb8@oracle.com> <405c49ec-8295-49a2-f7e4-002b393a05c3@oracle.com> Message-ID: Ok, thank you John. Valerie On 7/6/2020 5:55 PM, John Mahoney wrote: > > Thank you Valerie.? Unfortunately this will have to wait until John is > back from vacation (back on the 13^th ) > > *From:*Valerie Peng [mailto:valerie.peng at oracle.com] > *Sent:* Monday, July 6, 2020 8:02 PM > *To:* John Gray ; > security-dev at openjdk.java.net > *Cc:* John Mahoney > *Subject:* Re: [EXTERNAL]Re: SecureRandom regression with certain > security providers > > BTW, I have tentatively filed > https://bugs.openjdk.java.net/browse/JDK-8248885 > for Entrust NSAE > problem. Just FYI. > > Valerie > > On 7/6/2020 12:07 PM, Valerie Peng wrote: > > Hi John, > > Thanks for looking into this on your end. It's interesting how > Entrust has to do this deletion/re-insertion of providers and it's > interesting that adding a new instance of Entrust provider inside > the Security.insertProviderAt() call makes this problem go away. > > Please find my questions and comments in line below. > > On 7/3/2020 1:13 PM, John Gray wrote: > > Thanks for your comments!? They sparked off a lot more > investigation on my end.?? I created a test provider and could > not reproduce the issue.?? That led me to investigate how our > provider was being installed.?? We use our own internal > Initializer() class to install providers in various orders (we > have had to work around bugs in different JVM's in the > past).?? That work-around required we remove the provider from > the Security provider list (basically to clean it out), then > we run a simple crypto test with a new instantiation, and then > install that provider in 1st position. > > Does this Initializer() class does all this before the new > SecureRandom() call? Does the Entrust provider remove or changes > its registrations ever, i.e. is the provider mutable? One possible > scenario for legacy provider which add/remove registrations is > that every update to the legacy map will leads to new re-parsing > and new service being created as a result which may leads to > failing the check inside Service.newInstance() call and thus the NSAE. > > If I change the highlighted line above (the last line) to the > following, it works. > > Security.insertProviderAt(new Entrust(), 1); > > Having to make such a change seems strange.? ??It seems that > creating a new provider, using it to get an instance of an > algorithm, and then adding that same provider into first > position doesn?t work. I'm guessing because of the recent > changes you made the provider can?t be used before it is > inserted into the provider order because it may hold onto some > data from the previous usage??? So this led me to investigate > some more?.. > > Yes, it's indeed strange. Is the "entrustCsp" instance being > modified in anyway after its creation? > > When it fails, the type and algorithm are ?SecureRandom? and > ?DRBGUsingSHA512? > > Is ?DRBGUsingSHA512" the expected default algorithm for Entrust > provider? Is it being picked up as expected if basing on > registration ordering? > > The Provider.getService() code fails to match the > ?previousKey? ServiceKey type and algorithms.?? In my test > code I was testing an AES algorithm, so the previous key type > and Algorithm is ?Cipher? and ?AES/CBC/PKCS5PADDING? in the > getService() call which doesn?t match the type ?SecureRandom? > and ?DRBGUsingSHA512?.?? So it looks like there is a bug > caused by holding on to existing data. > > The previousKey is just an optimization to avoid repetitive > allocation on the same type and algorithm. If either of these two > does not match, it will be discarded and new key object created > for subsequent calls. So, this should not be the root cause. > > So I think when I create a brand new Entrust() instance it > works because the previous ServiceKey() contains the correct > data and it matches. Debugging showed it to work that way.?? > So I think using a provider before installing it in the > provider order is what is causing the issue because of > internal data in the Provider class. > > There is something deeper for the Entrust NSAE problem instead of > the previousKey usage per my comment above. Could you please > double check the Initializer class and whether the Entrust > provider entries are modified after it's constructed and when new > SecureRandom() is called? > > Thanks for looking into this~ > > Valerie > > It looks like I **could** put in this weird work-around (just > create a fresh instance of Entrust()) when installing the > provider to work around the issue, but I wonder if there will > be other consequences because of the way this previousKey is > used???? I can make the simple change to our toolkit without > breaking FIPS (the initialization class is not in the FIPS > boundary).? ?In fact, I assume I don?t need to keep that old > work-around for the old IBM JVM anymore either.. > > Thanks for your help! > > Happy July 4^th ? (I live in Ottawa Canada, so we had our > muted Canada day celebrations a couple days ago on July 1^st ). > > John Gray > > -----Original Message----- > From: Valerie Peng [mailto:valerie.peng at oracle.com] > Sent: Thursday, July 2, 2020 8:34 PM > To: John Gray > ; > security-dev at openjdk.java.net > > Cc: John Mahoney > ; Muthu Kannappan > > Subject: Re: [EXTERNAL]Re: SecureRandom regression with > certain security providers > > Hi John, > > Unfortunately this cannot wait til July 13th if this issue > needs to be fixed for jdk 15. > > Maybe you can try the webrev out or share more details on how > Entrust provider does its registration and what Provider APIs > it overrides. I need more info to help identifying the trigger > for the NSAE in Entrust's case. I have verified that the > current webrev works with BCFIPS provider. > > Regards and an early happy July 4th, > > Valerie > > On 7/2/2020 3:17 PM, Valerie Peng wrote: > > > I can certainly help you verify the fix.?? Let me know how I > can help > > > verify it for you. ?? > > > > > > Note:?? I will be on vacation next week, so I'll be back > July 13th... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Jul 7 10:44:58 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 7 Jul 2020 18:44:58 +0800 Subject: RFR[15] 8248505: Unexpected NoSuchAlgorithmException when using secure random impl from BCFIPS provider In-Reply-To: References: <2a4a0b62-b6ab-85c0-c47a-6fe7aea87c5f@oracle.com> Message-ID: <1513189C-886D-44D0-B707-EAD46FC9876A@oracle.com> > On Jul 7, 2020, at 12:33 AM, Valerie Peng wrote: > > Hi Max, > > The suggested fix is not much different than the suggested webrev. I understand they are mostly the same. > > The essential change is to call getService(...) for the returned service in Provider.getDefaultSecureRandomService(). The only difference here is using the hardcoded type "SecureRandom" vs the one returned by getType() call. Is this what you are referring to? That's not a problem. > > I re-write the rest to store String instead of Service as it may seem strange why the stored Service is not used but re-queried through getService(...). Also, looks cleaner to me this way. It's good if you like it. I was thinking that the Service object is already there (in parseLegacyPut and implRemoveService) and it's simpler to store them in the map, and maybe later you can detect whether that Service is registered and decide if you can simply return it or a create a new one by calling getService(). Thanks, Max > > Thanks, > Valerie > On 7/2/2020 9:05 PM, Weijun Wang wrote: >> Hi Valerie, >> >> How about the suggested fix from the bug reporter? >> >> Thanks, >> Max >> >>> On Jul 3, 2020, at 4:52 AM, Valerie Peng wrote: >>> >>> Hi Max and Sean, >>> >>> Can you help reviewing this fix for JDK-8248505? This is the followup fix for JDK-8246613 "Choose the default SecureRandom algo based on registration ordering" which you reviewed earlier. Based on the feedback, BCFIPS provider overrides putService/getService() calls which does not work well with the fix for JDK-8246613. Thus, I adapted to store the SecureRandom algorithm names internally and then return the result from getService(...) when Provider.getDefaultSecureRandomService() is called. Updated the regression test to include a custom provider which simulates the BCFIPS provider behavior. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8248505 >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8248505/webrev.00/ >>> >>> Thanks, >>> Valerie >>> >>> From valerie.peng at oracle.com Tue Jul 7 15:53:20 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 7 Jul 2020 08:53:20 -0700 Subject: RFR[15] 8248505: Unexpected NoSuchAlgorithmException when using secure random impl from BCFIPS provider In-Reply-To: <1513189C-886D-44D0-B707-EAD46FC9876A@oracle.com> References: <2a4a0b62-b6ab-85c0-c47a-6fe7aea87c5f@oracle.com> <1513189C-886D-44D0-B707-EAD46FC9876A@oracle.com> Message-ID: <79d3bd2c-824f-8e2c-62ea-03a80d6af4b9@oracle.com> Hi Max, Thanks for your review. Algorithm is also there, so both work technically. With existing APIs, the only way to check for service registration is to call getService(...) and check for ==. If there were another way to check service registration, then it makes sense to store Service object. Valerie On 7/7/2020 3:44 AM, Weijun Wang wrote: >> On Jul 7, 2020, at 12:33 AM, Valerie Peng wrote: >> >> Hi Max, >> >> The suggested fix is not much different than the suggested webrev. > I understand they are mostly the same. > >> The essential change is to call getService(...) for the returned service in Provider.getDefaultSecureRandomService(). The only difference here is using the hardcoded type "SecureRandom" vs the one returned by getType() call. Is this what you are referring to? > That's not a problem. > >> I re-write the rest to store String instead of Service as it may seem strange why the stored Service is not used but re-queried through getService(...). Also, looks cleaner to me this way. > It's good if you like it. I was thinking that the Service object is already there (in parseLegacyPut and implRemoveService) and it's simpler to store them in the map, and maybe later you can detect whether that Service is registered and decide if you can simply return it or a create a new one by calling getService(). > > Thanks, > Max > >> Thanks, >> Valerie >> On 7/2/2020 9:05 PM, Weijun Wang wrote: >>> Hi Valerie, >>> >>> How about the suggested fix from the bug reporter? >>> >>> Thanks, >>> Max >>> >>>> On Jul 3, 2020, at 4:52 AM, Valerie Peng wrote: >>>> >>>> Hi Max and Sean, >>>> >>>> Can you help reviewing this fix for JDK-8248505? This is the followup fix for JDK-8246613 "Choose the default SecureRandom algo based on registration ordering" which you reviewed earlier. Based on the feedback, BCFIPS provider overrides putService/getService() calls which does not work well with the fix for JDK-8246613. Thus, I adapted to store the SecureRandom algorithm names internally and then return the result from getService(...) when Provider.getDefaultSecureRandomService() is called. Updated the regression test to include a custom provider which simulates the BCFIPS provider behavior. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8248505 >>>> >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8248505/webrev.00/ >>>> >>>> Thanks, >>>> Valerie >>>> >>>> From weijun.wang at oracle.com Tue Jul 7 16:00:12 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 8 Jul 2020 00:00:12 +0800 Subject: RFR[15] 8248505: Unexpected NoSuchAlgorithmException when using secure random impl from BCFIPS provider In-Reply-To: <79d3bd2c-824f-8e2c-62ea-03a80d6af4b9@oracle.com> References: <2a4a0b62-b6ab-85c0-c47a-6fe7aea87c5f@oracle.com> <1513189C-886D-44D0-B707-EAD46FC9876A@oracle.com> <79d3bd2c-824f-8e2c-62ea-03a80d6af4b9@oracle.com> Message-ID: <3FE6C811-3C07-42DB-BDE9-672481675393@oracle.com> I see. No more comment. --Max > On Jul 7, 2020, at 11:53 PM, Valerie Peng wrote: > > Hi Max, > > Thanks for your review. > > Algorithm is also there, so both work technically. With existing APIs, the only way to check for service registration is to call getService(...) and check for ==. If there were another way to check service registration, then it makes sense to store Service object. > > Valerie > > On 7/7/2020 3:44 AM, Weijun Wang wrote: >>> On Jul 7, 2020, at 12:33 AM, Valerie Peng wrote: >>> >>> Hi Max, >>> >>> The suggested fix is not much different than the suggested webrev. >> I understand they are mostly the same. >> >>> The essential change is to call getService(...) for the returned service in Provider.getDefaultSecureRandomService(). The only difference here is using the hardcoded type "SecureRandom" vs the one returned by getType() call. Is this what you are referring to? >> That's not a problem. >> >>> I re-write the rest to store String instead of Service as it may seem strange why the stored Service is not used but re-queried through getService(...). Also, looks cleaner to me this way. >> It's good if you like it. I was thinking that the Service object is already there (in parseLegacyPut and implRemoveService) and it's simpler to store them in the map, and maybe later you can detect whether that Service is registered and decide if you can simply return it or a create a new one by calling getService(). >> >> Thanks, >> Max >> >>> Thanks, >>> Valerie >>> On 7/2/2020 9:05 PM, Weijun Wang wrote: >>>> Hi Valerie, >>>> >>>> How about the suggested fix from the bug reporter? >>>> >>>> Thanks, >>>> Max >>>> >>>>> On Jul 3, 2020, at 4:52 AM, Valerie Peng wrote: >>>>> >>>>> Hi Max and Sean, >>>>> >>>>> Can you help reviewing this fix for JDK-8248505? This is the followup fix for JDK-8246613 "Choose the default SecureRandom algo based on registration ordering" which you reviewed earlier. Based on the feedback, BCFIPS provider overrides putService/getService() calls which does not work well with the fix for JDK-8246613. Thus, I adapted to store the SecureRandom algorithm names internally and then return the result from getService(...) when Provider.getDefaultSecureRandomService() is called. Updated the regression test to include a custom provider which simulates the BCFIPS provider behavior. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8248505 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8248505/webrev.00/ >>>>> >>>>> Thanks, >>>>> Valerie >>>>> >>>>> From valerie.peng at oracle.com Tue Jul 7 16:16:13 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 7 Jul 2020 09:16:13 -0700 Subject: RFR[15] 8248505: Unexpected NoSuchAlgorithmException when using secure random impl from BCFIPS provider In-Reply-To: <3FE6C811-3C07-42DB-BDE9-672481675393@oracle.com> References: <2a4a0b62-b6ab-85c0-c47a-6fe7aea87c5f@oracle.com> <1513189C-886D-44D0-B707-EAD46FC9876A@oracle.com> <79d3bd2c-824f-8e2c-62ea-03a80d6af4b9@oracle.com> <3FE6C811-3C07-42DB-BDE9-672481675393@oracle.com> Message-ID: Thanks! Valerie On 7/7/2020 9:00 AM, Weijun Wang wrote: > I see. No more comment. > > --Max > >> On Jul 7, 2020, at 11:53 PM, Valerie Peng wrote: >> >> Hi Max, >> >> Thanks for your review. >> >> Algorithm is also there, so both work technically. With existing APIs, the only way to check for service registration is to call getService(...) and check for ==. If there were another way to check service registration, then it makes sense to store Service object. >> >> Valerie >> >> On 7/7/2020 3:44 AM, Weijun Wang wrote: >>>> On Jul 7, 2020, at 12:33 AM, Valerie Peng wrote: >>>> >>>> Hi Max, >>>> >>>> The suggested fix is not much different than the suggested webrev. >>> I understand they are mostly the same. >>> >>>> The essential change is to call getService(...) for the returned service in Provider.getDefaultSecureRandomService(). The only difference here is using the hardcoded type "SecureRandom" vs the one returned by getType() call. Is this what you are referring to? >>> That's not a problem. >>> >>>> I re-write the rest to store String instead of Service as it may seem strange why the stored Service is not used but re-queried through getService(...). Also, looks cleaner to me this way. >>> It's good if you like it. I was thinking that the Service object is already there (in parseLegacyPut and implRemoveService) and it's simpler to store them in the map, and maybe later you can detect whether that Service is registered and decide if you can simply return it or a create a new one by calling getService(). >>> >>> Thanks, >>> Max >>> >>>> Thanks, >>>> Valerie >>>> On 7/2/2020 9:05 PM, Weijun Wang wrote: >>>>> Hi Valerie, >>>>> >>>>> How about the suggested fix from the bug reporter? >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>>> On Jul 3, 2020, at 4:52 AM, Valerie Peng wrote: >>>>>> >>>>>> Hi Max and Sean, >>>>>> >>>>>> Can you help reviewing this fix for JDK-8248505? This is the followup fix for JDK-8246613 "Choose the default SecureRandom algo based on registration ordering" which you reviewed earlier. Based on the feedback, BCFIPS provider overrides putService/getService() calls which does not work well with the fix for JDK-8246613. Thus, I adapted to store the SecureRandom algorithm names internally and then return the result from getService(...) when Provider.getDefaultSecureRandomService() is called. Updated the regression test to include a custom provider which simulates the BCFIPS provider behavior. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8248505 >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8248505/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> Valerie >>>>>> >>>>>> From alexey at azul.com Tue Jul 7 16:29:06 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 7 Jul 2020 16:29:06 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com> References: <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com> <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com> <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com> <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com> <2267CBC7-85A9-4105-B405-E7499440B985@azul.com> <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com> <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com> <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com> Message-ID: Hello Sean, Thank you for review. You are right, we can eliminate requirements for connection timeout property. I?ve added handshakeComletedListener to the LDAP over SSl. In this case we?ll have no possible performance impact caused by synchronous handshake. Also, it allows to exclude changes in the LdapCtx class. Updated webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v12/ Regards Alexey > On 7 Jul 2020, at 02:30, Sean Mullan wrote: > > Thanks for that extra info. > > I think it would be much cleaner to avoid having to set that property and instead start the handshake synchronously if the "com.sun.jndi.ldap.tls.cbtype" property is set. This way only one property needs to be set and you don't need to guess what an acceptable value is for the timeout property, which could also cause the connection to be interrupted before the TLS handshake is complete if you use too small of a value. > > Or better yet, there may be another way to do this with JSSE where you wait for the TLS connection to complete. I'll ask my team and get back to you. > > --Sean > > > On 7/6/20 6:06 PM, Aleks Efimov wrote: >> Hi Sean, >> Alexey answered the same question for me: >>> I mean ?com.sun.jndi.ldap.connect.timeout? property. >>> The positive value forces to start TLS handshake and wait for it completion during the connectTimeout milliseconds: >>> Connection.java >>>>> if (connectTimeout > 0) { >>>>> int socketTimeout = sslSocket.getSoTimeout(); >>>>> sslSocket.setSoTimeout(connectTimeout); // reuse full timeout value >>>>> sslSocket.startHandshake(); >>>>> sslSocket.setSoTimeout(socketTimeout); >>>>> } >>> Without this property handshake is started later asynchronously. >>> As result >>>>> certs = ssock.getSession().getPeerCertificates(); >>> in the LdapClient.java could return SSLPeerUnverifiedException(). >>> This exception will be wrapped to NamingException and thrown to application. >>> >>> This is not usually happens but I saw it on the slow connection >> The full context of LDAP Connection code that initiates the SSL handshake could be viewed here: >> https://github.com/openjdk/jdk/blob/master/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L345 >> -- Aleksei >> On 06/07/2020 21:11, Sean Mullan wrote: >>> Hi Alexey, >>> >>> This may have been discussed already, but can you explain why the "com.sun.jndi.ldap.connect.timeout" property needs to be set in order to use this feature? That property is mostly used in tests to avoid long socket timeouts, etc. >>> >>> Why does that need to be set? What problem are you trying to solve? >>> >>> --Sean >>> >>> >>> On 7/3/20 11:31 AM, Alexey Bakhtin wrote: >>>> >>>>> I would suggest removing it. At least for the SASL GSS-API mech, it seems the GSSContext object will not be leaked and no one has a chance to call setChannelBinding again on it. >>>>> >>>>> There is no spec saying setChannelBinding() can only be called once, so I'd rather we don't enforce that, although you might say there is no need to call it twice. >>>> >>>> OK. >>>> GSSContextImpl class is removed from patch. >>>> >>>> Webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v11 >>>> >>>> Thank you >>>> Alexey >>>> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From anthony.scarpino at oracle.com Wed Jul 8 00:01:13 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 7 Jul 2020 17:01:13 -0700 Subject: [RFR] 8246806: Incorrect copyright header in KeyAgreementTest.java, GroupName.java Message-ID: <2ada2fa8-761a-63a5-d60a-331b8cfba2bf@oracle.com> Hi, I need a code review to fix some copyright headers. The diffs are below thanks Tony ------ +++ b/test/jdk/java/security/KeyAgreement/KeyAgreementTest.java - * Copyright (c) 2018, 2020 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights reserved. +++ b/test/jdk/sun/security/tools/keytool/GroupName.java - * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights reserved. From hai-may.chao at oracle.com Wed Jul 8 00:56:59 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Tue, 7 Jul 2020 17:56:59 -0700 Subject: [RFR] 8246806: Incorrect copyright header in KeyAgreementTest.java, GroupName.java In-Reply-To: <2ada2fa8-761a-63a5-d60a-331b8cfba2bf@oracle.com> References: <2ada2fa8-761a-63a5-d60a-331b8cfba2bf@oracle.com> Message-ID: <09CCFC0E-C60F-49AC-9DAD-7EC47F03875F@oracle.com> Hi Tony, Looks good. Hai-May > On Jul 7, 2020, at 5:01 PM, Anthony Scarpino wrote: > > Hi, > > I need a code review to fix some copyright headers. The diffs are below > > thanks > > Tony > > ------ > > +++ b/test/jdk/java/security/KeyAgreement/KeyAgreementTest.java > - * Copyright (c) 2018, 2020 Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights reserved. > > > +++ b/test/jdk/sun/security/tools/keytool/GroupName.java > - * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights reserved. > From weijun.wang at oracle.com Wed Jul 8 01:48:03 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 8 Jul 2020 09:48:03 +0800 Subject: [RFR] 8246806: Incorrect copyright header in KeyAgreementTest.java, GroupName.java In-Reply-To: <09CCFC0E-C60F-49AC-9DAD-7EC47F03875F@oracle.com> References: <2ada2fa8-761a-63a5-d60a-331b8cfba2bf@oracle.com> <09CCFC0E-C60F-49AC-9DAD-7EC47F03875F@oracle.com> Message-ID: <3D133662-0062-485C-82DA-59F3D5C20C76@oracle.com> +1 Thanks, Max > On Jul 8, 2020, at 8:56 AM, Hai-May Chao wrote: > > Hi Tony, > > Looks good. > > Hai-May > > >> On Jul 7, 2020, at 5:01 PM, Anthony Scarpino wrote: >> >> Hi, >> >> I need a code review to fix some copyright headers. The diffs are below >> >> thanks >> >> Tony >> >> ------ >> >> +++ b/test/jdk/java/security/KeyAgreement/KeyAgreementTest.java >> - * Copyright (c) 2018, 2020 Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights reserved. >> >> >> +++ b/test/jdk/sun/security/tools/keytool/GroupName.java >> - * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights reserved. >> > From daniel.fuchs at oracle.com Wed Jul 8 09:09:26 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 8 Jul 2020 10:09:26 +0100 Subject: Browser's accepting certificates that Java does not In-Reply-To: <46a3a1a636dc4d4dab9958d294aee83d@MailCorp01.ocie.net> References: <46a3a1a636dc4d4dab9958d294aee83d@MailCorp01.ocie.net> Message-ID: Hi Mark, This is probably a question for the security-dev mailing list, which I have put in the to: of my reply. best regards, -- daniel On 07/07/2020 20:24, Mark A. Claassen wrote: > I was curious if there has been any thought to allowing accessing to other certificate stores in Windows besides the "Trusted Root Certification Authorities" and the "Personal" ones. It seems like web servers omitting intermediate certificates in the certificate chain is pretty common. Browsers seems to fill in the gaps, but Java does not. > > We very recently encountered this again when a customer started proxying their SSL requests, creating a new certificate on the fly, resigning ours with their corporate CA. (The browser handled this fine, but our Java app detected a chain length of 2, instead of 4 like in the browser.) Having them put their intermediate certificates in the "Trusted Root Certification Authorities" solved the issue, but they are unwilling to do this on a corporate-wide basis. > > If Java was able to access more keystores through the MSCAPI interface, is seems like it would fill in the gaps as well and remove a pain point we are experiencing where Java does not accept a certificate even though all their browsers will. I think all intermediate certificates are supposed to be in the chain sent from the server (https://tools.ietf.org/html/rfc5246) in the TLS negotiation, but since browser's don't enforce care, people are left thinking everything is great (until Java tries to connect). > > Thanks, > > Mark Claassen > Senior Software Engineer > > Donnell Systems, Inc. > 130 South Main Street > Leighton Plaza Suite 375 > South Bend, IN? 46601 > E-mail: mailto:mclaassen at ocie.net > Voice: (574)232-3784 > Fax: (574)232-4014 > > Disclaimer: > The opinions provided herein do not necessarily state or reflect > those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and > assumes no legal liability or responsibility for the posting. > From ecki at zusammenkunft.net Wed Jul 8 09:27:42 2020 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 8 Jul 2020 09:27:42 +0000 Subject: Browser's accepting certificates that Java does not In-Reply-To: References: <46a3a1a636dc4d4dab9958d294aee83d@MailCorp01.ocie.net>, Message-ID: Note that many browsers also download certs from the AIA and even "well known" mechanisms. It won't help to access more truststores, that would be a function you need to prove directly. Also the dynamic installation from Windows Updates or offline from crypt32.dll is not triggered when only browsing the existing stores. If you need that kind of integration it's probably better do not use java :) Chrome does install those dynamically loaded intermiates to Windows truststores, I think - it would not hurt to get access to it. -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Daniel Fuchs Gesendet: Wednesday, July 8, 2020 11:09:26 AM An: Mark A. Claassen ; OpenJDK Cc: net-dev at openjdk.java.net Betreff: Re: Browser's accepting certificates that Java does not Hi Mark, This is probably a question for the security-dev mailing list, which I have put in the to: of my reply. best regards, -- daniel On 07/07/2020 20:24, Mark A. Claassen wrote: > I was curious if there has been any thought to allowing accessing to other certificate stores in Windows besides the "Trusted Root Certification Authorities" and the "Personal" ones. It seems like web servers omitting intermediate certificates in the certificate chain is pretty common. Browsers seems to fill in the gaps, but Java does not. > > We very recently encountered this again when a customer started proxying their SSL requests, creating a new certificate on the fly, resigning ours with their corporate CA. (The browser handled this fine, but our Java app detected a chain length of 2, instead of 4 like in the browser.) Having them put their intermediate certificates in the "Trusted Root Certification Authorities" solved the issue, but they are unwilling to do this on a corporate-wide basis. > > If Java was able to access more keystores through the MSCAPI interface, is seems like it would fill in the gaps as well and remove a pain point we are experiencing where Java does not accept a certificate even though all their browsers will. I think all intermediate certificates are supposed to be in the chain sent from the server (https://tools.ietf.org/html/rfc5246) in the TLS negotiation, but since browser's don't enforce care, people are left thinking everything is great (until Java tries to connect). > > Thanks, > > Mark Claassen > Senior Software Engineer > > Donnell Systems, Inc. > 130 South Main Street > Leighton Plaza Suite 375 > South Bend, IN 46601 > E-mail: mailto:mclaassen at ocie.net > Voice: (574)232-3784 > Fax: (574)232-4014 > > Disclaimer: > The opinions provided herein do not necessarily state or reflect > those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and > assumes no legal liability or responsibility for the posting. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Jul 8 12:25:08 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 8 Jul 2020 08:25:08 -0400 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com> <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com> <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com> <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com> <2267CBC7-85A9-4105-B405-E7499440B985@azul.com> <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com> <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com> <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com> Message-ID: <643f3744-cfa2-e871-1284-900d81709f53@oracle.com> On 7/7/20 12:29 PM, Alexey Bakhtin wrote: > Hello Sean, > > Thank you for review. > You are right, we can eliminate requirements for connection timeout property. I?ve added handshakeComletedListener to the LDAP over SSl. In this case we?ll have no possible performance impact caused by synchronous handshake. Great! And one less property to set too. > Also, it allows to exclude changes in the LdapCtx class. > > Updated webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v12/ You will also need to update the CSR to remove the connection timeout property. Also, you should document the "com.sun.jndi.ldap.tls.cbtype" property in the java.naming module-info file as was done for other properties in Daniel's recent RFR, once he has pushed it [1]. * src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java It looks like there is a possibility of deadlock if getTlsServerCertificate() is called before handshakeCompleted(). In that case the lock could be obtained first and the thread would end up holding the lock and waiting forever. Here are a few other mostly minor comments on the code: * src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java 61 * Channel binding on the base of TLS Finished message I think you mean to say "basis", not "base". Same comment on line 65. 87 throw new NamingException( "Channel binding type " + Remove extra space before "Channel. 114 * Construct tls-server-point-point Channel Binding data Typo: "point-point" -> "end-point". * src/java.security.jgss/share/classes/sun/security/jgss/krb5/InitialToken.java 380 // LDAP TLS Channel Binding requires CHANNEL_BINDING_AF_UNSPEC address type 381 // for unspecified initiator and acceptor addresses 382 // CHANNEL_BINDING_AF_NULL_ADDR value should be used for unspecified address 383 // in all other cases This would read better if there were periods at the end of each sentence on lines 381 and 383. The same comment applies to the comment block on lines 207-210 in src/java.security.jgss/share/native/libj2gss/GSSLibStub.c --Sean [1] https://mail.openjdk.java.net/pipermail/net-dev/2020-July/014148.html > > Regards > Alexey > >> On 7 Jul 2020, at 02:30, Sean Mullan wrote: >> >> Thanks for that extra info. >> >> I think it would be much cleaner to avoid having to set that property and instead start the handshake synchronously if the "com.sun.jndi.ldap.tls.cbtype" property is set. This way only one property needs to be set and you don't need to guess what an acceptable value is for the timeout property, which could also cause the connection to be interrupted before the TLS handshake is complete if you use too small of a value. >> >> Or better yet, there may be another way to do this with JSSE where you wait for the TLS connection to complete. I'll ask my team and get back to you. >> >> --Sean >> >> >> On 7/6/20 6:06 PM, Aleks Efimov wrote: >>> Hi Sean, >>> Alexey answered the same question for me: >>>> I mean ?com.sun.jndi.ldap.connect.timeout? property. >>>> The positive value forces to start TLS handshake and wait for it completion during the connectTimeout milliseconds: >>>> Connection.java >>>>>> if (connectTimeout > 0) { >>>>>> int socketTimeout = sslSocket.getSoTimeout(); >>>>>> sslSocket.setSoTimeout(connectTimeout); // reuse full timeout value >>>>>> sslSocket.startHandshake(); >>>>>> sslSocket.setSoTimeout(socketTimeout); >>>>>> } >>>> Without this property handshake is started later asynchronously. >>>> As result >>>>>> certs = ssock.getSession().getPeerCertificates(); >>>> in the LdapClient.java could return SSLPeerUnverifiedException(). >>>> This exception will be wrapped to NamingException and thrown to application. >>>> >>>> This is not usually happens but I saw it on the slow connection >>> The full context of LDAP Connection code that initiates the SSL handshake could be viewed here: >>> https://github.com/openjdk/jdk/blob/master/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L345 >>> -- Aleksei >>> On 06/07/2020 21:11, Sean Mullan wrote: >>>> Hi Alexey, >>>> >>>> This may have been discussed already, but can you explain why the "com.sun.jndi.ldap.connect.timeout" property needs to be set in order to use this feature? That property is mostly used in tests to avoid long socket timeouts, etc. >>>> >>>> Why does that need to be set? What problem are you trying to solve? >>>> >>>> --Sean >>>> >>>> >>>> On 7/3/20 11:31 AM, Alexey Bakhtin wrote: >>>>> >>>>>> I would suggest removing it. At least for the SASL GSS-API mech, it seems the GSSContext object will not be leaked and no one has a chance to call setChannelBinding again on it. >>>>>> >>>>>> There is no spec saying setChannelBinding() can only be called once, so I'd rather we don't enforce that, although you might say there is no need to call it twice. >>>>> >>>>> OK. >>>>> GSSContextImpl class is removed from patch. >>>>> >>>>> Webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v11 >>>>> >>>>> Thank you >>>>> Alexey >>>>> > From sean.mullan at oracle.com Wed Jul 8 13:38:25 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 8 Jul 2020 09:38:25 -0400 Subject: Browser's accepting certificates that Java does not In-Reply-To: References: <46a3a1a636dc4d4dab9958d294aee83d@MailCorp01.ocie.net> Message-ID: <1bbd048b-5530-c187-d313-e3a811217957@oracle.com> Also, in case you did not know, the JDK "PKIX" CertPathBuilder implementation (which is also the default used by the JSSE TrustManager) supports retrieving certificates via the AIA extension, but it is disabled by default. To enable it, set the "com.sun.security.enableAIAcaIssuers" system property to the value "true". --Sean On 7/8/20 5:27 AM, Bernd Eckenfels wrote: > Note that many browsers also download certs from the AIA and even "well > known" mechanisms. It won't help to access more truststores, that would > be a function you need to prove directly. Also the dynamic installation > from Windows Updates or offline from crypt32.dll is not triggered when > only browsing the existing stores. > > If you need that kind of integration it's probably better do not use java :) > > Chrome does install those dynamically loaded intermiates to Windows > truststores, I think - it would not hurt to get access to it. > > > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > *Von:* security-dev im Auftrag von > Daniel Fuchs > *Gesendet:* Wednesday, July 8, 2020 11:09:26 AM > *An:* Mark A. Claassen ; OpenJDK > > *Cc:* net-dev at openjdk.java.net > *Betreff:* Re: Browser's accepting certificates that Java does not > Hi Mark, > > This is probably a question for the security-dev mailing list, which > I have put in the to: of my reply. > > best regards, > > -- daniel > > On 07/07/2020 20:24, Mark A. Claassen wrote: >> I was curious if there has been any thought to allowing accessing to other certificate stores in Windows besides the "Trusted Root Certification Authorities" and the "Personal" ones.? It seems like web servers omitting intermediate certificates in the certificate chain is pretty common.? Browsers seems to fill in the gaps, but Java > does not. >> >> We very recently encountered this again when a customer started proxying their SSL requests, creating a new certificate on the fly, resigning ours with their corporate CA.? (The browser handled this fine, but our Java app detected a chain length of 2, instead of 4 like in the browser.)? Having them put their intermediate > certificates in the "Trusted Root Certification Authorities" solved the > issue, but they are unwilling to do this on a corporate-wide basis. >> >> If Java was able to access more keystores through the MSCAPI interface, is seems like it would fill in the gaps as well and remove a pain point we are experiencing where Java does not accept a certificate even though all their browsers will.? I think all intermediate certificates are supposed to be in the chain sent from > the server (https://tools.ietf.org/html/rfc5246) in the TLS negotiation, > but since browser's don't enforce care, people are left thinking > everything is great (until Java tries to connect). >> >> Thanks, >> >> Mark Claassen >> Senior Software Engineer >> >> Donnell Systems, Inc. >> 130 South Main Street >> Leighton Plaza Suite 375 >> South Bend, IN? 46601 >> E-mail: mailto:mclaassen at ocie.net >> Voice: (574)232-3784 >> Fax: (574)232-4014 >> >> Disclaimer: >> The opinions provided herein do not necessarily state or reflect >> those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and >> assumes no legal liability or responsibility for the posting. >> > From daniel.fuchs at oracle.com Wed Jul 8 14:41:22 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 8 Jul 2020 15:41:22 +0100 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <643f3744-cfa2-e871-1284-900d81709f53@oracle.com> References: <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com> <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com> <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com> <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com> <2267CBC7-85A9-4105-B405-E7499440B985@azul.com> <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com> <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com> <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com> <643f3744-cfa2-e871-1284-900d81709f53@oracle.com> Message-ID: <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com> Thanks Sean, Alexey, On 08/07/2020 13:25, Sean Mullan wrote: >> Updated webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v12/ > > You will also need to update the CSR to remove the connection timeout > property. > > Also, you should document the "com.sun.jndi.ldap.tls.cbtype" property in > the java.naming module-info file as was done for other properties in > Daniel's recent RFR, once he has pushed it [1]. I have pushed the fix: https://hg.openjdk.java.net/jdk/jdk/rev/ed375ae6c779 Alexey, you should now be able to document your new "com.sun.jndi.ldap.tls.cbtype" property in that @implNote as well, and update your CSR consequently. > > * src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java > > It looks like there is a possibility of deadlock if > getTlsServerCertificate() is called before handshakeCompleted(). In that > case the lock could be obtained first and the thread would end up > holding the lock and waiting forever. I also have a concern with the use of wait/notify in that code. I would suggest prototyping using a CompletableFuture instead (or can new certificates be exchanged later on the same connection?) CompletableFuture would allow you to relay and propagate any exception raised in the callback handler as well, and would avoid running into deadlocks. best regards, -- daniel From sean.mullan at oracle.com Wed Jul 8 18:46:21 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 8 Jul 2020 14:46:21 -0400 Subject: RFR 8243592: Subject$SecureSet::contains(null) is suboptimal In-Reply-To: <8B5D455B-0FBF-4C17-8FAD-55465F162AE2@oracle.com> References: <45F36569-C6F0-4827-ACF4-6A7B69890559@oracle.com> <40F07BEA-6C60-4D80-B1C1-86402FD67E57@oracle.com> <1dfd1e84-d1ea-6162-970e-f061373e8fa7@oracle.com> <1cb283c7-2047-bbd1-05a2-c852b19f67f8@oracle.com> <8B5D455B-0FBF-4C17-8FAD-55465F162AE2@oracle.com> Message-ID: <05fcd949-8245-b56b-38f6-d3e664560148@oracle.com> Looks good. --Sean On 6/30/20 11:31 PM, Weijun Wang wrote: > Please review an updated fix at > > https://cr.openjdk.java.net/~weijun/8243592/webrev.03 > > After some discussion, we think there is no need to call contains(null) at all since it might not be reliable (see the new test). Now, collectionNullClean inspects all items in the input collection and create a new LinkedList. > > Since there is no need to repopulate a list inside "new SecureSet", the new implementation is not slower than the original proposal from Tigran. > > And there is no need for a CSR because there will be no behavior change. > > Thanks, > Max > > p.s. Welcome to the github playground at https://github.com/openjdk/playground/pull/9, but formal code review should stay in this mail thread. > >> On Apr 30, 2020, at 9:50 PM, Weijun Wang wrote: >> >> Webrev updated at >> >> http://cr.openjdk.java.net/~weijun/8243592/webrev.02/ >> >> I removed my old test and rewrite the existing SubjectNullTests.java test in TestNG with quite some new test cases. >> >> There are so many behavior changes (although we might say good programs are not affected) that I decided to add a CSR and a release note. Please also take a look. >> >> CSR : https://bugs.openjdk.java.net/browse/JDK-8244165 >> release note : https://bugs.openjdk.java.net/browse/JDK-8244169 >> >> Thanks, >> Max >> >> >>> On Apr 29, 2020, at 2:57 AM, Sean Mullan wrote: >>> >>> I don't think containsAll and retainsAll need to call collectionNullClean either because SecureSet.contains(null) returns false now. >>> >>> --Sean >>> >>> On 4/28/20 9:58 AM, Weijun Wang wrote: >>>> A new webrev is at >>>> http://cr.openjdk.java.net/~weijun/8243592/webrev.01/ >>>> I take this chance to do some formatting and add a new test. My first testng test! >>>> Thanks, >>>> Max >>>>> On Apr 28, 2020, at 8:16 PM, Sean Mullan wrote: >>>>> >>>>> On 4/27/20 10:39 PM, Weijun Wang wrote: >>>>>> Reading the Set spec, it looks like an NPE is still needed for add(), but remove() can be modified. >>>>> >>>>> Good point, I agree. >>>>> >>>>> --Sean >>>>> >>>>>> --Max >>>>>>> On Apr 27, 2020, at 10:27 PM, Sean Mullan wrote: >>>>>>> >>>>>>> The fix looks fine to me. For consistency, you could make the same change for null elements in the other SecureSet methods: add, remove. >>>>>>> >>>>>>> --Sean >>>>>>> >>>>>>> On 4/25/20 3:39 AM, Weijun Wang wrote: >>>>>>>> Please take a review at >>>>>>>> http://cr.openjdk.java.net/~weijun/8243592/webrev.00/ >>>>>>>> This is helpful if we do any set arithmetic between 2 Subject objects. >>>>>>>> No new regression test, I intend to add a noreg-trivial label. >>>>>>>> *Tigran*: Please confirm you are OK with the "Contributed-by" line. >>>>>>>> Thanks, >>>>>>>> Max >> > From jamil.j.nimeh at oracle.com Wed Jul 8 22:57:15 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 8 Jul 2020 15:57:15 -0700 Subject: RFR JDK-8247630: Use two key share entries Message-ID: <2a123969-80ab-2187-61d8-2c8897b1b629@oracle.com> Hello all, This is a small enhancement to the TLS 1.3 client hello.? With this change JSSE will make a best-effort attempt to select the most-preferred XDH and ECDHE named group.? In most cases this will be x25519 and secp256r1.? This was done to help reduce the number of times our clients get HelloRetryRequests due to servers wanting secp256r1 when we would just assert x25519. The asserted key shares can be affected by different settings for the jdk.tls.namedGroups System property.? If x25519 and/or secp256r1 are missing, the next-most-preferred named group of that class will be selected.? If no other named group in that class is in the supported_groups extension, then it will be skipped.? In the unlikely event that no XDH or ECDHE supported group is asserted, then the client will assert one key share, the most preferred one out of the supported groups. This also fixes one minor spec compliance issue where we weren't throwing an exception when a server returned an illegal HelloRetryRequest with a named group that was in the original key_shares extension from the client hello. Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8247630/webrev.01/ JBS: https://bugs.openjdk.java.net/browse/JDK-8247630 --Jamil From alexey at azul.com Thu Jul 9 19:34:14 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 9 Jul 2020 19:34:14 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com> References: <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com> <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com> <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com> <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com> <2267CBC7-85A9-4105-B405-E7499440B985@azul.com> <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com> <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com> <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com> <643f3744-cfa2-e871-1284-900d81709f53@oracle.com> <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com> Message-ID: Hello Sean, Daniel, Thank you for review I?ve added ?com.sun.jndi.ldap.tls.cbtype? property into the module-info file and updated synchronisation using CompletableFuture. Also, I have added new test cases : successful and unsuccessful TLS handshake, synchronous and asynchronous TLS handshake. New webrev at : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v13 Connection property is removed from CSR : https://bugs.openjdk.java.net/browse/JDK-8247311 Regards Alexey > On 8 Jul 2020, at 17:41, Daniel Fuchs wrote: > > Thanks Sean, Alexey, > > On 08/07/2020 13:25, Sean Mullan wrote: >>> Updated webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v12/ >> You will also need to update the CSR to remove the connection timeout property. >> Also, you should document the "com.sun.jndi.ldap.tls.cbtype" property in the java.naming module-info file as was done for other properties in Daniel's recent RFR, once he has pushed it [1]. > > I have pushed the fix: > https://hg.openjdk.java.net/jdk/jdk/rev/ed375ae6c779 > > Alexey, you should now be able to document your new "com.sun.jndi.ldap.tls.cbtype" > property in that @implNote as well, and update your CSR > consequently. > >> * src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java >> It looks like there is a possibility of deadlock if getTlsServerCertificate() is called before handshakeCompleted(). In that case the lock could be obtained first and the thread would end up holding the lock and waiting forever. > > I also have a concern with the use of wait/notify in that code. > I would suggest prototyping using a CompletableFuture instead > (or can new certificates be exchanged later on the same > connection?) > > CompletableFuture would allow you to relay and propagate any > exception raised in the callback handler as well, and would > avoid running into deadlocks. > > best regards, > > -- daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From weijun.wang at oracle.com Fri Jul 10 13:00:29 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 10 Jul 2020 21:00:29 +0800 Subject: RFR 8242068: Signed JAR support for RSASSA-PSS and EdDSA In-Reply-To: <50C70B50-9B13-4098-B848-C68A68DC895A@oracle.com> References: <50C70B50-9B13-4098-B848-C68A68DC895A@oracle.com> Message-ID: New webrev at http://cr.openjdk.java.net/~weijun/8242068/webrev.03/ Changes since webrev.02: - Does not add OID.1.2.3.4 into KnownOIDs's name2enum map. Instead, check for the "OID." prefix in SignatureUtil::checkName. - Add a new "directsign" property to JarSigner.Builder::setProperty. - s/signManifest/sectionsonly/ and s/externalSF/internalsf/ in JarSigner, to be consistent with jarsigner option names. - When directsign == false, always uses PKCS7.generateNewSignedData - A new functional test to check several JarSigner properties CSR (withdrawn and) updated on the new JarSigner property at https://bugs.openjdk.java.net/browse/JDK-8245274 Thanks, Max > On Jun 2, 2020, at 4:07 PM, Weijun Wang wrote: > > Updated again at > > https://cr.openjdk.java.net/~weijun/8242068/webrev.02 > > Major changes this time: > > 1. Use Signed Attributes in generateNewSignedData(direct==false). This means for Ed448 we will use SHAKE256-LEN so there is no interop issue (BTW, BC recently added support to SHAKE256 in 166b07), hence removed the newly added system property in webrev.01. > > 2. Better interop with providers using Ed448 and Ed25519 as key algorithm names. > > Major changes previously: > > 1. Always encode the whole signature algorithm identifier (instead of encryption algorithmid) in PKCS7 SignerInfo. > > 2. New SignatureUtil methods > > Thanks, > Max > >> On May 27, 2020, at 8:21 AM, Weijun Wang wrote: >> >> Webrev updated at >> >> http://cr.openjdk.java.net/~weijun/8242068/webrev.01/ >> >> Two major changes: >> >> 1. Always use the signature algorithm directly in SignerInfo::signatureAlgorithm: >> >> In PKCS7 SignerInfo >> >> SignerInfo ::= SEQUENCE { >> version CMSVersion, >> sid SignerIdentifier, >> digestAlgorithm DigestAlgorithmIdentifier, >> signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, >> signatureAlgorithm SignatureAlgorithmIdentifier, >> signature SignatureValue, >> unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } >> >> We have always been putting "SHA-1" etc into DigestAlgorithmIdentifier, and "RSA", "DSA", "EC" into signatureAlgorithm. >> >> The latest https://tools.ietf.org/html/rfc5652#section-10.1.2 claims it to be >> >> The SignatureAlgorithmIdentifier type identifies a signature >> algorithm, and it can also identify a message digest algorithm. >> Examples include RSA, DSA, DSA with SHA-1, ECDSA, and ECDSA with >> SHA-256. >> >> It's complicated to always divide a signature algorithm into a digest algorithm and an encryption algorithm (and with the new RSASSA-PSS and EdDSA it's not easy to define it), therefore I decide to use the signature algorithm directly from now on. Fortunately Java has been able to parse this for a very long time so there is no compatibility issue. I noticed BouncyCastle has been doing the same, and OpenSSL too except for RSA. >> >> 2. Support both SHAKE256 and SHAKE256-LEN while parsing a Ed448 SignerInfo. They are both described in https://www.rfc-editor.org/rfc/rfc8419.html although it's a little complicated. To be standard compliant (https://www.rfc-editor.org/rfc/rfc8419.html#section-3.2 and we don't use Signed Attributes), by default Java will use SHAKE256 as the digestAlgorithm. However I noticed BouncyCastle does not recognize it, so if you set the system property "jdk.security.pkcs7.ed448.digalg.haslen" to "true", it will use SHAKE256-LEN (len == 512). I haven't described this system property in the CSR yet. >> >> Thanks, >> Max >> >> >>> On May 22, 2020, at 10:30 PM, Weijun Wang wrote: >>> >>> Please take a review at >>> >>> CSR : https://bugs.openjdk.java.net/browse/JDK-8245274 >>> webrev : http://cr.openjdk.java.net/~weijun/8242068/webrev.00/ >>> >>> Major points in CSR: >>> >>> - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in jarsigner >>> >>> - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a signed JAR) are reused for new signature algorithms >>> >>> major code changes: >>> >>> - Move signature related utilities methods from AlgorithmId.java to SignatureUtil.java >>> >>> - Add new SignatureUtil methods fromKey() and fromSignature() to simplify creating Signature and getting its AlgorithmId >>> >>> - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing >>> >>> - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all old and new signature algorithms >>> >>> - Mark all -altsign related code deprecated and they can be removed once ContentSigner is removed >>> >>> Next I'll do some basic interop tests with openssl and BouncyCastle. >>> >>> Thanks, >>> Max >>> >> > From aleksej.efimov at oracle.com Fri Jul 10 16:40:32 2020 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Fri, 10 Jul 2020 17:40:32 +0100 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com> <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com> <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com> <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com> <2267CBC7-85A9-4105-B405-E7499440B985@azul.com> <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com> <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com> <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com> <643f3744-cfa2-e871-1284-900d81709f53@oracle.com> <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com> Message-ID: Hi Alexey, Thank you for removing the dependency on the timeout property and adding tests for TLS handshake cases. Please, find the comments about the latest webrev below: Not quite sure why the CF is completed at two places. Probably that?s OK, but it would be good to know the reason :) The ExecutionException could be unpacked instead of using it directly - and its cause used instead. 'getTlsServerCertificate' should return null if 'isTlsConnection()' is false - rather than waiting forever. java.naming/share/classes/module-info.java: could we try to improve the formatting of the possible values for the new system property - maybe format them as a list. Connection.java:995 - you could use diamond operator here Formatting: Connection.java:1027 'catch (' Could we use the test/jdk/com/sun/jndi/ldap/lib/BaseLdapServer.java from the test library to implement dummy LDAPS server, I believe it could help to increase the test verbosity and reduce its code size. LdapCBPropertiesTest.java:122 - could use no param Hastable constructor I've also run your latest patch through our CI system and it showed no failures with your latest changes. -Aleksei On 09/07/2020 20:34, Alexey Bakhtin wrote: > Hello Sean, Daniel, > > Thank you for review > I?ve added ?com.sun.jndi.ldap.tls.cbtype? property into the module-info file > and updated synchronisation using CompletableFuture. > Also, I have added new test cases : successful and unsuccessful TLS handshake, > synchronous and asynchronous TLS handshake. > > New webrev at : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v13 > > Connection property is removed from CSR : > https://bugs.openjdk.java.net/browse/JDK-8247311 > > Regards > Alexey > >> On 8 Jul 2020, at 17:41, Daniel Fuchs wrote: >> >> Thanks Sean, Alexey, >> >> On 08/07/2020 13:25, Sean Mullan wrote: >>>> Updated webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v12/ >>> You will also need to update the CSR to remove the connection timeout property. >>> Also, you should document the "com.sun.jndi.ldap.tls.cbtype" property in the java.naming module-info file as was done for other properties in Daniel's recent RFR, once he has pushed it [1]. >> I have pushed the fix: >> https://hg.openjdk.java.net/jdk/jdk/rev/ed375ae6c779 >> >> Alexey, you should now be able to document your new "com.sun.jndi.ldap.tls.cbtype" >> property in that @implNote as well, and update your CSR >> consequently. >> >>> * src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java >>> It looks like there is a possibility of deadlock if getTlsServerCertificate() is called before handshakeCompleted(). In that case the lock could be obtained first and the thread would end up holding the lock and waiting forever. >> I also have a concern with the use of wait/notify in that code. >> I would suggest prototyping using a CompletableFuture instead >> (or can new certificates be exchanged later on the same >> connection?) >> >> CompletableFuture would allow you to relay and propagate any >> exception raised in the callback handler as well, and would >> avoid running into deadlocks. >> >> best regards, >> >> -- daniel From alexey at azul.com Fri Jul 10 20:37:26 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Fri, 10 Jul 2020 20:37:26 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com> <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com> <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com> <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com> <2267CBC7-85A9-4105-B405-E7499440B985@azul.com> <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com> <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com> <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com> <643f3744-cfa2-e871-1284-900d81709f53@oracle.com> <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com> Message-ID: Hello Aleksei, Thank you for review. Please see my comments below. Updated webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v14/ Regards Alexey > On 10 Jul 2020, at 19:40, Aleks Efimov wrote: > > Hi Alexey, > > Thank you for removing the dependency on the timeout property and adding tests for TLS handshake cases. > > Please, find the comments about the latest webrev below: > > Not quite sure why the CF is completed at two places. Probably that?s OK, but it would be good to know the reason :) HandshakeCompletedListener is called in case of successful handshake only. In case of async handshake failed we close the connection and complete CF exceptionally to release CF.get() > > The ExecutionException could be unpacked instead of using it directly - and its cause used instead. Thank you. Fixed in Connection.java and LdapCBPropertiesTest.java > > 'getTlsServerCertificate' should return null if 'isTlsConnection()' is false - rather than waiting forever. We call isTlsConnection() in the LdapSasl before getTlsServerCertificate(). But your are right, we can double check it to prevent possible deadlock in the future, if code changed. Fixed in Connection.java > > java.naming/share/classes/module-info.java: could we try to improve the formatting of the possible values for the new system property - maybe format them as a list. Done > > Connection.java:995 - you could use diamond operator here Updated > > Formatting: Connection.java:1027 'catch (? Updated > > Could we use the test/jdk/com/sun/jndi/ldap/lib/BaseLdapServer.java from the test library to implement dummy LDAPS server, I believe it could help to increase the test verbosity and reduce its code size. Thank you for suggestion. Updated to use BaseLdapServer in the test > > LdapCBPropertiesTest.java:122 - could use no param Hastable constructor Fixed > > I've also run your latest patch through our CI system and it showed no failures with your latest changes. > > -Aleksei > > On 09/07/2020 20:34, Alexey Bakhtin wrote: >> Hello Sean, Daniel, >> >> Thank you for review >> I?ve added ?com.sun.jndi.ldap.tls.cbtype? property into the module-info file >> and updated synchronisation using CompletableFuture. >> Also, I have added new test cases : successful and unsuccessful TLS handshake, >> synchronous and asynchronous TLS handshake. >> >> New webrev at : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v13 >> >> Connection property is removed from CSR : >> https://bugs.openjdk.java.net/browse/JDK-8247311 >> >> Regards >> Alexey >> >>> On 8 Jul 2020, at 17:41, Daniel Fuchs wrote: >>> >>> Thanks Sean, Alexey, >>> >>> On 08/07/2020 13:25, Sean Mullan wrote: >>>>> Updated webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v12/ >>>> You will also need to update the CSR to remove the connection timeout property. >>>> Also, you should document the "com.sun.jndi.ldap.tls.cbtype" property in the java.naming module-info file as was done for other properties in Daniel's recent RFR, once he has pushed it [1]. >>> I have pushed the fix: >>> https://hg.openjdk.java.net/jdk/jdk/rev/ed375ae6c779 >>> >>> Alexey, you should now be able to document your new "com.sun.jndi.ldap.tls.cbtype" >>> property in that @implNote as well, and update your CSR >>> consequently. >>> >>>> * src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java >>>> It looks like there is a possibility of deadlock if getTlsServerCertificate() is called before handshakeCompleted(). In that case the lock could be obtained first and the thread would end up holding the lock and waiting forever. >>> I also have a concern with the use of wait/notify in that code. >>> I would suggest prototyping using a CompletableFuture instead >>> (or can new certificates be exchanged later on the same >>> connection?) >>> >>> CompletableFuture would allow you to relay and propagate any >>> exception raised in the callback handler as well, and would >>> avoid running into deadlocks. >>> >>> best regards, >>> >>> -- daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From daniel.fuchs at oracle.com Tue Jul 14 15:28:30 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 14 Jul 2020 16:28:30 +0100 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com> <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com> <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com> <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com> <2267CBC7-85A9-4105-B405-E7499440B985@azul.com> <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com> <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com> <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com> <643f3744-cfa2-e871-1284-900d81709f53@oracle.com> <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com> Message-ID: <7621fa33-26cc-d545-cb33-a93fdbfd48c7@oracle.com> Hi Alexey, On 10/07/2020 21:37, Alexey Bakhtin wrote: > Updated webrev:http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v14/ In what the JNDI part is concerned this looks good to me now. nit: java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java: 138 }catch(NoSuchAlgorithmException | CertificateEncodingException e) { missing spaces around `catch`; No need for a new webrev. Please make sure to update the CSR, and in particular update the specification section with the diffs from src/java.naming/share/classes/module-info.java Also I am not sure the links that are currently in the specification section are at their place. They may be better placed in the Solution section (the solution is to implement the client part of the channel binding as described by these documents in the default JNDI/LDAP/GSS provider). Since we don't really have any end-to-end regression test (what we have is mostly a smoke test) - it would be good if you could describe in more details what you did to test your fix against a real server in a JBS comment in JDK-8245527 - so that someone (future or current maintainers) could reproduce this testing to verify that nothing is broken by future evolutions. In particular - if anything specific needs to be installed/configured on the test machine (LDAP server? Which? Is that all?) best regards, -- daniel From hai-may.chao at oracle.com Tue Jul 14 20:09:08 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Tue, 14 Jul 2020 13:09:08 -0700 Subject: RFR 8247960: jarsigner says "signer errors" for some normal warnings when -strict is set Message-ID: Hi, I?d like to request a review for: JBS: https://bugs.openjdk.java.net/browse/JDK-8247960 Webrev: https://cr.openjdk.java.net/~hchao/8247960/webrev.00/ Jarsigner is changed to emit ?with signer errors? only when there are errors detected during sign and verify with -strict specified. Thanks, Hai-May From weijun.wang at oracle.com Wed Jul 15 07:16:07 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 15 Jul 2020 15:16:07 +0800 Subject: RFR 8247960: jarsigner says "signer errors" for some normal warnings when -strict is set In-Reply-To: References: Message-ID: <1C7CDB22-B51E-41B1-B4A9-084C5601B9A7@oracle.com> The following lines are useless now: 1053 if (badKeyUsage || badExtendedKeyUsage || badNetscapeCertType || 1054 notYetValidCert || chainNotValidated || hasExpiredCert || 1055 hasUnsignedEntry || signerSelfSigned || (legacyAlg != 0) || 1056 (disabledAlg != 0) || aliasNotInStore || notSignedByAlias || 1057 tsaChainNotValidated || 1058 (hasExpiredTsaCert && !signerNotExpired)) { 1198 } 1205 if (hasExpiringCert || 1206 (hasExpiringTsaCert && expireDate != null) || 1207 (noTimestamp && expireDate != null) || 1208 (hasExpiredTsaCert && signerNotExpired)) { 1245 } I would even suggest you remove the "result" variable and move the "System.out.println(result)" line into branches of the if-else block on lines 1254-1272. No other comments. Thanks, Max > On Jul 15, 2020, at 4:09 AM, Hai-May Chao wrote: > > Hi, > > I?d like to request a review for: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8247960 > Webrev: https://cr.openjdk.java.net/~hchao/8247960/webrev.00/ > > Jarsigner is changed to emit ?with signer errors? only when there are errors detected during sign and verify with -strict specified. > > Thanks, > Hai-May > From aleksej.efimov at oracle.com Wed Jul 15 09:41:23 2020 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Wed, 15 Jul 2020 10:41:23 +0100 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com> <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com> <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com> <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com> <2267CBC7-85A9-4105-B405-E7499440B985@azul.com> <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com> <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com> <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com> <643f3744-cfa2-e871-1284-900d81709f53@oracle.com> <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com> Message-ID: <5fa647e7-4ced-31ce-1dc5-97ac0886c329@oracle.com> Hi Alexey, Thanks for addressing comments and answering questions. The JNDI changes in latest webrev looks good to me. CI is also happy with the latest changes. Best, Aleksei On 10/07/2020 21:37, Alexey Bakhtin wrote: > Hello Aleksei, > > Thank you for review. > Please see my comments below. > > Updated webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v14/ > > Regards > Alexey > >> On 10 Jul 2020, at 19:40, Aleks Efimov wrote: >> >> Hi Alexey, >> >> Thank you for removing the dependency on the timeout property and adding tests for TLS handshake cases. >> >> Please, find the comments about the latest webrev below: >> >> Not quite sure why the CF is completed at two places. Probably that?s OK, but it would be good to know the reason :) > HandshakeCompletedListener is called in case of successful handshake only. > In case of async handshake failed we close the connection and complete CF exceptionally to release CF.get() > >> The ExecutionException could be unpacked instead of using it directly - and its cause used instead. > Thank you. Fixed in Connection.java and LdapCBPropertiesTest.java >> 'getTlsServerCertificate' should return null if 'isTlsConnection()' is false - rather than waiting forever. > We call isTlsConnection() in the LdapSasl before getTlsServerCertificate(). > But your are right, we can double check it to prevent possible deadlock in the future, if code changed. > Fixed in Connection.java > >> java.naming/share/classes/module-info.java: could we try to improve the formatting of the possible values for the new system property - maybe format them as a list. > Done >> Connection.java:995 - you could use diamond operator here > Updated >> Formatting: Connection.java:1027 'catch (? > Updated >> Could we use the test/jdk/com/sun/jndi/ldap/lib/BaseLdapServer.java from the test library to implement dummy LDAPS server, I believe it could help to increase the test verbosity and reduce its code size. > Thank you for suggestion. Updated to use BaseLdapServer in the test > >> LdapCBPropertiesTest.java:122 - could use no param Hastable constructor > Fixed >> I've also run your latest patch through our CI system and it showed no failures with your latest changes. >> >> -Aleksei >> >> On 09/07/2020 20:34, Alexey Bakhtin wrote: >>> Hello Sean, Daniel, >>> >>> Thank you for review >>> I?ve added ?com.sun.jndi.ldap.tls.cbtype? property into the module-info file >>> and updated synchronisation using CompletableFuture. >>> Also, I have added new test cases : successful and unsuccessful TLS handshake, >>> synchronous and asynchronous TLS handshake. >>> >>> New webrev at : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v13 >>> >>> Connection property is removed from CSR : >>> https://bugs.openjdk.java.net/browse/JDK-8247311 >>> >>> Regards >>> Alexey >>> >>>> On 8 Jul 2020, at 17:41, Daniel Fuchs wrote: >>>> >>>> Thanks Sean, Alexey, >>>> >>>> On 08/07/2020 13:25, Sean Mullan wrote: >>>>>> Updated webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v12/ >>>>> You will also need to update the CSR to remove the connection timeout property. >>>>> Also, you should document the "com.sun.jndi.ldap.tls.cbtype" property in the java.naming module-info file as was done for other properties in Daniel's recent RFR, once he has pushed it [1]. >>>> I have pushed the fix: >>>> https://hg.openjdk.java.net/jdk/jdk/rev/ed375ae6c779 >>>> >>>> Alexey, you should now be able to document your new "com.sun.jndi.ldap.tls.cbtype" >>>> property in that @implNote as well, and update your CSR >>>> consequently. >>>> >>>>> * src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java >>>>> It looks like there is a possibility of deadlock if getTlsServerCertificate() is called before handshakeCompleted(). In that case the lock could be obtained first and the thread would end up holding the lock and waiting forever. >>>> I also have a concern with the use of wait/notify in that code. >>>> I would suggest prototyping using a CompletableFuture instead >>>> (or can new certificates be exchanged later on the same >>>> connection?) >>>> >>>> CompletableFuture would allow you to relay and propagate any >>>> exception raised in the callback handler as well, and would >>>> avoid running into deadlocks. >>>> >>>> best regards, >>>> >>>> -- daniel From weijun.wang at oracle.com Wed Jul 15 10:06:01 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 15 Jul 2020 18:06:01 +0800 Subject: RFR 8247960: jarsigner says "signer errors" for some normal warnings when -strict is set In-Reply-To: <1C7CDB22-B51E-41B1-B4A9-084C5601B9A7@oracle.com> References: <1C7CDB22-B51E-41B1-B4A9-084C5601B9A7@oracle.com> Message-ID: Oops, 1101 if (hasExpiredTsaCert) { 1102 errors.add(rb.getString("The.timestamp.has.expired.")); 1103 } was inside 1058 (hasExpiredTsaCert && !signerNotExpired)) { and it should be combined with 1210 if (hasExpiredTsaCert && signerNotExpired) { 1211 if (expireDate != null) { 1212 warnings.add(String.format( 1213 rb.getString("The.timestamp.expired.1.but.usable.2"), 1214 tsaExpireDate, 1215 expireDate)); 1216 } 1217 // Reset the flag so exit code is 0 1218 hasExpiredTsaCert = false; 1219 } to be something like if (hasExpiredTsaCert) { if (signerNotExpired) { warnings... } else { errors.... } } Thanks, Max > On Jul 15, 2020, at 3:16 PM, Weijun Wang wrote: > > The following lines are useless now: > > 1053 if (badKeyUsage || badExtendedKeyUsage || badNetscapeCertType || > 1054 notYetValidCert || chainNotValidated || hasExpiredCert || > 1055 hasUnsignedEntry || signerSelfSigned || (legacyAlg != 0) || > 1056 (disabledAlg != 0) || aliasNotInStore || notSignedByAlias || > 1057 tsaChainNotValidated || > 1058 (hasExpiredTsaCert && !signerNotExpired)) { > > 1198 } > > 1205 if (hasExpiringCert || > 1206 (hasExpiringTsaCert && expireDate != null) || > 1207 (noTimestamp && expireDate != null) || > 1208 (hasExpiredTsaCert && signerNotExpired)) { > > 1245 } > > I would even suggest you remove the "result" variable and move the "System.out.println(result)" line into branches of the if-else block on lines 1254-1272. > > No other comments. > > Thanks, > Max > > > >> On Jul 15, 2020, at 4:09 AM, Hai-May Chao wrote: >> >> Hi, >> >> I?d like to request a review for: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8247960 >> Webrev: https://cr.openjdk.java.net/~hchao/8247960/webrev.00/ >> >> Jarsigner is changed to emit ?with signer errors? only when there are errors detected during sign and verify with -strict specified. >> >> Thanks, >> Hai-May >> > From alexey at azul.com Wed Jul 15 11:18:45 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 15 Jul 2020 11:18:45 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <7621fa33-26cc-d545-cb33-a93fdbfd48c7@oracle.com> References: <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com> <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com> <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com> <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com> <2267CBC7-85A9-4105-B405-E7499440B985@azul.com> <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com> <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com> <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com> <643f3744-cfa2-e871-1284-900d81709f53@oracle.com> <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com> <7621fa33-26cc-d545-cb33-a93fdbfd48c7@oracle.com> Message-ID: <8804341B-E534-4FA8-A652-86F8A30F18B3@azul.com> Hello Daniel, I?ve updated CSR as you suggested and added kerberos ldap setup commands for the client host in the JDK-8245527 Regards Alexey > On 14 Jul 2020, at 18:28, Daniel Fuchs wrote: > > Hi Alexey, > > On 10/07/2020 21:37, Alexey Bakhtin wrote: >> Updated webrev:http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v14/ > > In what the JNDI part is concerned this looks good to me now. > > nit: java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java: > 138 }catch(NoSuchAlgorithmException | CertificateEncodingException e) { > > missing spaces around `catch`; No need for a new webrev. > > Please make sure to update the CSR, and in particular update > the specification section with the diffs from > > src/java.naming/share/classes/module-info.java > > Also I am not sure the links that are currently in the > specification section are at their place. They may be better > placed in the Solution section (the solution is to implement > the client part of the channel binding as described by these > documents in the default JNDI/LDAP/GSS provider). > > Since we don't really have any end-to-end regression test > (what we have is mostly a smoke test) - it would be good if > you could describe in more details what you did to test your > fix against a real server in a JBS comment in JDK-8245527 - so > that someone (future or current maintainers) could reproduce > this testing to verify that nothing is broken by future evolutions. > In particular - if anything specific needs to be > installed/configured on the test machine (LDAP server? Which? > Is that all?) > > > best regards, > > -- daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From schlosna at gmail.com Wed Jul 15 15:48:35 2020 From: schlosna at gmail.com (David Schlosnagle) Date: Wed, 15 Jul 2020 11:48:35 -0400 Subject: SSLSocketImpl and Handshake Notifier efficiency/thread pooling In-Reply-To: References: <50F626D4.5030101@oracle.com> Message-ID: Hi security-dev, I'd like to revive this 7.5 year old thread for discussion as I have seen seen several high throughput applications using `SSLSocket.addHandshakeCompletedListener(HandshakeCompletedListener)` where the "HandshakeCompletedNotify-Thread" created at https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/TransportContext.java#L640 for each TLS handshake adds significant spike in resource utilization. For example, a service receiving say 10,000 requests per second with handshakes required for 0.5% we're creating 50 threads per second, which is significant thrash. We would like to avoid this thread creation to smooth out resource utilization. I am tracking Project Loom's progress [1] where HandshakeCompletedListener handling may be an ideal case for virtual thread, but would like understand if folks here are open to patches to improve this situation in the interim? Would utilizing a cached thread pool be an acceptable patch request option? Would providing a system property configurable option to execute the handlers directly on the handshaking thread be an option (e.g. when a handler is lightweight such as incrementing handshake, cipher suite, and protocol metrics)? Thanks, Dave [1] https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html On Thu, Feb 7, 2013 at 6:27 PM Bernd Eckenfels wrote: > > Hello, > > I have now submitted my OCA, how can we proceed here? > > Am 17.01.2013, 02:19 Uhr, schrieb Bernd Eckenfels > : > > Am 16.01.2013, 05:04 Uhr, schrieb Xuelei Fan : > > > >> I agree with you that create new threads in SSLSocket implementation is > >> not good. The application is the better place to decide what's the > >> right thread model. > > > >> For the same reason, using Executor in SSLSocket > >> implementation might not be an option from my understanding. > > > > > > A small change without Executor would be to have a boolean setter which > > deactivates the Thread dispatching. The default will use new Threads, if > > direct mode is enabled it will directly call the listeners in the data > > thread: > ... > > Greetings > Bernd > -- > http://bernd.eckenfels.net From sean.mullan at oracle.com Wed Jul 15 19:06:59 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 15 Jul 2020 15:06:59 -0400 Subject: RFR 8247960: jarsigner says "signer errors" for some normal warnings when -strict is set In-Reply-To: References: Message-ID: I'll defer to Max on the code changes, but I noticed one thing on the test - you should add the bugid to the @bug line of the test. --Sean On 7/14/20 4:09 PM, Hai-May Chao wrote: > Hi, > > I?d like to request a review for: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8247960 > Webrev: https://cr.openjdk.java.net/~hchao/8247960/webrev.00/ > > Jarsigner is changed to emit ?with signer errors? only when there are errors detected during sign and verify with -strict specified. > > Thanks, > Hai-May > From hai-may.chao at oracle.com Wed Jul 15 20:34:10 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Wed, 15 Jul 2020 13:34:10 -0700 Subject: RFR 8247960: jarsigner says "signer errors" for some normal warnings when -strict is set In-Reply-To: References: Message-ID: <976653DD-4ECE-48B4-8284-FE9CF652AF3D@oracle.com> Bugid added. Thanks, Hai-May > On Jul 15, 2020, at 12:06 PM, Sean Mullan wrote: > > I'll defer to Max on the code changes, but I noticed one thing on the test - you should add the bugid to the @bug line of the test. > > --Sean > > On 7/14/20 4:09 PM, Hai-May Chao wrote: >> Hi, >> I?d like to request a review for: >> JBS: https://bugs.openjdk.java.net/browse/JDK-8247960 >> Webrev: https://cr.openjdk.java.net/~hchao/8247960/webrev.00/ >> Jarsigner is changed to emit ?with signer errors? only when there are errors detected during sign and verify with -strict specified. >> Thanks, >> Hai-May From ecki at zusammenkunft.net Fri Jul 17 17:54:48 2020 From: ecki at zusammenkunft.net (Bernd) Date: Fri, 17 Jul 2020 19:54:48 +0200 Subject: NPE in jarsigner -verify for broken TSA Message-ID: Hello, I have currently intermittent errors with codesigning by Setico. Some signed JARs will cause a NullPointerException in jarsigner -verify: "C:\Program Files\Java\jdk-14.0.2\bin\jarsigner.exe" -verify -debug adapter.deployment.util-1.95.0.jar Command line args: [-verify, -debug, adapter.deployment.util-1.95.0.jar] jarsigner: java.lang.NullPointerException java.lang.NullPointerException at java.base/sun.security.pkcs.SignerInfo.getTimestamp(SignerInfo.java:568) at java.base/sun.security.util.SignatureFileVerifier.getSigners(SignatureFileVerifier.java:728) at java.base/sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:300) at java.base/sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:268) at java.base/java.util.jar.JarVerifier.processEntry(JarVerifier.java:316) at java.base/java.util.jar.JarVerifier.update(JarVerifier.java:230) at java.base/java.util.jar.JarFile.initializeVerifier(JarFile.java:759) at java.base/java.util.jar.JarFile.getInputStream(JarFile.java:840) at jdk.jartool/sun.security.tools.jarsigner.Main.verifyJar(Main.java:698) at jdk.jartool/sun.security.tools.jarsigner.Main.run(Main.java:264) at jdk.jartool/sun.security.tools.jarsigner.Main.main(Main.java:118) (this is java.net 14 GA release, also happens on Zulu-8) Looking at the code this seems to be a TS validation error suppressed internally. And indeed, if I try to validate the Timestamp in the PKCS7 SECTIGO_.RSA file (with bouncycastle) it tells me that it looks like the TSA has provided the wrong certificate. This is of course something I need to check with Setigo (anybody has same experience?). However there are two questions: a) should jarsigner when signing with a TSA do some validation, especially on the received timestamp object? (I cant try different jarsigner for signing due to isolated sign server, I think the version who created the signature is java8). b) should the TS validation in jarsigner -verify be either ignored/skipped (in some other places it looks like the same exception is already catched and ignored) or should it throw a more qualified error than a NPE (in -strict mode). Gruss Bernd BC Test Code: https://gist.github.com/ecki/42aaa3a8621344c1cd0034c440a73400 Failed Sectigo Signature: SECTIGO_.RSA: https://mft.seeburger.de:443/portal-seefx/~public/ZjgwNzgxNWItZGE5MC00MWU2LWFkYWUtOWNkNzkwMTdmODI5?download (i can share the test jar privately only) BC Test Result (failed): TS validating sig file: SECTIGO_.RSA Signature has 3 certs. Has 1 signers Has 1 timestamps TS Signer: C=GB,ST=Greater Manchester,L=Salford,O=Sectigo Limited,CN=Sectigo RSA Time Stamping CA TS generated: Fri Jul 17 15:43:20 CEST 2020 Checking C=GB,ST=Greater Manchester,L=Salford,O=Sectigo Limited,CN=Sectigo RSA Time Stamping Signer #1 <- C=GB,ST=Greater Manchester,L=Salford,O=Sectigo Limited,CN=Sectigo RSA Time Stamping CA Failed org.bouncycastle.tsp.TSPValidationException: signature not created by certificate. at org.bouncycastle.tsp.TimeStampToken.validate(Unknown Source) at net.eckenfels.test.jartest.JarTimestampChecker.main(JarTimestampChecker.java:87) (I tested with a signature from Comodo and the test program worked) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Fri Jul 17 18:47:30 2020 From: ecki at zusammenkunft.net (Bernd) Date: Fri, 17 Jul 2020 20:47:30 +0200 Subject: NPE in jarsigner -verify for broken TSA In-Reply-To: References: Message-ID: I just found another case, when jarsigner correctly verifies a JAR with this sectigo signing I see two certificates in the TS record and one of them does validate. In the failed case only the CA cert seems to have been present in the list (see last mail and gist) The signer certificate will expire on 2023-06-04. The timestamp will expire on 2030-08-02. TS validating sig file: D:\dev\wsBIS65\JavaCryptoTest\SECTIGO2.RSA Signature has 3 certs. Has 1 signers Has 1 timestamps TS Signer issuer: C=GB,ST=Greater Manchester,L=Salford,O=Sectigo Limited,CN=Sectigo RSA Time Stamping CA TS generated: Mon Jul 13 16:10:10 CEST 2020 Checking C=GB,ST=Greater Manchester,L=Salford,O=Sectigo Limited,CN=Sectigo RSA Time Stamping Signer #1 <- C=GB,ST=Greater Manchester,L=Salford,O=Sectigo Limited,CN=Sectigo RSA Time Stamping CA *ok* Checking C=GB,ST=Greater Manchester,L=Salford,O=Sectigo Limited,CN=Sectigo RSA Time Stamping CA <- C=US,ST=New Jersey,L=Jersey City,O=The USERTRUST Network,CN=USERTrust RSA Certification Authority Failed org.bouncycastle.tsp.TSPValidationException: certificate hash does not match certID hash. at org.bouncycastle.tsp.TimeStampToken.validate(Unknown Source) at net.eckenfels.test.jartest.JarTimestampChecker.main(JarTimestampChecker.java:88) Am Fr., 17. Juli 2020 um 19:54 Uhr schrieb Bernd : > Hello, > > I have currently intermittent errors with codesigning by Setico. Some > signed JARs will cause a NullPointerException in jarsigner -verify: > > "C:\Program Files\Java\jdk-14.0.2\bin\jarsigner.exe" -verify -debug > adapter.deployment.util-1.95.0.jar > Command line args: [-verify, -debug, adapter.deployment.util-1.95.0.jar] > jarsigner: java.lang.NullPointerException > java.lang.NullPointerException > at > java.base/sun.security.pkcs.SignerInfo.getTimestamp(SignerInfo.java:568) > at > java.base/sun.security.util.SignatureFileVerifier.getSigners(SignatureFileVerifier.java:728) > at > java.base/sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:300) > at > java.base/sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:268) > at > java.base/java.util.jar.JarVerifier.processEntry(JarVerifier.java:316) > at java.base/java.util.jar.JarVerifier.update(JarVerifier.java:230) > at > java.base/java.util.jar.JarFile.initializeVerifier(JarFile.java:759) > at java.base/java.util.jar.JarFile.getInputStream(JarFile.java:840) > at > jdk.jartool/sun.security.tools.jarsigner.Main.verifyJar(Main.java:698) > at jdk.jartool/sun.security.tools.jarsigner.Main.run(Main.java:264) > at > jdk.jartool/sun.security.tools.jarsigner.Main.main(Main.java:118) > > (this is java.net 14 GA release, also happens on Zulu-8) > > Looking at the code this seems to be a TS validation error suppressed > internally. And indeed, if I try to validate the Timestamp in the PKCS7 > SECTIGO_.RSA file (with bouncycastle) it tells me that it looks like the > TSA has provided the wrong certificate. > > This is of course something I need to check with Setigo (anybody has same > experience?). > > However there are two questions: > > a) should jarsigner when signing with a TSA do some validation, especially > on the received timestamp object? (I cant try different jarsigner for > signing due to isolated sign server, I think the version who created the > signature is java8). > > b) should the TS validation in jarsigner -verify be either ignored/skipped > (in some other places it looks like the same exception is already catched > and ignored) or should it throw a more qualified error than a NPE (in > -strict mode). > > Gruss > Bernd > > BC Test Code: > > https://gist.github.com/ecki/42aaa3a8621344c1cd0034c440a73400 > > > Failed Sectigo Signature: > > SECTIGO_.RSA: > > https://mft.seeburger.de:443/portal-seefx/~public/ZjgwNzgxNWItZGE5MC00MWU2LWFkYWUtOWNkNzkwMTdmODI5?download > > (i can share the test jar privately only) > > BC Test Result (failed): > > TS validating sig file: SECTIGO_.RSA > Signature has 3 certs. > Has 1 signers > Has 1 timestamps > TS Signer: C=GB,ST=Greater Manchester,L=Salford,O=Sectigo > Limited,CN=Sectigo RSA Time Stamping CA > TS generated: Fri Jul 17 15:43:20 CEST 2020 > Checking C=GB,ST=Greater Manchester,L=Salford,O=Sectigo Limited,CN=Sectigo > RSA Time Stamping Signer #1 <- C=GB,ST=Greater > Manchester,L=Salford,O=Sectigo Limited,CN=Sectigo RSA Time Stamping CA > Failed org.bouncycastle.tsp.TSPValidationException: signature not created > by certificate. > at org.bouncycastle.tsp.TimeStampToken.validate(Unknown Source) > at > net.eckenfels.test.jartest.JarTimestampChecker.main(JarTimestampChecker.java:87) > > (I tested with a signature from Comodo and the test program worked) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rahul.r.yadav at oracle.com Mon Jul 20 16:36:05 2020 From: rahul.r.yadav at oracle.com (Rahul Yadav) Date: Mon, 20 Jul 2020 17:36:05 +0100 Subject: RFR 8245306 : Update sun.security.ssl.SSLLogger to use Immutable DateTimeFormatter In-Reply-To: <0eb8a449-e460-b1be-2e8c-f6cdb24d1b85@oracle.com> References: <0eb8a449-e460-b1be-2e8c-f6cdb24d1b85@oracle.com> Message-ID: <94caf882-e266-6a16-bcfa-310c9ee0287a@oracle.com> Hello, Request to have my fix reviewed for issue: JDK-8245306 :? Update sun.security.ssl.SSLLogger to use Immutable DateTimeFormatter This fix updates sun.security.ssl.SSLLogger to use immutable DateTimeFormatter in place of ThreadLocal, this is an effort as part of Project Loom, to replace usages of ThreadLocal wherever feasible, to improve virtual thread memory efficiency. Issue:? https://bugs.openjdk.java.net/browse/JDK-8245306 webrev: http://cr.openjdk.java.net/~ryadav/webrev_8245306/index.html - rahul From swpalmer at gmail.com Mon Jul 20 18:00:23 2020 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 20 Jul 2020 14:00:23 -0400 Subject: DTLS Support Message-ID: <2B1EBEA8-E153-4035-8C2F-A06950888B13@gmail.com> When DTLS support was added in https://bugs.openjdk.java.net/browse/JDK-8043758 DTLS-SRTP and WebRTC were specifically mentioned in the motivation. However, DTLS- SRTP requires the ?use_srtp? extension to be in the handshake. (https://tools.ietf.org/html/rfc5764#section-4.1 ) It appears that extension is still not supported as of JDK 14. Is support for ?use_srtp? planned? Is there any way to add extensions to the handshake from the application level? If not, are there any plans to add a mechanism that would allow such customization of the extensions used by the SSLEngine? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Tue Jul 21 17:48:52 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 21 Jul 2020 10:48:52 -0700 Subject: Fwd: RFR JDK-8247630: Use two key share entries In-Reply-To: <2a123969-80ab-2187-61d8-2c8897b1b629@oracle.com> References: <2a123969-80ab-2187-61d8-2c8897b1b629@oracle.com> Message-ID: <958e28a0-c068-98da-b579-464ee8539513@oracle.com> Ping. --J -------- Forwarded Message -------- Subject: RFR JDK-8247630: Use two key share entries Date: Wed, 8 Jul 2020 15:57:15 -0700 From: Jamil Nimeh To: security-dev at openjdk.java.net Hello all, This is a small enhancement to the TLS 1.3 client hello.? With this change JSSE will make a best-effort attempt to select the most-preferred XDH and ECDHE named group.? In most cases this will be x25519 and secp256r1.? This was done to help reduce the number of times our clients get HelloRetryRequests due to servers wanting secp256r1 when we would just assert x25519. The asserted key shares can be affected by different settings for the jdk.tls.namedGroups System property.? If x25519 and/or secp256r1 are missing, the next-most-preferred named group of that class will be selected.? If no other named group in that class is in the supported_groups extension, then it will be skipped.? In the unlikely event that no XDH or ECDHE supported group is asserted, then the client will assert one key share, the most preferred one out of the supported groups. This also fixes one minor spec compliance issue where we weren't throwing an exception when a server returned an illegal HelloRetryRequest with a named group that was in the original key_shares extension from the client hello. Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8247630/webrev.01/ JBS: https://bugs.openjdk.java.net/browse/JDK-8247630 --Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Jul 22 12:39:28 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Jul 2020 13:39:28 +0100 Subject: RFR 8245306 : Update sun.security.ssl.SSLLogger to use Immutable DateTimeFormatter In-Reply-To: <94caf882-e266-6a16-bcfa-310c9ee0287a@oracle.com> References: <0eb8a449-e460-b1be-2e8c-f6cdb24d1b85@oracle.com> <94caf882-e266-6a16-bcfa-310c9ee0287a@oracle.com> Message-ID: <06272d30-b5e8-4e29-a42f-1998340e569d@oracle.com> On 20/07/2020 17:36, Rahul Yadav wrote: > Hello, > > Request to have my fix reviewed for issue: > > JDK-8245306 :? Update sun.security.ssl.SSLLogger to use Immutable > DateTimeFormatter > > This fix updates sun.security.ssl.SSLLogger to use immutable > DateTimeFormatter in place of ThreadLocal, > this is an effort as part of Project Loom, to replace usages of > ThreadLocal wherever feasible, to > improve virtual thread memory efficiency. > > Issue:? https://bugs.openjdk.java.net/browse/JDK-8245306 > webrev: http://cr.openjdk.java.net/~ryadav/webrev_8245306/index.html The replacing of the TL looks good to me. Style-wise then I would probably declare pattern as a static final so that it is compiled in the initializer but it's not important. If you do change anything then the pattern strings can be final. -Alan From rahul.r.yadav at oracle.com Wed Jul 22 16:56:53 2020 From: rahul.r.yadav at oracle.com (Rahul Yadav) Date: Wed, 22 Jul 2020 17:56:53 +0100 Subject: RFR 8245306 : Update sun.security.ssl.SSLLogger to use Immutable DateTimeFormatter In-Reply-To: <06272d30-b5e8-4e29-a42f-1998340e569d@oracle.com> References: <0eb8a449-e460-b1be-2e8c-f6cdb24d1b85@oracle.com> <94caf882-e266-6a16-bcfa-310c9ee0287a@oracle.com> <06272d30-b5e8-4e29-a42f-1998340e569d@oracle.com> Message-ID: <9467b433-abee-d79e-bb78-1ddc0784b072@oracle.com> Thanks for the feedback Alan, have included pattern string as final. - rahul On 22/07/2020 13:39, Alan Bateman wrote: > > > On 20/07/2020 17:36, Rahul Yadav wrote: >> Hello, >> >> Request to have my fix reviewed for issue: >> >> JDK-8245306 :? Update sun.security.ssl.SSLLogger to use Immutable >> DateTimeFormatter >> >> This fix updates sun.security.ssl.SSLLogger to use immutable >> DateTimeFormatter in place of ThreadLocal, >> this is an effort as part of Project Loom, to replace usages of >> ThreadLocal wherever feasible, to >> improve virtual thread memory efficiency. >> >> Issue:? https://bugs.openjdk.java.net/browse/JDK-8245306 >> webrev: http://cr.openjdk.java.net/~ryadav/webrev_8245306/index.html > The replacing of the TL looks good to me. > > Style-wise then I would probably declare pattern as a static final so > that it is compiled in the initializer but it's not important. If you > do change anything then the pattern strings can be final. > > -Alan From jamil.j.nimeh at oracle.com Thu Jul 23 17:49:24 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 23 Jul 2020 10:49:24 -0700 Subject: RFR 8245306 : Update sun.security.ssl.SSLLogger to use Immutable DateTimeFormatter In-Reply-To: <94caf882-e266-6a16-bcfa-310c9ee0287a@oracle.com> References: <0eb8a449-e460-b1be-2e8c-f6cdb24d1b85@oracle.com> <94caf882-e266-6a16-bcfa-310c9ee0287a@oracle.com> Message-ID: This looks good to me. --Jamil On 7/20/2020 9:36 AM, Rahul Yadav wrote: > Hello, > > Request to have my fix reviewed for issue: > > JDK-8245306 :? Update sun.security.ssl.SSLLogger to use Immutable > DateTimeFormatter > > This fix updates sun.security.ssl.SSLLogger to use immutable > DateTimeFormatter in place of ThreadLocal, > this is an effort as part of Project Loom, to replace usages of > ThreadLocal wherever feasible, to > improve virtual thread memory efficiency. > > Issue:? https://bugs.openjdk.java.net/browse/JDK-8245306 > webrev: http://cr.openjdk.java.net/~ryadav/webrev_8245306/index.html > > - rahul From joe.darcy at oracle.com Fri Jul 24 05:17:36 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 23 Jul 2020 22:17:36 -0700 Subject: JDK 16 RFR of JDK-8250246: Address reliance on default constructors in security libs Message-ID: Hello, Please review a set of changes to add explicit constructors to replace default (implicit) constructors in various classes in security libs across several modules: ??? JDK-8250246: Address reliance on default constructors in security libs ??? http://cr.openjdk.java.net/~darcy/8250246.0/ ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8250248 (This is a companion to similar changes being made across other libraries in preparation for creating a new javac lint warning.) One of the classes seems to only accidentally have a constructor, so I added that one as terminally deprecated. Thanks, -Joe From hai-may.chao at oracle.com Fri Jul 24 08:25:13 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Fri, 24 Jul 2020 01:25:13 -0700 Subject: RFR 8247960: jarsigner says "signer errors" for some normal warnings when -strict is set In-Reply-To: <1C7CDB22-B51E-41B1-B4A9-084C5601B9A7@oracle.com> References: <1C7CDB22-B51E-41B1-B4A9-084C5601B9A7@oracle.com> Message-ID: <29E65196-E86D-44E5-BF0A-E1171576362B@oracle.com> > On Jul 15, 2020, at 12:16 AM, Weijun Wang wrote: > > The following lines are useless now: > Ok, this is a separate problem from the original bug to be addressed. Cleanup/refactoring of the checking on flags is also included in this changeset. > 1053 if (badKeyUsage || badExtendedKeyUsage || badNetscapeCertType || > 1054 notYetValidCert || chainNotValidated || hasExpiredCert || > 1055 hasUnsignedEntry || signerSelfSigned || (legacyAlg != 0) || > 1056 (disabledAlg != 0) || aliasNotInStore || notSignedByAlias || > 1057 tsaChainNotValidated || > 1058 (hasExpiredTsaCert && !signerNotExpired)) { > > 1198 } > > 1205 if (hasExpiringCert || > 1206 (hasExpiringTsaCert && expireDate != null) || > 1207 (noTimestamp && expireDate != null) || > 1208 (hasExpiredTsaCert && signerNotExpired)) { > > 1245 } > > I would even suggest you remove the "result" variable and move the "System.out.println(result)" line into branches of the if-else block on lines 1254-1272. Current change has the checking for sign and verify. Keep it as-is that you agreed. https://cr.openjdk.java.net/~hchao/8247960/webrev.01/ Thanks, Hai-May > > No other comments. > > Thanks, > Max > > > >> On Jul 15, 2020, at 4:09 AM, Hai-May Chao wrote: >> >> Hi, >> >> I?d like to request a review for: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8247960 >> Webrev: https://cr.openjdk.java.net/~hchao/8247960/webrev.00/ >> >> Jarsigner is changed to emit ?with signer errors? only when there are errors detected during sign and verify with -strict specified. >> >> Thanks, >> Hai-May >> > From sean.mullan at oracle.com Fri Jul 24 11:52:50 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 24 Jul 2020 07:52:50 -0400 Subject: JDK 16 RFR of JDK-8250246: Address reliance on default constructors in security libs In-Reply-To: References: Message-ID: <3ff0cde4-73d0-60bd-27b4-710510d20e5c@oracle.com> Hi Joe, On 7/24/20 1:17 AM, Joe Darcy wrote: > Hello, > > Please review a set of changes to add explicit constructors to replace > default (implicit) constructors in various classes in security libs > across several modules: > > ??? JDK-8250246: Address reliance on default constructors in security libs > ??? http://cr.openjdk.java.net/~darcy/8250246.0/ > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8250248 > > (This is a companion to similar changes being made across other > libraries in preparation for creating a new javac lint warning.) > > One of the classes seems to only accidentally have a constructor, so I > added that one as terminally deprecated. You have not updated the copyright dates; not sure if that is necessary for this type of change. - src/jdk.security.jgss/share/classes/com/sun/security/jgss/GSSUtil.java 37 /** 38 * Do not call. 39 */ 40 @Deprecated(since="16", forRemoval=true) 41 public GSSUtil() {} Is your concern that there may be some code out there that might be erroneously using the default constructor so you want to give some warning first before making this a private ctor after it is removed? (I think I agree, but I want to make sure I understand your thinking). - src/jdk.security.auth/share/classes/com/sun/security/auth/module/NTLoginModule.java 87 * Creates a {@code NTLoginModule}. s/a/an/ - src/jdk.security.auth/share/classes/com/sun/security/auth/module/LdapLoginModule.java 359 * Creates a {@code LdapLoginModule}. s/a/an/ --Sean From weijun.wang at oracle.com Fri Jul 24 13:54:36 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 24 Jul 2020 21:54:36 +0800 Subject: RFR 8247960: jarsigner says "signer errors" for some normal warnings when -strict is set In-Reply-To: <29E65196-E86D-44E5-BF0A-E1171576362B@oracle.com> References: <1C7CDB22-B51E-41B1-B4A9-084C5601B9A7@oracle.com> <29E65196-E86D-44E5-BF0A-E1171576362B@oracle.com> Message-ID: <3695107A-BC1A-4F53-9937-A0BA722EFE8E@oracle.com> I'd suggest changing + result = isSigning ? rb.getString("jar.signed.") : rb.getString("jar.verified."); + if ((strict) && (!errors.isEmpty())) { + result = isSigning ? rb.getString("jar.signed.with.signer.errors.") + : rb.getString("jar.verified.with.signer.errors."); + } to + if ((strict) && (!errors.isEmpty())) { + result = isSigning ? rb.getString("jar.signed.with.signer.errors.") + : rb.getString("jar.verified.with.signer.errors."); + } else { + result = isSigning ? rb.getString("jar.signed.") : rb.getString("jar.verified."); + } Everything else looks fine. Also, I remember you meant to fix 2 bugs with a single changeset. What should the full commit message be? Thanks, Max > On Jul 24, 2020, at 4:25 PM, Hai-May Chao wrote: > > > >> On Jul 15, 2020, at 12:16 AM, Weijun Wang wrote: >> >> The following lines are useless now: >> > > Ok, this is a separate problem from the original bug to be addressed. Cleanup/refactoring of the checking on flags is also included in this changeset. > >> 1053 if (badKeyUsage || badExtendedKeyUsage || badNetscapeCertType || >> 1054 notYetValidCert || chainNotValidated || hasExpiredCert || >> 1055 hasUnsignedEntry || signerSelfSigned || (legacyAlg != 0) || >> 1056 (disabledAlg != 0) || aliasNotInStore || notSignedByAlias || >> 1057 tsaChainNotValidated || >> 1058 (hasExpiredTsaCert && !signerNotExpired)) { >> >> 1198 } >> >> 1205 if (hasExpiringCert || >> 1206 (hasExpiringTsaCert && expireDate != null) || >> 1207 (noTimestamp && expireDate != null) || >> 1208 (hasExpiredTsaCert && signerNotExpired)) { >> >> 1245 } >> >> I would even suggest you remove the "result" variable and move the "System.out.println(result)" line into branches of the if-else block on lines 1254-1272. > > Current change has the checking for sign and verify. Keep it as-is that you agreed. > > https://cr.openjdk.java.net/~hchao/8247960/webrev.01/ > > Thanks, > Hai-May > > >> >> No other comments. >> >> Thanks, >> Max >> >> >> >>> On Jul 15, 2020, at 4:09 AM, Hai-May Chao wrote: >>> >>> Hi, >>> >>> I?d like to request a review for: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8247960 >>> Webrev: https://cr.openjdk.java.net/~hchao/8247960/webrev.00/ >>> >>> Jarsigner is changed to emit ?with signer errors? only when there are errors detected during sign and verify with -strict specified. >>> >>> Thanks, >>> Hai-May From joe.darcy at oracle.com Fri Jul 24 17:18:54 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 24 Jul 2020 10:18:54 -0700 Subject: JDK 16 RFR of JDK-8250246: Address reliance on default constructors in security libs In-Reply-To: <3ff0cde4-73d0-60bd-27b4-710510d20e5c@oracle.com> References: <3ff0cde4-73d0-60bd-27b4-710510d20e5c@oracle.com> Message-ID: Hi Sean, On 7/24/2020 4:52 AM, Sean Mullan wrote: > Hi Joe, > > On 7/24/20 1:17 AM, Joe Darcy wrote: >> Hello, >> >> Please review a set of changes to add explicit constructors to >> replace default (implicit) constructors in various classes in >> security libs across several modules: >> >> ???? JDK-8250246: Address reliance on default constructors in >> security libs >> ???? http://cr.openjdk.java.net/~darcy/8250246.0/ >> ???? CSR: https://bugs.openjdk.java.net/browse/JDK-8250248 >> >> (This is a companion to similar changes being made across other >> libraries in preparation for creating a new javac lint warning.) >> >> One of the classes seems to only accidentally have a constructor, so >> I added that one as terminally deprecated. > > You have not updated the copyright dates; not sure if that is > necessary for this type of change. Right; I run a script that handles the copyright updates before a push -- less clutter in a review like this where the per-file changes is small and reduces the possibility of spurious merge conflicts for the copyright line during the review period. > > - src/jdk.security.jgss/share/classes/com/sun/security/jgss/GSSUtil.java > > ? 37???? /** > ? 38????? * Do not call. > ? 39????? */ > ? 40???? @Deprecated(since="16", forRemoval=true) > ? 41???? public GSSUtil() {} > > Is your concern that there may be some code out there that might be > erroneously using the default constructor so you want to give some > warning first before making this a private ctor after it is removed? > (I think I agree, but I want to make sure I understand your thinking). That is my concern here, yes. We've had a number of other cases in the JDK where the default constructor appeared in an static-only class as an attractive nuisance. Before static imports, subclassing such a class was a way to get its names in the namespace of the subclass, but that is an anti-pattern that should not be encouraged. > > - > src/jdk.security.auth/share/classes/com/sun/security/auth/module/NTLoginModule.java > > 87????? * Creates a {@code NTLoginModule}. > > s/a/an/ Hmm. If the this is pronounced as "N T Login Module", "N" would be a consonant sound so should be prefixed by the indefinite article "a", no? > > - > src/jdk.security.auth/share/classes/com/sun/security/auth/module/LdapLoginModule.java > > 359????? * Creates a {@code LdapLoginModule}. > > s/a/an/ Okay. Thanks, -Joe From sean.mullan at oracle.com Fri Jul 24 17:32:57 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 24 Jul 2020 13:32:57 -0400 Subject: JDK 16 RFR of JDK-8250246: Address reliance on default constructors in security libs In-Reply-To: References: <3ff0cde4-73d0-60bd-27b4-710510d20e5c@oracle.com> Message-ID: <6f16e2d4-cf25-a5a1-3e7d-7d0551190125@oracle.com> On 7/24/20 1:18 PM, Joe Darcy wrote: >> - src/jdk.security.jgss/share/classes/com/sun/security/jgss/GSSUtil.java >> >> ? 37???? /** >> ? 38????? * Do not call. >> ? 39????? */ >> ? 40???? @Deprecated(since="16", forRemoval=true) >> ? 41???? public GSSUtil() {} >> >> Is your concern that there may be some code out there that might be >> erroneously using the default constructor so you want to give some >> warning first before making this a private ctor after it is removed? >> (I think I agree, but I want to make sure I understand your thinking). > > That is my concern here, yes. We've had a number of other cases in the > JDK where the default constructor appeared in an static-only class as an > attractive nuisance. Before static imports, subclassing such a class was > a way to get its names in the namespace of the subclass, but that is an > anti-pattern that should not be encouraged. Ok, sounds good. >> src/jdk.security.auth/share/classes/com/sun/security/auth/module/NTLoginModule.java >> >> >> 87????? * Creates a {@code NTLoginModule}. >> >> s/a/an/ > > Hmm. If the this is pronounced as "N T Login Module", "N" would be a > consonant sound so should be prefixed by the indefinite article "a", no? This might be a question for one of the grammar experts amongst us. But isn't "N" a vowel sound: "en"? --Sean >> src/jdk.security.auth/share/classes/com/sun/security/auth/module/LdapLoginModule.java >> >> >> 359????? * Creates a {@code LdapLoginModule}. >> >> s/a/an/ > > Okay. > > Thanks, > > -Joe > From joe.darcy at oracle.com Fri Jul 24 17:35:07 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 24 Jul 2020 10:35:07 -0700 Subject: JDK 16 RFR of JDK-8250246: Address reliance on default constructors in security libs In-Reply-To: <6f16e2d4-cf25-a5a1-3e7d-7d0551190125@oracle.com> References: <3ff0cde4-73d0-60bd-27b4-710510d20e5c@oracle.com> <6f16e2d4-cf25-a5a1-3e7d-7d0551190125@oracle.com> Message-ID: On 7/24/2020 10:32 AM, Sean Mullan wrote: > On 7/24/20 1:18 PM, Joe Darcy wrote: > >>> - >>> src/jdk.security.jgss/share/classes/com/sun/security/jgss/GSSUtil.java >>> >>> ? 37???? /** >>> ? 38????? * Do not call. >>> ? 39????? */ >>> ? 40???? @Deprecated(since="16", forRemoval=true) >>> ? 41???? public GSSUtil() {} >>> >>> Is your concern that there may be some code out there that might be >>> erroneously using the default constructor so you want to give some >>> warning first before making this a private ctor after it is removed? >>> (I think I agree, but I want to make sure I understand your thinking). >> >> That is my concern here, yes. We've had a number of other cases in >> the JDK where the default constructor appeared in an static-only >> class as an attractive nuisance. Before static imports, subclassing >> such a class was a way to get its names in the namespace of the >> subclass, but that is an anti-pattern that should not be encouraged. > > Ok, sounds good. > >>> src/jdk.security.auth/share/classes/com/sun/security/auth/module/NTLoginModule.java >>> >>> >>> 87????? * Creates a {@code NTLoginModule}. >>> >>> s/a/an/ >> >> Hmm. If the this is pronounced as "N T Login Module", "N" would be a >> consonant sound so should be prefixed by the indefinite article "a", no? > > This might be a question for one of the grammar experts amongst us. > But isn't "N" a vowel sound: "en"? > > I suppose looked at that way it is :-) I'll make the adjustments, copyrights, etc. and push this later today. Thanks, -Joe From hai-may.chao at oracle.com Fri Jul 24 23:32:21 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Fri, 24 Jul 2020 16:32:21 -0700 Subject: RFR 8247960: jarsigner says "signer errors" for some normal warnings when -strict is set In-Reply-To: <3695107A-BC1A-4F53-9937-A0BA722EFE8E@oracle.com> References: <1C7CDB22-B51E-41B1-B4A9-084C5601B9A7@oracle.com> <29E65196-E86D-44E5-BF0A-E1171576362B@oracle.com> <3695107A-BC1A-4F53-9937-A0BA722EFE8E@oracle.com> Message-ID: <0F21DF53-B441-47D5-A427-3728E8FAC67F@oracle.com> > On Jul 24, 2020, at 6:54 AM, Weijun Wang wrote: > > I'd suggest changing > > + result = isSigning ? rb.getString("jar.signed.") : rb.getString("jar.verified."); > + if ((strict) && (!errors.isEmpty())) { > + result = isSigning ? rb.getString("jar.signed.with.signer.errors.") > + : rb.getString("jar.verified.with.signer.errors."); > + } > > to > > + if ((strict) && (!errors.isEmpty())) { > + result = isSigning ? rb.getString("jar.signed.with.signer.errors.") > + : rb.getString("jar.verified.with.signer.errors."); > + } else { > + result = isSigning ? rb.getString("jar.signed.") : rb.getString("jar.verified."); > + } > Webrev updated as suggested. > Everything else looks fine. > > Also, I remember you meant to fix 2 bugs with a single changeset. What should the full commit message be? Fix in a single changeset, so use this bug as the commit message please. Thanks, Hai-May > > Thanks, > Max > >> On Jul 24, 2020, at 4:25 PM, Hai-May Chao wrote: >> >> >> >>> On Jul 15, 2020, at 12:16 AM, Weijun Wang wrote: >>> >>> The following lines are useless now: >>> >> >> Ok, this is a separate problem from the original bug to be addressed. Cleanup/refactoring of the checking on flags is also included in this changeset. >> >>> 1053 if (badKeyUsage || badExtendedKeyUsage || badNetscapeCertType || >>> 1054 notYetValidCert || chainNotValidated || hasExpiredCert || >>> 1055 hasUnsignedEntry || signerSelfSigned || (legacyAlg != 0) || >>> 1056 (disabledAlg != 0) || aliasNotInStore || notSignedByAlias || >>> 1057 tsaChainNotValidated || >>> 1058 (hasExpiredTsaCert && !signerNotExpired)) { >>> >>> 1198 } >>> >>> 1205 if (hasExpiringCert || >>> 1206 (hasExpiringTsaCert && expireDate != null) || >>> 1207 (noTimestamp && expireDate != null) || >>> 1208 (hasExpiredTsaCert && signerNotExpired)) { >>> >>> 1245 } >>> >>> I would even suggest you remove the "result" variable and move the "System.out.println(result)" line into branches of the if-else block on lines 1254-1272. >> >> Current change has the checking for sign and verify. Keep it as-is that you agreed. >> >> https://cr.openjdk.java.net/~hchao/8247960/webrev.01/ >> >> Thanks, >> Hai-May >> >> >>> >>> No other comments. >>> >>> Thanks, >>> Max >>> >>> >>> >>>> On Jul 15, 2020, at 4:09 AM, Hai-May Chao wrote: >>>> >>>> Hi, >>>> >>>> I?d like to request a review for: >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8247960 >>>> Webrev: https://cr.openjdk.java.net/~hchao/8247960/webrev.00/ >>>> >>>> Jarsigner is changed to emit ?with signer errors? only when there are errors detected during sign and verify with -strict specified. >>>> >>>> Thanks, >>>> Hai-May > From mbalao at redhat.com Sat Jul 25 04:35:56 2020 From: mbalao at redhat.com (Martin Balao) Date: Sat, 25 Jul 2020 01:35:56 -0300 Subject: RFR 8250582: Revert Principal Name type to NT-UNKNOWN when requesting TGS Kerberos tickets Message-ID: <1277af98-49ac-e16f-622c-134770d070d6@redhat.com> Hello Max, I'd like to propose a patch for "8250582: Revert Principal Name type to NT-UNKNOWN when requesting TGS Kerberos tickets" [1]. Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8250582/8250582.webrev.00/ This change is trivial and we are reverting to a previous (and known state). I've run tests under sun/security/krb5 and did not find any regression (125 passed). I've also run my internal Kerberos-referrals test -based on a real Active Directory environment- and worked fine. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8250582 From weijun.wang at oracle.com Sat Jul 25 04:54:25 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 25 Jul 2020 12:54:25 +0800 Subject: RFR 8250582: Revert Principal Name type to NT-UNKNOWN when requesting TGS Kerberos tickets In-Reply-To: <1277af98-49ac-e16f-622c-134770d070d6@redhat.com> References: <1277af98-49ac-e16f-622c-134770d070d6@redhat.com> Message-ID: <78C55C05-F168-4B82-9D9C-FE1C019F2DF1@oracle.com> Looks fine to me. Thanks for the quick fix. ?Max > ? 2020?7?25??12:36?Martin Balao ??? > > ?Hello Max, > > I'd like to propose a patch for "8250582: Revert Principal Name type to > NT-UNKNOWN when requesting TGS Kerberos tickets" [1]. > > Webrev.00: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8250582/8250582.webrev.00/ > > This change is trivial and we are reverting to a previous (and known > state). I've run tests under sun/security/krb5 and did not find any > regression (125 passed). I've also run my internal Kerberos-referrals > test -based on a real Active Directory environment- and worked fine. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8250582 > From ecki at zusammenkunft.net Sat Jul 25 07:03:18 2020 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sat, 25 Jul 2020 07:03:18 +0000 Subject: NPE in jarsigner -verify for broken TSA In-Reply-To: References: Message-ID: Hello, Just a little update, after implementing a jarsigner -verify after each sign operation and by retrying signatures when it fails, we could resolve the problem, when signing 50 jars one or two failed with NullPointer and worked after immediate retry. Gruss Bernd -- https://bernd.eckenfels.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Sat Jul 25 08:53:28 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 25 Jul 2020 16:53:28 +0800 Subject: NPE in jarsigner -verify for broken TSA In-Reply-To: References: Message-ID: <9A1C11B4-DF3D-46BA-B2EB-8B2605B12698@oracle.com> Hi Bernd, We've found out the problem inside JDK. There is a place where it takes for granted that a trusted chain can be built and then uses the output directly without checking for null. We'll most likely throw a SignatureException instead. Is it still the same reason that the TSA server sometimes sends the full chain and sometimes not? This is quite interesting. Thanks, Max > On Jul 25, 2020, at 3:03 PM, Bernd Eckenfels wrote: > > Hello, > > Just a little update, after implementing a jarsigner -verify after each sign operation and by retrying signatures when it fails, we could resolve the problem, when signing 50 jars one or two failed with NullPointer and worked after immediate retry. > > Gruss > Bernd > -- > https://bernd.eckenfels.net > > From xuelei.fan at oracle.com Mon Jul 27 15:21:14 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 27 Jul 2020 08:21:14 -0700 Subject: RFR JDK-8247630: Use two key share entries In-Reply-To: <2a123969-80ab-2187-61d8-2c8897b1b629@oracle.com> References: <2a123969-80ab-2187-61d8-2c8897b1b629@oracle.com> Message-ID: I was just wondering, could we just simplify the implementation by using two named groups for the top two-preferred categories, without limited to XDH and ECDHE? For example, if FFDHE is on the top 2, FFDHE will be used as well. Normally, XDH and ECDHE will be used, but the simplifying is a little bit more flexible if FFDHE is preferred. What do you think? Xuelei On 7/8/2020 3:57 PM, Jamil Nimeh wrote: > Hello all, > > This is a small enhancement to the TLS 1.3 client hello.? With this > change JSSE will make a best-effort attempt to select the most-preferred > XDH and ECDHE named group.? In most cases this will be x25519 and > secp256r1.? This was done to help reduce the number of times our clients > get HelloRetryRequests due to servers wanting secp256r1 when we would > just assert x25519. > > The asserted key shares can be affected by different settings for the > jdk.tls.namedGroups System property.? If x25519 and/or secp256r1 are > missing, the next-most-preferred named group of that class will be > selected.? If no other named group in that class is in the > supported_groups extension, then it will be skipped.? In the unlikely > event that no XDH or ECDHE supported group is asserted, then the client > will assert one key share, the most preferred one out of the supported > groups. > > This also fixes one minor spec compliance issue where we weren't > throwing an exception when a server returned an illegal > HelloRetryRequest with a named group that was in the original key_shares > extension from the client hello. > > Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8247630/webrev.01/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8247630 > > --Jamil > From xuelei.fan at oracle.com Mon Jul 27 15:44:14 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 27 Jul 2020 08:44:14 -0700 Subject: DTLS Support In-Reply-To: <2B1EBEA8-E153-4035-8C2F-A06950888B13@gmail.com> References: <2B1EBEA8-E153-4035-8C2F-A06950888B13@gmail.com> Message-ID: Hi Scott, Thanks for the feedback. May I have more information if there is a real project/requirement for the use_srtp extension? As would help me plan for the priority for the support. I'm thinking about to support more flexible extension customization, but for now it is not easy to add extension from application level. Thanks, Xuelei On 7/20/2020 11:00 AM, Scott Palmer wrote: > When DTLS support was added in > https://bugs.openjdk.java.net/browse/JDK-8043758?DTLS-SRTP and WebRTC > were specifically mentioned in the motivation. However, DTLS- SRTP > requires the ?use_srtp? extension to be in the handshake. > (https://tools.ietf.org/html/rfc5764#section-4.1) > It appears that extension is still not supported as of JDK 14. > Is support for ?use_srtp? planned? > Is there any way to add extensions to the handshake from the application > level? > If not, are there any plans to add a mechanism that would allow such > customization of the extensions used by the SSLEngine? > > > Scott From jamil.j.nimeh at oracle.com Mon Jul 27 16:11:27 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 27 Jul 2020 09:11:27 -0700 Subject: RFR JDK-8247630: Use two key share entries In-Reply-To: References: <2a123969-80ab-2187-61d8-2c8897b1b629@oracle.com> Message-ID: <2621a307-1877-019a-34e3-5709808fa2d1@oracle.com> Yes, I think I could restructure this to support that approach. You're right in that FFDHE gets the short end of the stick in the current scheme unless it's the only type in the namedGroups property and even then it takes the longest in terms of time. I'll restructure this and issue a new webrev. --Jamil On 7/27/2020 8:21 AM, Xuelei Fan wrote: > I was just wondering, could we just simplify the implementation by > using two named groups for the top two-preferred categories, without > limited to XDH and ECDHE?? For example, if FFDHE is on the top 2, > FFDHE will be used as well.? Normally, XDH and ECDHE will be used, but > the simplifying is a little bit more flexible if FFDHE is preferred.? > What do you think? > > Xuelei > > On 7/8/2020 3:57 PM, Jamil Nimeh wrote: >> Hello all, >> >> This is a small enhancement to the TLS 1.3 client hello.? With this >> change JSSE will make a best-effort attempt to select the >> most-preferred XDH and ECDHE named group.? In most cases this will be >> x25519 and secp256r1.? This was done to help reduce the number of >> times our clients get HelloRetryRequests due to servers wanting >> secp256r1 when we would just assert x25519. >> >> The asserted key shares can be affected by different settings for the >> jdk.tls.namedGroups System property.? If x25519 and/or secp256r1 are >> missing, the next-most-preferred named group of that class will be >> selected.? If no other named group in that class is in the >> supported_groups extension, then it will be skipped.? In the unlikely >> event that no XDH or ECDHE supported group is asserted, then the >> client will assert one key share, the most preferred one out of the >> supported groups. >> >> This also fixes one minor spec compliance issue where we weren't >> throwing an exception when a server returned an illegal >> HelloRetryRequest with a named group that was in the original >> key_shares extension from the client hello. >> >> Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8247630/webrev.01/ >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8247630 >> >> --Jamil >> From abdul.kolarkunnu at oracle.com Mon Jul 27 16:15:09 2020 From: abdul.kolarkunnu at oracle.com (abdul.kolarkunnu at oracle.com) Date: Mon, 27 Jul 2020 21:45:09 +0530 Subject: RFR [16] [JDK-8248745] Add jarsigner and keytool tests for restricted algorithms Message-ID: Hi All, This is a new test int the area of jarsigner and keytool for the restricted/disabled algorithms. Bug Id - https://bugs.openjdk.java.net/browse/JDK-8248745 Webrev - http://cr.openjdk.java.net/~akolarkunnu/8248745/webrev.00/ Description: Adding a test for key generation, jar signing and verification with all disabled algorithms and key sizes which are in the property jdk.jar.disabledAlgorithms. Covered the scenario of with and without these disabled entries in jdk.jar.disabledAlgorithms. Whenever the entries are in the property jdk.jar.disabledAlgorithms, corresponding warning or error message should shown, otherwise everything should work fine without any related error or warning. This test covers all entries listed in "jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, include jdk.disabled.namedCurves". In case of disabled curves, this test covers only one curve secp112r1. Tested in Linux, Windows and Mac Osx platforms and all are working fine. -Muneer From jamil.j.nimeh at oracle.com Mon Jul 27 19:28:56 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 27 Jul 2020 12:28:56 -0700 Subject: RFR JDK-8247630: Use two key share entries In-Reply-To: <2621a307-1877-019a-34e3-5709808fa2d1@oracle.com> References: <2a123969-80ab-2187-61d8-2c8897b1b629@oracle.com> <2621a307-1877-019a-34e3-5709808fa2d1@oracle.com> Message-ID: <316458a2-ca6f-e1f5-259a-2c920bb36995@oracle.com> Hi Xuelei, I've updated the webrev based on your suggestion.? It actually made the logic a lot simpler so that was a good suggestion for sure. I also added a couple additional tests in ClientHelloKeyShares.java to cover a few different namedGroup orderings. https://cr.openjdk.java.net/~jnimeh/reviews/8247630/webrev.02/ --Jamil On 7/27/20 9:11 AM, Jamil Nimeh wrote: > Yes, I think I could restructure this to support that approach. You're > right in that FFDHE gets the short end of the stick in the current > scheme unless it's the only type in the namedGroups property and even > then it takes the longest in terms of time. I'll restructure this and > issue a new webrev. > > --Jamil > > On 7/27/2020 8:21 AM, Xuelei Fan wrote: >> I was just wondering, could we just simplify the implementation by >> using two named groups for the top two-preferred categories, without >> limited to XDH and ECDHE? For example, if FFDHE is on the top 2, >> FFDHE will be used as well.? Normally, XDH and ECDHE will be used, >> but the simplifying is a little bit more flexible if FFDHE is >> preferred.? What do you think? >> >> Xuelei >> >> On 7/8/2020 3:57 PM, Jamil Nimeh wrote: >>> Hello all, >>> >>> This is a small enhancement to the TLS 1.3 client hello.? With this >>> change JSSE will make a best-effort attempt to select the >>> most-preferred XDH and ECDHE named group.? In most cases this will >>> be x25519 and secp256r1.? This was done to help reduce the number of >>> times our clients get HelloRetryRequests due to servers wanting >>> secp256r1 when we would just assert x25519. >>> >>> The asserted key shares can be affected by different settings for >>> the jdk.tls.namedGroups System property.? If x25519 and/or secp256r1 >>> are missing, the next-most-preferred named group of that class will >>> be selected.? If no other named group in that class is in the >>> supported_groups extension, then it will be skipped.? In the >>> unlikely event that no XDH or ECDHE supported group is asserted, >>> then the client will assert one key share, the most preferred one >>> out of the supported groups. >>> >>> This also fixes one minor spec compliance issue where we weren't >>> throwing an exception when a server returned an illegal >>> HelloRetryRequest with a named group that was in the original >>> key_shares extension from the client hello. >>> >>> Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8247630/webrev.01/ >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8247630 >>> >>> --Jamil >>> From swpalmer at gmail.com Mon Jul 27 20:24:16 2020 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 27 Jul 2020 16:24:16 -0400 Subject: DTLS Support In-Reply-To: References: Message-ID: <2FBD2121-BE09-4CE4-A7A9-3554E6733161@gmail.com> My goal is implementing a server that can stream video to a browser using the WebRTC standard. WebRTC has good browser support and requires only a few lines of JavaScript code on the client side making it an ideal means to send low-latency video. It has many advantages over other mechanisms like HLS. I got quite far into it, getting bits and pieces of WebRTC implemented in Java. This includes exchanging SDP Offer/Answer messages and initiating ICE/STUN/TURN protocols to establish connectivity. At that point WebRTC requires a DTLS handshake that includes the use_srtp extension in both the Client and Server Hello messages. (For media connections anyway.) I found some sample code for implementing DTLS in Java (DTLSOverDatagram.java from bug 8043758) and tried to make it work. That?s when I discovered that the use_srtp extension was not supported. I could find no way of implementing it myself using the existing classes in the JDK (SSLEngine). I had hoped, since WebRTC was explicitly called out as motivation for implementing DTLS, that the subsequent DTLS support would actually be usable to make a WebRTC media connection. It seems that while steps were made toward that goal, it wasn?t enough to get there. See the link in my initial message to RFC 5764 (section 4.1) for more information. Other implementations of WebRTC in Java (e.g. Jitsi) are forced to use the popular Bouncy Castle libraries and implement DTLS without any support from the core Java classes. That is the direction I?m pursuing now, while trying to keep things light-weight. (The Jitsi platform is massive and very poirl documented.) On another note, it would be really great if creating a certificate was supported in Java SSE. The code is there in the JDK to support keytool, but not as a publicly accessible API. A self-signed certificate is used by WebRTC. Thank you very much for your consideration. Scott > On Jul 27, 2020, at 11:44 AM, Xuelei Fan wrote: > > ?Hi Scott, > > Thanks for the feedback. May I have more information if there is a real project/requirement for the use_srtp extension? As would help me plan for the priority for the support. > > > I'm thinking about to support more flexible extension customization, but for now it is not easy to add extension from application level. > > Thanks, > Xuelei > >>> On 7/20/2020 11:00 AM, Scott Palmer wrote: >> When DTLS support was added in https://bugs.openjdk.java.net/browse/JDK-8043758 DTLS-SRTP and WebRTC were specifically mentioned in the motivation. However, DTLS- SRTP requires the ?use_srtp? extension to be in the handshake. (https://tools.ietf.org/html/rfc5764#section-4.1) >> It appears that extension is still not supported as of JDK 14. >> Is support for ?use_srtp? planned? >> Is there any way to add extensions to the handshake from the application level? >> If not, are there any plans to add a mechanism that would allow such customization of the extensions used by the SSLEngine? >> Scott From xuelei.fan at oracle.com Mon Jul 27 20:58:25 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 27 Jul 2020 13:58:25 -0700 Subject: RFR JDK-8247630: Use two key share entries In-Reply-To: <316458a2-ca6f-e1f5-259a-2c920bb36995@oracle.com> References: <2a123969-80ab-2187-61d8-2c8897b1b629@oracle.com> <2621a307-1877-019a-34e3-5709808fa2d1@oracle.com> <316458a2-ca6f-e1f5-259a-2c920bb36995@oracle.com> Message-ID: <31d08073-b108-3df8-416f-5257c7ae643a@oracle.com> Hi Jamil, Thanks for taking the comment. The webrev looks good to me. Just a few trivial comments about the coding style. No more code review is required to me. - for (NamedGroup ng : namedGroups) { + while(ngTypes.size() < 2 && ngIter.hasNext()) { I prefer to use for-each as it has a clean coding style, and maybe better performance. The loop could be broken when ngTypes.size() equals 2. + byte[] shareData; RFC 8446 defines the key share data as "key_exchange". I may update the name to keyExchangeData. I may remove the debug enable code in the test cases, to speed up the automated testing. It could be configured in the command line if needed to debug into test failure in the future. System.setProperty("javax.net.debug", "ssl:handshake"); Thanks, Xuelei On 7/27/2020 12:28 PM, Jamil Nimeh wrote: > Hi Xuelei, I've updated the webrev based on your suggestion.? It > actually made the logic a lot simpler so that was a good suggestion for > sure. > > I also added a couple additional tests in ClientHelloKeyShares.java to > cover a few different namedGroup orderings. > > https://cr.openjdk.java.net/~jnimeh/reviews/8247630/webrev.02/ > > --Jamil > > On 7/27/20 9:11 AM, Jamil Nimeh wrote: >> Yes, I think I could restructure this to support that approach. You're >> right in that FFDHE gets the short end of the stick in the current >> scheme unless it's the only type in the namedGroups property and even >> then it takes the longest in terms of time. I'll restructure this and >> issue a new webrev. >> >> --Jamil >> >> On 7/27/2020 8:21 AM, Xuelei Fan wrote: >>> I was just wondering, could we just simplify the implementation by >>> using two named groups for the top two-preferred categories, without >>> limited to XDH and ECDHE? For example, if FFDHE is on the top 2, >>> FFDHE will be used as well.? Normally, XDH and ECDHE will be used, >>> but the simplifying is a little bit more flexible if FFDHE is >>> preferred.? What do you think? >>> >>> Xuelei >>> >>> On 7/8/2020 3:57 PM, Jamil Nimeh wrote: >>>> Hello all, >>>> >>>> This is a small enhancement to the TLS 1.3 client hello.? With this >>>> change JSSE will make a best-effort attempt to select the >>>> most-preferred XDH and ECDHE named group.? In most cases this will >>>> be x25519 and secp256r1.? This was done to help reduce the number of >>>> times our clients get HelloRetryRequests due to servers wanting >>>> secp256r1 when we would just assert x25519. >>>> >>>> The asserted key shares can be affected by different settings for >>>> the jdk.tls.namedGroups System property.? If x25519 and/or secp256r1 >>>> are missing, the next-most-preferred named group of that class will >>>> be selected.? If no other named group in that class is in the >>>> supported_groups extension, then it will be skipped.? In the >>>> unlikely event that no XDH or ECDHE supported group is asserted, >>>> then the client will assert one key share, the most preferred one >>>> out of the supported groups. >>>> >>>> This also fixes one minor spec compliance issue where we weren't >>>> throwing an exception when a server returned an illegal >>>> HelloRetryRequest with a named group that was in the original >>>> key_shares extension from the client hello. >>>> >>>> Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8247630/webrev.01/ >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8247630 >>>> >>>> --Jamil >>>> From xuelei.fan at oracle.com Mon Jul 27 21:13:54 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 27 Jul 2020 14:13:54 -0700 Subject: DTLS Support In-Reply-To: <2FBD2121-BE09-4CE4-A7A9-3554E6733161@gmail.com> References: <2FBD2121-BE09-4CE4-A7A9-3554E6733161@gmail.com> Message-ID: <8e7803ff-c691-bb7f-7203-7572749eafad@oracle.com> Hi Scott, Thank you very much for the feedback. I filed a feature request: https://bugs.openjdk.java.net/browse/JDK-8250643. Please keep track of the status. Thanks, Xuelei On 7/27/2020 1:24 PM, Scott Palmer wrote: > My goal is implementing a server that can stream video to a browser using the WebRTC standard. WebRTC has good browser support and requires only a few lines of JavaScript code on the client side making it an ideal means to send low-latency video. It has many advantages over other mechanisms like HLS. > > I got quite far into it, getting bits and pieces of WebRTC implemented in Java. This includes exchanging SDP Offer/Answer messages and initiating ICE/STUN/TURN protocols to establish connectivity. > > At that point WebRTC requires a DTLS handshake that includes the use_srtp extension in both the Client and Server Hello > messages. (For media connections anyway.) > I found some sample code for implementing DTLS in Java (DTLSOverDatagram.java from bug 8043758) and tried to make it work. That?s when I discovered that the use_srtp extension was not supported. I could find no way of implementing it myself using the existing classes in the JDK (SSLEngine). > > I had hoped, since WebRTC was explicitly called out as motivation for implementing DTLS, that the subsequent DTLS support would actually be usable to make a WebRTC media connection. It seems that while steps were made toward that goal, it wasn?t enough to get there. See the link in my initial message to RFC 5764 (section 4.1) for more information. > > Other implementations of WebRTC in Java (e.g. Jitsi) are forced to use the popular Bouncy Castle libraries and implement DTLS without any support from the core Java classes. That is the direction I?m pursuing now, while trying to keep things light-weight. (The Jitsi platform is massive and very poirl documented.) > > On another note, it would be really great if creating a certificate was supported in Java SSE. The code is there in the JDK to support keytool, but not as a publicly accessible API. A self-signed certificate is used by WebRTC. > > Thank you very much for your consideration. > > > Scott > >> On Jul 27, 2020, at 11:44 AM, Xuelei Fan wrote: >> >> ?Hi Scott, >> >> Thanks for the feedback. May I have more information if there is a real project/requirement for the use_srtp extension? As would help me plan for the priority for the support. >> >> >> I'm thinking about to support more flexible extension customization, but for now it is not easy to add extension from application level. >> >> Thanks, >> Xuelei >> >>>> On 7/20/2020 11:00 AM, Scott Palmer wrote: >>> When DTLS support was added in https://bugs.openjdk.java.net/browse/JDK-8043758 DTLS-SRTP and WebRTC were specifically mentioned in the motivation. However, DTLS- SRTP requires the ?use_srtp? extension to be in the handshake. (https://tools.ietf.org/html/rfc5764#section-4.1) >>> It appears that extension is still not supported as of JDK 14. >>> Is support for ?use_srtp? planned? >>> Is there any way to add extensions to the handshake from the application level? >>> If not, are there any plans to add a mechanism that would allow such customization of the extensions used by the SSLEngine? >>> Scott From jamil.j.nimeh at oracle.com Mon Jul 27 23:03:21 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 27 Jul 2020 16:03:21 -0700 Subject: RFR JDK-8247630: Use two key share entries In-Reply-To: <31d08073-b108-3df8-416f-5257c7ae643a@oracle.com> References: <2a123969-80ab-2187-61d8-2c8897b1b629@oracle.com> <2621a307-1877-019a-34e3-5709808fa2d1@oracle.com> <316458a2-ca6f-e1f5-259a-2c920bb36995@oracle.com> <31d08073-b108-3df8-416f-5257c7ae643a@oracle.com> Message-ID: <70696cea-d8e8-b328-adbd-70e04156fe2e@oracle.com> All taken care of. https://cr.openjdk.java.net/~jnimeh/reviews/8247630/webrev.03/ --Jamil On 7/27/20 1:58 PM, Xuelei Fan wrote: > Hi Jamil, > > Thanks for taking the comment.? The webrev looks good to me. Just a > few trivial comments about the coding style.? No more code review is > required to me. > > > -??? for (NamedGroup ng : namedGroups) { > +??? while(ngTypes.size() < 2 && ngIter.hasNext()) { > > I prefer to use for-each as it has a clean coding style, and maybe > better performance.? The loop could be broken when ngTypes.size() > equals 2. > > +??? byte[] shareData; > RFC 8446 defines the key share data as "key_exchange".? I may update > the name to keyExchangeData. > > I may remove the debug enable code in the test cases, to speed up the > automated testing.? It could be configured in the command line if > needed to debug into test failure in the future. > ???? System.setProperty("javax.net.debug", "ssl:handshake"); > > Thanks, > Xuelei > > On 7/27/2020 12:28 PM, Jamil Nimeh wrote: >> Hi Xuelei, I've updated the webrev based on your suggestion.? It >> actually made the logic a lot simpler so that was a good suggestion >> for sure. >> >> I also added a couple additional tests in ClientHelloKeyShares.java >> to cover a few different namedGroup orderings. >> >> https://cr.openjdk.java.net/~jnimeh/reviews/8247630/webrev.02/ >> >> --Jamil >> >> On 7/27/20 9:11 AM, Jamil Nimeh wrote: >>> Yes, I think I could restructure this to support that approach. >>> You're right in that FFDHE gets the short end of the stick in the >>> current scheme unless it's the only type in the namedGroups property >>> and even then it takes the longest in terms of time. I'll >>> restructure this and issue a new webrev. >>> >>> --Jamil >>> >>> On 7/27/2020 8:21 AM, Xuelei Fan wrote: >>>> I was just wondering, could we just simplify the implementation by >>>> using two named groups for the top two-preferred categories, >>>> without limited to XDH and ECDHE? For example, if FFDHE is on the >>>> top 2, FFDHE will be used as well.? Normally, XDH and ECDHE will be >>>> used, but the simplifying is a little bit more flexible if FFDHE is >>>> preferred.? What do you think? >>>> >>>> Xuelei >>>> >>>> On 7/8/2020 3:57 PM, Jamil Nimeh wrote: >>>>> Hello all, >>>>> >>>>> This is a small enhancement to the TLS 1.3 client hello. With this >>>>> change JSSE will make a best-effort attempt to select the >>>>> most-preferred XDH and ECDHE named group.? In most cases this will >>>>> be x25519 and secp256r1.? This was done to help reduce the number >>>>> of times our clients get HelloRetryRequests due to servers wanting >>>>> secp256r1 when we would just assert x25519. >>>>> >>>>> The asserted key shares can be affected by different settings for >>>>> the jdk.tls.namedGroups System property.? If x25519 and/or >>>>> secp256r1 are missing, the next-most-preferred named group of that >>>>> class will be selected.? If no other named group in that class is >>>>> in the supported_groups extension, then it will be skipped.? In >>>>> the unlikely event that no XDH or ECDHE supported group is >>>>> asserted, then the client will assert one key share, the most >>>>> preferred one out of the supported groups. >>>>> >>>>> This also fixes one minor spec compliance issue where we weren't >>>>> throwing an exception when a server returned an illegal >>>>> HelloRetryRequest with a named group that was in the original >>>>> key_shares extension from the client hello. >>>>> >>>>> Webrev: >>>>> https://cr.openjdk.java.net/~jnimeh/reviews/8247630/webrev.01/ >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8247630 >>>>> >>>>> --Jamil >>>>> From xuelei.fan at oracle.com Mon Jul 27 23:42:31 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 27 Jul 2020 16:42:31 -0700 Subject: RFR JDK-8247630: Use two key share entries In-Reply-To: <70696cea-d8e8-b328-adbd-70e04156fe2e@oracle.com> References: <2a123969-80ab-2187-61d8-2c8897b1b629@oracle.com> <2621a307-1877-019a-34e3-5709808fa2d1@oracle.com> <316458a2-ca6f-e1f5-259a-2c920bb36995@oracle.com> <31d08073-b108-3df8-416f-5257c7ae643a@oracle.com> <70696cea-d8e8-b328-adbd-70e04156fe2e@oracle.com> Message-ID: Looks good to me. Thanks! Xuelei On 7/27/2020 4:03 PM, Jamil Nimeh wrote: > All taken care of. > > https://cr.openjdk.java.net/~jnimeh/reviews/8247630/webrev.03/ > > --Jamil > > On 7/27/20 1:58 PM, Xuelei Fan wrote: >> Hi Jamil, >> >> Thanks for taking the comment.? The webrev looks good to me. Just a >> few trivial comments about the coding style.? No more code review is >> required to me. >> >> >> -??? for (NamedGroup ng : namedGroups) { >> +??? while(ngTypes.size() < 2 && ngIter.hasNext()) { >> >> I prefer to use for-each as it has a clean coding style, and maybe >> better performance.? The loop could be broken when ngTypes.size() >> equals 2. >> >> +??? byte[] shareData; >> RFC 8446 defines the key share data as "key_exchange".? I may update >> the name to keyExchangeData. >> >> I may remove the debug enable code in the test cases, to speed up the >> automated testing.? It could be configured in the command line if >> needed to debug into test failure in the future. >> ???? System.setProperty("javax.net.debug", "ssl:handshake"); >> >> Thanks, >> Xuelei >> >> On 7/27/2020 12:28 PM, Jamil Nimeh wrote: >>> Hi Xuelei, I've updated the webrev based on your suggestion.? It >>> actually made the logic a lot simpler so that was a good suggestion >>> for sure. >>> >>> I also added a couple additional tests in ClientHelloKeyShares.java >>> to cover a few different namedGroup orderings. >>> >>> https://cr.openjdk.java.net/~jnimeh/reviews/8247630/webrev.02/ >>> >>> --Jamil >>> >>> On 7/27/20 9:11 AM, Jamil Nimeh wrote: >>>> Yes, I think I could restructure this to support that approach. >>>> You're right in that FFDHE gets the short end of the stick in the >>>> current scheme unless it's the only type in the namedGroups property >>>> and even then it takes the longest in terms of time. I'll >>>> restructure this and issue a new webrev. >>>> >>>> --Jamil >>>> >>>> On 7/27/2020 8:21 AM, Xuelei Fan wrote: >>>>> I was just wondering, could we just simplify the implementation by >>>>> using two named groups for the top two-preferred categories, >>>>> without limited to XDH and ECDHE? For example, if FFDHE is on the >>>>> top 2, FFDHE will be used as well.? Normally, XDH and ECDHE will be >>>>> used, but the simplifying is a little bit more flexible if FFDHE is >>>>> preferred.? What do you think? >>>>> >>>>> Xuelei >>>>> >>>>> On 7/8/2020 3:57 PM, Jamil Nimeh wrote: >>>>>> Hello all, >>>>>> >>>>>> This is a small enhancement to the TLS 1.3 client hello. With this >>>>>> change JSSE will make a best-effort attempt to select the >>>>>> most-preferred XDH and ECDHE named group.? In most cases this will >>>>>> be x25519 and secp256r1.? This was done to help reduce the number >>>>>> of times our clients get HelloRetryRequests due to servers wanting >>>>>> secp256r1 when we would just assert x25519. >>>>>> >>>>>> The asserted key shares can be affected by different settings for >>>>>> the jdk.tls.namedGroups System property.? If x25519 and/or >>>>>> secp256r1 are missing, the next-most-preferred named group of that >>>>>> class will be selected.? If no other named group in that class is >>>>>> in the supported_groups extension, then it will be skipped.? In >>>>>> the unlikely event that no XDH or ECDHE supported group is >>>>>> asserted, then the client will assert one key share, the most >>>>>> preferred one out of the supported groups. >>>>>> >>>>>> This also fixes one minor spec compliance issue where we weren't >>>>>> throwing an exception when a server returned an illegal >>>>>> HelloRetryRequest with a named group that was in the original >>>>>> key_shares extension from the client hello. >>>>>> >>>>>> Webrev: >>>>>> https://cr.openjdk.java.net/~jnimeh/reviews/8247630/webrev.01/ >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8247630 >>>>>> >>>>>> --Jamil >>>>>> From rahul.r.yadav at oracle.com Tue Jul 28 17:28:57 2020 From: rahul.r.yadav at oracle.com (Rahul Yadav) Date: Tue, 28 Jul 2020 18:28:57 +0100 Subject: RFR 8250602 : Update sun/security/ssl/SSLLogger/LoggerDateFormatterTest.java to handle TimeZones In-Reply-To: References: Message-ID: <258a11c5-a8f9-9f4e-3a5d-8498787f671b@oracle.com> Hello, Request to have my fix reviewed for issue: JDK-8250602 :? Update sun/security/ssl/SSLLogger/LoggerDateFormatterTest.java to handle TimeZones. This fix updates the test LoggerDateFormatterTest.java to be able to handle some of the edge cases for time zones where the test is run, the regex for zones has been updated to handle all the cases. Issue:? https://bugs.openjdk.java.net/browse/JDK-8250602 webrev: http://cr.openjdk.java.net/~ryadav/webrev_8250602/index.html - rahul From xuelei.fan at oracle.com Tue Jul 28 17:46:22 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 28 Jul 2020 10:46:22 -0700 Subject: RFR 8250602 : Update sun/security/ssl/SSLLogger/LoggerDateFormatterTest.java to handle TimeZones In-Reply-To: <258a11c5-a8f9-9f4e-3a5d-8498787f671b@oracle.com> References: <258a11c5-a8f9-9f4e-3a5d-8498787f671b@oracle.com> Message-ID: <033ea563-e798-eb1a-90b1-c5dc0221599e@oracle.com> Looks good to me. Thanks, Xuelei On 7/28/2020 10:28 AM, Rahul Yadav wrote: > Hello, > > Request to have my fix reviewed for issue: > > JDK-8250602 :? Update > sun/security/ssl/SSLLogger/LoggerDateFormatterTest.java to handle > TimeZones. > > This fix updates the test LoggerDateFormatterTest.java to be able to > handle some of the edge cases > for time zones where the test is run, the regex for zones has been > updated to handle all the cases. > > Issue:? https://bugs.openjdk.java.net/browse/JDK-8250602 > webrev: http://cr.openjdk.java.net/~ryadav/webrev_8250602/index.html > > - rahul From Alan.Bateman at oracle.com Tue Jul 28 18:07:10 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 28 Jul 2020 19:07:10 +0100 Subject: RFR 8250602 : Update sun/security/ssl/SSLLogger/LoggerDateFormatterTest.java to handle TimeZones In-Reply-To: <258a11c5-a8f9-9f4e-3a5d-8498787f671b@oracle.com> References: <258a11c5-a8f9-9f4e-3a5d-8498787f671b@oracle.com> Message-ID: <8afc9dd5-f737-d4cf-d4e0-e54bedd4285d@oracle.com> On 28/07/2020 18:28, Rahul Yadav wrote: > Hello, > > Request to have my fix reviewed for issue: > > JDK-8250602 :? Update > sun/security/ssl/SSLLogger/LoggerDateFormatterTest.java to handle > TimeZones. > > This fix updates the test LoggerDateFormatterTest.java to be able to > handle some of the edge cases > for time zones where the test is run, the regex for zones has been > updated to handle all the cases. > > Issue:? https://bugs.openjdk.java.net/browse/JDK-8250602 > webrev: http://cr.openjdk.java.net/~ryadav/webrev_8250602/index.html Looks good. From daniel.fuchs at oracle.com Tue Jul 28 18:39:46 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 28 Jul 2020 19:39:46 +0100 Subject: RFR 8250602 : Update sun/security/ssl/SSLLogger/LoggerDateFormatterTest.java to handle TimeZones In-Reply-To: <258a11c5-a8f9-9f4e-3a5d-8498787f671b@oracle.com> References: <258a11c5-a8f9-9f4e-3a5d-8498787f671b@oracle.com> Message-ID: Looks good Rahul! Thanks for the fix. best regards, -- daniel On 28/07/2020 18:28, Rahul Yadav wrote: > Hello, > > Request to have my fix reviewed for issue: > > JDK-8250602 :? Update > sun/security/ssl/SSLLogger/LoggerDateFormatterTest.java to handle > TimeZones. > > This fix updates the test LoggerDateFormatterTest.java to be able to > handle some of the edge cases > for time zones where the test is run, the regex for zones has been > updated to handle all the cases. > > Issue:? https://bugs.openjdk.java.net/browse/JDK-8250602 > webrev: http://cr.openjdk.java.net/~ryadav/webrev_8250602/index.html > > - rahul From RAJAN.HALADE at ORACLE.COM Wed Jul 29 06:42:33 2020 From: RAJAN.HALADE at ORACLE.COM (Rajan Halade) Date: Tue, 28 Jul 2020 23:42:33 -0700 Subject: RFR: 8243321: Add Entrust root CA - G4 to Oracle Root CA program Message-ID: <924D254A-9E3C-4E44-A864-052C3B8DEC12@ORACLE.COM> Please review this patch to add ?Entrust Root Certification Authority - G4? root certificate to cacerts store. Webrev: http://cr.openjdk.java.net/~rhalade/8243321/webrev.00/ Release note: https://bugs.openjdk.java.net/browse/JDK-8250756 Thanks, Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Jul 29 12:14:41 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 29 Jul 2020 08:14:41 -0400 Subject: RFR: 8243321: Add Entrust root CA - G4 to Oracle Root CA program In-Reply-To: <924D254A-9E3C-4E44-A864-052C3B8DEC12@ORACLE.COM> References: <924D254A-9E3C-4E44-A864-052C3B8DEC12@ORACLE.COM> Message-ID: <31c2a4b5-cd30-05ec-b76e-da59a5481455@oracle.com> Looks good. --Sean On 7/29/20 2:42 AM, Rajan Halade wrote: > Please review this patch to add ?Entrust Root Certification Authority - > G4? root certificate to cacerts store. > > Webrev: http://cr.openjdk.java.net/~rhalade/8243321/webrev.00/ > Release note: https://bugs.openjdk.java.net/browse/JDK-8250756 > > Thanks, > Rajan > From alexey at azul.com Thu Jul 30 09:17:11 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 30 Jul 2020 09:17:11 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <8804341B-E534-4FA8-A652-86F8A30F18B3@azul.com> References: <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com> <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com> <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com> <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com> <2267CBC7-85A9-4105-B405-E7499440B985@azul.com> <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com> <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com> <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com> <643f3744-cfa2-e871-1284-900d81709f53@oracle.com> <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com> <7621fa33-26cc-d545-cb33-a93fdbfd48c7@oracle.com> <8804341B-E534-4FA8-A652-86F8A30F18B3@azul.com> Message-ID: <999EF4D0-4084-4EC2-803C-EDC23D3EB8F2@azul.com> Gentle ping Regards Alexey > On 15 Jul 2020, at 14:18, Alexey Bakhtin wrote: > > Hello Daniel, > > I?ve updated CSR as you suggested and added kerberos ldap setup commands for the client host in the JDK-8245527 > > Regards > Alexey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From daniel.fuchs at oracle.com Thu Jul 30 10:14:46 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 30 Jul 2020 11:14:46 +0100 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <999EF4D0-4084-4EC2-803C-EDC23D3EB8F2@azul.com> References: <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com> <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com> <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com> <2267CBC7-85A9-4105-B405-E7499440B985@azul.com> <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com> <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com> <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com> <643f3744-cfa2-e871-1284-900d81709f53@oracle.com> <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com> <7621fa33-26cc-d545-cb33-a93fdbfd48c7@oracle.com> <8804341B-E534-4FA8-A652-86F8A30F18B3@azul.com> <999EF4D0-4084-4EC2-803C-EDC23D3EB8F2@azul.com> Message-ID: Hi Alexey, I have added myself as a reviewer to the CSR [1]. It would be good to get someone from security-dev to do the same, and then move the CSR state to "Proposed". best regards, -- daniel [1] https://bugs.openjdk.java.net/browse/JDK-8247311 On 30/07/2020 10:17, Alexey Bakhtin wrote: > Gentle ping > > Regards > Alexey From xuelei.fan at oracle.com Thu Jul 30 18:26:36 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 30 Jul 2020 11:26:36 -0700 Subject: RFR JDK-8250839: Improve test template SSLEngineTemplate with SSLContextTemplate Message-ID: Hi, May I get the following test code update reviewed? http://cr.openjdk.java.net/~xuelei/8250839/webrev.00/ SSLEngineTemplate is a template used for SSLEngine testing, which depends on binary key store files, and not easy to extend. This update makes it easier to extend, by removing the files dependency and using SSLContextTemplate. Thanks, Xuelei From RAJAN.HALADE at ORACLE.COM Thu Jul 30 23:22:35 2020 From: RAJAN.HALADE at ORACLE.COM (Rajan Halade) Date: Thu, 30 Jul 2020 16:22:35 -0700 Subject: RFR: 8243320: Add SSL root certificates to Oracle Root CA program Message-ID: <462A7876-AC17-4CEA-84CD-7105B39FA63C@ORACLE.COM> Please review this patch to add SSL Corporation issued root CA certificates to cacerts. Webrev: http://cr.openjdk.java.net/~rhalade/8243320/webrev.00/ Release Note: https://bugs.openjdk.java.net/browse/JDK-8250860 Thanks, Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Jul 31 12:49:28 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 31 Jul 2020 08:49:28 -0400 Subject: RFR: 8243320: Add SSL root certificates to Oracle Root CA program In-Reply-To: <462A7876-AC17-4CEA-84CD-7105B39FA63C@ORACLE.COM> References: <462A7876-AC17-4CEA-84CD-7105B39FA63C@ORACLE.COM> Message-ID: <7becc73f-8a91-1fd1-e099-b0d33b9a82bc@oracle.com> Looks good. --Sean On 7/30/20 7:22 PM, Rajan Halade wrote: > Please review this patch to add SSL Corporation issued root CA > certificates to cacerts. > > Webrev: http://cr.openjdk.java.net/~rhalade/8243320/webrev.00/ > Release Note: https://bugs.openjdk.java.net/browse/JDK-8250860 > > Thanks, > Rajan > From John.Mahoney at entrustdatacard.com Tue Jul 7 00:55:46 2020 From: John.Mahoney at entrustdatacard.com (John Mahoney) Date: Tue, 07 Jul 2020 00:55:46 -0000 Subject: [EXTERNAL]Re: SecureRandom regression with certain security providers In-Reply-To: References: <2HnXazk66-nxoiS5rxih3yQnqfj2EePRDjdw0P7z8YN4Dr3iqR5WBcHoIM7U8ZIquneZ60ridpBTRPjuYaAmTvTZ11lOT2twH2PlEwzBfm8=@protonmail.com> <85ac45ca-28c7-a17b-57cb-b7f35d1ce731@oracle.com> <8840c02b-cec6-1ef9-4b5d-1649b1d93bba@oracle.com> <684222be-3b19-937e-9066-c53c69474cb8@oracle.com> <405c49ec-8295-49a2-f7e4-002b393a05c3@oracle.com> Message-ID: Thank you Valerie. Unfortunately this will have to wait until John is back from vacation (back on the 13th) From: Valerie Peng [mailto:valerie.peng at oracle.com] Sent: Monday, July 6, 2020 8:02 PM To: John Gray ; security-dev at openjdk.java.net Cc: John Mahoney Subject: Re: [EXTERNAL]Re: SecureRandom regression with certain security providers BTW, I have tentatively filed https://bugs.openjdk.java.net/browse/JDK-8248885 for Entrust NSAE problem. Just FYI. Valerie On 7/6/2020 12:07 PM, Valerie Peng wrote: Hi John, Thanks for looking into this on your end. It's interesting how Entrust has to do this deletion/re-insertion of providers and it's interesting that adding a new instance of Entrust provider inside the Security.insertProviderAt() call makes this problem go away. Please find my questions and comments in line below. On 7/3/2020 1:13 PM, John Gray wrote: Thanks for your comments! They sparked off a lot more investigation on my end. I created a test provider and could not reproduce the issue. That led me to investigate how our provider was being installed. We use our own internal Initializer() class to install providers in various orders (we have had to work around bugs in different JVM's in the past). That work-around required we remove the provider from the Security provider list (basically to clean it out), then we run a simple crypto test with a new instantiation, and then install that provider in 1st position. Does this Initializer() class does all this before the new SecureRandom() call? Does the Entrust provider remove or changes its registrations ever, i.e. is the provider mutable? One possible scenario for legacy provider which add/remove registrations is that every update to the legacy map will leads to new re-parsing and new service being created as a result which may leads to failing the check inside Service.newInstance() call and thus the NSAE. If I change the highlighted line above (the last line) to the following, it works. Security.insertProviderAt(new Entrust(), 1); Having to make such a change seems strange. It seems that creating a new provider, using it to get an instance of an algorithm, and then adding that same provider into first position doesn?t work. I'm guessing because of the recent changes you made the provider can?t be used before it is inserted into the provider order because it may hold onto some data from the previous usage? So this led me to investigate some more?.. Yes, it's indeed strange. Is the "entrustCsp" instance being modified in anyway after its creation? When it fails, the type and algorithm are ?SecureRandom? and ?DRBGUsingSHA512? Is ?DRBGUsingSHA512" the expected default algorithm for Entrust provider? Is it being picked up as expected if basing on registration ordering? The Provider.getService() code fails to match the ?previousKey? ServiceKey type and algorithms. In my test code I was testing an AES algorithm, so the previous key type and Algorithm is ?Cipher? and ?AES/CBC/PKCS5PADDING? in the getService() call which doesn?t match the type ?SecureRandom? and ?DRBGUsingSHA512?. So it looks like there is a bug caused by holding on to existing data. The previousKey is just an optimization to avoid repetitive allocation on the same type and algorithm. If either of these two does not match, it will be discarded and new key object created for subsequent calls. So, this should not be the root cause. So I think when I create a brand new Entrust() instance it works because the previous ServiceKey() contains the correct data and it matches. Debugging showed it to work that way. So I think using a provider before installing it in the provider order is what is causing the issue because of internal data in the Provider class. There is something deeper for the Entrust NSAE problem instead of the previousKey usage per my comment above. Could you please double check the Initializer class and whether the Entrust provider entries are modified after it's constructed and when new SecureRandom() is called? Thanks for looking into this~ Valerie It looks like I *could* put in this weird work-around (just create a fresh instance of Entrust()) when installing the provider to work around the issue, but I wonder if there will be other consequences because of the way this previousKey is used? I can make the simple change to our toolkit without breaking FIPS (the initialization class is not in the FIPS boundary). In fact, I assume I don?t need to keep that old work-around for the old IBM JVM anymore either.. Thanks for your help! Happy July 4th (I live in Ottawa Canada, so we had our muted Canada day celebrations a couple days ago on July 1st). John Gray -----Original Message----- From: Valerie Peng [mailto:valerie.peng at oracle.com] Sent: Thursday, July 2, 2020 8:34 PM To: John Gray ; security-dev at openjdk.java.net Cc: John Mahoney ; Muthu Kannappan Subject: Re: [EXTERNAL]Re: SecureRandom regression with certain security providers Hi John, Unfortunately this cannot wait til July 13th if this issue needs to be fixed for jdk 15. Maybe you can try the webrev out or share more details on how Entrust provider does its registration and what Provider APIs it overrides. I need more info to help identifying the trigger for the NSAE in Entrust's case. I have verified that the current webrev works with BCFIPS provider. Regards and an early happy July 4th, Valerie On 7/2/2020 3:17 PM, Valerie Peng wrote: > I can certainly help you verify the fix. Let me know how I can help > verify it for you. ?? > > Note: I will be on vacation next week, so I'll be back July 13th... -------------- next part -------------- An HTML attachment was scrubbed... URL: From MClaassen at ocie.net Wed Jul 8 14:22:44 2020 From: MClaassen at ocie.net (Mark A. Claassen) Date: Wed, 08 Jul 2020 14:22:44 -0000 Subject: Browser's accepting certificates that Java does not In-Reply-To: <1bbd048b-5530-c187-d313-e3a811217957@oracle.com> References: <46a3a1a636dc4d4dab9958d294aee83d@MailCorp01.ocie.net> <1bbd048b-5530-c187-d313-e3a811217957@oracle.com> Message-ID: Wow. Thank you so much! I need to read this all more thoroughly. I really appreciate the suggestions and the help getting this on the correct mailing list. Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN? 46601 E-mail: mailto:mclaassen at ocie.net Voice: (574)232-3784 Fax: (574)232-4014 ? Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. -----Original Message----- From: net-dev On Behalf Of Sean Mullan Sent: Wednesday, July 8, 2020 9:38 AM To: Bernd Eckenfels ; OpenJDK Cc: net-dev at openjdk.java.net Subject: Re: Browser's accepting certificates that Java does not Also, in case you did not know, the JDK "PKIX" CertPathBuilder implementation (which is also the default used by the JSSE TrustManager) supports retrieving certificates via the AIA extension, but it is disabled by default. To enable it, set the "com.sun.security.enableAIAcaIssuers" system property to the value "true". --Sean On 7/8/20 5:27 AM, Bernd Eckenfels wrote: > Note that many browsers also download certs from the AIA and even > "well known" mechanisms. It won't help to access more truststores, > that would be a function you need to prove directly. Also the dynamic > installation from Windows Updates or offline from crypt32.dll is not > triggered when only browsing the existing stores. > > If you need that kind of integration it's probably better do not use > java :) > > Chrome does install those dynamically loaded intermiates to Windows > truststores, I think - it would not hurt to get access to it. > > > -- > http://bernd.eckenfels.net > ---------------------------------------------------------------------- > -- > *Von:* security-dev im Auftrag > von Daniel Fuchs > *Gesendet:* Wednesday, July 8, 2020 11:09:26 AM > *An:* Mark A. Claassen ; OpenJDK > > *Cc:* net-dev at openjdk.java.net > *Betreff:* Re: Browser's accepting certificates that Java does not Hi > Mark, > > This is probably a question for the security-dev mailing list, which I > have put in the to: of my reply. > > best regards, > > -- daniel > > On 07/07/2020 20:24, Mark A. Claassen wrote: >> I was curious if there has been any thought to allowing accessing to >> other certificate stores in Windows besides the "Trusted Root >> Certification Authorities" and the "Personal" ones.? It seems like >> web servers omitting intermediate certificates in the certificate >> chain is pretty common.? Browsers seems to fill in the gaps, but Java > does not. >> >> We very recently encountered this again when a customer started >> proxying their SSL requests, creating a new certificate on the fly, >> resigning ours with their corporate CA.? (The browser handled this >> fine, but our Java app detected a chain length of 2, instead of 4 >> like in the browser.)? Having them put their intermediate > certificates in the "Trusted Root Certification Authorities" solved > the issue, but they are unwilling to do this on a corporate-wide basis. >> >> If Java was able to access more keystores through the MSCAPI >> interface, is seems like it would fill in the gaps as well and remove >> a pain point we are experiencing where Java does not accept a >> certificate even though all their browsers will.? I think all >> intermediate certificates are supposed to be in the chain sent from > the server (https://tools.ietf.org/html/rfc5246) in the TLS > negotiation, but since browser's don't enforce care, people are left > thinking everything is great (until Java tries to connect). >> >> Thanks, >> >> Mark Claassen >> Senior Software Engineer >> >> Donnell Systems, Inc. >> 130 South Main Street >> Leighton Plaza Suite 375 >> South Bend, IN? 46601 >> E-mail: mailto:mclaassen at ocie.net >> Voice: (574)232-3784 >> Fax: (574)232-4014 >> >> Disclaimer: >> The opinions provided herein do not necessarily state or reflect >> those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and >> assumes no legal liability or responsibility for the posting. >> >