From ivan.gerasimov at oracle.com Tue Oct 1 20:26:05 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 1 Oct 2019 13:26:05 -0700 Subject: RFR (S) 8230407 : SocketPermission and FilePermission action list allows leading comma Message-ID: Hello! The constructors of SocketPermission and FilePermission expect a String argument with comma-separated list of actions. If the list is malformed, then the constructors throw IllegalArgumentException. It turns out that the current implementation fails to throw IAE if the list starts with a leading comma. Would you please help review a simple fix, which will make the behavior more consistent? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230407 WEBREV: http://cr.openjdk.java.net/~igerasim/8230407/00/webrev/ -- With kind regards, Ivan Gerasimov From chris.hegarty at oracle.com Wed Oct 2 13:44:41 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 2 Oct 2019 14:44:41 +0100 Subject: RFR (S) 8230407 : SocketPermission and FilePermission action list allows leading comma In-Reply-To: References: Message-ID: <23ef065b-bdd6-2729-7afd-47aaed5d4943@oracle.com> Ivan, On 01/10/2019 21:26, Ivan Gerasimov wrote: > Hello! > > The constructors of SocketPermission and FilePermission expect a String > argument with comma-separated list of actions. > > If the list is malformed, then the constructors throw > IllegalArgumentException. > > It turns out that the current implementation fails to throw IAE if the > list starts with a leading comma. > > Would you please help review a simple fix, which will make the behavior > more consistent? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230407 > WEBREV: http://cr.openjdk.java.net/~igerasim/8230407/00/webrev/ The implementation changes look ok. The SocketPermission constructor should be updated to specify IAE too, right? -Chris. From ivan.gerasimov at oracle.com Wed Oct 2 23:26:05 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 2 Oct 2019 16:26:05 -0700 Subject: RFR (S) 8230407 : SocketPermission and FilePermission action list allows leading comma In-Reply-To: <23ef065b-bdd6-2729-7afd-47aaed5d4943@oracle.com> References: <23ef065b-bdd6-2729-7afd-47aaed5d4943@oracle.com> Message-ID: Hi Chris! Thank you very much for review! I agree that it makes sense to update the javadoc for consistency. I don't think CSR is required in this case, is it? (IAE is unchecked anyway, and the fix doesn't really change the behavior.) Here's the updated webrev: http://cr.openjdk.java.net/~igerasim/8230407/01/webrev/ With kind regards, Ivan On 10/2/19 6:44 AM, Chris Hegarty wrote: > Ivan, > > On 01/10/2019 21:26, Ivan Gerasimov wrote: >> Hello! >> >> The constructors of SocketPermission and FilePermission expect a >> String argument with comma-separated list of actions. >> >> If the list is malformed, then the constructors throw >> IllegalArgumentException. >> >> It turns out that the current implementation fails to throw IAE if >> the list starts with a leading comma. >> >> Would you please help review a simple fix, which will make the >> behavior more consistent? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230407 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8230407/00/webrev/ > > The implementation changes look ok. > > The SocketPermission constructor should be updated to specify IAE too, > right? > > -Chris. > > -- With kind regards, Ivan Gerasimov From joe.darcy at oracle.com Wed Oct 2 23:38:34 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 2 Oct 2019 16:38:34 -0700 Subject: RFR (S) 8230407 : SocketPermission and FilePermission action list allows leading comma In-Reply-To: References: <23ef065b-bdd6-2729-7afd-47aaed5d4943@oracle.com> Message-ID: <81df8c76-c7da-b61c-a88a-d7429e77a1bd@oracle.com> Hello, At least from a quick reading, either the spec change or the behavior change would seem to merit a CSR. Cheers, -Joe On 10/2/2019 4:26 PM, Ivan Gerasimov wrote: > Hi Chris! > > Thank you very much for review! > > I agree that it makes sense to update the javadoc for consistency. > > I don't think CSR is required in this case, is it? (IAE is unchecked > anyway, and the fix doesn't really change the behavior.) > > Here's the updated webrev: > > http://cr.openjdk.java.net/~igerasim/8230407/01/webrev/ > > With kind regards, > > Ivan > > > On 10/2/19 6:44 AM, Chris Hegarty wrote: >> Ivan, >> >> On 01/10/2019 21:26, Ivan Gerasimov wrote: >>> Hello! >>> >>> The constructors of SocketPermission and FilePermission expect a >>> String argument with comma-separated list of actions. >>> >>> If the list is malformed, then the constructors throw >>> IllegalArgumentException. >>> >>> It turns out that the current implementation fails to throw IAE if >>> the list starts with a leading comma. >>> >>> Would you please help review a simple fix, which will make the >>> behavior more consistent? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230407 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8230407/00/webrev/ >> >> The implementation changes look ok. >> >> The SocketPermission constructor should be updated to specify IAE >> too, right? >> >> -Chris. >> >> From valerie.peng at oracle.com Thu Oct 3 00:09:01 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 2 Oct 2019 17:09:01 -0700 Subject: [14] RFR JDK-8229243 "SunPKCS11-Solaris provider tests failing on Solaris 11.4" In-Reply-To: <2acfd22a-7682-d7d8-a49d-516f0a064abd@oracle.com> References: <2acfd22a-7682-d7d8-a49d-516f0a064abd@oracle.com> Message-ID: During the pre-integration mach5 run, I ran into a window-specific data alignment problem when the custom GCM param structure is declared inside pkcs11wrapper.h in webrev.01. So, I ended up adding a separate header file pkcs11gcm2.h containing only this structure and include it in the platform-specific header p11_md.h so the current logic of using sizeof() works as expected. Mach5 run and Solaris 11.4 run pass as expected with webrev.02. http://cr.openjdk.java.net/~valeriep/8229243/webrev.02/ If there are more comments, please let me know in a few days. Thanks! Valerie On 9/24/2019 9:45 PM, Valerie Peng wrote: > Great, thanks for the review and feedback~ > > Valerie > > On 9/24/2019 9:20 PM, Xuelei Fan wrote: >> I looked at the latest webrev: >> ? http://cr.openjdk.java.net/~valeriep/8229243/webrev.01/ >> >> Which is good to me. >> >> Thanks, >> Xuelei >> >> On 9/19/2019 5:46 PM, Valerie Peng wrote: >>> >>> I am not on the PKCS#11 committee and not sure about the plan. >>> As for which one is right, I am more inclined to the "spec is right" >>> side which is also what NSS picked. >>> Comparing between spec and header, shouldn't the former get more >>> eyeballs in terms of review? >>> The header file also has a deprecated structure CK_AES_GCM_PARAMS >>> which contains both ulIvLen and ulIvBits fields. >>> As ulIvBits and ulIvLen are essentially same in terms of meaning >>> except bytes vs bits. Having both just creates confusion and >>> potential inconsistency and makes not much sense to me. >>> >>> Valerie >>> >>> ----- Original Message ----- >>> From: xuelei.fan at oracle.com >>> To: valerie.peng at oracle.com, security-dev at openjdk.java.net >>> Sent: Thursday, September 19, 2019 7:47:43 AM GMT -08:00 US/Canada >>> Pacific >>> Subject: Re: [14] RFR JDK-8229243 "SunPKCS11-Solaris provider tests >>> failing on Solaris 11.4" >>> >>> Will the inconsistency structure be continue?? I was just wondering if >>> OpenHSM2/Solaris/NSS will fix the bug and use one structure in the >>> future, then we may not need to workaround the issue in the calling >>> side. >>> >>> I had a quick look the PKCS#11 3.0 draft, there is no update of the >>> structure yet. >>> >>> Xuelei >>> >>> On 9/18/2019 6:01 PM, Valerie Peng wrote: >>>> Ping? >>>> >>>> Can someone help take a look? >>>> >>>> Thanks, >>>> >>>> Valerie >>>> >>>> On 8/15/2019 4:49 PM, Valerie Peng wrote: >>>>> >>>>> Anyone has time to help review this fix? PKCS#11 v2.40 has >>>>> inconsistent definition for CK_GCM_PARAMS struct. The mechanism spec >>>>> (sec 2..12.3) has: >>>>> >>>>> ???? typedef struct CK_GCM_PARAMS { >>>>> ???? ??? CK_BYTE_PTR?????? pIv; >>>>> ???? ??? CK_ULONG????????? ulIvLen; >>>>> ???? ??? CK_BYTE_PTR?????? pAAD; >>>>> ???? ??? CK_ULONG????????? ulAADLen; >>>>> ???? ??? CK_ULONG????????? ulTagBits; >>>>> ???? } CK_GCM_PARAMS; >>>>> >>>>> However, the header file pkcs11t.h has an extra "ulIvBits" field: >>>>> >>>>> ???? typedef struct CK_GCM_PARAMS { >>>>> ???? ??? CK_BYTE_PTR?????? pIv; >>>>> ???? ??? CK_ULONG????????? ulIvLen; >>>>> ???? *??? CK_ULONG????????? ulIvBits;* >>>>> ???? ??? CK_BYTE_PTR?????? pAAD; >>>>> ???? ??? CK_ULONG????????? ulAADLen; >>>>> ???? ??? CK_ULONG????????? ulTagBits; >>>>> ???? } CK_GCM_PARAMS; >>>>> >>>>> Some vendors such OpenHSM2 and Solaris go with the header file while >>>>> some vendor such as NSS go with the mech spec. Current SunPKCS11 >>>>> provider impl works with NSS but not with other vendors whose >>>>> CK_GCM_PARAMS struct contains ulIvBits field. Based on testing >>>>> results, OpenHSM2 and Solaris error out at init time when the >>>>> parameter length does not have their expected value. Thus, one way to >>>>> workaround this inconsistency is to re-try with a different structure >>>>> for AES GCM when the init failed. In addition, given the parameters >>>>> contains Iv and AAD which some vendor may use during subsequent >>>>> enc/dec operations, I changed to use the same model as RSASSA-PSS to >>>>> defer the freeing after the enc/dec operation is finished. Verified >>>>> the changes on Solaris 11.4 against existing GCM regression tests. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229243 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8229243/webrev.00/ >>>>> >>>>> Thanks, >>>>> Valerie From ivan.gerasimov at oracle.com Thu Oct 3 03:41:20 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 2 Oct 2019 20:41:20 -0700 Subject: RFR (S) 8230407 : SocketPermission and FilePermission action list allows leading comma In-Reply-To: <81df8c76-c7da-b61c-a88a-d7429e77a1bd@oracle.com> References: <23ef065b-bdd6-2729-7afd-47aaed5d4943@oracle.com> <81df8c76-c7da-b61c-a88a-d7429e77a1bd@oracle.com> Message-ID: Thank you Joe for checking it! On 10/2/19 4:38 PM, Joe Darcy wrote: > Hello, > > At least from a quick reading, either the spec change or the behavior > change would seem to merit a CSR. > Sigh.? I was hopping it'll be a quick fix :-) So, I filed CSR: https://bugs.openjdk.java.net/browse/JDK-8231805 to cover the addition of @throws paragraph in the javadoc of SocketPermission. I would really appreciate it, if someone helped to review it. W.r.t the behavior change, I don't think the fix has to be counted as such. ? Current implementation already would throw IllegalArgumentException if the action list were malformed (for example if it were " , accept", or "connect,,accept", or "connect,", etc.)? The only case when it would *not* throw IAE is when the argument *immediately* starts with a comma, and that's what the fix is about. It's not like if we used to allow commas in arbitrary places and stopped doing that.? Instead, it just turned out that the code fails to catch one specific pattern of malformed action list. With kind regards, Ivan > Cheers, > > -Joe > > On 10/2/2019 4:26 PM, Ivan Gerasimov wrote: >> Hi Chris! >> >> Thank you very much for review! >> >> I agree that it makes sense to update the javadoc for consistency. >> >> I don't think CSR is required in this case, is it? (IAE is unchecked >> anyway, and the fix doesn't really change the behavior.) >> >> Here's the updated webrev: >> >> http://cr.openjdk.java.net/~igerasim/8230407/01/webrev/ >> >> With kind regards, >> >> Ivan >> >> >> On 10/2/19 6:44 AM, Chris Hegarty wrote: >>> Ivan, >>> >>> On 01/10/2019 21:26, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> The constructors of SocketPermission and FilePermission expect a >>>> String argument with comma-separated list of actions. >>>> >>>> If the list is malformed, then the constructors throw >>>> IllegalArgumentException. >>>> >>>> It turns out that the current implementation fails to throw IAE if >>>> the list starts with a leading comma. >>>> >>>> Would you please help review a simple fix, which will make the >>>> behavior more consistent? >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230407 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8230407/00/webrev/ >>> >>> The implementation changes look ok. >>> >>> The SocketPermission constructor should be updated to specify IAE >>> too, right? >>> >>> -Chris. >>> >>> > -- With kind regards, Ivan Gerasimov -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Thu Oct 3 06:40:52 2019 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 3 Oct 2019 08:40:52 +0200 Subject: RFR (S) 8230407 : SocketPermission and FilePermission action list allows leading comma In-Reply-To: References: Message-ID: <5e3525d3-bced-f65d-8fb3-b4cf3bae6ca2@gmail.com> Hi Ivan, On 10/1/19 10:26 PM, Ivan Gerasimov wrote: > Hello! > > The constructors of SocketPermission and FilePermission expect a > String argument with comma-separated list of actions. > > If the list is malformed, then the constructors throw > IllegalArgumentException. > > It turns out that the current implementation fails to throw IAE if the > list starts with a leading comma. > > Would you please help review a simple fix, which will make the > behavior more consistent? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230407 > WEBREV: http://cr.openjdk.java.net/~igerasim/8230407/00/webrev/ > With new switch expressions the logic could be a little clearer. For example: ??????????? for (boolean seencomma = false; i >= matchlen && !seencomma; i--) { ??????????????? seencomma = switch (a[i - matchlen]) { ??????????????????? case ' ', '\r', '\n', '\f', '\t': yield false; ??????????????????? case ',': if (i > matchlen) yield true; ??????????????????? default: throw new IllegalArgumentException( ??????????????????????????????? "invalid permission: " + actions); ??????????????? }; ??????????? } This is still experimental, but I think it will be proposed to be standard soon. If you want to backport it later, then maybe you don't want to do that now. Regards, Peter From j08ny at mail.muni.cz Thu Oct 3 09:14:54 2019 From: j08ny at mail.muni.cz (=?UTF-8?B?SsOhbiBKYW7EjcOhcg==?=) Date: Thu, 3 Oct 2019 11:14:54 +0200 Subject: Minerva vulnerability + patch Message-ID: Hi all, we have recently disclosed a vulnerability in ECDSA on binary field curves in the SunEC library used in OpenJDK at: https://minerva.crocs.fi.muni.cz We have prepared a patch for this earlier, which was sent to Oracle along with the report of the vulnerability. As the vulnerability is not fixed at this time, I am resending the patch here. *Vulnerability description* Timing leak in ECDSA signature generation on binary field curves (ec2) in the SunEC library (libsunec.so). The library essentially leaks the bit-length of the secret nonce used in the scalar multiplication via the duration of scalar multiplication. This leak is present in all scalar multiplication on binary field curves in SunEC, but can be abused in the case of ECDSA, where an attacker that is able to measure the duration of signing of a few hundreds or thousands of known messages can use a lattice attack based on the Hidden Number Problem [1] to reconstruct the private key used, as demonstrated in [2]. *Issue* The issue is in ec_GF2m_pt_mul_mont in ec2_mont.c which starts the Montgomery ladder at the most significant set bit thus leaking bit-length by the duration of the loop. This is necessary because the addition formulas used are incomplete (they cannot handle the point at infinity correctly) and thus the computation of the ladder cannot start past the end of the scalar at some fixed bit-length (of the order of the curve for example). If it did, the variables (x1, z1) would have to be initialized with the point at infinity, which is not even representable in the coordinates that are used here. *Affected* Java 7 - Java 12 (current master) seems to all be affected, because ec_GF2m_pt_mul_mont was not changed during that time and ECDSA_SignDigestWithSeed calls it through this call chain: ECDSA_SignDigestWithSeed -> ec_points_mul -> ECPoints_mul -> group->points_mul == ec_pts_mul_basic -> ECPoint_mul -> group->point_mul == ec_GF2m_pt_mul_mont Notice also the pointless detour through the multi-scalar multiplication functions which then short circuit to the single-scalar multiplication function when only one input is provided. *Mitigation* One mitigation, that was presented in [2] and is used in quite a few libraries, is to blind the bit-length of the secret nonce (and any secret scalar used in EC point multiplication, so private key in ECDH, etc.) as follows: Instead of computing [k]G, with k being the nonce, compute k* = k + 2*n (if log_2(k + n) = log_2(n)) = k + n (else) then compute [k*]G, which = [k]G, because n is the order of the subgroup. The log_2(k*) is then a fixed value, so nothing leaks. This fixes the bit-length of k*, such that the distribution of k = k* mod n remains unaffected (and so ECDSA is ok with regards to lattice attacks on biased nonces) and [k*]G = [k]G so the mitigation is correct. Other mitigations might include using complete addition formulas, which will allows the ladder to start at any bit past the end of the scalar, thus it might be fixed to the order bit-length. The patch does the following to fix the issue: - ec.c: * Splits ec_points_mul to ec_point_mul and ec_points_mul, so that the single-scalar multiplication doesn't go through ECPoints_mul and the multi-scalar functions. * Cleans up some ifdef'ed code that really has no purpose to be there. * Adds the mitigation to the ECDSA sign function. - ecl_mult.c, ecl.h: * Introduces an argument to the ECPoint_mul and ECPoints_mul function that specifies whether to reduce the scalar modulo the order or not. This is necessary because the mitigation in ECDSA adjust the scalar to be bigger than the order. So reducing here would negate the effect. This argument is false (not reduce) only in the ECDSA sign call site. - ecp_jm.c: * Changes the orderBitSize bound in the ec_GFp_pt_mul_jm_wNAF function to take the maximum of the order bit size and the scalar bit size. For reduced scalars, this is constant and is equal to the order bit size. For scalars produced as a result of the above mitigation, this is larger than the order bit size, but still constant. - ecp_aff.c, ec2_aff.c: * Use the new parameter to the ECPoint_mul function in the pubkey validation functions. After applying this patch, all tests passed on my end, I tested with: make test TEST="sun/security/ec" With this patch applied, one issue could still be present. Since the scalars passed to the scalar multiplication function will not be reduced, there is a possibility that the point at infinity is reached as an intermediate value during computation. Looking at the prime field code, there it should not be an issue, as the formulas handle the case of a point at infinity by short circuiting and returning the correct value. The timing difference by the short-circuit would be minuscule in this case and mitigated by the currently applied timing measure. Looking at the binary field case might pose a problem currently, as the formulas are incomplete (which is actually the root cause of this whole vulnerability) and do not short-circuit on the point at infinity. This point doesn't really have a representation in the coordinates used, but could be represented and detected as (0, 0), then the formulas could be made to handle this and short-circuit to the correct result. It can be shown that for scalars of the form k + n or k + 2n, with k in [1, n-1], the intermediate value of [n]G or [2n]G is is only reached in Montgomery ladder for a few values so that this is actually not an issue. [1]: D. Boneh, R. Venkatesan: Hardness of computing the most significant bits of secret keys in Diffie-Hellman and related schemes; https://crypto.stanford.edu/~dabo/abstracts/dhmsb.html [2]: B. B. Brumley, N. Tuveri: Remote Timing Attacks are Still Practical; https://eprint.iacr.org/2011/232.pdf Cheers, Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: kfix.diff Type: text/x-patch Size: 26320 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From chris.hegarty at oracle.com Thu Oct 3 15:05:27 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 3 Oct 2019 16:05:27 +0100 Subject: RFR (S) 8230407 : SocketPermission and FilePermission action list allows leading comma In-Reply-To: References: <23ef065b-bdd6-2729-7afd-47aaed5d4943@oracle.com> <81df8c76-c7da-b61c-a88a-d7429e77a1bd@oracle.com> Message-ID: <3C09DC9E-A126-4F0A-ABAA-25E380B2A157@oracle.com> Ivan, > On 3 Oct 2019, at 04:41, Ivan Gerasimov wrote: > > ... > > So, I filed CSR: https://bugs.openjdk.java.net/browse/JDK-8231805 to cover the addition of @throws paragraph in the javadoc of SocketPermission. > > I would really appreciate it, if someone helped to review it. > Since we?re here ... ;-) It would be good to specify the NPE behavior of the constructor. Here are the changes for SocketPermission. If you agree, fold them into your patch and CSR. ( I?ve included test changes to verify the new tighter spec ) https://cr.openjdk.java.net/~chegar/8230407.extra/ -Chris. From eric.caspole at oracle.com Thu Oct 3 21:27:22 2019 From: eric.caspole at oracle.com (eric.caspole at oracle.com) Date: Thu, 3 Oct 2019 17:27:22 -0400 Subject: RFR (S) 8215521: add microbenchmark to measure AccessController.getContext Message-ID: Hi everybody, Could I get some reviews for JDK-8215521 to add a new JMH for AccessController.getContext() -- this was written by Dean after a bug from almost a year ago, then we forgot about it. I made the stack depth into a parameter. JBS: https://bugs.openjdk.java.net/browse/JDK-8215521 Webrev: http://cr.openjdk.java.net/~ecaspole/JDK-8215521/01/webrev/ Thanks, Eric From claes.redestad at oracle.com Thu Oct 3 21:51:06 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 3 Oct 2019 23:51:06 +0200 Subject: RFR (S) 8215521: add microbenchmark to measure AccessController.getContext In-Reply-To: References: Message-ID: <4e1446c9-8ba3-ade6-16c3-b7e9f93f5170@oracle.com> Hi Eric, benchmarks looks good to me! Nit: javadoc says "Benchmark measuring DoPrivileged", which doesn't look right. /Claes On 2019-10-03 23:27, eric.caspole at oracle.com wrote: > Hi everybody, > Could I get some reviews for JDK-8215521 to add a new JMH for > AccessController.getContext() -- this was written by Dean after a bug > from almost a year ago, then we forgot about it. I made the stack depth > into a parameter. > > JBS: > > https://bugs.openjdk.java.net/browse/JDK-8215521 > > Webrev: > > http://cr.openjdk.java.net/~ecaspole/JDK-8215521/01/webrev/ > > Thanks, > Eric From eric.caspole at oracle.com Thu Oct 3 21:54:07 2019 From: eric.caspole at oracle.com (eric.caspole at oracle.com) Date: Thu, 3 Oct 2019 17:54:07 -0400 Subject: RFR (S) 8215521: add microbenchmark to measure AccessController.getContext In-Reply-To: <4e1446c9-8ba3-ade6-16c3-b7e9f93f5170@oracle.com> References: <4e1446c9-8ba3-ade6-16c3-b7e9f93f5170@oracle.com> Message-ID: <6d3a6782-ee73-30b5-2421-55319153f8dd@oracle.com> Oh thanks, I will fix it before pushing, Eric On 10/3/19 5:51 PM, Claes Redestad wrote: > Hi Eric, > > benchmarks looks good to me! > > Nit: javadoc says "Benchmark measuring DoPrivileged", which doesn't look > right. > > /Claes > > On 2019-10-03 23:27, eric.caspole at oracle.com wrote: >> Hi everybody, >> Could I get some reviews for JDK-8215521 to add a new JMH for >> AccessController.getContext() -- this was written by Dean after a bug >> from almost a year ago, then we forgot about it. I made the stack >> depth into a parameter. >> >> JBS: >> >> https://bugs.openjdk.java.net/browse/JDK-8215521 >> >> Webrev: >> >> http://cr.openjdk.java.net/~ecaspole/JDK-8215521/01/webrev/ >> >> Thanks, >> Eric From ivan.gerasimov at oracle.com Fri Oct 4 01:36:42 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 3 Oct 2019 18:36:42 -0700 Subject: RFR (S) 8230407 : SocketPermission and FilePermission action list allows leading comma In-Reply-To: <5e3525d3-bced-f65d-8fb3-b4cf3bae6ca2@gmail.com> References: <5e3525d3-bced-f65d-8fb3-b4cf3bae6ca2@gmail.com> Message-ID: <26e0fa0e-bc5d-32a1-05d9-e7fdf511d14b@oracle.com> Thanks Peter, your variant looks cute! Let's keep this code in mind as a candidate for refactoring once the switch expression will make its way to the standard. I would hesitate to allow using experimental features in building the JDK just for that code :) With kind regards, Ivan On 10/2/19 11:40 PM, Peter Levart wrote: > Hi Ivan, > > On 10/1/19 10:26 PM, Ivan Gerasimov wrote: >> Hello! >> >> The constructors of SocketPermission and FilePermission expect a >> String argument with comma-separated list of actions. >> >> If the list is malformed, then the constructors throw >> IllegalArgumentException. >> >> It turns out that the current implementation fails to throw IAE if >> the list starts with a leading comma. >> >> Would you please help review a simple fix, which will make the >> behavior more consistent? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230407 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8230407/00/webrev/ >> > > With new switch expressions the logic could be a little clearer. For > example: > > ??????????? for (boolean seencomma = false; i >= matchlen && > !seencomma; i--) { > ??????????????? seencomma = switch (a[i - matchlen]) { > ??????????????????? case ' ', '\r', '\n', '\f', '\t': yield false; > ??????????????????? case ',': if (i > matchlen) yield true; > ??????????????????? default: throw new IllegalArgumentException( > ??????????????????????????????? "invalid permission: " + actions); > ??????????????? }; > ??????????? } > > > This is still experimental, but I think it will be proposed to be > standard soon. > > If you want to backport it later, then maybe you don't want to do that > now. > > Regards, Peter > -- With kind regards, Ivan Gerasimov From ivan.gerasimov at oracle.com Fri Oct 4 02:00:45 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 3 Oct 2019 19:00:45 -0700 Subject: RFR (S) 8230407 : SocketPermission and FilePermission action list allows leading comma In-Reply-To: <3C09DC9E-A126-4F0A-ABAA-25E380B2A157@oracle.com> References: <23ef065b-bdd6-2729-7afd-47aaed5d4943@oracle.com> <81df8c76-c7da-b61c-a88a-d7429e77a1bd@oracle.com> <3C09DC9E-A126-4F0A-ABAA-25E380B2A157@oracle.com> Message-ID: Hi Chris! On 10/3/19 8:05 AM, Chris Hegarty wrote: > Ivan, > >> On 3 Oct 2019, at 04:41, Ivan Gerasimov wrote: >> >> ... >> >> So, I filed CSR: https://bugs.openjdk.java.net/browse/JDK-8231805 to cover the addition of @throws paragraph in the javadoc of SocketPermission. >> >> I would really appreciate it, if someone helped to review it. >> > Since we?re here ... ;-) > It would be good to specify the NPE behavior of the constructor. Here are the changes for SocketPermission. If you agree, fold them into your patch and CSR. ( I?ve included test changes to verify the new tighter spec ) > > https://cr.openjdk.java.net/~chegar/8230407.extra/ Yes, it's a good point, thanks! I've adopted your suggested changes and the test: http://cr.openjdk.java.net/~igerasim/8230407/02/webrev/ CSR was also updated accordingly: https://bugs.openjdk.java.net/browse/JDK-8231805 With kind regards, Ivan > -Chris. > > > -- With kind regards, Ivan Gerasimov From Alan.Bateman at oracle.com Fri Oct 4 06:21:50 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Oct 2019 07:21:50 +0100 Subject: RFR (S) 8215521: add microbenchmark to measure AccessController.getContext In-Reply-To: References: Message-ID: On 03/10/2019 22:27, eric.caspole at oracle.com wrote: > : > > http://cr.openjdk.java.net/~ecaspole/JDK-8215521/01/webrev/ > The cast is bit ugly. In other cases, we create PrivilegedAction like the following to make it easier to read: PrivilegedAction pa = () -> AccessController.getContext(); return AccessController.doPrivileged(pa); -Alan From chris.hegarty at oracle.com Fri Oct 4 08:32:22 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 4 Oct 2019 09:32:22 +0100 Subject: RFR (S) 8230407 : SocketPermission and FilePermission action list allows leading comma In-Reply-To: References: <23ef065b-bdd6-2729-7afd-47aaed5d4943@oracle.com> <81df8c76-c7da-b61c-a88a-d7429e77a1bd@oracle.com> <3C09DC9E-A126-4F0A-ABAA-25E380B2A157@oracle.com> Message-ID: <6EE5B925-A874-46E7-981F-91B18D3E48AA@oracle.com> Ivan, > On 4 Oct 2019, at 03:00, Ivan Gerasimov wrote: > > ... > > I've adopted your suggested changes and the test: > http://cr.openjdk.java.net/~igerasim/8230407/02/webrev/ LGTM. > CSR was also updated accordingly: > https://bugs.openjdk.java.net/browse/JDK-8231805 I added myself as reviewer. -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Oct 4 14:06:05 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 4 Oct 2019 10:06:05 -0400 Subject: RFR 8231365, 8231196: bugs on kerberos permissions In-Reply-To: References: Message-ID: <8a5db15f-6fb8-167e-87f6-e4a66a8cef43@oracle.com> The changes for ServicePermission look fine. For DelegationPermission, I have a couple of comments: - The test has the wrong copyright (no need for the "Classpath" exception) - I think we should clarify the specification of DelegationPermission constructors for the @throws IllegalArgumentException. It currently says: * @throws IllegalArgumentException if {@code principals} is empty. But with your fix, it also throws IllegalArgumentExc if principals does not contain a pair. Also, the current code throws IAE if there is a syntax error. So I would propose: * @throws IllegalArgumentException if {@code principals} is empty, or does not contain a pair of principals, or is improperly quoted --Sean On 9/25/19 10:50 PM, Weijun Wang wrote: > Please take a review at > > https://cr.openjdk.java.net/~weijun/8231365/webrev.00 > > Thanks, > Max > From eric.caspole at oracle.com Fri Oct 4 14:25:25 2019 From: eric.caspole at oracle.com (Eric Caspole) Date: Fri, 4 Oct 2019 10:25:25 -0400 Subject: RFR (S) 8215521: add microbenchmark to measure AccessController.getContext In-Reply-To: References: Message-ID: <71d74fa6-0c8c-4459-ab0d-659eb1f8571e@oracle.com> Hi Alan, Here it is: http://cr.openjdk.java.net/~ecaspole/JDK-8215521/02/webrev/ thanks, Eric On 10/4/19 02:21, Alan Bateman wrote: > > > On 03/10/2019 22:27, eric.caspole at oracle.com wrote: >> : >> >> http://cr.openjdk.java.net/~ecaspole/JDK-8215521/01/webrev/ >> > The cast is bit ugly. In other cases, we create PrivilegedAction like > the following to make it easier to read: > > PrivilegedAction pa = () -> > AccessController.getContext(); > return AccessController.doPrivileged(pa); > > -Alan From claes.redestad at oracle.com Fri Oct 4 14:35:18 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 4 Oct 2019 16:35:18 +0200 Subject: RFR (S) 8215521: add microbenchmark to measure AccessController.getContext In-Reply-To: <71d74fa6-0c8c-4459-ab0d-659eb1f8571e@oracle.com> References: <71d74fa6-0c8c-4459-ab0d-659eb1f8571e@oracle.com> Message-ID: <14aca915-4dfc-4006-3cad-449386a08cdb@oracle.com> On 2019-10-04 16:25, Eric Caspole wrote: > http://cr.openjdk.java.net/~ecaspole/JDK-8215521/02/webrev/ Looks good to me. /Claes From Alan.Bateman at oracle.com Fri Oct 4 14:54:54 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Oct 2019 15:54:54 +0100 Subject: RFR (S) 8215521: add microbenchmark to measure AccessController.getContext In-Reply-To: <71d74fa6-0c8c-4459-ab0d-659eb1f8571e@oracle.com> References: <71d74fa6-0c8c-4459-ab0d-659eb1f8571e@oracle.com> Message-ID: <88ce518d-59a6-b191-5463-067035634b7d@oracle.com> On 04/10/2019 15:25, Eric Caspole wrote: > Hi Alan, > > Here it is: > > http://cr.openjdk.java.net/~ecaspole/JDK-8215521/02/webrev/ Looks good. From xuelei.fan at oracle.com Sat Oct 5 03:30:05 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 4 Oct 2019 20:30:05 -0700 Subject: [14] RFR JDK-8229243 "SunPKCS11-Solaris provider tests failing on Solaris 11.4" In-Reply-To: References: <2acfd22a-7682-d7d8-a49d-516f0a064abd@oracle.com> Message-ID: <80883b26-8674-74b4-e6fa-919ffb878661@oracle.com> I have no more comment. Xuelei On 10/2/2019 5:09 PM, Valerie Peng wrote: > During the pre-integration mach5 run, I ran into a window-specific data > alignment problem when the custom GCM param structure is declared inside > pkcs11wrapper.h in webrev.01. So, I ended up adding a separate header > file pkcs11gcm2.h containing only this structure and include it in the > platform-specific header p11_md.h so the current logic of using sizeof() > works as expected. > > Mach5 run and Solaris 11.4 run pass as expected with webrev.02. > > http://cr.openjdk.java.net/~valeriep/8229243/webrev.02/ > > If there are more comments, please let me know in a few days. > > Thanks! > Valerie > On 9/24/2019 9:45 PM, Valerie Peng wrote: >> Great, thanks for the review and feedback~ >> >> Valerie >> >> On 9/24/2019 9:20 PM, Xuelei Fan wrote: >>> I looked at the latest webrev: >>> ? http://cr.openjdk.java.net/~valeriep/8229243/webrev.01/ >>> >>> Which is good to me. >>> >>> Thanks, >>> Xuelei >>> >>> On 9/19/2019 5:46 PM, Valerie Peng wrote: >>>> >>>> I am not on the PKCS#11 committee and not sure about the plan. >>>> As for which one is right, I am more inclined to the "spec is right" >>>> side which is also what NSS picked. >>>> Comparing between spec and header, shouldn't the former get more >>>> eyeballs in terms of review? >>>> The header file also has a deprecated structure CK_AES_GCM_PARAMS >>>> which contains both ulIvLen and ulIvBits fields. >>>> As ulIvBits and ulIvLen are essentially same in terms of meaning >>>> except bytes vs bits. Having both just creates confusion and >>>> potential inconsistency and makes not much sense to me. >>>> >>>> Valerie >>>> >>>> ----- Original Message ----- >>>> From: xuelei.fan at oracle.com >>>> To: valerie.peng at oracle.com, security-dev at openjdk.java.net >>>> Sent: Thursday, September 19, 2019 7:47:43 AM GMT -08:00 US/Canada >>>> Pacific >>>> Subject: Re: [14] RFR JDK-8229243 "SunPKCS11-Solaris provider tests >>>> failing on Solaris 11.4" >>>> >>>> Will the inconsistency structure be continue?? I was just wondering if >>>> OpenHSM2/Solaris/NSS will fix the bug and use one structure in the >>>> future, then we may not need to workaround the issue in the calling >>>> side. >>>> >>>> I had a quick look the PKCS#11 3.0 draft, there is no update of the >>>> structure yet. >>>> >>>> Xuelei >>>> >>>> On 9/18/2019 6:01 PM, Valerie Peng wrote: >>>>> Ping? >>>>> >>>>> Can someone help take a look? >>>>> >>>>> Thanks, >>>>> >>>>> Valerie >>>>> >>>>> On 8/15/2019 4:49 PM, Valerie Peng wrote: >>>>>> >>>>>> Anyone has time to help review this fix? PKCS#11 v2.40 has >>>>>> inconsistent definition for CK_GCM_PARAMS struct. The mechanism spec >>>>>> (sec 2..12.3) has: >>>>>> >>>>>> ???? typedef struct CK_GCM_PARAMS { >>>>>> ???? ??? CK_BYTE_PTR?????? pIv; >>>>>> ???? ??? CK_ULONG????????? ulIvLen; >>>>>> ???? ??? CK_BYTE_PTR?????? pAAD; >>>>>> ???? ??? CK_ULONG????????? ulAADLen; >>>>>> ???? ??? CK_ULONG????????? ulTagBits; >>>>>> ???? } CK_GCM_PARAMS; >>>>>> >>>>>> However, the header file pkcs11t.h has an extra "ulIvBits" field: >>>>>> >>>>>> ???? typedef struct CK_GCM_PARAMS { >>>>>> ???? ??? CK_BYTE_PTR?????? pIv; >>>>>> ???? ??? CK_ULONG????????? ulIvLen; >>>>>> ???? *??? CK_ULONG????????? ulIvBits;* >>>>>> ???? ??? CK_BYTE_PTR?????? pAAD; >>>>>> ???? ??? CK_ULONG????????? ulAADLen; >>>>>> ???? ??? CK_ULONG????????? ulTagBits; >>>>>> ???? } CK_GCM_PARAMS; >>>>>> >>>>>> Some vendors such OpenHSM2 and Solaris go with the header file while >>>>>> some vendor such as NSS go with the mech spec. Current SunPKCS11 >>>>>> provider impl works with NSS but not with other vendors whose >>>>>> CK_GCM_PARAMS struct contains ulIvBits field. Based on testing >>>>>> results, OpenHSM2 and Solaris error out at init time when the >>>>>> parameter length does not have their expected value. Thus, one way to >>>>>> workaround this inconsistency is to re-try with a different structure >>>>>> for AES GCM when the init failed. In addition, given the parameters >>>>>> contains Iv and AAD which some vendor may use during subsequent >>>>>> enc/dec operations, I changed to use the same model as RSASSA-PSS to >>>>>> defer the freeing after the enc/dec operation is finished. Verified >>>>>> the changes on Solaris 11.4 against existing GCM regression tests. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229243 >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8229243/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> Valerie From fedor.burdun at azul.com Mon Oct 7 16:35:11 2019 From: fedor.burdun at azul.com (Fedor Burdun) Date: Mon, 7 Oct 2019 16:35:11 +0000 Subject: RFR: 8231507: Update Apache Santuario (XML Signature) to version 2.1.4 Message-ID: <1cea5e8055784f999fc3bf952e0e975a@azul.com> Dear all, Would you please review the following change? Bug: https://bugs.openjdk.java.net/browse/JDK-8231507 Webrev: http://cr.openjdk.java.net/~fijiol/8231507/webrev.00/ This change upgrades Apache Santuario library to version 2.1.4 Best regards, Fedor -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Mon Oct 7 22:07:54 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 7 Oct 2019 15:07:54 -0700 Subject: [14] RFR JDK-8229243 "SunPKCS11-Solaris provider tests failing on Solaris 11.4" In-Reply-To: <80883b26-8674-74b4-e6fa-919ffb878661@oracle.com> References: <2acfd22a-7682-d7d8-a49d-516f0a064abd@oracle.com> <80883b26-8674-74b4-e6fa-919ffb878661@oracle.com> Message-ID: Thanks for the review~ Valerie On 10/4/2019 8:30 PM, Xuelei Fan wrote: > I have no more comment. > > Xuelei > > On 10/2/2019 5:09 PM, Valerie Peng wrote: >> During the pre-integration mach5 run, I ran into a window-specific >> data alignment problem when the custom GCM param structure is >> declared inside pkcs11wrapper.h in webrev.01. So, I ended up adding a >> separate header file pkcs11gcm2.h containing only this structure and >> include it in the platform-specific header p11_md.h so the current >> logic of using sizeof() works as expected. >> >> Mach5 run and Solaris 11.4 run pass as expected with webrev.02. >> >> http://cr.openjdk.java.net/~valeriep/8229243/webrev.02/ >> >> If there are more comments, please let me know in a few days. >> >> Thanks! >> Valerie >> On 9/24/2019 9:45 PM, Valerie Peng wrote: >>> Great, thanks for the review and feedback~ >>> >>> Valerie >>> >>> On 9/24/2019 9:20 PM, Xuelei Fan wrote: >>>> I looked at the latest webrev: >>>> ? http://cr.openjdk.java.net/~valeriep/8229243/webrev.01/ >>>> >>>> Which is good to me. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 9/19/2019 5:46 PM, Valerie Peng wrote: >>>>> >>>>> I am not on the PKCS#11 committee and not sure about the plan. >>>>> As for which one is right, I am more inclined to the "spec is >>>>> right" side which is also what NSS picked. >>>>> Comparing between spec and header, shouldn't the former get more >>>>> eyeballs in terms of review? >>>>> The header file also has a deprecated structure CK_AES_GCM_PARAMS >>>>> which contains both ulIvLen and ulIvBits fields. >>>>> As ulIvBits and ulIvLen are essentially same in terms of meaning >>>>> except bytes vs bits. Having both just creates confusion and >>>>> potential inconsistency and makes not much sense to me. >>>>> >>>>> Valerie >>>>> >>>>> ----- Original Message ----- >>>>> From: xuelei.fan at oracle.com >>>>> To: valerie.peng at oracle.com, security-dev at openjdk.java.net >>>>> Sent: Thursday, September 19, 2019 7:47:43 AM GMT -08:00 US/Canada >>>>> Pacific >>>>> Subject: Re: [14] RFR JDK-8229243 "SunPKCS11-Solaris provider >>>>> tests failing on Solaris 11.4" >>>>> >>>>> Will the inconsistency structure be continue?? I was just >>>>> wondering if >>>>> OpenHSM2/Solaris/NSS will fix the bug and use one structure in the >>>>> future, then we may not need to workaround the issue in the >>>>> calling side. >>>>> >>>>> I had a quick look the PKCS#11 3.0 draft, there is no update of the >>>>> structure yet. >>>>> >>>>> Xuelei >>>>> >>>>> On 9/18/2019 6:01 PM, Valerie Peng wrote: >>>>>> Ping? >>>>>> >>>>>> Can someone help take a look? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Valerie >>>>>> >>>>>> On 8/15/2019 4:49 PM, Valerie Peng wrote: >>>>>>> >>>>>>> Anyone has time to help review this fix? PKCS#11 v2.40 has >>>>>>> inconsistent definition for CK_GCM_PARAMS struct. The mechanism >>>>>>> spec >>>>>>> (sec 2..12.3) has: >>>>>>> >>>>>>> ???? typedef struct CK_GCM_PARAMS { >>>>>>> ???? ??? CK_BYTE_PTR?????? pIv; >>>>>>> ???? ??? CK_ULONG????????? ulIvLen; >>>>>>> ???? ??? CK_BYTE_PTR?????? pAAD; >>>>>>> ???? ??? CK_ULONG????????? ulAADLen; >>>>>>> ???? ??? CK_ULONG????????? ulTagBits; >>>>>>> ???? } CK_GCM_PARAMS; >>>>>>> >>>>>>> However, the header file pkcs11t.h has an extra "ulIvBits" field: >>>>>>> >>>>>>> ???? typedef struct CK_GCM_PARAMS { >>>>>>> ???? ??? CK_BYTE_PTR?????? pIv; >>>>>>> ???? ??? CK_ULONG????????? ulIvLen; >>>>>>> ???? *??? CK_ULONG????????? ulIvBits;* >>>>>>> ???? ??? CK_BYTE_PTR?????? pAAD; >>>>>>> ???? ??? CK_ULONG????????? ulAADLen; >>>>>>> ???? ??? CK_ULONG????????? ulTagBits; >>>>>>> ???? } CK_GCM_PARAMS; >>>>>>> >>>>>>> Some vendors such OpenHSM2 and Solaris go with the header file >>>>>>> while >>>>>>> some vendor such as NSS go with the mech spec. Current SunPKCS11 >>>>>>> provider impl works with NSS but not with other vendors whose >>>>>>> CK_GCM_PARAMS struct contains ulIvBits field. Based on testing >>>>>>> results, OpenHSM2 and Solaris error out at init time when the >>>>>>> parameter length does not have their expected value. Thus, one >>>>>>> way to >>>>>>> workaround this inconsistency is to re-try with a different >>>>>>> structure >>>>>>> for AES GCM when the init failed. In addition, given the parameters >>>>>>> contains Iv and AAD which some vendor may use during subsequent >>>>>>> enc/dec operations, I changed to use the same model as >>>>>>> RSASSA-PSS to >>>>>>> defer the freeing after the enc/dec operation is finished. Verified >>>>>>> the changes on Solaris 11.4 against existing GCM regression tests. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229243 >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8229243/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> Valerie From joe.darcy at oracle.com Tue Oct 8 17:11:18 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 8 Oct 2019 10:11:18 -0700 Subject: JDK 14 RFR of JDK-8231368: Suppress warnings on non-serializable non-transient instance fields in java.security.jgss In-Reply-To: <2aba8d6c-90f9-96d4-1be5-6765459e9929@oracle.com> References: <2aba8d6c-90f9-96d4-1be5-6765459e9929@oracle.com> Message-ID: <8065efae-5678-7b5d-876a-3e7e1fc54cc6@oracle.com> Hi Sean, Returning to this review.... On 9/26/2019 12:35 PM, Sean Mullan wrote: > - Krb5Context.java > > 1394???????? @SuppressWarnings("serial") // Not statically typed as > Serializable > 1395???????? private final EncryptionKey key; > > EncryptionKey is Serializable (it derives from java.security.Key which > is Serializable). I was wondering why we needed to suppress the > warning here. Taking a closer look, the field in question is of type ??? sun.security.krb5.EncryptionKey which is *not* declared to be Serializable: public class EncryptionKey ??? implements Cloneable { In contrast, the javax.security.auth.kerberos.EncryptionKey class is declared to be Serializable. Therefore, the @SuppressWarnings on the field in the initial patch is needed. If the patch looks good, I'll get this pushed. Thanks, -Joe > > --Sean > > On 9/23/19 8:15 PM, Joe Darcy wrote: >> Hello, >> >> Another module, another review request as part of making serial >> warnings more robust: >> >> ???? JDK-8231368: Suppress warnings on non-serializable non-transient >> instance fields in java.security.jgss >> ???? http://cr.openjdk.java.net/~darcy/8231368.0/ >> >> (Related earlier review >> https://mail.openjdk.java.net/pipermail/security-dev/2019-September/020672.html.) >> >> >> In this latest review, I included a comment in KRBError.java that its >> writeObject method uses a different encoding scheme. >> >> Thanks, >> >> -Joe >> From joe.darcy at oracle.com Tue Oct 8 17:36:04 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 8 Oct 2019 10:36:04 -0700 Subject: JDK 14 RFR of JDK-8231368: Suppress warnings on non-serializable non-transient instance fields in java.security.jgss In-Reply-To: <8065efae-5678-7b5d-876a-3e7e1fc54cc6@oracle.com> References: <2aba8d6c-90f9-96d4-1be5-6765459e9929@oracle.com> <8065efae-5678-7b5d-876a-3e7e1fc54cc6@oracle.com> Message-ID: PS And a revised webrev acting on comments from the JDK-8231262 to use a single class-level @SuppressWarnings when an alternative serial form is implicitly being used: ??? http://cr.openjdk.java.net/~darcy/8231368.1/ Thanks, -Joe On 10/8/2019 10:11 AM, Joe Darcy wrote: > Hi Sean, > > Returning to this review.... > > On 9/26/2019 12:35 PM, Sean Mullan wrote: >> - Krb5Context.java >> >> 1394???????? @SuppressWarnings("serial") // Not statically typed as >> Serializable >> 1395???????? private final EncryptionKey key; >> >> EncryptionKey is Serializable (it derives from java.security.Key >> which is Serializable). I was wondering why we needed to suppress the >> warning here. > > > Taking a closer look, the field in question is of type > > ??? sun.security.krb5.EncryptionKey > > which is *not* declared to be Serializable: > > public class EncryptionKey > ??? implements Cloneable { > > In contrast, the javax.security.auth.kerberos.EncryptionKey class is > declared to be Serializable. Therefore, the @SuppressWarnings on the > field in the initial patch is needed. > > If the patch looks good, I'll get this pushed. > > Thanks, > > -Joe > >> >> --Sean >> >> On 9/23/19 8:15 PM, Joe Darcy wrote: >>> Hello, >>> >>> Another module, another review request as part of making serial >>> warnings more robust: >>> >>> ???? JDK-8231368: Suppress warnings on non-serializable >>> non-transient instance fields in java.security.jgss >>> ???? http://cr.openjdk.java.net/~darcy/8231368.0/ >>> >>> (Related earlier review >>> https://mail.openjdk.java.net/pipermail/security-dev/2019-September/020672.html.) >>> >>> >>> In this latest review, I included a comment in KRBError.java that >>> its writeObject method uses a different encoding scheme. >>> >>> Thanks, >>> >>> -Joe >>> From sean.mullan at oracle.com Tue Oct 8 21:12:06 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 8 Oct 2019 17:12:06 -0400 Subject: JDK 14 RFR of JDK-8231368: Suppress warnings on non-serializable non-transient instance fields in java.security.jgss In-Reply-To: References: <2aba8d6c-90f9-96d4-1be5-6765459e9929@oracle.com> <8065efae-5678-7b5d-876a-3e7e1fc54cc6@oracle.com> Message-ID: <27e31fa0-4525-a371-6cf0-957934c93fc9@oracle.com> I would change "asn1" to "ASN.1" in the comment as that is the more common usage of the acronym, otherwise looks good. Thanks, Sean On 10/8/19 1:36 PM, Joe Darcy wrote: > PS And a revised webrev acting on comments from the JDK-8231262 to use a > single class-level @SuppressWarnings when an alternative serial form is > implicitly being used: > > ??? http://cr.openjdk.java.net/~darcy/8231368.1/ > > Thanks, > > -Joe > > On 10/8/2019 10:11 AM, Joe Darcy wrote: >> Hi Sean, >> >> Returning to this review.... >> >> On 9/26/2019 12:35 PM, Sean Mullan wrote: >>> - Krb5Context.java >>> >>> 1394???????? @SuppressWarnings("serial") // Not statically typed as >>> Serializable >>> 1395???????? private final EncryptionKey key; >>> >>> EncryptionKey is Serializable (it derives from java.security.Key >>> which is Serializable). I was wondering why we needed to suppress the >>> warning here. >> >> >> Taking a closer look, the field in question is of type >> >> ??? sun.security.krb5.EncryptionKey >> >> which is *not* declared to be Serializable: >> >> public class EncryptionKey >> ??? implements Cloneable { >> >> In contrast, the javax.security.auth.kerberos.EncryptionKey class is >> declared to be Serializable. Therefore, the @SuppressWarnings on the >> field in the initial patch is needed. >> >> If the patch looks good, I'll get this pushed. >> >> Thanks, >> >> -Joe >> >>> >>> --Sean >>> >>> On 9/23/19 8:15 PM, Joe Darcy wrote: >>>> Hello, >>>> >>>> Another module, another review request as part of making serial >>>> warnings more robust: >>>> >>>> ???? JDK-8231368: Suppress warnings on non-serializable >>>> non-transient instance fields in java.security.jgss >>>> ???? http://cr.openjdk.java.net/~darcy/8231368.0/ >>>> >>>> (Related earlier review >>>> https://mail.openjdk.java.net/pipermail/security-dev/2019-September/020672.html.) >>>> >>>> >>>> In this latest review, I included a comment in KRBError.java that >>>> its writeObject method uses a different encoding scheme. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> From joe.darcy at oracle.com Tue Oct 8 22:36:22 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 8 Oct 2019 15:36:22 -0700 Subject: JDK 14 RFR of JDK-8231368: Suppress warnings on non-serializable non-transient instance fields in java.security.jgss In-Reply-To: <27e31fa0-4525-a371-6cf0-957934c93fc9@oracle.com> References: <2aba8d6c-90f9-96d4-1be5-6765459e9929@oracle.com> <8065efae-5678-7b5d-876a-3e7e1fc54cc6@oracle.com> <27e31fa0-4525-a371-6cf0-957934c93fc9@oracle.com> Message-ID: <36128c55-19af-702e-3033-205a5e4dece7@oracle.com> Hi Sean, Amended as requested before pushing; thanks, -Joe On 10/8/2019 2:12 PM, Sean Mullan wrote: > I would change "asn1" to "ASN.1" in the comment as that is the more > common usage of the acronym, otherwise looks good. > > Thanks, > Sean > > On 10/8/19 1:36 PM, Joe Darcy wrote: >> PS And a revised webrev acting on comments from the JDK-8231262 to >> use a single class-level @SuppressWarnings when an alternative serial >> form is implicitly being used: >> >> ???? http://cr.openjdk.java.net/~darcy/8231368.1/ >> >> Thanks, >> >> -Joe >> >> On 10/8/2019 10:11 AM, Joe Darcy wrote: >>> Hi Sean, >>> >>> Returning to this review.... >>> >>> On 9/26/2019 12:35 PM, Sean Mullan wrote: >>>> - Krb5Context.java >>>> >>>> 1394???????? @SuppressWarnings("serial") // Not statically typed as >>>> Serializable >>>> 1395???????? private final EncryptionKey key; >>>> >>>> EncryptionKey is Serializable (it derives from java.security.Key >>>> which is Serializable). I was wondering why we needed to suppress >>>> the warning here. >>> >>> >>> Taking a closer look, the field in question is of type >>> >>> ??? sun.security.krb5.EncryptionKey >>> >>> which is *not* declared to be Serializable: >>> >>> public class EncryptionKey >>> ??? implements Cloneable { >>> >>> In contrast, the javax.security.auth.kerberos.EncryptionKey class is >>> declared to be Serializable. Therefore, the @SuppressWarnings on the >>> field in the initial patch is needed. >>> >>> If the patch looks good, I'll get this pushed. >>> >>> Thanks, >>> >>> -Joe >>> >>>> >>>> --Sean >>>> >>>> On 9/23/19 8:15 PM, Joe Darcy wrote: >>>>> Hello, >>>>> >>>>> Another module, another review request as part of making serial >>>>> warnings more robust: >>>>> >>>>> ???? JDK-8231368: Suppress warnings on non-serializable >>>>> non-transient instance fields in java.security.jgss >>>>> ???? http://cr.openjdk.java.net/~darcy/8231368.0/ >>>>> >>>>> (Related earlier review >>>>> https://mail.openjdk.java.net/pipermail/security-dev/2019-September/020672.html.) >>>>> >>>>> >>>>> In this latest review, I included a comment in KRBError.java that >>>>> its writeObject method uses a different encoding scheme. >>>>> >>>>> Thanks, >>>>> >>>>> -Joe >>>>> From joe.darcy at oracle.com Wed Oct 9 01:56:46 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 8 Oct 2019 18:56:46 -0700 Subject: JDK 14 RFR of JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes In-Reply-To: <3fb58edd-9095-ee2d-5b64-3a92640a1cdc@oracle.com> References: <1cce2ac6-cfa1-6859-aa24-4051aeece1aa@oracle.com> <4ec1729b-6625-4aef-8fb2-03adc9536431@oracle.com> <6b2e97ed-7865-05a2-622f-40dcf2a0602c@oracle.com> <3fb58edd-9095-ee2d-5b64-3a92640a1cdc@oracle.com> Message-ID: <85890c3b-948e-b3e4-0e44-0a6bea3a48cc@oracle.com> Hi Sean, Getting back to this review... On 9/26/2019 1:55 PM, Sean Mullan wrote: > On 9/26/19 4:20 PM, Sean Mullan wrote: >>> Would you prefer I revise the patch where there are multiple >>> SuppressWarnings("serial") on fields to put a single one on the >>> class instead? >> >> Yes, but only in the cases where we are clearly using some form of >> alternate serialization like ASN.1 encoding. I need to double-check >> the review again (it's a bit more time consuming because I have to >> look at the code in more detail), but the two that I spotted so far are: >> >> src/java.base/share/classes/sun/security/x509/X509CertImpl.java >> src/java.security.jgss/share/classes/sun/security/krb5/internal/KRBError.java >> (from the JDK-8231368 review) > > Ok, I double-checked everything. The only other class in the webrev > that uses an alternate serial form is: > > sun/security/x509/X509Key.java > > but since that only has one field that is not Serializable, it > probably is ok to leave as-is. > > I've put the updated webrev at: ??? http://cr.openjdk.java.net/~darcy/8231262.1/ The difference from the first webrev is I marked a field in X509Key.java as transient; diff of webrev patches: > --- old/src/java.base/share/classes/sun/security/x509/X509Key.java 2019-10-08 18:37:02.143999531 -0700 > +++ new/src/java.base/share/classes/sun/security/x509/X509Key.java 2019-10-08 18:37:01.815999531 -0700 > @@ -84,7 +84,7 @@ 214,215c214,215 < +??? @SuppressWarnings("serial") // Not statically typed as Serializable -??? private BitArray bitStringKey = null; > +??? private transient BitArray bitStringKey = null; For src/java.base/share/classes/sun/security/x509/X509CertImpl.java, I don't see any of the read* or write* methods associated with serialization defined in the class. I would seem clearer to me to having the @SuppressWarning("serial") at each field, but if you'd prefer to have it at the class level, I'll defer to your judgement on the matter. FYI, of the files being modified only src/java.base/share/classes/javax/security/auth/Subject.java uses readFields or putFields. Thanks, -Joe From sean.mullan at oracle.com Wed Oct 9 13:54:52 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 9 Oct 2019 09:54:52 -0400 Subject: JDK 14 RFR of JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes In-Reply-To: <85890c3b-948e-b3e4-0e44-0a6bea3a48cc@oracle.com> References: <1cce2ac6-cfa1-6859-aa24-4051aeece1aa@oracle.com> <4ec1729b-6625-4aef-8fb2-03adc9536431@oracle.com> <6b2e97ed-7865-05a2-622f-40dcf2a0602c@oracle.com> <3fb58edd-9095-ee2d-5b64-3a92640a1cdc@oracle.com> <85890c3b-948e-b3e4-0e44-0a6bea3a48cc@oracle.com> Message-ID: <04fc437e-9bae-47fe-990a-c1687e28fd40@oracle.com> On 10/8/19 9:56 PM, Joe Darcy wrote: > Hi Sean, > > Getting back to this review... > > On 9/26/2019 1:55 PM, Sean Mullan wrote: >> On 9/26/19 4:20 PM, Sean Mullan wrote: >>>> Would you prefer I revise the patch where there are multiple >>>> SuppressWarnings("serial") on fields to put a single one on the >>>> class instead? >>> >>> Yes, but only in the cases where we are clearly using some form of >>> alternate serialization like ASN.1 encoding. I need to double-check >>> the review again (it's a bit more time consuming because I have to >>> look at the code in more detail), but the two that I spotted so far are: >>> >>> src/java.base/share/classes/sun/security/x509/X509CertImpl.java >>> src/java.security.jgss/share/classes/sun/security/krb5/internal/KRBError.java >>> (from the JDK-8231368 review) >> >> Ok, I double-checked everything. The only other class in the webrev >> that uses an alternate serial form is: >> >> sun/security/x509/X509Key.java >> >> but since that only has one field that is not Serializable, it >> probably is ok to leave as-is. >> >> > I've put the updated webrev at: > > ??? http://cr.openjdk.java.net/~darcy/8231262.1/ > > The difference from the first webrev is I marked a field in X509Key.java > as transient; diff of webrev patches: > > > --- old/src/java.base/share/classes/sun/security/x509/X509Key.java > 2019-10-08 18:37:02.143999531 -0700 > > +++ new/src/java.base/share/classes/sun/security/x509/X509Key.java > 2019-10-08 18:37:01.815999531 -0700 > > @@ -84,7 +84,7 @@ > 214,215c214,215 > < +??? @SuppressWarnings("serial") // Not statically typed as Serializable > --- > > -??? private BitArray bitStringKey = null; > > +??? private transient BitArray bitStringKey = null; > > For src/java.base/share/classes/sun/security/x509/X509CertImpl.java, I > don't see any of the read* or write* methods associated with > serialization defined in the class. I would seem clearer to me to having > the @SuppressWarning("serial") at each field, but if you'd prefer to > have it at the class level, I'll defer to your judgement on the matter. X509CertImpl extends X509Certificate which extends Certificate. Certificate has a writeReplace method. I now think that a better fix for classes that use a custom serial format is to mark all the instance fields that are not part of that custom format as transient. This includes the fields that are primitive types as well as other types (and whether or not they actually implement Serializable or not). But maybe we need to document a best practice for cases like this. JB does provide the following advice in Item 87 of Eff Java (p. 351 of 3rd edition): "If you use a custom serialized form, most or all of the instance fields should be labeled transient, ..." In the case of X509Key, that would mean marking the algid, key, unusedBits and bitStringKey fields transient, and for X509CertImpl I suppose this would mean all of the instance fields. If this is more than you bargained for when fixing this :), feel free to file a follow-on issue and assign it to me. Thanks, Sean > > FYI, of the files being modified only > src/java.base/share/classes/javax/security/auth/Subject.java uses > readFields or putFields. > > Thanks, > > -Joe > From chris.hegarty at oracle.com Wed Oct 9 14:14:56 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 9 Oct 2019 15:14:56 +0100 Subject: JDK 14 RFR of JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes In-Reply-To: <04fc437e-9bae-47fe-990a-c1687e28fd40@oracle.com> References: <1cce2ac6-cfa1-6859-aa24-4051aeece1aa@oracle.com> <4ec1729b-6625-4aef-8fb2-03adc9536431@oracle.com> <6b2e97ed-7865-05a2-622f-40dcf2a0602c@oracle.com> <3fb58edd-9095-ee2d-5b64-3a92640a1cdc@oracle.com> <85890c3b-948e-b3e4-0e44-0a6bea3a48cc@oracle.com> <04fc437e-9bae-47fe-990a-c1687e28fd40@oracle.com> Message-ID: <2febaa9f-887d-d227-a0b2-0a3d6d545755@oracle.com> On 09/10/2019 14:54, Sean Mullan wrote: >... > > X509CertImpl extends X509Certificate which extends Certificate. > Certificate has a writeReplace method. Another possible follow-on is to add readObject methods, that unconditionally throw, to both X509Certificate and X509CertImpl, since serialized instances of these types should not appear in the stream. That would be a nice addition to the suggestion to make all the fields transient - and improve the readability of the code. -Chris. From joe.darcy at oracle.com Wed Oct 9 16:24:09 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 9 Oct 2019 09:24:09 -0700 Subject: JDK 14 RFR of JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes In-Reply-To: <2febaa9f-887d-d227-a0b2-0a3d6d545755@oracle.com> References: <1cce2ac6-cfa1-6859-aa24-4051aeece1aa@oracle.com> <4ec1729b-6625-4aef-8fb2-03adc9536431@oracle.com> <6b2e97ed-7865-05a2-622f-40dcf2a0602c@oracle.com> <3fb58edd-9095-ee2d-5b64-3a92640a1cdc@oracle.com> <85890c3b-948e-b3e4-0e44-0a6bea3a48cc@oracle.com> <04fc437e-9bae-47fe-990a-c1687e28fd40@oracle.com> <2febaa9f-887d-d227-a0b2-0a3d6d545755@oracle.com> Message-ID: <7cc4a6aa-a12d-7cd2-87f2-2ce39872fbba@oracle.com> Hi Chris and Sean, I'll push a fix for JDK-8231262 with a single class-level suppression in X509CertImpl: ??? @SuppressWarnings("serial") // See writeReplace method in Certificate I've filed ??? ??? JDK-8232062: Clarify serialization mechanisms of X509CertImpl for the follow-up work. Thanks, -Joe On 10/9/2019 7:14 AM, Chris Hegarty wrote: > > > On 09/10/2019 14:54, Sean Mullan wrote: >> ... >> >> X509CertImpl extends X509Certificate which extends Certificate. >> Certificate has a writeReplace method. > > Another possible follow-on is to add readObject methods, that > unconditionally throw, to both X509Certificate and X509CertImpl, since > serialized instances of these types should not appear in the stream. > That would be a nice addition to the suggestion to make all the fields > transient - and improve the readability of the code. > > -Chris. From RAJAN.HALADE at ORACLE.COM Wed Oct 9 17:56:40 2019 From: RAJAN.HALADE at ORACLE.COM (Rajan Halade) Date: Wed, 9 Oct 2019 10:56:40 -0700 Subject: RFR: 8231887: ComodoCA.java fails because certificate was revoked Message-ID: <1B5DEDFD-0DA0-42CE-866D-578A609A2F73@ORACLE.COM> Please review this fix in ComodoCA.java test to update test certificates used. CA revoked earlier test artifacts so we need to update those. Webrev: http://cr.openjdk.java.net/~rhalade/8231887/webrev.00/ Thanks, Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Oct 9 18:58:19 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 9 Oct 2019 14:58:19 -0400 Subject: RFR: 8231887: ComodoCA.java fails because certificate was revoked In-Reply-To: <1B5DEDFD-0DA0-42CE-866D-578A609A2F73@ORACLE.COM> References: <1B5DEDFD-0DA0-42CE-866D-578A609A2F73@ORACLE.COM> Message-ID: You should add the bugid to @bug and it probably should have a noreg-self label. Looks good otherwise. --Sean On 10/9/19 1:56 PM, Rajan Halade wrote: > Please review this fix in ComodoCA.java test to update test certificates > used. CA revoked earlier test artifacts so we need to update those. > > Webrev: http://cr.openjdk.java.net/~rhalade/8231887/webrev.00/ > > Thanks, > Rajan > From christoph.langer at sap.com Wed Oct 9 19:02:30 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 9 Oct 2019 19:02:30 +0000 Subject: RFR: 8231887: ComodoCA.java fails because certificate was revoked In-Reply-To: References: <1B5DEDFD-0DA0-42CE-866D-578A609A2F73@ORACLE.COM> Message-ID: +1 Thanks, Christoph > -----Original Message----- > From: Sean Mullan > Sent: Mittwoch, 9. Oktober 2019 20:58 > To: Rajan Halade ; security- > dev at openjdk.java.net > Cc: Langer, Christoph > Subject: Re: RFR: 8231887: ComodoCA.java fails because certificate was > revoked > > You should add the bugid to @bug and it probably should have a > noreg-self label. Looks good otherwise. > > --Sean > > On 10/9/19 1:56 PM, Rajan Halade wrote: > > Please review this fix in ComodoCA.java test to update test certificates > > used. CA revoked earlier test artifacts so we need to update those. > > > > Webrev: http://cr.openjdk.java.net/~rhalade/8231887/webrev.00/ > > > > Thanks, > > Rajan > > From weijun.wang at oracle.com Thu Oct 10 02:47:51 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 10 Oct 2019 10:47:51 +0800 Subject: [JDK-8223172] Incomplete/Unusable Kerberos Cross-Realm Referrals Support In-Reply-To: References: Message-ID: <146A87FB-11AD-44C5-BF69-C28D49EC7C26@oracle.com> Hi Michael, Thanks for trying this new feature, you are always the first one. If I remember correctly, when Martin developed this new feature, he was thinking of adding as little as possible spec change at the beginning. Therefore although there is a new KerberosPrincipal::KRB_NT_ENTERPRISE constant, it was just an integer and anyone can hardcode it. His next steps will be `kinit -e` and a new Krb5LoginModule option. And welcome to provide more detail on your usecase. --Max > On Sep 26, 2019, at 5:27 AM, Osipov, Michael wrote: > > Hi folks, > > apologies upfront that I wasn't able when Martin Balao asked for a review of the code. I finally made to test it and cannot see that it is working anyhow here. > > I won't dive into my usecase now, but will depict two simple cases which are not possible. > > All tests were performed with Oracle JDK 13 on Windows 7: >> java version "13" 2019-09-17 >> Java(TM) SE Runtime Environment (build 13+33) >> Java HotSpot(TM) 64-Bit Server VM (build 13+33, mixed mode, sharing) > > 1. kinit (JDK bundled) does not work. It does neither provide an '-E' option, nor does it send NT-ENTERPRISE, but only NT-UNKNOWN: > >> 0000 30 25 a0 03 02 01 00 a1 1e 30 1c 1b 1a 6d 69 63 0%.......0...mic >> 0010 68 61 65 6c 2e 6f 73 69 70 6f 76 40 73 69 65 6d hael.osipov at siem >> 0020 65 6e 73 2e 63 6f 6d ens.com > > In byte 0x06 is the name type NT-UNKNOWN (0). In contrast to this with MIT Kerberos 1.17 and 'kinit -E' I see in Wireshark: > >> 0000 30 25 a0 03 02 01 0a a1 1e 30 1c 1b 1a 6d 69 63 0%.......0...mic >> 0010 68 61 65 6c 2e 6f 73 69 70 6f 76 40 73 69 65 6d hael.osipov at siem >> 0020 65 6e 73 2e 63 6f 6d ens.com > > byte 0x06 is now name type NT-ENTERPRISE-PRINCIPAL (10). > > Trying the very same with LSA on Windows with "run as user" I get for my implicit UPN osipovmi at AD001.SIEMENS.NET always type 10. It only uses NT-PRINCIPAL when I provide the local part (samAccountName). > > 2. Using the appropriate OID for the enterprise principal: > >> public static void main(String[] args) throws GSSException { >> GSSManager m = GSSManager.getInstance(); >> Oid msUpnOid = new Oid("1.3.6.1.4.1.311.20.2.3"); >> Oid krb5PrincipalOid = new Oid("1.2.840.113554.1.2.2.1"); >> Oid krb5EnterprisePrincialOid = new Oid("1.2.840.113554.1.2.2.6"); >> Oid krb5MechOid = new Oid("1.2.840.113554.1.2.2"); >> GSSName upn = m.createName("michael.osipov at siemens.com", krb5EnterprisePrincialOid); >> } > > gives me: >> Exception in thread "main" GSSException: Name of unsupported type provided (Mechanism level: 1.2.840.113554.1.2.2.6 is an unsupported nametype) >> at java.security.jgss/sun.security.jgss.krb5.Krb5NameElement.getInstance(Krb5NameElement.java:87) >> at java.security.jgss/sun.security.jgss.krb5.Krb5MechFactory.getNameElement(Krb5MechFactory.java:99) >> at java.security.jgss/sun.security.jgss.GSSManagerImpl.getNameElement(GSSManagerImpl.java:184) >> at java.security.jgss/sun.security.jgss.GSSNameImpl.getElement(GSSNameImpl.java:478) >> at java.security.jgss/sun.security.jgss.GSSNameImpl.init(GSSNameImpl.java:201) >> at java.security.jgss/sun.security.jgss.GSSNameImpl.(GSSNameImpl.java:170) >> at java.security.jgss/sun.security.jgss.GSSNameImpl.(GSSNameImpl.java:151) >> at java.security.jgss/sun.security.jgss.GSSManagerImpl.createName(GSSManagerImpl.java:109) >> at com.siemens.dynamowerk.Main.main(Main.java:20) > > and yes, the OID has never been defined in that class [1], but is present in MIT Kerberos [2]. > > I haven't tried a programmatical kinit, but as mentioned in the notes [3], Krb5LoginModule does not support it, so I don't even have to try. > > > Any insights? > > Beside that, it'd be very cool if this gets into 11u or better yet to 8u. I have talked with Weijun about this several times many years ago for Java 7+. I have no option to use anything else, but Java 8 for now. > > If someone wants to know better about my usecase, I'd be happy to lay it out in detail. I do need at least krb5EnterprisePrincialOid and better msUpnOid for my usecase. > > The only option I see now is to write a delegating wrapper for this: > >> GSSName upn = m.createName("michael.osipov at siemens.com", krb5PrincipalOid); >> GSSName wrappedUpn = new WrappedGSSName(upn, krb5EnterprisePrincialOid); >> System.out.println(wrappedUpn); >> System.out.println(wrappedUpn.getStringNameType()); > >> michael.osipov at siemens.com >> 1.2.840.113554.1.2.2.6 > > Michael > > [1] https://github.com/AdoptOpenJDK/openjdk-jdk13u/blob/bb0786d980437800b9d6efe17e42d18241714ea1/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java#L51-L61 > [2] https://web.mit.edu/kerberos/krb5-devel/doc/appdev/gssapi.html > [3] http://mail.openjdk.java.net/pipermail/security-dev/2018-December/018952.html From weijun.wang at oracle.com Thu Oct 10 04:37:56 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 10 Oct 2019 12:37:56 +0800 Subject: RFR 8228969: 2019-10 public suffix list update Message-ID: http://cr.openjdk.java.net/~weijun/8228969/webrev.00/ Thanks, Max From weijun.wang at oracle.com Thu Oct 10 10:08:54 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 10 Oct 2019 18:08:54 +0800 Subject: RFR: 8231507: Update Apache Santuario (XML Signature) to version 2.1.4 In-Reply-To: <1cea5e8055784f999fc3bf952e0e975a@azul.com> References: <1cea5e8055784f999fc3bf952e0e975a@azul.com> Message-ID: <0FDF3251-E624-429B-A794-C0F1C0F97CBF@oracle.com> Hi Fedor, First, thanks a lot for the contribution. Overall the code change looks fine, but I have several comments: 1. The change in EncryptionConstants.java is not necessary. In this module we only do the signature part, but not encryption. 2. For the same reason, 5 new methods in XMLUtils.java about encryption. 3. In DOMRetrievalMethod.java, please revert to the use of "Policy.restrictNumTransforms(newTransforms.size())". The java.xml.crypto module inside OpenJDK is a little different from Santuario here and it uses a java.security property named "jdk.xml.dsig.secureValidationPolicy". 4. XMLDSigRI.java contains no actual change and can be kept unchanged. Have you found a committer to sponsor your code change? If not, I'll be happy to do it. Thanks, Max > On Oct 8, 2019, at 12:35 AM, Fedor Burdun wrote: > > Dear all, > > Would you please review the following change? > Bug: https://bugs.openjdk.java.net/browse/JDK-8231507 > Webrev: http://cr.openjdk.java.net/~fijiol/8231507/webrev.00/ > > This change upgrades Apache Santuario library to version 2.1.4 > > Best regards, > Fedor From fedor.burdun at azul.com Thu Oct 10 14:48:16 2019 From: fedor.burdun at azul.com (Fedor Burdun) Date: Thu, 10 Oct 2019 14:48:16 +0000 Subject: RFR: 8231507: Update Apache Santuario (XML Signature) to version 2.1.4 In-Reply-To: <0FDF3251-E624-429B-A794-C0F1C0F97CBF@oracle.com> References: <1cea5e8055784f999fc3bf952e0e975a@azul.com>, <0FDF3251-E624-429B-A794-C0F1C0F97CBF@oracle.com> Message-ID: <95bb954ec1ee45c4ba9e15a6333a2602@azul.com> Hi Weijun, I am glad to be helpful for community. Thanks a lot for your notes. In addition to all mentioned above and due to (8151893: Add security property to configure XML Signature secure validation mode) it seems the checking of Policy.restrictRetrievalMethodLoops also should be reverted? Please correct me if I'm wrong and it should not. Andrew Brygin volunteered to be sponsor for this code change. New webrev: http://cr.openjdk.java.net/~fijiol/8231507/webrev.01/ Tests: test/jdk/javax/xml/crypto/dsig/ Best regards, Fedor ________________________________ ??: Weijun Wang ??????????: 10 ??????? 2019 ?. 13:08 ????: Fedor Burdun ?????: security-dev at openjdk.java.net ????: Re: RFR: 8231507: Update Apache Santuario (XML Signature) to version 2.1.4 Hi Fedor, First, thanks a lot for the contribution. Overall the code change looks fine, but I have several comments: 1. The change in EncryptionConstants.java is not necessary. In this module we only do the signature part, but not encryption. 2. For the same reason, 5 new methods in XMLUtils.java about encryption. 3. In DOMRetrievalMethod.java, please revert to the use of "Policy.restrictNumTransforms(newTransforms.size())". The java.xml.crypto module inside OpenJDK is a little different from Santuario here and it uses a java.security property named "jdk.xml.dsig.secureValidationPolicy". 4. XMLDSigRI.java contains no actual change and can be kept unchanged. Have you found a committer to sponsor your code change? If not, I'll be happy to do it. Thanks, Max > On Oct 8, 2019, at 12:35 AM, Fedor Burdun wrote: > > Dear all, > > Would you please review the following change? > Bug: https://bugs.openjdk.java.net/browse/JDK-8231507 > Webrev: http://cr.openjdk.java.net/~fijiol/8231507/webrev.00/ > > This change upgrades Apache Santuario library to version 2.1.4 > > Best regards, > Fedor -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.osipov at siemens.com Thu Oct 10 15:09:48 2019 From: michael.osipov at siemens.com (Osipov, Michael) Date: Thu, 10 Oct 2019 17:09:48 +0200 Subject: [JDK-8223172] Incomplete/Unusable Kerberos Cross-Realm Referrals Support In-Reply-To: <146A87FB-11AD-44C5-BF69-C28D49EC7C26@oracle.com> References: <146A87FB-11AD-44C5-BF69-C28D49EC7C26@oracle.com> Message-ID: Mi Max, looking at the commit, I see only this being relevant: > + ReferralsState() throws KrbException { > + if (Config.DISABLE_REFERRALS) { > + if (cname.getNameType() == PrincipalName.KRB_NT_ENTERPRISE) { > + throw new KrbException("NT-ENTERPRISE principals only allowed" + > + " when referrals are enabled."); > + } > + enabled = false; > + } else { > + enabled = true; > + } > + refreshComm = true; > + } but I see no way to set cname with that name type. Anyway, the change provided by Martin Balao is merely limited to the Kerberos mechanism and does no export any of those changes upto the JGSS interface. I am excited to see these next steps. My use case is the following: one upcoming application will require a change in authentication layers with two phases where phase two might or might not happen. All changes happen on already existing code which works with Java for the last 8+ years and are freely available under ALv2. Phase 1: A webapp (REST API) hosted on Tomcat shall support either optional certificate-based and/or mandatory SPNEGO-based authentication. With SPNEGO I get the GSS name from the context, with the OID KRB5_NT_PRINCIPAL: 1.2.840.113554.1.2.2.1. Windows always canonicalizes and all Unix servers have "canonicalize = true" set. With certificates we don't have a GSS name, but we use then SAN which contains SSL_CLIENT_SAN_Email_0 and SSL_CLIENT_SAN_OTHER_msUPN_0. We care for the UPN only which maps to AD's userPrincipalName attribute with the OID 1.3.6.1.4.1.311.20.2.3. Though, this OID does not exist in Kerberos space we can map it to KRB5_NT_ENTERPRISE_PRINCIPAL: 1.2.840.113554.1.2.2.6 because in AD it is the same value. Similar to he MS-PAC data . With this GSS name which can be distinguished by OID I can feed Tomcat's Realm#authenticate(GSSName, GSSCredential) (in development by me [1]). My realm impl ActiveDirectoryRealm will happily pass this GSS name to a UsernameSearchMapper [2] which will tell the realm how to search for this principal. The OID-based support is not there yet, but is trivial to implement. After all that I can easily locate the user in the tree and read out all AD attributes including security groups. Without the KRB5_NT_ENTERPRISE_PRINCIPAL OID I cannot construct the GSS name from the cert and reuse it properly. As I have mentioned one can write a WrappedGSSName, but that's ugly. Phase 2: reuse the supplied principal to use S4U2 which may or may not be used. So this is optional. The GSS name will be crucial here because when S4U2proxy will have the enterprise principal from the cert, it will fail with unsupported OID. I would have to perform another AD search to construct the Kerberos principal or normalize in phase one to regular principals and throw away the enterprise principals which I don't want to do. Side note: I still run on Java 8 and Java 11 won't happen that fast here. Cross-realm referrals were solved with krb5.conf in previous years. In AD terms, you can use enterprise principals w/o following referrals in my opinions if and only if the principal is in the same realm and the machine you are logged in. Michael [1] https://github.com/apache/tomcat/commit/6be96ebba4e7056d5c9621bada2c496f8c0a82d0 [2] http://tomcatspnegoad.sourceforge.net/xref/net/sf/michaelo/tomcat/realm/mapper/UsernameSearchMapper.html#UsernameSearchMapper Am 2019-10-10 um 04:47 schrieb Weijun Wang: > Hi Michael, > > Thanks for trying this new feature, you are always the first one. > > If I remember correctly, when Martin developed this new feature, he was thinking of adding as little as possible spec change at the beginning. Therefore although there is a new KerberosPrincipal::KRB_NT_ENTERPRISE constant, it was just an integer and anyone can hardcode it. His next steps will be `kinit -e` and a new Krb5LoginModule option. > > And welcome to provide more detail on your usecase. > > --Max > >> On Sep 26, 2019, at 5:27 AM, Osipov, Michael wrote: >> >> Hi folks, >> >> apologies upfront that I wasn't able when Martin Balao asked for a review of the code. I finally made to test it and cannot see that it is working anyhow here. >> >> I won't dive into my usecase now, but will depict two simple cases which are not possible. >> >> All tests were performed with Oracle JDK 13 on Windows 7: >>> java version "13" 2019-09-17 >>> Java(TM) SE Runtime Environment (build 13+33) >>> Java HotSpot(TM) 64-Bit Server VM (build 13+33, mixed mode, sharing) >> >> 1. kinit (JDK bundled) does not work. It does neither provide an '-E' option, nor does it send NT-ENTERPRISE, but only NT-UNKNOWN: >> >>> 0000 30 25 a0 03 02 01 00 a1 1e 30 1c 1b 1a 6d 69 63 0%.......0...mic >>> 0010 68 61 65 6c 2e 6f 73 69 70 6f 76 40 73 69 65 6d hael.osipov at siem >>> 0020 65 6e 73 2e 63 6f 6d ens.com >> >> In byte 0x06 is the name type NT-UNKNOWN (0). In contrast to this with MIT Kerberos 1.17 and 'kinit -E' I see in Wireshark: >> >>> 0000 30 25 a0 03 02 01 0a a1 1e 30 1c 1b 1a 6d 69 63 0%.......0...mic >>> 0010 68 61 65 6c 2e 6f 73 69 70 6f 76 40 73 69 65 6d hael.osipov at siem >>> 0020 65 6e 73 2e 63 6f 6d ens.com >> >> byte 0x06 is now name type NT-ENTERPRISE-PRINCIPAL (10). >> >> Trying the very same with LSA on Windows with "run as user" I get for my implicit UPN osipovmi at AD001.SIEMENS.NET always type 10. It only uses NT-PRINCIPAL when I provide the local part (samAccountName). >> >> 2. Using the appropriate OID for the enterprise principal: >> >>> public static void main(String[] args) throws GSSException { >>> GSSManager m = GSSManager.getInstance(); >>> Oid msUpnOid = new Oid("1.3.6.1.4.1.311.20.2.3"); >>> Oid krb5PrincipalOid = new Oid("1.2.840.113554.1.2.2.1"); >>> Oid krb5EnterprisePrincialOid = new Oid("1.2.840.113554.1.2.2.6"); >>> Oid krb5MechOid = new Oid("1.2.840.113554.1.2.2"); >>> GSSName upn = m.createName("michael.osipov at siemens.com", krb5EnterprisePrincialOid); >>> } >> >> gives me: >>> Exception in thread "main" GSSException: Name of unsupported type provided (Mechanism level: 1.2.840.113554.1.2.2.6 is an unsupported nametype) >>> at java.security.jgss/sun.security.jgss.krb5.Krb5NameElement.getInstance(Krb5NameElement.java:87) >>> at java.security.jgss/sun.security.jgss.krb5.Krb5MechFactory.getNameElement(Krb5MechFactory.java:99) >>> at java.security.jgss/sun.security.jgss.GSSManagerImpl.getNameElement(GSSManagerImpl.java:184) >>> at java.security.jgss/sun.security.jgss.GSSNameImpl.getElement(GSSNameImpl.java:478) >>> at java.security.jgss/sun.security.jgss.GSSNameImpl.init(GSSNameImpl.java:201) >>> at java.security.jgss/sun.security.jgss.GSSNameImpl.(GSSNameImpl.java:170) >>> at java.security.jgss/sun.security.jgss.GSSNameImpl.(GSSNameImpl.java:151) >>> at java.security.jgss/sun.security.jgss.GSSManagerImpl.createName(GSSManagerImpl.java:109) >>> at com.siemens.dynamowerk.Main.main(Main.java:20) >> >> and yes, the OID has never been defined in that class [1], but is present in MIT Kerberos [2]. >> >> I haven't tried a programmatical kinit, but as mentioned in the notes [3], Krb5LoginModule does not support it, so I don't even have to try. >> >> >> Any insights? >> >> Beside that, it'd be very cool if this gets into 11u or better yet to 8u. I have talked with Weijun about this several times many years ago for Java 7+. I have no option to use anything else, but Java 8 for now. >> >> If someone wants to know better about my usecase, I'd be happy to lay it out in detail. I do need at least krb5EnterprisePrincialOid and better msUpnOid for my usecase. >> >> The only option I see now is to write a delegating wrapper for this: >> >>> GSSName upn = m.createName("michael.osipov at siemens.com", krb5PrincipalOid); >>> GSSName wrappedUpn = new WrappedGSSName(upn, krb5EnterprisePrincialOid); >>> System.out.println(wrappedUpn); >>> System.out.println(wrappedUpn.getStringNameType()); >> >>> michael.osipov at siemens.com >>> 1.2.840.113554.1.2.2.6 >> >> Michael >> >> [1] https://github.com/AdoptOpenJDK/openjdk-jdk13u/blob/bb0786d980437800b9d6efe17e42d18241714ea1/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java#L51-L61 >> [2] https://web.mit.edu/kerberos/krb5-devel/doc/appdev/gssapi.html >> [3] http://mail.openjdk.java.net/pipermail/security-dev/2018-December/018952.html > From sean.mullan at oracle.com Thu Oct 10 17:47:53 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 10 Oct 2019 13:47:53 -0400 Subject: RFR 8228969: 2019-10 public suffix list update In-Reply-To: References: Message-ID: <1bfbfca4-367a-1ed5-a08b-f5927c817330@oracle.com> Looks good although I would suggest changing the bug title to "2019-09-28 public suffix list update" to match the date of the PSL. --Sean On 10/10/19 12:37 AM, Weijun Wang wrote: > http://cr.openjdk.java.net/~weijun/8228969/webrev.00/ > > Thanks, > Max > From weijun.wang at oracle.com Fri Oct 11 03:30:52 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 11 Oct 2019 11:30:52 +0800 Subject: RFR 8231365, 8231196: bugs on kerberos permissions In-Reply-To: <8a5db15f-6fb8-167e-87f6-e4a66a8cef43@oracle.com> References: <8a5db15f-6fb8-167e-87f6-e4a66a8cef43@oracle.com> Message-ID: <81501458-0BA8-40FD-95C5-DBE078D8C2C8@oracle.com> Webrev updated at https://cr.openjdk.java.net/~weijun/8231365/webrev.01. I've also created a CSR at https://bugs.openjdk.java.net/browse/JDK-8232155. Please take a review. Thanks Max > On Oct 4, 2019, at 10:06 PM, Sean Mullan wrote: > > The changes for ServicePermission look fine. For DelegationPermission, I have a couple of comments: > > - The test has the wrong copyright (no need for the "Classpath" exception) > - I think we should clarify the specification of DelegationPermission constructors for the @throws IllegalArgumentException. It currently says: > > * @throws IllegalArgumentException if {@code principals} is empty. > > But with your fix, it also throws IllegalArgumentExc if principals does not contain a pair. Also, the current code throws IAE if there is a syntax error. So I would propose: > > * @throws IllegalArgumentException if {@code principals} is empty, or does not contain a pair of principals, or is improperly quoted > > --Sean > > On 9/25/19 10:50 PM, Weijun Wang wrote: >> Please take a review at >> https://cr.openjdk.java.net/~weijun/8231365/webrev.00 >> Thanks, >> Max From weijun.wang at oracle.com Sun Oct 13 08:27:11 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 13 Oct 2019 16:27:11 +0800 Subject: RFR 8231950: keytool -ext camel-case shorthand not working Message-ID: <13076EAA-2BEC-442E-ABC0-100E08EE39C0@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8231950/webrev.00/ Before this fix, the oneOf(s,list) method compares s to each item of the list in a case-insensitive way, and if there are multiple matches, it errors out saying input is ambiguous. The comparison looks like item.toLowerCase().startsWith(s.toLowerCase()) || item.toCamelCase().equalsIgnoreCase(s) Here, "howAreYou".toCamelCase() == "hAY". This means "de" or "dE" would match both "decipherOnly" and "dataEncipherment", and thus treated ambiguous. After this fix, the comparison is broken into 2 steps. If there is a single case-sensitive match, it's returned. Otherwise, fallback to case-insensitive. This means "de" would match "decipherOnly" and "dE" would match "dataEncipherment". This is a behavior change but all working cases still work, it's only those ambiguous cases are clean now. Also, in order to deal with the case that one option starts with another option, I've added an exact match at the beginning. Precisely, the steps are now item.equals(s) item.startsWith(s) || item.toCamelCase().equals(s) item.toLowerCase().startsWith(s.toLowerCase()) || item.toCamelCase().equalsIgnoreCase(s) A new test is added. An existing test is modified, where ambiguous case becomes not now. Thanks, Max From christian.schaefer at microfocus.com Mon Oct 14 08:41:25 2019 From: christian.schaefer at microfocus.com (Christian Schaefer) Date: Mon, 14 Oct 2019 08:41:25 +0000 Subject: FIPS 140.2 enabled TLS server rejects clients sending SSLv3 as record version in ClientHello Message-ID: Hi all, We have TLS connection issues when the server (openjdk version "1.8.0_222") runs in FIPS 140.2 mode. The error thrown on the server is: "javax.net.ssl.SSLException: Unsupported record version SSLv3" (which originates from: sun.security.ssl.InputRecord.checkRecordVersion(...)) This error only happens when the server JRE runs in FIPS 140.2 mode. This is because of the following code in class sun.security.ssl.ProtocolVersion: " // minimum version we implement (SSL 3.0) final static ProtocolVersion MIN = FIPS ? TLS10 : SSL30; " Our server *only* allows TLS 1.2 as TLS protocol version, however, If I have the correct understanding of the TLS 1.2 specification enforcing a record version of (at least ) TLS10 seems to violate the specification (https://tools.ietf.org/html/rfc5246#appendix-E.1): " [...] Thus, TLS servers compliant with this specification MUST accept any value {03,XX} as the record layer version number for ClientHello. [...] (Appendix E. Backward Compatibility - E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0) " Is this something which should be fixed in the JRE? Or is the behavior of the client wrong? Thanks, Christian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Oct 14 15:51:40 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 14 Oct 2019 11:51:40 -0400 Subject: FIPS 140.2 enabled TLS server rejects clients sending SSLv3 as record version in ClientHello In-Reply-To: References: Message-ID: On 10/14/19 4:41 AM, Christian Schaefer wrote: > Hi all, > > We have TLS connection issues when the server (openjdk version > "1.8.0_222") runs in FIPS 140.2 mode. The error thrown on the server is: > > ?javax.net.ssl.SSLException: Unsupported record version SSLv3? (which > originates from: sun.security.ssl.InputRecord.checkRecordVersion(?)) > > This error only happens when the server JRE runs in FIPS 140.2 mode. > This is because of the following code in class > sun.security.ssl.ProtocolVersion: > > ? > > ??? // minimum version we implement (SSL 3.0) > > ??? final static ProtocolVersion MIN = FIPS ? TLS10 : SSL30; > > ? > > Our server **only** allows TLS 1.2 as TLS protocol version, however, If > I have the correct understanding of the TLS 1.2 specification enforcing > a record version of (at least ) TLS10 seems to violate the specification > (https://tools.ietf.org/html/rfc5246#appendix-E.1): > > ? > > ?? [?] Thus, TLS servers compliant with this specification MUST accept > any value {03,XX} as > > ?? the record layer version number for ClientHello. [?] > > (Appendix E.? Backward Compatibility - E.1.? Compatibility with TLS > 1.0/1.1 and SSL 3.0) > > ? > > Is this something which should be fixed in the JRE? Or is the behavior > of the client wrong? Are you referring to the "FIPS 140 Compliant Mode for SunJSSE"? Note that this was documented as an "experimental" feature and has since been removed from the JDK [1]. However, one of the behavior differences of this mode was documented as: "Only TLS 1.0 and later can be used. SSL 2.0 and SSL 3.0 are not available. Any attempt to enable SSL 2.0 or 3.0 will fail with an exception." Can you give more info as to why SSLv3.0 is being used since it has well documented security weaknesses and should really no longer be used anymore? Thanks, Sean [1] https://bugs.openjdk.java.net/browse/JDK-8217907 From xuelei.fan at oracle.com Mon Oct 14 16:21:14 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 14 Oct 2019 09:21:14 -0700 Subject: FIPS 140.2 enabled TLS server rejects clients sending SSLv3 as record version in ClientHello In-Reply-To: References: Message-ID: If the client uses SSL 3.0 as the record version number, it normally means that the client support SSL 3.0. Since TLS 1.0, the spec is clear about the record version value. I don't think SSL 3.0 is acceptable in FIPS certified circumstances. Personally, I don't think it is a priority to fix in JDK unless there is a requirement in practice. Regards, Xuelei On 10/14/2019 1:41 AM, Christian Schaefer wrote: > Hi all, > > We have TLS connection issues when the server (openjdk version > "1.8.0_222") runs in FIPS 140.2 mode. The error thrown on the server is: > > ?javax.net.ssl.SSLException: Unsupported record version SSLv3? (which > originates from: sun.security.ssl.InputRecord.checkRecordVersion(?)) > > This error only happens when the server JRE runs in FIPS 140.2 mode. > This is because of the following code in class > sun.security.ssl.ProtocolVersion: > > ? > > ??? // minimum version we implement (SSL 3.0) > > ??? final static ProtocolVersion MIN = FIPS ? TLS10 : SSL30; > > ? > > Our server **only** allows TLS 1.2 as TLS protocol version, however, If > I have the correct understanding of the TLS 1.2 specification enforcing > a record version of (at least ) TLS10 seems to violate the specification > (https://tools.ietf.org/html/rfc5246#appendix-E.1): > > ? > > ?? [?] Thus, TLS servers compliant with this specification MUST accept > any value {03,XX} as > > ?? the record layer version number for ClientHello. [?] > > (Appendix E.? Backward Compatibility - E.1.? Compatibility with TLS > 1.0/1.1 and SSL 3.0) > > ? > > Is this something which should be fixed in the JRE? Or is the behavior > of the client wrong? > > Thanks, > > Christian. > From fw at deneb.enyo.de Mon Oct 14 17:43:56 2019 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 14 Oct 2019 19:43:56 +0200 Subject: FIPS 140.2 enabled TLS server rejects clients sending SSLv3 as record version in ClientHello In-Reply-To: (Sean Mullan's message of "Mon, 14 Oct 2019 11:51:40 -0400") References: Message-ID: <87a7a3rzmr.fsf@mid.deneb.enyo.de> * Sean Mullan: > Can you give more info as to why SSLv3.0 is being used since it has well > documented security weaknesses and should really no longer be used anymore? I think the SSLv3.0-compatible client hello is not in itself inherently unsafe, at least as long as the client is not willing to actually negotiate SSLv3.0. In the past, there were load balancers which could handle SSLv3.0-compatible hellos, but not much else. The actual backend server would negotiate something more recent off the legacy hello. I have no idea whether these workarounds are still needed in practice. However, I remember that past OpenJDK versions more or less defaulted to sending such client hellos. If these clients are in principle able to negotiate TLS 1.0 (or maybe even something newer), accepting that in FIPS mode as well would be nice. From eugene.adell at gmail.com Mon Oct 14 20:13:34 2019 From: eugene.adell at gmail.com (=?UTF-8?Q?Eug=C3=A8ne_Adell?=) Date: Mon, 14 Oct 2019 22:13:34 +0200 Subject: the GMT timestamp given in the trace is sometimes wrong In-Reply-To: References: Message-ID: Hello, I've posted this issue below 2 months ago and still did not see any reply. I also suggested how to correct. Can anyone please check ? Eugene Le lun. 12 ao?t 2019 ? 01:26, Eug?ne Adell a ?crit : > > Hello, > > When using the well-known javax.net.debug=all property we get outputs > similar to this : > > ... > Ignoring unsupported cipher suite: > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1 > Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 > for TLSv1.1 > Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 > for TLSv1.1 > %% No cached client session > update handshake state: client_hello[1] > upcoming handshake states: server_hello[2] > *** ClientHello, TLSv1.2 > RandomCookie: GMT: 1565495356 bytes = { 119, 88, 206, 84, 104, 18, > 56, 110, 157, 162, 50, 247, 142, 47, 46, 11, 133, 196, 21, 108, 17, > 205, 121, 220, 52, 127, 169, 241 } > Session ID: {} > Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, > TLS_RSA_WITH_AES_256_CBC_SHA256, > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, > ... > Compression Methods: { 0 } > Extension elliptic_curves, curve names: {secp256r1, secp384r1, > secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, > sect571r1, secp256k1} > Extension ec_point_formats, formats: [uncompressed] > Extension signature_algorithms, signature_algorithms: SHA512withECDSA, > SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, > SHA256withRSA, SHA256withDSA, SHA224withECDSA, SHA224withRSA, > SHA224withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA > Extension extended_master_secret > Extension server_name, server_name: [type=host_name (0), > value=bugs.openjdk.java.net] > *** > [write] MD5 and SHA1 hashes: len = 229 > 0000: 01 00 00 E1 03 03 5D 50 90 3C 77 58 CE 54 68 12 ......]P. 0010: 38 6E 9D A2 32 F7 8E 2F 2E 0B 85 C4 15 6C 11 CD 8n..2../.....l.. > 0020: 79 DC 34 7F A9 F1 00 00 56 C0 24 C0 28 00 3D C0 y.4.....V.$.(.=. > 0030: 26 C0 2A 00 6B 00 6A C0 0A C0 14 00 35 C0 05 C0 &.*.k.j.....5... > ... > > However converting the timestamp found in the RandomCookie 1565495356 > gives 5D4F903C and not 5D50903C, which is the value found in the debug > trace (line starting by "0000:") > This of course doesn't break anything but I guess this is not the > expected behaviour. > The problem is reproducible depending on the current time. From my > tests, the GMT value is wrong, and the value sent in the handshake > itself is right. Probably RandomCookie.print() is facing the > endianness problem, and I suggest the following patch that I > unit-tested but not in JSSE itself : > > --- a/RandomCookie.java 2019-08-12 00:43:56.458000000 +0200 > +++ b/RandomCookie.java 2019-08-12 01:18:06.874000000 +0200 > @@ -70,10 +70,10 @@ > void print(PrintStream s) { > int i, gmt_unix_time; > > - gmt_unix_time = random_bytes[0] << 24; > - gmt_unix_time += random_bytes[1] << 16; > - gmt_unix_time += random_bytes[2] << 8; > - gmt_unix_time += random_bytes[3]; > + gmt_unix_time = ((random_bytes[0] & 0xFF) << 24) | > + ((random_bytes[1] & 0xFF) << 16) | > + ((random_bytes[2] & 0xFF) << 8) | > + ((random_bytes[3] & 0xFF) << 0); > > s.print("GMT: " + gmt_unix_time + " "); > s.print("bytes = { "); > > > best regards > Eugene Adell From weijun.wang at oracle.com Tue Oct 15 02:07:57 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 15 Oct 2019 10:07:57 +0800 Subject: RFR 8231598: keytool does not export sun.security.mscapi Message-ID: Please take a look at http://cr.openjdk.java.net/~weijun/8231598/webrev.00/ For new grammars on how to add a provider in a module, use -addprovider (See [1]). Thanks, Max [1] https://bugs.openjdk.java.net/browse/JDK-8130302 From christian.schaefer at microfocus.com Tue Oct 15 07:31:13 2019 From: christian.schaefer at microfocus.com (Christian Schaefer) Date: Tue, 15 Oct 2019 07:31:13 +0000 Subject: FIPS 140.2 enabled TLS server rejects clients sending SSLv3 as record version in ClientHello In-Reply-To: <87a7a3rzmr.fsf@mid.deneb.enyo.de> References: <87a7a3rzmr.fsf@mid.deneb.enyo.de> Message-ID: * Sean Mullan > Are you referring to the "FIPS 140 Compliant Mode for SunJSSE"? Note that this was documented as an "experimental" feature and has since been removed from the JDK [1] Yes, I was referring to the "FIPS 140 Compliant Mode for SunJSSE". Sorry, for not being precise enough. Thanks for pointing out that this mode of SunJSSE was experimental - I didn't know. > Can you give more info as to why SSLv3.0 is being used since it has well documented security weaknesses and should really no longer be used anymore? We're not using SSLv3.0. The only place where this version appears is in the record version of one single client. > "Only TLS 1.0 and later can be used. SSL 2.0 and SSL 3.0 are not available. Any attempt to enable SSL 2.0 or 3.0 will fail with an exception." Yes. But TLS 1.2 seems to allow the client to specify SSLv3.0 as record version (not protocol version). I did not fully understand the reason behind this but it is how I understood the paragraph from rfc5246 that I referenced in my first email. * Florian Weimer > I think the SSLv3.0-compatible client hello is not in itself inherently unsafe, at > least as long as the client is not willing to actually negotiate SSLv3.0. Right, this is exactly how I understand it. In our scenario both, client and server are negotiating TLS 1.2 as the *only* protocol. Both, client and server don't support SSLv3. We only noticed that there was one client which stopped working after we switched the server into "FIPS mode". I first thought the client behavior is wrong, however, according to Appendix E. Backward Compatibility - E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 (which I referenced in my previous email) this seems to be not true. It is the server that rejects the client although it should not. * Xuelei Fan > Personally, I don't think it is a priority to fix in JDK unless there is a requirement in practice. Yes. We only had this issue with one client and it seems like we can change the client. So practically this is solved for us even w/o a fix. I hope there are not more clients which negotiate TLS 1.2 but set the record version to SSLv3.0. Personally, if you haven't heard this problem before I don't think it is a bigger issue. Thanks for your help. Christian > -----Original Message----- > From: Florian Weimer > Sent: Monday, October 14, 2019 7:44 PM > To: Sean Mullan > Cc: Christian Schaefer ; security- > dev at openjdk.java.net > Subject: Re: FIPS 140.2 enabled TLS server rejects clients sending SSLv3 as > record version in ClientHello > > * Sean Mullan: > > > Can you give more info as to why SSLv3.0 is being used since it has > > well documented security weaknesses and should really no longer be used > anymore? > > I think the SSLv3.0-compatible client hello is not in itself inherently unsafe, at > least as long as the client is not willing to actually negotiate SSLv3.0. In the > past, there were load balancers which could handle SSLv3.0-compatible > hellos, but not much else. The actual backend server would negotiate > something more recent off the legacy hello. I have no idea whether these > workarounds are still needed in practice. > > However, I remember that past OpenJDK versions more or less defaulted to > sending such client hellos. If these clients are in principle able to negotiate > TLS 1.0 (or maybe even something newer), accepting that in FIPS mode as > well would be nice. From weijun.wang at oracle.com Wed Oct 16 03:15:31 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 16 Oct 2019 11:15:31 +0800 Subject: RFR 8232357: Compare version info of Santuario to legal notice Message-ID: http://cr.openjdk.java.net/~weijun/8232357/webrev.00/ This fix adds the version info of Santuario into the source code and also introduces a test to ensure the version is the same with the one in the legal notice. Thanks, Max From simone.bordet at gmail.com Wed Oct 16 09:53:13 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Wed, 16 Oct 2019 11:53:13 +0200 Subject: Change in closeOutbound() behavior for unused SSLEngine Message-ID: Hi, SSLContext sslContext = SSLContext.getDefault(); SSLEngine sslEngine = sslContext.createSSLEngine(); sslEngine.closeOutbound(); SSLEngineResult.HandshakeStatus hsStatus = sslEngine.getHandshakeStatus(); System.err.println("hsStatus = " + hsStatus); This prints "NOT_HANDSHAKING" in Java 8 and "NEED_UNWRAP" in JDK 11+. In both cases, trying to wrap() consumes and produces 0 bytes (so the close_notify is not generated, which I think is fine given that the SSLEngine was never used) and produces a CLOSED result. This case is common for connections that are established but never used (not even a TLS byte was exchanged). Is this change in behavior expected? I find strange that calling closeOutbound() results in a NEED_UNWRAP (as there is nothing to read). Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From sean.mullan at oracle.com Wed Oct 16 14:36:06 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 16 Oct 2019 10:36:06 -0400 Subject: RFR 8232357: Compare version info of Santuario to legal notice In-Reply-To: References: Message-ID: <6c006d91-db48-998d-e412-09d6174c95eb@oracle.com> Looks fine to me. --Sean On 10/15/19 11:15 PM, Weijun Wang wrote: > http://cr.openjdk.java.net/~weijun/8232357/webrev.00/ > > This fix adds the version info of Santuario into the source code and also introduces a test to ensure the version is the same with the one in the legal notice. > > Thanks, > Max > From xuelei.fan at oracle.com Wed Oct 16 15:42:26 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 16 Oct 2019 08:42:26 -0700 Subject: Change in closeOutbound() behavior for unused SSLEngine In-Reply-To: References: Message-ID: The TLS protocol was changed to use half-close policy since TLS 1.3. As means that sslEngine.closeOutbound() will close the outbound and keep the inbound open. "NEED_UNWRAP" is used to indicate that the engine can still be used to decode input message. For the specific case bellow, it is reasonable to expect "NOT_HANDSHAKING" as the handshaking has not been started. On the other side, as only the inbound open, it is also reasonable to me to use "NEED_UNWRAP" although there is nothing to unwrap. I think, using ""NOT_HANDSHAKING" may lead to confusing about what the next operation, wrap() or unwrap(), could be in practice. CLOSED is not an option to me as the inbound is still open. I understand there might be some compatibility issues for the use of half-close policy. I may close both inbound and outbound of an engine in the application code if the connection is not used. Is there a known compatibility impact on you applications? Thanks & Regards, Xuelei On 10/16/2019 2:53 AM, Simone Bordet wrote: > Hi, > > SSLContext sslContext = SSLContext.getDefault(); > SSLEngine sslEngine = sslContext.createSSLEngine(); > sslEngine.closeOutbound(); > SSLEngineResult.HandshakeStatus hsStatus = sslEngine.getHandshakeStatus(); > System.err.println("hsStatus = " + hsStatus); > > This prints "NOT_HANDSHAKING" in Java 8 and "NEED_UNWRAP" in JDK 11+. > > In both cases, trying to wrap() consumes and produces 0 bytes (so the > close_notify is not generated, which I think is fine given that the > SSLEngine was never used) and produces a CLOSED result. > > This case is common for connections that are established but never > used (not even a TLS byte was exchanged). > > Is this change in behavior expected? > > I find strange that calling closeOutbound() results in a NEED_UNWRAP > (as there is nothing to read). > > Thanks! > From simone.bordet at gmail.com Wed Oct 16 16:13:22 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Wed, 16 Oct 2019 18:13:22 +0200 Subject: Change in closeOutbound() behavior for unused SSLEngine In-Reply-To: References: Message-ID: Hi, On Wed, Oct 16, 2019 at 5:42 PM Xuelei Fan wrote: > > The TLS protocol was changed to use half-close policy since TLS 1.3. As > means that sslEngine.closeOutbound() will close the outbound and keep > the inbound open. "NEED_UNWRAP" is used to indicate that the engine can > still be used to decode input message. Maybe it's a matter of interpretation, but the SSLEngine state was not used to indicate what may _possibly_ be done in the future. It was an exact indication of what an application should do _now_. In the normal case (after the handshake is completed), closeOutbound() turns the state into NEED_WRAP because wrapping will generate the close_notify. In this case, NEED_UNWRAP is strange because I just closed the outbound, and it's not clear what I need to read right now. In fact, most of the times the read will yield 0 bytes because the other peer is not aware that we have closed the outbound (as nothing was produced to be sent to the other peer). > For the specific case bellow, it is reasonable to expect > "NOT_HANDSHAKING" as the handshaking has not been started. On the other > side, as only the inbound open, it is also reasonable to me to use > "NEED_UNWRAP" although there is nothing to unwrap. I think, using > ""NOT_HANDSHAKING" may lead to confusing about what the next operation, > wrap() or unwrap(), could be in practice. CLOSED is not an option to me > as the inbound is still open. CLOSED is the _result_ (not the state) after a wrap(). Seems to me that you are saying that NOT_HANDSHAKING is wrong because it does not tell what to do now, and NEED_UNWRAP is also wrong because, well, there is nothing to unwrap. What remains is NEED_WRAP, which will correctly tell what an application needs to do. This is exactly what happens after the TLS handshake is completed: the application is in NOT_HANDSHAKING and calling closeOutbound() changes the state into NEED_WRAP. So I think there is an asymmetry between the behavior of closeOutbound() before and after the handshake that does not seem justified? > I understand there might be some compatibility issues for the use of > half-close policy. I may close both inbound and outbound of an engine > in the application code if the connection is not used. I think that if an application calls closeOutbound(), the implementation should only do that. > Is there a known compatibility impact on you applications? Yes. It's not possible to use the same code JDK 8 and JDK 11, unless there is some "if (isJDK11Behavior())" throughout the code. Looking just at JDK 11 behavior, what happens is: * closeOutbound() * state is now NEED_UNWRAP * read from network, 0 bytes * call unwrap(), produces a BUFFER_UNDERFLOW result, basically says "wait for bytes to read" that will never come * 0 bytes have been produced so nothing gets sent to the other peer * the application does not know _when_ to send a FIN to the other peer (it's waiting for the state to move away from NEED_UNWRAP and/or for a CLOSED result) Contrast that with: * closeOutbound() * state is now NEED_WRAP * call wrap(), produces CLOSED result, basically says "we are done with the output" * 0 bytes have been produced, so no close_notify is sent to the other peer, but we know from the CLOSED result that we can now send the FIN to the other peer. Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From xuelei.fan at oracle.com Wed Oct 16 17:42:07 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 16 Oct 2019 10:42:07 -0700 Subject: Change in closeOutbound() behavior for unused SSLEngine In-Reply-To: References: Message-ID: <9970a01d-4296-d89a-675a-5c2ec64de823@oracle.com> Hi Simone, The compatibility impact makes sense to me. Would you mind file a new bug? Thanks, Xuelei On 10/16/2019 9:13 AM, Simone Bordet wrote: > Hi, > > On Wed, Oct 16, 2019 at 5:42 PM Xuelei Fan wrote: >> >> The TLS protocol was changed to use half-close policy since TLS 1.3. As >> means that sslEngine.closeOutbound() will close the outbound and keep >> the inbound open. "NEED_UNWRAP" is used to indicate that the engine can >> still be used to decode input message. > > Maybe it's a matter of interpretation, but the SSLEngine state was not > used to indicate what may _possibly_ be done in the future. > It was an exact indication of what an application should do _now_. > In the normal case (after the handshake is completed), closeOutbound() > turns the state into NEED_WRAP because wrapping will generate the > close_notify. > In this case, NEED_UNWRAP is strange because I just closed the > outbound, and it's not clear what I need to read right now. > In fact, most of the times the read will yield 0 bytes because the > other peer is not aware that we have closed the outbound (as nothing > was produced to be sent to the other peer). > >> For the specific case bellow, it is reasonable to expect >> "NOT_HANDSHAKING" as the handshaking has not been started. On the other >> side, as only the inbound open, it is also reasonable to me to use >> "NEED_UNWRAP" although there is nothing to unwrap. I think, using >> ""NOT_HANDSHAKING" may lead to confusing about what the next operation, >> wrap() or unwrap(), could be in practice. CLOSED is not an option to me >> as the inbound is still open. > > CLOSED is the _result_ (not the state) after a wrap(). > Seems to me that you are saying that NOT_HANDSHAKING is wrong because > it does not tell what to do now, and NEED_UNWRAP is also wrong > because, well, there is nothing to unwrap. > What remains is NEED_WRAP, which will correctly tell what an > application needs to do. > This is exactly what happens after the TLS handshake is completed: the > application is in NOT_HANDSHAKING and calling closeOutbound() changes > the state into NEED_WRAP. > So I think there is an asymmetry between the behavior of > closeOutbound() before and after the handshake that does not seem > justified? > >> I understand there might be some compatibility issues for the use of >> half-close policy. I may close both inbound and outbound of an engine >> in the application code if the connection is not used. > > I think that if an application calls closeOutbound(), the > implementation should only do that. > >> Is there a known compatibility impact on you applications? > > Yes. > It's not possible to use the same code JDK 8 and JDK 11, unless there > is some "if (isJDK11Behavior())" throughout the code. > > Looking just at JDK 11 behavior, what happens is: > * closeOutbound() > * state is now NEED_UNWRAP > * read from network, 0 bytes > * call unwrap(), produces a BUFFER_UNDERFLOW result, basically says > "wait for bytes to read" that will never come > * 0 bytes have been produced so nothing gets sent to the other peer > * the application does not know _when_ to send a FIN to the other peer > (it's waiting for the state to move away from NEED_UNWRAP and/or for a > CLOSED result) > > Contrast that with: > * closeOutbound() > * state is now NEED_WRAP > * call wrap(), produces CLOSED result, basically says "we are done > with the output" > * 0 bytes have been produced, so no close_notify is sent to the other > peer, but we know from the CLOSED result that we can now send the FIN > to the other peer. > > Thanks! > From simone.bordet at gmail.com Wed Oct 16 20:27:17 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Wed, 16 Oct 2019 22:27:17 +0200 Subject: Change in closeOutbound() behavior for unused SSLEngine In-Reply-To: <9970a01d-4296-d89a-675a-5c2ec64de823@oracle.com> References: <9970a01d-4296-d89a-675a-5c2ec64de823@oracle.com> Message-ID: Hi, On Wed, Oct 16, 2019 at 7:42 PM Xuelei Fan wrote: > > Hi Simone, > > The compatibility impact makes sense to me. Would you mind file a new bug? https://bugs.openjdk.java.net/browse/JDK-8232432 Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From ivan.gerasimov at oracle.com Thu Oct 17 01:33:27 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 16 Oct 2019 18:33:27 -0700 Subject: RFR (XS) 8231859 : Extra dash after the exception name in @throws clause of javadoc Message-ID: <668e7cc2-5c1f-08a6-a9b4-84b93e5b32b5@oracle.com> Hello! This is a javadoc-only cleanup. In a few places a dash was used between the exception name and the description under the @throws tag. This causes a double dash in the produced documentation.? For example, see https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/security/PermissionCollection.html#add(java.security.Permission) Would you please help review a trivial cleanup? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8231859 WEBREV: http://cr.openjdk.java.net/~igerasim/8231859/00/webrev/ -- With kind regards, Ivan Gerasimov From weijun.wang at oracle.com Thu Oct 17 01:42:56 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 17 Oct 2019 09:42:56 +0800 Subject: RFR (XS) 8231859 : Extra dash after the exception name in @throws clause of javadoc In-Reply-To: <668e7cc2-5c1f-08a6-a9b4-84b93e5b32b5@oracle.com> References: <668e7cc2-5c1f-08a6-a9b4-84b93e5b32b5@oracle.com> Message-ID: <9D6677AB-245A-4BE0-81CA-B8C6C43C9287@oracle.com> The change looks fine to me. Thanks, Max > On Oct 17, 2019, at 9:33 AM, Ivan Gerasimov wrote: > > Hello! > > This is a javadoc-only cleanup. > > In a few places a dash was used between the exception name and the description under the @throws tag. > > This causes a double dash in the produced documentation. For example, see https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/security/PermissionCollection.html#add(java.security.Permission) > > Would you please help review a trivial cleanup? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8231859 > WEBREV: http://cr.openjdk.java.net/~igerasim/8231859/00/webrev/ > > -- > With kind regards, > Ivan Gerasimov > From ivan.gerasimov at oracle.com Thu Oct 17 06:21:18 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 16 Oct 2019 23:21:18 -0700 Subject: RFR (XS) 8231859 : Extra dash after the exception name in @throws clause of javadoc In-Reply-To: <9D6677AB-245A-4BE0-81CA-B8C6C43C9287@oracle.com> References: <668e7cc2-5c1f-08a6-a9b4-84b93e5b32b5@oracle.com> <9D6677AB-245A-4BE0-81CA-B8C6C43C9287@oracle.com> Message-ID: <6f68c187-afe2-e7b5-acab-6311dc48e348@oracle.com> Thank you Weijun! Pushed. On 10/16/19 6:42 PM, Weijun Wang wrote: > The change looks fine to me. > > Thanks, > Max > > >> On Oct 17, 2019, at 9:33 AM, Ivan Gerasimov wrote: >> >> Hello! >> >> This is a javadoc-only cleanup. >> >> In a few places a dash was used between the exception name and the description under the @throws tag. >> >> This causes a double dash in the produced documentation. For example, see https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/security/PermissionCollection.html#add(java.security.Permission) >> >> Would you please help review a trivial cleanup? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8231859 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8231859/00/webrev/ >> >> -- >> With kind regards, >> Ivan Gerasimov >> > -- With kind regards, Ivan Gerasimov From weijun.wang at oracle.com Thu Oct 17 07:00:12 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 17 Oct 2019 15:00:12 +0800 Subject: RFR 8026393: jarsigner never shows a warning in badKeyUsage case Message-ID: <76CA6D80-89D3-4BE2-AF04-1CF2121508CA@oracle.com> While verifying a signed jar, the signer certificate's KeyUsage and ExtendedKeyUsage extensions are treated differently. If the ExtendedKeyUsage extension does not allow code signing, the JarFile API will accept the signature (i.e. jarEntry.getCodeSigners() returns something), and then jarsigner will check the cert and print out a warning. If the KeyUsage extension does not allow code signing, the JarFile API will reject it directly and jarsigner will skip the certificate checking because the file is treated unsigned. We used to think that we could treat them in the same manner. Two tests - BadExtendedKeyUsageTest.java[2] and BadKeyUsageTest.java[1] - were developed for this purpose, and BadKeyUsageTest.java is labeled @ignore (before we make the change). My current opinion is we will not update the JarFile API for this, and will also keep the jarsigner behavior, i.e. if JarFile API think it's unsigned, we treat it unsigned and stop. Thus one will never see the badKeyUsage warning at verification time. The fix to the issue will be simply - remove test/jdk/sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java I assume there is no need to post a webrev. Please note that there will be no change to the jarsigner doc because the badKeyUsage warning is still possible when signing a file. Thanks, Max [1] https://hg.openjdk.java.net/jdk/jdk/file/d2108d9fc4f5/test/jdk/sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java [2] https://hg.openjdk.java.net/jdk/jdk/file/d2108d9fc4f5/test/jdk/sun/security/tools/jarsigner/warnings/BadExtendedKeyUsageTest.java From j08ny at mail.muni.cz Thu Oct 17 08:49:54 2019 From: j08ny at mail.muni.cz (=?UTF-8?B?SsOhbiBKYW7EjcOhcg==?=) Date: Thu, 17 Oct 2019 10:49:54 +0200 Subject: Minerva vulnerability + patch In-Reply-To: References: Message-ID: Hi all, I saw that the CVE for this vulnerability was mentioned in the latest critical patch update advisory as fixed: https://www.oracle.com/technetwork/security-advisory/cpuoct2019-5072832.html And is now also public: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2894 However, the only change related to ECDSA I saw in the OpenJDK tree is this: https://hg.openjdk.java.net/jdk/jdk/rev/d66bdf0e2dfe 8228825: Enhance ECDSA operations Reviewed-by: mullan Author: ascarpino It basically disables support for binary field curves in the Java TLS/SSL server. However, this does not fix the vulnerability: - Any user of the SunEC library through JCA remains vulnerable. - Any user of the Java TLS/SSL server that sets up the server to allow and use binary field curves (through "jdk.tls.namedGroups" for example) remains vulnerable. A proper patch for this issue was posted earlier, with analysis of correctness and passing tests. Cheers, Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From Alan.Bateman at oracle.com Thu Oct 17 10:26:36 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Oct 2019 11:26:36 +0100 Subject: Minerva vulnerability + patch In-Reply-To: References: Message-ID: <7dffb05e-5b2b-3ad5-482e-d99d2a6182ab@oracle.com> On 17/10/2019 09:49, J?n Jan??r wrote: > Hi all, > I saw that the CVE for this vulnerability was mentioned in the latest > critical patch update advisory as fixed: > The OpenJDK mailing lists shouldn't be used to discuss vulnerability issues. Instead you should engage with the OpenJDK Vulnerability Group via their reporting page [1]. -Alan [1] https://openjdk.java.net/groups/vulnerability/report From j08ny at mail.muni.cz Thu Oct 17 13:10:44 2019 From: j08ny at mail.muni.cz (=?UTF-8?B?SsOhbiBKYW7EjcOhcg==?=) Date: Thu, 17 Oct 2019 15:10:44 +0200 Subject: Minerva vulnerability + patch In-Reply-To: <7dffb05e-5b2b-3ad5-482e-d99d2a6182ab@oracle.com> References: <7dffb05e-5b2b-3ad5-482e-d99d2a6182ab@oracle.com> Message-ID: <6ee83a93-cf7c-00e0-4149-dbf630e6e6ff@mail.muni.cz> On 17/10/2019 12:26, Alan Bateman wrote: > On 17/10/2019 09:49, J?n Jan??r wrote: >> Hi all, >> I saw that the CVE for this vulnerability was mentioned in the latest >> critical patch update advisory as fixed: >> > The OpenJDK mailing lists shouldn't be used to discuss vulnerability issues. Instead you should engage with the OpenJDK Vulnerability Group via their reporting page [1]. > Hi Alan, all, we already did this months ago. In fact this fix I mention is the direct consequence of our report. As this is all public after our disclosure [1], I see no reason to keep this discussion private. The patch provided on this mailing list was sent to the Oracle security contact (and hopefully passed on to the OpenJDK security team) on 14.08.2019. By posting to this list I was hoping to move forward on fixing the issue by applying this patch, or a similar one based on it, as the issue remains unfixed months after our discovery/notification. [1]: https://minerva.crocs.fi.muni.cz Cheers, Jan From weijun.wang at oracle.com Fri Oct 18 02:43:23 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 18 Oct 2019 10:43:23 +0800 Subject: RFR 8228969: 2019-09-28 public suffix list update In-Reply-To: <1bfbfca4-367a-1ed5-a08b-f5927c817330@oracle.com> References: <1bfbfca4-367a-1ed5-a08b-f5927c817330@oracle.com> Message-ID: I've updated the title and also added a test that deals with several typical forms of domain names. Files in webrev.00 are not altered. Please take a review: http://cr.openjdk.java.net/~weijun/8228969/webrev.01/ Thanks, Max > On Oct 11, 2019, at 1:47 AM, Sean Mullan wrote: > > Looks good although I would suggest changing the bug title to "2019-09-28 public suffix list update" to match the date of the PSL. > > --Sean > > On 10/10/19 12:37 AM, Weijun Wang wrote: >> http://cr.openjdk.java.net/~weijun/8228969/webrev.00/ >> Thanks, >> Max From sean.mullan at oracle.com Fri Oct 18 17:05:48 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 18 Oct 2019 13:05:48 -0400 Subject: RFR 8228969: 2019-09-28 public suffix list update In-Reply-To: References: <1bfbfca4-367a-1ed5-a08b-f5927c817330@oracle.com> Message-ID: Looks good. --Sean On 10/17/19 10:43 PM, Weijun Wang wrote: > I've updated the title and also added a test that deals with several typical forms of domain names. Files in webrev.00 are not altered. Please take a review: > > http://cr.openjdk.java.net/~weijun/8228969/webrev.01/ > > Thanks, > Max > > >> On Oct 11, 2019, at 1:47 AM, Sean Mullan wrote: >> >> Looks good although I would suggest changing the bug title to "2019-09-28 public suffix list update" to match the date of the PSL. >> >> --Sean >> >> On 10/10/19 12:37 AM, Weijun Wang wrote: >>> http://cr.openjdk.java.net/~weijun/8228969/webrev.00/ >>> Thanks, >>> Max > From fw at deneb.enyo.de Sat Oct 19 13:41:52 2019 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 19 Oct 2019 15:41:52 +0200 Subject: Socket and SSLSocket thread safety Message-ID: <87eez8ua1r.fsf@mid.deneb.enyo.de> If I'm not mistaken, there are currently no concurrency guarantees in the spec for Socket and SSLSocket. Specifically, I'm interested whether two different threads can use the the streams returned by getInputStream() and getOutputStream() without synchronization. (This is useful for implementing full-duplex connections without having to wrestle with SSLEngine.) Peeking at the implementation of SSLSocket, I see that there is quite a bit of locking performed in there. Is this expected to be sufficient for the scenario I outlined? From mbalao at redhat.com Mon Oct 21 20:07:39 2019 From: mbalao at redhat.com (Martin Balao) Date: Mon, 21 Oct 2019 17:07:39 -0300 Subject: [JDK-8223172] Incomplete/Unusable Kerberos Cross-Realm Referrals Support In-Reply-To: References: Message-ID: Hi Michael, Thanks for providing your feedback and apologies for the delay to answer. As you well noticed (and @Max already said), the kinit/login/jgss parts of NT-ENTERPRISE were not implemented in the first stage; only the internal machinery. It should be pretty straight forward to implement the missing bits now that we have the basis. My plan is the following: 1) Have S4U2Self and S4U2Proxy referrals approved (webrev already proposed, under review) 2) Backport all the referrals-related work so far to 11u and 8u * 11u is almost done Only after that I can try to make time for your request. However, feel free to propose a patch before and I'll certainly have a look :-) Thanks, Martin.- From sean.mullan at oracle.com Tue Oct 22 15:33:24 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 22 Oct 2019 11:33:24 -0400 Subject: RFR 8231598: keytool does not export sun.security.mscapi In-Reply-To: References: Message-ID: <1876ab17-474d-c2f2-b31e-a974b6eb23dd@oracle.com> In KeyStoreUtil.java, change: 307 // For compatibility, SunPKCS11 and OracleUcrypto can still be to: 307: // For compatibility, SunPKCS11, OracleUcrypto and SunMSCAPI can still be Otherwise, looks fine. --Sean On 10/14/19 10:07 PM, Weijun Wang wrote: > Please take a look at > > http://cr.openjdk.java.net/~weijun/8231598/webrev.00/ > > For new grammars on how to add a provider in a module, use -addprovider (See [1]). > > Thanks, > Max > > [1] https://bugs.openjdk.java.net/browse/JDK-8130302 > From mbalao at redhat.com Tue Oct 22 16:36:32 2019 From: mbalao at redhat.com (Martin Balao) Date: Tue, 22 Oct 2019 13:36:32 -0300 Subject: RFR 8005819: Support cross-realm MSSFU In-Reply-To: References: Message-ID: Hi, I'd like to propose Webrev.01 for 8005819 [1]: * http://cr.openjdk.java.net/~mbalao/webrevs/8005819/8005819.webrev.01/ New changes: * Avoid re-checking S4U2Proxy and S4U2Self status in each referral request (do this only once in "CredentialsUtils::serviceCreds") * Other minor improvements (code readability introducing S4U2Type, do not propagate client alias for impersonation TGSs, debugging output) Testing: no regressions found in jdk/sun/security/krb5. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8005819 From Nico.Williams at twosigma.com Wed Oct 23 02:07:53 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Wed, 23 Oct 2019 02:07:53 +0000 Subject: CR request for JGSS improvements Message-ID: <20191023020753.GL240820@twosigma.com> Webrevs are at https://cr.openjdk.java.net/~weijun/twosigma-gss-2019/. I used Dave Pacheco's webrev fork to generate these from my git clone of AdoptOpenJDK. The bugs/enhancements are at: https://bugs.openjdk.java.net/issues/?jql=assignee%20%3D%20nwilliams%20ORDER%20BY%20key%20ASC. Nico -- From weijun.wang at oracle.com Thu Oct 24 08:16:38 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 24 Oct 2019 16:16:38 +0800 Subject: RFR 8231508: Spec Clarification : KeyTab:exist() method does not specify about the fallback details Message-ID: <85631C41-788D-4F94-AA01-5486271DF655@oracle.com> Please review the patch below: --- a/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KeyTab.java +++ b/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KeyTab.java @@ -303,13 +303,11 @@ /** * Checks if the keytab file exists. Implementation of this method * should make sure that the result matches the latest status of the * keytab file. - *

- * The caller can use the result to determine if it should fallback to - * another mechanism to read the keys. + * * @return true if the keytab file exists; false otherwise. * @throws SecurityException if a security manager exists and the read * access to the keytab file is not permitted */ public boolean exists() { The spec here is not clear and even our own JGSS SubjectComber looks into both KeyTab and KerberosKey and there is no fallback of any kind. Do you think this is worth a CSR? Thanks, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Thu Oct 24 10:52:07 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 24 Oct 2019 10:52:07 +0000 Subject: RFR [11] CSR for "Add Brainpool ECC support (RFC 5639)" In-Reply-To: References: <5b28158a.1c69fb81.da9dc.2500@mx.google.com> <46ebf4bd-ba09-657b-3c88-c884400edc36@oracle.com>, Message-ID: Hello, Coming back to the message of Tobias, it looks* like even in 14 the Brainpool curves have not landed for JSSE, are there any plans for adding this? can you maybe share your incomplete patch, Tobias? * i don?t see them in ssl/NamesGroups: http://hg.openjdk.java.net/jdk/jdk/file/tip/src/java.base/share/classes/sun/security/ssl/NamedGroup.java Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Tobias Wagner Gesendet: Mittwoch, Juni 27, 2018 7:49 PM An: security-dev at openjdk.java.net Betreff: AW: RFR [11] CSR for "Add Brainpool ECC support (RFC 5639)" Hi Valerie and Bernd, Valerie is right, I tested my JTREG Tests against SoftHSM2 in March: http://mail.openjdk.java.net/pipermail/security-dev/2018-March/016863.html I don't think there are more PKCS#11 related issues, as SunEC is not a PKCS#11 implementation. There are only shared tests. The JTREG known answer tests use the X9.62 key format as they are used in certificates as well. I assume, brainpool public keys would work in certificates as well. I actually implemented the support for brainpool curves in TLS as well, but I had no time to provide proper JTREG tests for that, and therefore no patch yet. Regards, Tobias -- phone: +49 221 222896 17 fax: +49 221 222896 11 keybase: https://keybase.io/toebix n - d e s i g n G m b H https://n-design.de Alpenerstr. 16 50825 K?ln Deutschland / Germany Amtsgericht K?ln HRB 33766 B Gesch?ftsf?hrer Andy Kohl > -----Urspr?ngliche Nachricht----- > Von: security-dev Im Auftrag von > Valerie Peng > Gesendet: Donnerstag, 21. Juni 2018 01:07 > An: security-dev at openjdk.java.net > Betreff: Re: RFR [11] CSR for "Add Brainpool ECC support (RFC 5639)" > > Are you asking about CSR or existing bug for including Brainpool support > in TLS? > > I saw some bugs which mentions errors/exceptions which brainpool is > used, e.g. JSSE has https://bugs.openjdk.java.net/browse/JDK-7189107, > key tool has https://bugs.openjdk.java.net/browse/JDK-8201290. After > this brainpool support is integrated, it'll be easier to re-evaluate > these. > > > As for PKCS11, Tobias tested this against a 3rd party PKCS11 library and > the result is positive if I recall correctly. > > > Thanks, > Valerie > > > On 6/18/2018 1:26 PM, Bernd Eckenfels wrote: > > > Hello, > > > > not a Reviewer, but some Questions on the CSR: > > > > * Are there other CSRs for including in TLS? > * I also wonder if PKI (CA Signatures) will work out of the box > then (OID aliases?) > * Does PKCS11 require additional changes? (especially for the > Government use mentioned in the justification HSMs are often mandatory) > > > > Gruss > > Bernd > > -- > http://bernd.eckenfels.net > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Oct 24 17:56:43 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 24 Oct 2019 13:56:43 -0400 Subject: RFR 8005819: Support cross-realm MSSFU In-Reply-To: References: Message-ID: Hi Martin, Can you update the Description of this Enhancement with more specific details of what the Enhancement is and what problems it will address? The current issue contains an exception stack trace from a test and no further details. This is important for Reviewers as well as being able to understand later on what the Enhancement was about. Thanks, Sean On 10/22/19 12:36 PM, Martin Balao wrote: > Hi, > > I'd like to propose Webrev.01 for 8005819 [1]: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8005819/8005819.webrev.01/ > > New changes: > > * Avoid re-checking S4U2Proxy and S4U2Self status in each referral > request (do this only once in "CredentialsUtils::serviceCreds") > > * Other minor improvements (code readability introducing S4U2Type, do > not propagate client alias for impersonation TGSs, debugging output) > > Testing: no regressions found in jdk/sun/security/krb5. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8005819 > From xuelei.fan at oracle.com Thu Oct 24 20:56:05 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 24 Oct 2019 13:56:05 -0700 Subject: RFR [14] 8223940: Private key not supported by chosen signature algorithm Message-ID: <427ac332-3add-c426-ea9f-4b7ed047519f@oracle.com> Hi, Could I get the following update reviewed? http://cr.openjdk.java.net/~xuelei/8223940/webrev.00/ For signature algorithms, the update will fail back to use the supported signature algorithm for the specific private key. Previously, the first preferred signature algorithm get used ad the private key may not be able to work with the signature algorithm however. No new regression test as RSASSA-PSS has been supported in the SunPKCS11 provider currently. Can I get a help for the test if you are running a provider that does not support RSASSA-PSS yet? Thanks & Regards, Xuelei From weijun.wang at oracle.com Fri Oct 25 02:15:18 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 25 Oct 2019 10:15:18 +0800 Subject: RFR 8231508: Spec Clarification : KeyTab:exist() method does not specify about the fallback details In-Reply-To: <85631C41-788D-4F94-AA01-5486271DF655@oracle.com> References: <85631C41-788D-4F94-AA01-5486271DF655@oracle.com> Message-ID: <5ED7BFCE-1E4C-4A7A-A92C-FD6370EC45B8@oracle.com> I added a CSR at https://bugs.openjdk.java.net/browse/JDK-8232994, please take a review. My point is that not only it's useless but it also be misleading, so better remove than ignore. Thanks, Max > On Oct 24, 2019, at 4:16 PM, Weijun Wang wrote: > > Please review the patch below: > > --- a/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KeyTab.java > +++ b/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KeyTab.java > @@ -303,13 +303,11 @@ > > /** > * Checks if the keytab file exists. Implementation of this method > * should make sure that the result matches the latest status of the > * keytab file. > - *

> - * The caller can use the result to determine if it should fallback to > - * another mechanism to read the keys. > + * > * @return true if the keytab file exists; false otherwise. > * @throws SecurityException if a security manager exists and the read > * access to the keytab file is not permitted > */ > public boolean exists() { > > The spec here is not clear and even our own JGSS SubjectComber looks into both KeyTab and KerberosKey and there is no fallback of any kind. > > Do you think this is worth a CSR? > > Thanks, > Max > From mbalao at redhat.com Fri Oct 25 04:33:39 2019 From: mbalao at redhat.com (Martin Balao) Date: Fri, 25 Oct 2019 01:33:39 -0300 Subject: RFR 8005819: Support cross-realm MSSFU In-Reply-To: References: Message-ID: <5e0bd0e2-79ac-84d3-b8ef-6bbf7b9c4266@redhat.com> Hi Sean, You are absolutely right. Thanks for the reminder. Update: https://bugs.openjdk.java.net/browse/JDK-8005819 Kind regards, Martin.- From sean.mullan at oracle.com Fri Oct 25 17:38:54 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 25 Oct 2019 13:38:54 -0400 Subject: RFR 8231365, 8231196: bugs on kerberos permissions In-Reply-To: <81501458-0BA8-40FD-95C5-DBE078D8C2C8@oracle.com> References: <8a5db15f-6fb8-167e-87f6-e4a66a8cef43@oracle.com> <81501458-0BA8-40FD-95C5-DBE078D8C2C8@oracle.com> Message-ID: <33edcc85-2c94-57c8-a316-e265e84a1693@oracle.com> Looks good, I added my name as Reviewer to the CSR. You should also add a release note for 8231196. --Sean On 10/10/19 11:30 PM, Weijun Wang wrote: > Webrev updated at https://cr.openjdk.java.net/~weijun/8231365/webrev.01. > > I've also created a CSR at https://bugs.openjdk.java.net/browse/JDK-8232155. Please take a review. > > Thanks > Max > >> On Oct 4, 2019, at 10:06 PM, Sean Mullan wrote: >> >> The changes for ServicePermission look fine. For DelegationPermission, I have a couple of comments: >> >> - The test has the wrong copyright (no need for the "Classpath" exception) >> - I think we should clarify the specification of DelegationPermission constructors for the @throws IllegalArgumentException. It currently says: >> >> * @throws IllegalArgumentException if {@code principals} is empty. >> >> But with your fix, it also throws IllegalArgumentExc if principals does not contain a pair. Also, the current code throws IAE if there is a syntax error. So I would propose: >> >> * @throws IllegalArgumentException if {@code principals} is empty, or does not contain a pair of principals, or is improperly quoted >> >> --Sean >> >> On 9/25/19 10:50 PM, Weijun Wang wrote: >>> Please take a review at >>> https://cr.openjdk.java.net/~weijun/8231365/webrev.00 >>> Thanks, >>> Max > From sean.mullan at oracle.com Fri Oct 25 18:49:14 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 25 Oct 2019 14:49:14 -0400 Subject: the GMT timestamp given in the trace is sometimes wrong In-Reply-To: References: Message-ID: On 10/14/19 4:13 PM, Eug?ne Adell wrote: > Hello, > > I've posted this issue below 2 months ago and still did not see any > reply. I also suggested how to correct. > > Can anyone please check ? It does seem like an issue, but what version of the JDK are you using? The RandomCookie code has changed in later versions of the JDK such that it may not be an issue anymore. I would recommend checking with JDK 11 or later. If it is still an issue, please file a bug at https://bugreport.java.com/bugreport/. Thanks, Sean > > Eugene > > > Le lun. 12 ao?t 2019 ? 01:26, Eug?ne Adell a ?crit : >> >> Hello, >> >> When using the well-known javax.net.debug=all property we get outputs >> similar to this : >> >> ... >> Ignoring unsupported cipher suite: >> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1 >> Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 >> for TLSv1.1 >> Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 >> for TLSv1.1 >> %% No cached client session >> update handshake state: client_hello[1] >> upcoming handshake states: server_hello[2] >> *** ClientHello, TLSv1.2 >> RandomCookie: GMT: 1565495356 bytes = { 119, 88, 206, 84, 104, 18, >> 56, 110, 157, 162, 50, 247, 142, 47, 46, 11, 133, 196, 21, 108, 17, >> 205, 121, 220, 52, 127, 169, 241 } >> Session ID: {} >> Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, >> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, >> TLS_RSA_WITH_AES_256_CBC_SHA256, >> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, >> ... >> Compression Methods: { 0 } >> Extension elliptic_curves, curve names: {secp256r1, secp384r1, >> secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, >> sect571r1, secp256k1} >> Extension ec_point_formats, formats: [uncompressed] >> Extension signature_algorithms, signature_algorithms: SHA512withECDSA, >> SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, >> SHA256withRSA, SHA256withDSA, SHA224withECDSA, SHA224withRSA, >> SHA224withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA >> Extension extended_master_secret >> Extension server_name, server_name: [type=host_name (0), >> value=bugs.openjdk.java.net] >> *** >> [write] MD5 and SHA1 hashes: len = 229 >> 0000: 01 00 00 E1 03 03 5D 50 90 3C 77 58 CE 54 68 12 ......]P.> 0010: 38 6E 9D A2 32 F7 8E 2F 2E 0B 85 C4 15 6C 11 CD 8n..2../.....l.. >> 0020: 79 DC 34 7F A9 F1 00 00 56 C0 24 C0 28 00 3D C0 y.4.....V.$.(.=. >> 0030: 26 C0 2A 00 6B 00 6A C0 0A C0 14 00 35 C0 05 C0 &.*.k.j.....5... >> ... >> >> However converting the timestamp found in the RandomCookie 1565495356 >> gives 5D4F903C and not 5D50903C, which is the value found in the debug >> trace (line starting by "0000:") >> This of course doesn't break anything but I guess this is not the >> expected behaviour. >> The problem is reproducible depending on the current time. From my >> tests, the GMT value is wrong, and the value sent in the handshake >> itself is right. Probably RandomCookie.print() is facing the >> endianness problem, and I suggest the following patch that I >> unit-tested but not in JSSE itself : >> >> --- a/RandomCookie.java 2019-08-12 00:43:56.458000000 +0200 >> +++ b/RandomCookie.java 2019-08-12 01:18:06.874000000 +0200 >> @@ -70,10 +70,10 @@ >> void print(PrintStream s) { >> int i, gmt_unix_time; >> >> - gmt_unix_time = random_bytes[0] << 24; >> - gmt_unix_time += random_bytes[1] << 16; >> - gmt_unix_time += random_bytes[2] << 8; >> - gmt_unix_time += random_bytes[3]; >> + gmt_unix_time = ((random_bytes[0] & 0xFF) << 24) | >> + ((random_bytes[1] & 0xFF) << 16) | >> + ((random_bytes[2] & 0xFF) << 8) | >> + ((random_bytes[3] & 0xFF) << 0); >> >> s.print("GMT: " + gmt_unix_time + " "); >> s.print("bytes = { "); >> >> >> best regards >> Eugene Adell From eugene.adell at gmail.com Sat Oct 26 09:21:35 2019 From: eugene.adell at gmail.com (=?UTF-8?Q?Eug=C3=A8ne_Adell?=) Date: Sat, 26 Oct 2019 11:21:35 +0200 Subject: the GMT timestamp given in the trace is sometimes wrong In-Reply-To: References: Message-ID: Hello, I was working with JDK 8 (jdk8u232-b03). I just downloaded JDK 11 and it has another behavior but still not respecting the 4 bytes related to gmt_unix_time (as mentioned in RFC 2246 - 5246). Opening a capture with Wireshark gives "Mar 7, 2069 08:42:00.000000000 Paris, Madrid" for the gmt_unix field. If confirmed, I will open a bug regards Eugene Le ven. 25 oct. 2019 ? 20:49, Sean Mullan a ?crit : > > On 10/14/19 4:13 PM, Eug?ne Adell wrote: > > Hello, > > > > I've posted this issue below 2 months ago and still did not see any > > reply. I also suggested how to correct. > > > > Can anyone please check ? > > It does seem like an issue, but what version of the JDK are you using? > The RandomCookie code has changed in later versions of the JDK such that > it may not be an issue anymore. I would recommend checking with JDK 11 > or later. If it is still an issue, please file a bug at > https://bugreport.java.com/bugreport/. > > Thanks, > Sean > > > > > Eugene > > > > > > Le lun. 12 ao?t 2019 ? 01:26, Eug?ne Adell a ?crit : > >> > >> Hello, > >> > >> When using the well-known javax.net.debug=all property we get outputs > >> similar to this : > >> > >> ... > >> Ignoring unsupported cipher suite: > >> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1 > >> Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 > >> for TLSv1.1 > >> Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 > >> for TLSv1.1 > >> %% No cached client session > >> update handshake state: client_hello[1] > >> upcoming handshake states: server_hello[2] > >> *** ClientHello, TLSv1.2 > >> RandomCookie: GMT: 1565495356 bytes = { 119, 88, 206, 84, 104, 18, > >> 56, 110, 157, 162, 50, 247, 142, 47, 46, 11, 133, 196, 21, 108, 17, > >> 205, 121, 220, 52, 127, 169, 241 } > >> Session ID: {} > >> Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, > >> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, > >> TLS_RSA_WITH_AES_256_CBC_SHA256, > >> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, > >> ... > >> Compression Methods: { 0 } > >> Extension elliptic_curves, curve names: {secp256r1, secp384r1, > >> secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, > >> sect571r1, secp256k1} > >> Extension ec_point_formats, formats: [uncompressed] > >> Extension signature_algorithms, signature_algorithms: SHA512withECDSA, > >> SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, > >> SHA256withRSA, SHA256withDSA, SHA224withECDSA, SHA224withRSA, > >> SHA224withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA > >> Extension extended_master_secret > >> Extension server_name, server_name: [type=host_name (0), > >> value=bugs.openjdk.java.net] > >> *** > >> [write] MD5 and SHA1 hashes: len = 229 > >> 0000: 01 00 00 E1 03 03 5D 50 90 3C 77 58 CE 54 68 12 ......]P. >> 0010: 38 6E 9D A2 32 F7 8E 2F 2E 0B 85 C4 15 6C 11 CD 8n..2../.....l.. > >> 0020: 79 DC 34 7F A9 F1 00 00 56 C0 24 C0 28 00 3D C0 y.4.....V.$.(.=. > >> 0030: 26 C0 2A 00 6B 00 6A C0 0A C0 14 00 35 C0 05 C0 &.*.k.j.....5... > >> ... > >> > >> However converting the timestamp found in the RandomCookie 1565495356 > >> gives 5D4F903C and not 5D50903C, which is the value found in the debug > >> trace (line starting by "0000:") > >> This of course doesn't break anything but I guess this is not the > >> expected behaviour. > >> The problem is reproducible depending on the current time. From my > >> tests, the GMT value is wrong, and the value sent in the handshake > >> itself is right. Probably RandomCookie.print() is facing the > >> endianness problem, and I suggest the following patch that I > >> unit-tested but not in JSSE itself : > >> > >> --- a/RandomCookie.java 2019-08-12 00:43:56.458000000 +0200 > >> +++ b/RandomCookie.java 2019-08-12 01:18:06.874000000 +0200 > >> @@ -70,10 +70,10 @@ > >> void print(PrintStream s) { > >> int i, gmt_unix_time; > >> > >> - gmt_unix_time = random_bytes[0] << 24; > >> - gmt_unix_time += random_bytes[1] << 16; > >> - gmt_unix_time += random_bytes[2] << 8; > >> - gmt_unix_time += random_bytes[3]; > >> + gmt_unix_time = ((random_bytes[0] & 0xFF) << 24) | > >> + ((random_bytes[1] & 0xFF) << 16) | > >> + ((random_bytes[2] & 0xFF) << 8) | > >> + ((random_bytes[3] & 0xFF) << 0); > >> > >> s.print("GMT: " + gmt_unix_time + " "); > >> s.print("bytes = { "); > >> > >> > >> best regards > >> Eugene Adell From weijun.wang at oracle.com Mon Oct 28 03:04:41 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 28 Oct 2019 11:04:41 +0800 Subject: RFR 8231365, 8231196: bugs on kerberos permissions In-Reply-To: <33edcc85-2c94-57c8-a316-e265e84a1693@oracle.com> References: <8a5db15f-6fb8-167e-87f6-e4a66a8cef43@oracle.com> <81501458-0BA8-40FD-95C5-DBE078D8C2C8@oracle.com> <33edcc85-2c94-57c8-a316-e265e84a1693@oracle.com> Message-ID: <8075522D-2341-42CD-8786-05A6F4344B84@oracle.com> Thanks and I've finalized the CSR. A release note is created at https://bugs.openjdk.java.net/browse/JDK-8233043. --Max > On Oct 26, 2019, at 1:38 AM, Sean Mullan wrote: > > Looks good, I added my name as Reviewer to the CSR. You should also add a release note for 8231196. > > --Sean > > On 10/10/19 11:30 PM, Weijun Wang wrote: >> Webrev updated at https://cr.openjdk.java.net/~weijun/8231365/webrev.01. >> I've also created a CSR at https://bugs.openjdk.java.net/browse/JDK-8232155. Please take a review. >> Thanks >> Max >>> On Oct 4, 2019, at 10:06 PM, Sean Mullan wrote: >>> >>> The changes for ServicePermission look fine. For DelegationPermission, I have a couple of comments: >>> >>> - The test has the wrong copyright (no need for the "Classpath" exception) >>> - I think we should clarify the specification of DelegationPermission constructors for the @throws IllegalArgumentException. It currently says: >>> >>> * @throws IllegalArgumentException if {@code principals} is empty. >>> >>> But with your fix, it also throws IllegalArgumentExc if principals does not contain a pair. Also, the current code throws IAE if there is a syntax error. So I would propose: >>> >>> * @throws IllegalArgumentException if {@code principals} is empty, or does not contain a pair of principals, or is improperly quoted >>> >>> --Sean >>> >>> On 9/25/19 10:50 PM, Weijun Wang wrote: >>>> Please take a review at >>>> https://cr.openjdk.java.net/~weijun/8231365/webrev.00 >>>> Thanks, >>>> Max From tobias.wagner at n-design.de Mon Oct 28 11:09:21 2019 From: tobias.wagner at n-design.de (Tobias Wagner) Date: Mon, 28 Oct 2019 11:09:21 +0000 Subject: RFR [11] CSR for "Add Brainpool ECC support (RFC 5639)" In-Reply-To: References: <5b28158a.1c69fb81.da9dc.2500@mx.google.com> <46ebf4bd-ba09-657b-3c88-c884400edc36@oracle.com> Message-ID: <0e86689a-567a-0d48-c86b-f376e705d8fc@n-design.de> Hi Bernd and all, the mentioned patch was for jdk8, I think. I attached a new one. It simply adds the brainpool curves to NamedGroup - twice. 1. According to RFC 7027 for TLS <= 1.2 2. According to * https://datatracker.ietf.org/doc/draft-bruckert-brainpool-for-tls13/ and * https://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-8 This works for TLSv1.2 using https://testssl.sh - but I had no opportunity to test this for TLSv1.3 and unfortunately little time to look in to it now. Cheers, Tobias Am 24.10.19 um 12:52 schrieb Bernd Eckenfels: > Hello, > > Coming back to the message of Tobias, it looks* like even in 14 the > Brainpool curves have not landed for JSSE, are there any plans for > adding this? can you maybe share your incomplete patch, Tobias? > > * i don?t see them in ssl/NamesGroups: > http://hg.openjdk.java.net/jdk/jdk/file/tip/src/java.base/share/classes/sun/security/ssl/NamedGroup.java > Gruss > Bernd > > > -- > http://bernd.eckenfels.net > ? > ------------------------------------------------------------------------ > *Von:* security-dev im Auftrag > von Tobias Wagner > *Gesendet:* Mittwoch, Juni 27, 2018 7:49 PM > *An:* security-dev at openjdk.java.net > *Betreff:* AW: RFR [11] CSR for "Add Brainpool ECC support (RFC 5639)" > ? > Hi Valerie and Bernd, > Valerie is right, I tested my JTREG Tests against SoftHSM2 in March: > http://mail.openjdk.java.net/pipermail/security-dev/2018-March/016863.html > I don't think there are more PKCS#11 related issues, as SunEC is not a > PKCS#11 implementation. There are only shared tests. > > The JTREG known answer tests use the X9.62 key format as they are used > in certificates as well. I assume, brainpool public keys would work in > certificates as well. > > I actually implemented the support for brainpool curves in TLS as well, > but I had no time to provide proper JTREG tests for that, and therefore > no patch yet. > > Regards, Tobias > > -- > phone: +49 221 222896 17 > fax: +49 221 222896 11 > keybase: https://keybase.io/toebix > > n - d e s i g n G m b H > https://n-design.de > Alpenerstr. 16 > 50825 K?ln > Deutschland / Germany > > Amtsgericht K?ln HRB 33766 B > Gesch?ftsf?hrer Andy Kohl > >> -----Urspr?ngliche Nachricht----- >> Von: security-dev Im Auftrag von >> Valerie Peng >> Gesendet: Donnerstag, 21. Juni 2018 01:07 >> An: security-dev at openjdk.java.net >> Betreff: Re: RFR [11] CSR for "Add Brainpool ECC support (RFC 5639)" >> >> Are you asking about CSR or existing bug for including Brainpool support >> in TLS? >> >> I saw some bugs which mentions errors/exceptions which brainpool is >> used, e.g. JSSE has https://bugs.openjdk.java.net/browse/JDK-7189107, >> key tool has https://bugs.openjdk.java.net/browse/JDK-8201290. After >> this brainpool support is integrated, it'll be easier to re-evaluate >> these. >> >> >> As for PKCS11, Tobias tested this against a 3rd party PKCS11 library and >> the result is positive if I recall correctly. >> >> >> Thanks, >> Valerie >> >> >> On 6/18/2018 1:26 PM, Bernd Eckenfels wrote: >> >> >> Hello, >> >> >> >> not a Reviewer, but some Questions on the CSR: >> >> >> >> * Are there other CSRs for including in TLS? >> * I also wonder if PKI (CA Signatures) will work out of the box >> then (OID aliases?) >> * Does PKCS11 require additional changes? (especially for the >> Government use mentioned in the justification HSMs are often mandatory) >> >> >> >> Gruss >> >> Bernd >> >> -- >> http://bernd.eckenfels.net >> >> >> > > -- phone: +49 221 222896 17 fax: +49 221 222896 11 keybase: https://keybase.io/toebix n - d e s i g n G m b H https://n-design.de Alpenerstr. 16 50825 K?ln Deutschland / Germany Amtsgericht K?ln HRB 33766 B Gesch?ftsf?hrer: Andy Kohl, Dr. Tino Gro?mann -------------- next part -------------- A non-text attachment was scrubbed... Name: patch_56744.diff Type: text/x-patch Size: 2374 bytes Desc: patch_56744.diff URL: From sean.mullan at oracle.com Mon Oct 28 12:08:31 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 28 Oct 2019 08:08:31 -0400 Subject: RFR 8231365, 8231196: bugs on kerberos permissions In-Reply-To: <8075522D-2341-42CD-8786-05A6F4344B84@oracle.com> References: <8a5db15f-6fb8-167e-87f6-e4a66a8cef43@oracle.com> <81501458-0BA8-40FD-95C5-DBE078D8C2C8@oracle.com> <33edcc85-2c94-57c8-a316-e265e84a1693@oracle.com> <8075522D-2341-42CD-8786-05A6F4344B84@oracle.com> Message-ID: <6550b98b-cdd7-d8ac-03c8-77bd183b7ebf@oracle.com> On 10/27/19 11:04 PM, Weijun Wang wrote: > Thanks and I've finalized the CSR. A release note is created at https://bugs.openjdk.java.net/browse/JDK-8233043. I tweaked the Description a little - if you are ok with it, you can mark it Resolved. --Sean > > --Max > >> On Oct 26, 2019, at 1:38 AM, Sean Mullan wrote: >> >> Looks good, I added my name as Reviewer to the CSR. You should also add a release note for 8231196. >> >> --Sean >> >> On 10/10/19 11:30 PM, Weijun Wang wrote: >>> Webrev updated at https://cr.openjdk.java.net/~weijun/8231365/webrev.01. >>> I've also created a CSR at https://bugs.openjdk.java.net/browse/JDK-8232155. Please take a review. >>> Thanks >>> Max >>>> On Oct 4, 2019, at 10:06 PM, Sean Mullan wrote: >>>> >>>> The changes for ServicePermission look fine. For DelegationPermission, I have a couple of comments: >>>> >>>> - The test has the wrong copyright (no need for the "Classpath" exception) >>>> - I think we should clarify the specification of DelegationPermission constructors for the @throws IllegalArgumentException. It currently says: >>>> >>>> * @throws IllegalArgumentException if {@code principals} is empty. >>>> >>>> But with your fix, it also throws IllegalArgumentExc if principals does not contain a pair. Also, the current code throws IAE if there is a syntax error. So I would propose: >>>> >>>> * @throws IllegalArgumentException if {@code principals} is empty, or does not contain a pair of principals, or is improperly quoted >>>> >>>> --Sean >>>> >>>> On 9/25/19 10:50 PM, Weijun Wang wrote: >>>>> Please take a review at >>>>> https://cr.openjdk.java.net/~weijun/8231365/webrev.00 >>>>> Thanks, >>>>> Max > From sean.mullan at oracle.com Mon Oct 28 13:07:23 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 28 Oct 2019 09:07:23 -0400 Subject: RFR 8231508: Spec Clarification : KeyTab:exist() method does not specify about the fallback details In-Reply-To: <5ED7BFCE-1E4C-4A7A-A92C-FD6370EC45B8@oracle.com> References: <85631C41-788D-4F94-AA01-5486271DF655@oracle.com> <5ED7BFCE-1E4C-4A7A-A92C-FD6370EC45B8@oracle.com> Message-ID: On 10/24/19 10:15 PM, Weijun Wang wrote: > I added a CSR at https://bugs.openjdk.java.net/browse/JDK-8232994, please take a review. > > My point is that not only it's useless but it also be misleading, so better remove than ignore. It's fine with me to remove this, but from my reading of the bug report, the submitter was more concerned that it is underspecified as to whether exist() will return true or false if it is not created with a keytab file. Maybe what is also needed is a better description of how a keytab file is found. I think that would better address the issue. In your comment in the bug report, you actually described how that works, so I think it would might be a good idea to add that to the KeyTab.exist() specification. --Sean > > Thanks, > Max > > >> On Oct 24, 2019, at 4:16 PM, Weijun Wang wrote: >> >> Please review the patch below: >> >> --- a/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KeyTab.java >> +++ b/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KeyTab.java >> @@ -303,13 +303,11 @@ >> >> /** >> * Checks if the keytab file exists. Implementation of this method >> * should make sure that the result matches the latest status of the >> * keytab file. >> - *

>> - * The caller can use the result to determine if it should fallback to >> - * another mechanism to read the keys. >> + * >> * @return true if the keytab file exists; false otherwise. >> * @throws SecurityException if a security manager exists and the read >> * access to the keytab file is not permitted >> */ >> public boolean exists() { >> >> The spec here is not clear and even our own JGSS SubjectComber looks into both KeyTab and KerberosKey and there is no fallback of any kind. >> >> Do you think this is worth a CSR? >> >> Thanks, >> Max >> > From michael.osipov at siemens.com Tue Oct 29 15:40:44 2019 From: michael.osipov at siemens.com (Osipov, Michael) Date: Tue, 29 Oct 2019 16:40:44 +0100 Subject: CR request for JGSS improvements In-Reply-To: <20191023020753.GL240820@twosigma.com> References: <20191023020753.GL240820@twosigma.com> Message-ID: <7bb24dc9-997c-4984-96fb-4601459aa897@siemens.com> Am 2019-10-23 um 04:07 schrieb Nico Williams: > Webrevs are at https://cr.openjdk.java.net/~weijun/twosigma-gss-2019/. I used > Dave Pacheco's webrev fork to generate these from my git clone of AdoptOpenJDK. > > The bugs/enhancements are at: > > https://bugs.openjdk.java.net/issues/?jql=assignee%20%3D%20nwilliams%20ORDER%20BY%20key%20ASC. I am highly in favor of Nico's and Two Sigma's work on MIT Kerberos/JGSS alignment as well as getting rid of JAAS in the future. Michael From michael.osipov at siemens.com Tue Oct 29 15:18:57 2019 From: michael.osipov at siemens.com (Osipov, Michael) Date: Tue, 29 Oct 2019 16:18:57 +0100 Subject: [JDK-8223172] Incomplete/Unusable Kerberos Cross-Realm Referrals Support In-Reply-To: References: Message-ID: Am 2019-10-21 um 22:07 schrieb Martin Balao: > Hi Michael, > > Thanks for providing your feedback and apologies for the delay to answer. > > As you well noticed (and @Max already said), the kinit/login/jgss parts > of NT-ENTERPRISE were not implemented in the first stage; only the > internal machinery. It should be pretty straight forward to implement > the missing bits now that we have the basis. > > My plan is the following: > > 1) Have S4U2Self and S4U2Proxy referrals approved (webrev already > proposed, under review) > > 2) Backport all the referrals-related work so far to 11u and 8u > * 11u is almost done That looks very very promising for 8u. > Only after that I can try to make time for your request. However, feel > free to propose a patch before and I'll certainly have a look :-) Thank you, I will keep an eye open and read your current open webrevs. Michael From michael.osipov at siemens.com Tue Oct 29 15:35:30 2019 From: michael.osipov at siemens.com (Osipov, Michael) Date: Tue, 29 Oct 2019 16:35:30 +0100 Subject: RFR 8005819: Support cross-realm MSSFU In-Reply-To: References: Message-ID: A few questions: * In handleS4U2ProxyReferral(): > + sname = new PrincipalName(PrincipalName.KRB_NT_PRINCIPAL, > + sname.getNameStrings(), sname.getRealm()); Why do you use here KRB_NT_PRINCIPAL? Is that the assumption that in AD all services are bound to regular accounts compared to MIT Kerberos? client1 at REALM => HTTP/host at REALM where HTTP/host at REALM is bound to srv$@REALM => postgres/host2 at REALM and the transition is done with srv$@REALM? Michael From christoph.langer at sap.com Wed Oct 30 15:28:44 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 30 Oct 2019 15:28:44 +0000 Subject: [11u] RFR 8215032: Support Kerberos cross-realm referrals (RFC 6806) In-Reply-To: <8285a00c-9e6e-6b63-eb9d-660dd09d9266@redhat.com> References: <57d1dd6b-3395-cb87-de91-690893332468@redhat.com> <8285a00c-9e6e-6b63-eb9d-660dd09d9266@redhat.com> Message-ID: Hi Martin, Sorry for the late reply... been rather busy the last days. You're asking me to review the CSR for backporting JDK8215032. I, however, am not an expert in that area and could probably only check whether you copied the content correctly from the original CSR. So, I'd like to refer this to the original CSR reviewer. @Weijun Wang, can you please have a look at CSR https://bugs.openjdk.java.net/browse/JDK-8230496 and add yourself as reviewer once you find everything is ok and it's a thing feasible to backport to JDK11? Thanks Christoph > -----Original Message----- > From: Martin Balao > Sent: Montag, 21. Oktober 2019 22:56 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR 8215032: Support Kerberos cross-realm referrals (RFC > 6806) > > Hi Christoph, > > Can you please have a look at the CSR [1] so we move it from Provisional > to Finalized? > > Now that 8224589 is in 11u, patch applies cleanly net copyright. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8230496 From xuelei.fan at oracle.com Wed Oct 30 17:48:08 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 30 Oct 2019 10:48:08 -0700 Subject: RFR [14] 8223940: Private key not supported by chosen signature algorithm In-Reply-To: <427ac332-3add-c426-ea9f-4b7ed047519f@oracle.com> References: <427ac332-3add-c426-ea9f-4b7ed047519f@oracle.com> Message-ID: <058480d2-45bb-966c-51e4-e14dde7730a1@oracle.com> ping ... On 10/24/2019 1:56 PM, Xuelei Fan wrote: > Hi, > > Could I get the following update reviewed? > ??? http://cr.openjdk.java.net/~xuelei/8223940/webrev.00/ > > For signature algorithms, the update will fail back to use the supported > signature algorithm for the specific private key.? Previously, the first > preferred signature algorithm get used ad the private key may not be > able to work with the signature algorithm however. > > No new regression test as RSASSA-PSS has been supported in the SunPKCS11 > provider currently.? Can I get a help for the test if you are running a > provider that does not support RSASSA-PSS yet? > > Thanks & Regards, > Xuelei From mbalao at redhat.com Wed Oct 30 18:21:00 2019 From: mbalao at redhat.com (Martin Balao) Date: Wed, 30 Oct 2019 15:21:00 -0300 Subject: Is there any reason not to have 8223269 in JDK baseline? Message-ID: Hi, I've noticed that 8223269 [1] (not public) has been included in Oracle's 8u231 JDK [2]. Is there a reason not to have this in JDK baseline? (and, thus, create a backport for the open JDKs) In case there is not, I'll proceed with a new ticket (unless you want to make [1] public), a CSR and a patch. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8223269 [2] - https://www.oracle.com/technetwork/java/javase/8u231-relnotes-5592812.html#JDK-8223269 From valerie.peng at oracle.com Wed Oct 30 20:14:26 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 30 Oct 2019 13:14:26 -0700 Subject: RFR [14] 8223940: Private key not supported by chosen signature algorithm In-Reply-To: <058480d2-45bb-966c-51e4-e14dde7730a1@oracle.com> References: <427ac332-3add-c426-ea9f-4b7ed047519f@oracle.com> <058480d2-45bb-966c-51e4-e14dde7730a1@oracle.com> Message-ID: Ok, I will take a look~ Valerie On 10/30/2019 10:48 AM, Xuelei Fan wrote: > ping ... > > On 10/24/2019 1:56 PM, Xuelei Fan wrote: >> Hi, >> >> Could I get the following update reviewed? >> ???? http://cr.openjdk.java.net/~xuelei/8223940/webrev.00/ >> >> For signature algorithms, the update will fail back to use the >> supported signature algorithm for the specific private key. >> Previously, the first preferred signature algorithm get used ad the >> private key may not be able to work with the signature algorithm >> however. >> >> No new regression test as RSASSA-PSS has been supported in the >> SunPKCS11 provider currently.? Can I get a help for the test if you >> are running a provider that does not support RSASSA-PSS yet? >> >> Thanks & Regards, >> Xuelei From valerie.peng at oracle.com Wed Oct 30 20:13:25 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 30 Oct 2019 13:13:25 -0700 Subject: RFR[14] 8232950: SUNPKCS11 Provider incorrectly check key length for PSS Signatures. Message-ID: Anyone has a minute to review this trivial fix? The supported key size info for the PKCS#11 PSS mechanism should be in bits. The current code treat them as in bytes. This does not cause any existing regression test failure because NSS has a very low value, i.e. 128, as the minimum key size. Bug: https://bugs.openjdk.java.net/browse/JDK-8232950 Webrev: http://cr.openjdk.java.net/~valeriep/8232950/webrev.00/ Mach5 run passed. Thanks, Valerie From anthony.scarpino at oracle.com Wed Oct 30 21:00:32 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 30 Oct 2019 14:00:32 -0700 Subject: RFR[14] 8232950: SUNPKCS11 Provider incorrectly check key length for PSS Signatures. In-Reply-To: References: Message-ID: <17b2e69d-7ef3-6312-10f8-df6cd74369ef@oracle.com> On 10/30/19 1:13 PM, Valerie Peng wrote: > Anyone has a minute to review this trivial fix? The supported key size > info for the PKCS#11 PSS mechanism should be in bits. The current code > treat them as in bytes. This does not cause any existing regression test > failure because NSS has a very low value, i.e. 128, as the minimum key > size. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232950 > > Webrev: http://cr.openjdk.java.net/~valeriep/8232950/webrev.00/ > > Mach5 run passed. > > Thanks, > Valerie It looks good to me. Tony From sean.coffey at oracle.com Wed Oct 30 23:14:35 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 30 Oct 2019 23:14:35 +0000 Subject: Is there any reason not to have 8223269 in JDK baseline? In-Reply-To: References: Message-ID: <0a0847c6-a3f3-9bc0-8894-a510bd1dc775@oracle.com> Martin, Newer JDK families should be using the PKCS12 keystore format. For that reason, I kept it 8u only. It was a solution to address a particular use case reported by an Oracle JDK user. regards, Sean. On 30/10/2019 18:21, Martin Balao wrote: > Hi, > > I've noticed that 8223269 [1] (not public) has been included in Oracle's > 8u231 JDK [2]. > > Is there a reason not to have this in JDK baseline? (and, thus, create a > backport for the open JDKs) > > In case there is not, I'll proceed with a new ticket (unless you want to > make [1] public), a CSR and a patch. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8223269 > [2] - > https://www.oracle.com/technetwork/java/javase/8u231-relnotes-5592812.html#JDK-8223269 > From Xuelei.Fan at Oracle.Com Thu Oct 31 01:28:15 2019 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Wed, 30 Oct 2019 18:28:15 -0700 Subject: RFR[14] 8232950: SUNPKCS11 Provider incorrectly check key length for PSS Signatures. In-Reply-To: <17b2e69d-7ef3-6312-10f8-df6cd74369ef@oracle.com> References: <17b2e69d-7ef3-6312-10f8-df6cd74369ef@oracle.com> Message-ID: <6F1A3F12-9D83-46E7-979D-5B5F39F40CE3@Oracle.Com> +1 > On Oct 30, 2019, at 2:00 PM, Anthony Scarpino wrote: > >> On 10/30/19 1:13 PM, Valerie Peng wrote: >> Anyone has a minute to review this trivial fix? The supported key size info for the PKCS#11 PSS mechanism should be in bits. The current code treat them as in bytes. This does not cause any existing regression test failure because NSS has a very low value, i.e. 128, as the minimum key size. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8232950 >> Webrev: http://cr.openjdk.java.net/~valeriep/8232950/webrev.00/ >> Mach5 run passed. >> Thanks, >> Valerie > > It looks good to me. > > Tony From mbalao at redhat.com Thu Oct 31 15:01:59 2019 From: mbalao at redhat.com (Martin Balao) Date: Thu, 31 Oct 2019 12:01:59 -0300 Subject: Is there any reason not to have 8223269 in JDK baseline? In-Reply-To: <0a0847c6-a3f3-9bc0-8894-a510bd1dc775@oracle.com> References: <0a0847c6-a3f3-9bc0-8894-a510bd1dc775@oracle.com> Message-ID: <1f1fad9c-06d5-ec3a-cb12-e5d480fe12bc@redhat.com> Hi Sean, Thanks for your answer. Even though newer JDKs should be using the PKCS12 keystore format, there are still customers using the old JKS format and they would benefit from this feature. Is there any objection if I propose this for JDK base line? Thanks, Martin.- On 10/30/19 8:14 PM, Se?n Coffey wrote: > Martin, > > Newer JDK families should be using the PKCS12 keystore format. For that > reason, I kept it 8u only. It was a solution to address a particular use > case reported by an Oracle JDK user. > > regards, > Sean. > > On 30/10/2019 18:21, Martin Balao wrote: >> Hi, >> >> I've noticed that 8223269 [1] (not public) has been included in Oracle's >> 8u231 JDK [2]. >> >> Is there a reason not to have this in JDK baseline? (and, thus, create a >> backport for the open JDKs) >> >> In case there is not, I'll proceed with a new ticket (unless you want to >> make [1] public), a CSR and a patch. >> >> Thanks, >> Martin.- >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8223269 >> [2] - >> https://www.oracle.com/technetwork/java/javase/8u231-relnotes-5592812.html#JDK-8223269 >> >> From sean.mullan at oracle.com Thu Oct 31 17:06:37 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 31 Oct 2019 13:06:37 -0400 Subject: RFR 8231950: keytool -ext camel-case shorthand not working In-Reply-To: <13076EAA-2BEC-442E-ABC0-100E08EE39C0@oracle.com> References: <13076EAA-2BEC-442E-ABC0-100E08EE39C0@oracle.com> Message-ID: Looks good to me. --Sean On 10/13/19 4:27 AM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8231950/webrev.00/ > > Before this fix, the oneOf(s,list) method compares s to each item of the list in a case-insensitive way, and if there are multiple matches, it errors out saying input is ambiguous. The comparison looks like > > item.toLowerCase().startsWith(s.toLowerCase()) || item.toCamelCase().equalsIgnoreCase(s) > > Here, "howAreYou".toCamelCase() == "hAY". > > This means "de" or "dE" would match both "decipherOnly" and "dataEncipherment", and thus treated ambiguous. > > After this fix, the comparison is broken into 2 steps. If there is a single case-sensitive match, it's returned. Otherwise, fallback to case-insensitive. This means "de" would match "decipherOnly" and "dE" would match "dataEncipherment". This is a behavior change but all working cases still work, it's only those ambiguous cases are clean now. > > Also, in order to deal with the case that one option starts with another option, I've added an exact match at the beginning. > > Precisely, the steps are now > > item.equals(s) > item.startsWith(s) || item.toCamelCase().equals(s) > item.toLowerCase().startsWith(s.toLowerCase()) || item.toCamelCase().equalsIgnoreCase(s) > > A new test is added. An existing test is modified, where ambiguous case becomes not now. > > Thanks, > Max > From mbalao at redhat.com Thu Oct 31 20:40:32 2019 From: mbalao at redhat.com (Martin Balao) Date: Thu, 31 Oct 2019 17:40:32 -0300 Subject: RFR 8005819: Support cross-realm MSSFU In-Reply-To: References: Message-ID: <947d3ef0-2246-56fc-5474-2904bca8a4c1@redhat.com> Hi Michael, Thanks for having a look at this proposal. On 10/29/19 12:35 PM, Osipov, Michael wrote: > * In handleS4U2ProxyReferral(): >> +??????? sname = new PrincipalName(PrincipalName.KRB_NT_PRINCIPAL, >> +??????????????? sname.getNameStrings(), sname.getRealm()); > > Why do you use here KRB_NT_PRINCIPAL? Is that the assumption that in AD > all services are bound to regular accounts compared to MIT Kerberos? > The backend PrincipalName is constructed from a string, so we really don't know the type and KRB_NT_UNKNOWN is used. I've not found any issue in my tests with KRB_NT_PRINCIPAL but it should look less arbitrary to keep KRB_NT_UNKNOWN. I'll do some more testing and change it if there are no issues. > client1 at REALM => HTTP/host at REALM where HTTP/host at REALM is bound to > srv$@REALM => postgres/host2 at REALM and the transition is done with > srv$@REALM? > I'm not sure of what you mean here. Can you please elaborate a bit more? Kind regards, Martin.- From mbalao at redhat.com Thu Oct 31 20:43:12 2019 From: mbalao at redhat.com (Martin Balao) Date: Thu, 31 Oct 2019 17:43:12 -0300 Subject: RFR 8005819: Support cross-realm MSSFU In-Reply-To: <947d3ef0-2246-56fc-5474-2904bca8a4c1@redhat.com> References: <947d3ef0-2246-56fc-5474-2904bca8a4c1@redhat.com> Message-ID: On 10/31/19 5:40 PM, Martin Balao wrote: > > On 10/29/19 12:35 PM, Osipov, Michael wrote: >> * In handleS4U2ProxyReferral(): >>> +??????? sname = new PrincipalName(PrincipalName.KRB_NT_PRINCIPAL, >>> +??????????????? sname.getNameStrings(), sname.getRealm()); >> >> Why do you use here KRB_NT_PRINCIPAL? Is that the assumption that in AD >> all services are bound to regular accounts compared to MIT Kerberos? >> > > The backend PrincipalName is constructed from a string, so we really > don't know the type and KRB_NT_UNKNOWN is used. I've not found any issue > in my tests with KRB_NT_PRINCIPAL but it should look less arbitrary to > keep KRB_NT_UNKNOWN. I'll do some more testing and change it if there > are no issues. > Hmm.. perhaps we can assume SRV. Let me think about that. From xuelei.fan at oracle.com Thu Oct 31 20:50:50 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 31 Oct 2019 13:50:50 -0700 Subject: the GMT timestamp given in the trace is sometimes wrong In-Reply-To: References: Message-ID: <24533013-df83-9b7e-63af-65b609462562@oracle.com> Hi, The TLS spec does not require a correct gmt_unix_time: [RFC 5246] "Clocks are not required to be set correctly by the basic TLS protocol; higher-level or application protocols may define additional requirements." Please don't have the application rely on the gmt_unix_time value. Xuelei On 8/11/2019 4:26 PM, Eug?ne Adell wrote: > Hello, > > When using the well-known javax.net.debug=all property we get outputs > similar to this : > > ... > Ignoring unsupported cipher suite: > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1 > Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 > for TLSv1.1 > Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 > for TLSv1.1 > %% No cached client session > update handshake state: client_hello[1] > upcoming handshake states: server_hello[2] > *** ClientHello, TLSv1.2 > RandomCookie: GMT: 1565495356 bytes = { 119, 88, 206, 84, 104, 18, > 56, 110, 157, 162, 50, 247, 142, 47, 46, 11, 133, 196, 21, 108, 17, > 205, 121, 220, 52, 127, 169, 241 } > Session ID: {} > Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, > TLS_RSA_WITH_AES_256_CBC_SHA256, > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, > ... > Compression Methods: { 0 } > Extension elliptic_curves, curve names: {secp256r1, secp384r1, > secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, > sect571r1, secp256k1} > Extension ec_point_formats, formats: [uncompressed] > Extension signature_algorithms, signature_algorithms: SHA512withECDSA, > SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, > SHA256withRSA, SHA256withDSA, SHA224withECDSA, SHA224withRSA, > SHA224withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA > Extension extended_master_secret > Extension server_name, server_name: [type=host_name (0), > value=bugs.openjdk.java.net] > *** > [write] MD5 and SHA1 hashes: len = 229 > 0000: 01 00 00 E1 03 03 5D 50 90 3C 77 58 CE 54 68 12 ......]P. 0010: 38 6E 9D A2 32 F7 8E 2F 2E 0B 85 C4 15 6C 11 CD 8n..2../.....l.. > 0020: 79 DC 34 7F A9 F1 00 00 56 C0 24 C0 28 00 3D C0 y.4.....V.$.(.=. > 0030: 26 C0 2A 00 6B 00 6A C0 0A C0 14 00 35 C0 05 C0 &.*.k.j.....5... > ... > > However converting the timestamp found in the RandomCookie 1565495356 > gives 5D4F903C and not 5D50903C, which is the value found in the debug > trace (line starting by "0000:") > This of course doesn't break anything but I guess this is not the > expected behaviour. > The problem is reproducible depending on the current time. From my > tests, the GMT value is wrong, and the value sent in the handshake > itself is right. Probably RandomCookie.print() is facing the > endianness problem, and I suggest the following patch that I > unit-tested but not in JSSE itself : > > --- a/RandomCookie.java 2019-08-12 00:43:56.458000000 +0200 > +++ b/RandomCookie.java 2019-08-12 01:18:06.874000000 +0200 > @@ -70,10 +70,10 @@ > void print(PrintStream s) { > int i, gmt_unix_time; > > - gmt_unix_time = random_bytes[0] << 24; > - gmt_unix_time += random_bytes[1] << 16; > - gmt_unix_time += random_bytes[2] << 8; > - gmt_unix_time += random_bytes[3]; > + gmt_unix_time = ((random_bytes[0] & 0xFF) << 24) | > + ((random_bytes[1] & 0xFF) << 16) | > + ((random_bytes[2] & 0xFF) << 8) | > + ((random_bytes[3] & 0xFF) << 0); > > s.print("GMT: " + gmt_unix_time + " "); > s.print("bytes = { "); > > > best regards > Eugene Adell > From mbalao at redhat.com Thu Oct 31 21:37:05 2019 From: mbalao at redhat.com (Martin Balao) Date: Thu, 31 Oct 2019 18:37:05 -0300 Subject: RFR 8005819: Support cross-realm MSSFU In-Reply-To: References: Message-ID: <12d309a6-bf97-cbc7-4f86-46c16f554583@redhat.com> Hi, Webrev.02: * http://cr.openjdk.java.net/~mbalao/webrevs/8005819/8005819.webrev.02/ Changes: * No need to create a new sname PrincipalName in CredentialsUtil::handleS4U2ProxyReferral as it's not mutable. Regards, Martin.- From eugene.adell at gmail.com Thu Oct 31 21:36:23 2019 From: eugene.adell at gmail.com (=?UTF-8?Q?Eug=C3=A8ne_Adell?=) Date: Thu, 31 Oct 2019 22:36:23 +0100 Subject: the GMT timestamp given in the trace is sometimes wrong In-Reply-To: <24533013-df83-9b7e-63af-65b609462562@oracle.com> References: <24533013-df83-9b7e-63af-65b609462562@oracle.com> Message-ID: Hello, with Java 8 and earlier (and probably some later that I didn't check), the timestamp is correct half of the time, incorrect the other half, because of the bad shifting that I pointed in my first post. One incorrect clock is not supposed to be correct 50% of the time, for example it would be 1 minute late all the time. With Java 11 the clock is always incorrect, and even it can't be considered a clock anymore when your clock is years late, it's still more consistent than the previous behaviour. "Please don't have the application rely on the gmt_unix_time value." Sure, and anyway a Java application cannot access to this value from what I know. Having a correct time is however useful when analyzing logs produced with javax.net.debug property, or correlating with a network capture. This is how I went to see that problem, by investigating an issue, and we shouldn't underestimate the very few tools that allow troubleshooting. best regards E.A. Le jeu. 31 oct. 2019 ? 21:50, Xuelei Fan a ?crit : > > Hi, > > The TLS spec does not require a correct gmt_unix_time: > [RFC 5246] "Clocks are not required to be set correctly by the > basic TLS protocol; higher-level or application protocols may > define additional requirements." > > Please don't have the application rely on the gmt_unix_time value. > > Xuelei > > On 8/11/2019 4:26 PM, Eug?ne Adell wrote: > > Hello, > > > > When using the well-known javax.net.debug=all property we get outputs > > similar to this : > > > > ... > > Ignoring unsupported cipher suite: > > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1 > > Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 > > for TLSv1.1 > > Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 > > for TLSv1.1 > > %% No cached client session > > update handshake state: client_hello[1] > > upcoming handshake states: server_hello[2] > > *** ClientHello, TLSv1.2 > > RandomCookie: GMT: 1565495356 bytes = { 119, 88, 206, 84, 104, 18, > > 56, 110, 157, 162, 50, 247, 142, 47, 46, 11, 133, 196, 21, 108, 17, > > 205, 121, 220, 52, 127, 169, 241 } > > Session ID: {} > > Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, > > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, > > TLS_RSA_WITH_AES_256_CBC_SHA256, > > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, > > ... > > Compression Methods: { 0 } > > Extension elliptic_curves, curve names: {secp256r1, secp384r1, > > secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, > > sect571r1, secp256k1} > > Extension ec_point_formats, formats: [uncompressed] > > Extension signature_algorithms, signature_algorithms: SHA512withECDSA, > > SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, > > SHA256withRSA, SHA256withDSA, SHA224withECDSA, SHA224withRSA, > > SHA224withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA > > Extension extended_master_secret > > Extension server_name, server_name: [type=host_name (0), > > value=bugs.openjdk.java.net] > > *** > > [write] MD5 and SHA1 hashes: len = 229 > > 0000: 01 00 00 E1 03 03 5D 50 90 3C 77 58 CE 54 68 12 ......]P. > 0010: 38 6E 9D A2 32 F7 8E 2F 2E 0B 85 C4 15 6C 11 CD 8n..2../.....l.. > > 0020: 79 DC 34 7F A9 F1 00 00 56 C0 24 C0 28 00 3D C0 y.4.....V.$.(.=. > > 0030: 26 C0 2A 00 6B 00 6A C0 0A C0 14 00 35 C0 05 C0 &.*.k.j.....5... > > ... > > > > However converting the timestamp found in the RandomCookie 1565495356 > > gives 5D4F903C and not 5D50903C, which is the value found in the debug > > trace (line starting by "0000:") > > This of course doesn't break anything but I guess this is not the > > expected behaviour. > > The problem is reproducible depending on the current time. From my > > tests, the GMT value is wrong, and the value sent in the handshake > > itself is right. Probably RandomCookie.print() is facing the > > endianness problem, and I suggest the following patch that I > > unit-tested but not in JSSE itself : > > > > --- a/RandomCookie.java 2019-08-12 00:43:56.458000000 +0200 > > +++ b/RandomCookie.java 2019-08-12 01:18:06.874000000 +0200 > > @@ -70,10 +70,10 @@ > > void print(PrintStream s) { > > int i, gmt_unix_time; > > > > - gmt_unix_time = random_bytes[0] << 24; > > - gmt_unix_time += random_bytes[1] << 16; > > - gmt_unix_time += random_bytes[2] << 8; > > - gmt_unix_time += random_bytes[3]; > > + gmt_unix_time = ((random_bytes[0] & 0xFF) << 24) | > > + ((random_bytes[1] & 0xFF) << 16) | > > + ((random_bytes[2] & 0xFF) << 8) | > > + ((random_bytes[3] & 0xFF) << 0); > > > > s.print("GMT: " + gmt_unix_time + " "); > > s.print("bytes = { "); > > > > > > best regards > > Eugene Adell > > From xuelei.fan at oracle.com Thu Oct 31 22:09:24 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 31 Oct 2019 15:09:24 -0700 Subject: the GMT timestamp given in the trace is sometimes wrong In-Reply-To: References: <24533013-df83-9b7e-63af-65b609462562@oracle.com> Message-ID: The ClientHello.random has been changed to use "random number" since TLS 1.3 (See RFC 8446). The 4 leading bytes are not more used to indicate clock in the current implementation. For more details, please consider this doc (https://tools.ietf.org/id/draft-mathewson-no-gmtunixtime-00.txt). Xuelei On 10/31/2019 2:36 PM, Eug?ne Adell wrote: > Hello, > > with Java 8 and earlier (and probably some later that I didn't check), > the timestamp is correct half of the time, incorrect the other half, > because of the bad shifting that I pointed in my first post. One > incorrect clock is not supposed to be correct 50% of the time, for > example it would be 1 minute late all the time. > > With Java 11 the clock is always incorrect, and even it can't be > considered a clock anymore when your clock is years late, it's still > more consistent than the previous behaviour. > > "Please don't have the application rely on the gmt_unix_time value." > Sure, and anyway a Java application cannot access to this value from > what I know. Having a correct time is however useful when analyzing > logs produced with javax.net.debug property, or correlating with a > network capture. This is how I went to see that problem, by > investigating an issue, and we shouldn't underestimate the very few > tools that allow troubleshooting. > > best regards > E.A. > > > Le jeu. 31 oct. 2019 ? 21:50, Xuelei Fan a ?crit : >> >> Hi, >> >> The TLS spec does not require a correct gmt_unix_time: >> [RFC 5246] "Clocks are not required to be set correctly by the >> basic TLS protocol; higher-level or application protocols may >> define additional requirements." >> >> Please don't have the application rely on the gmt_unix_time value. >> >> Xuelei >> >> On 8/11/2019 4:26 PM, Eug?ne Adell wrote: >>> Hello, >>> >>> When using the well-known javax.net.debug=all property we get outputs >>> similar to this : >>> >>> ... >>> Ignoring unsupported cipher suite: >>> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1 >>> Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 >>> for TLSv1.1 >>> Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 >>> for TLSv1.1 >>> %% No cached client session >>> update handshake state: client_hello[1] >>> upcoming handshake states: server_hello[2] >>> *** ClientHello, TLSv1.2 >>> RandomCookie: GMT: 1565495356 bytes = { 119, 88, 206, 84, 104, 18, >>> 56, 110, 157, 162, 50, 247, 142, 47, 46, 11, 133, 196, 21, 108, 17, >>> 205, 121, 220, 52, 127, 169, 241 } >>> Session ID: {} >>> Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, >>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, >>> TLS_RSA_WITH_AES_256_CBC_SHA256, >>> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, >>> ... >>> Compression Methods: { 0 } >>> Extension elliptic_curves, curve names: {secp256r1, secp384r1, >>> secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, >>> sect571r1, secp256k1} >>> Extension ec_point_formats, formats: [uncompressed] >>> Extension signature_algorithms, signature_algorithms: SHA512withECDSA, >>> SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, >>> SHA256withRSA, SHA256withDSA, SHA224withECDSA, SHA224withRSA, >>> SHA224withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA >>> Extension extended_master_secret >>> Extension server_name, server_name: [type=host_name (0), >>> value=bugs.openjdk.java.net] >>> *** >>> [write] MD5 and SHA1 hashes: len = 229 >>> 0000: 01 00 00 E1 03 03 5D 50 90 3C 77 58 CE 54 68 12 ......]P.>> 0010: 38 6E 9D A2 32 F7 8E 2F 2E 0B 85 C4 15 6C 11 CD 8n..2../.....l.. >>> 0020: 79 DC 34 7F A9 F1 00 00 56 C0 24 C0 28 00 3D C0 y.4.....V.$.(.=. >>> 0030: 26 C0 2A 00 6B 00 6A C0 0A C0 14 00 35 C0 05 C0 &.*.k.j.....5... >>> ... >>> >>> However converting the timestamp found in the RandomCookie 1565495356 >>> gives 5D4F903C and not 5D50903C, which is the value found in the debug >>> trace (line starting by "0000:") >>> This of course doesn't break anything but I guess this is not the >>> expected behaviour. >>> The problem is reproducible depending on the current time. From my >>> tests, the GMT value is wrong, and the value sent in the handshake >>> itself is right. Probably RandomCookie.print() is facing the >>> endianness problem, and I suggest the following patch that I >>> unit-tested but not in JSSE itself : >>> >>> --- a/RandomCookie.java 2019-08-12 00:43:56.458000000 +0200 >>> +++ b/RandomCookie.java 2019-08-12 01:18:06.874000000 +0200 >>> @@ -70,10 +70,10 @@ >>> void print(PrintStream s) { >>> int i, gmt_unix_time; >>> >>> - gmt_unix_time = random_bytes[0] << 24; >>> - gmt_unix_time += random_bytes[1] << 16; >>> - gmt_unix_time += random_bytes[2] << 8; >>> - gmt_unix_time += random_bytes[3]; >>> + gmt_unix_time = ((random_bytes[0] & 0xFF) << 24) | >>> + ((random_bytes[1] & 0xFF) << 16) | >>> + ((random_bytes[2] & 0xFF) << 8) | >>> + ((random_bytes[3] & 0xFF) << 0); >>> >>> s.print("GMT: " + gmt_unix_time + " "); >>> s.print("bytes = { "); >>> >>> >>> best regards >>> Eugene Adell >>> From ecki at zusammenkunft.net Thu Oct 31 22:44:14 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 31 Oct 2019 22:44:14 +0000 Subject: the GMT timestamp given in the trace is sometimes wrong In-Reply-To: References: <24533013-df83-9b7e-63af-65b609462562@oracle.com> , Message-ID: It would make sense to no longer calculate and print the timestamp in the debug log if we don?t want it to be relied upon. This would be less missleading (and mopst likely the shifting logic can be removed?) -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Xuelei Fan Gesendet: Donnerstag, Oktober 31, 2019 11:10 PM An: Eug?ne Adell Cc: security-dev at openjdk.java.net Betreff: Re: the GMT timestamp given in the trace is sometimes wrong The ClientHello.random has been changed to use "random number" since TLS 1.3 (See RFC 8446). The 4 leading bytes are not more used to indicate clock in the current implementation. For more details, please consider this doc (https://tools.ietf.org/id/draft-mathewson-no-gmtunixtime-00.txt). Xuelei On 10/31/2019 2:36 PM, Eug?ne Adell wrote: > Hello, > > with Java 8 and earlier (and probably some later that I didn't check), > the timestamp is correct half of the time, incorrect the other half, > because of the bad shifting that I pointed in my first post. One > incorrect clock is not supposed to be correct 50% of the time, for > example it would be 1 minute late all the time. > > With Java 11 the clock is always incorrect, and even it can't be > considered a clock anymore when your clock is years late, it's still > more consistent than the previous behaviour. > > "Please don't have the application rely on the gmt_unix_time value." > Sure, and anyway a Java application cannot access to this value from > what I know. Having a correct time is however useful when analyzing > logs produced with javax.net.debug property, or correlating with a > network capture. This is how I went to see that problem, by > investigating an issue, and we shouldn't underestimate the very few > tools that allow troubleshooting. > > best regards > E.A. > > > Le jeu. 31 oct. 2019 ? 21:50, Xuelei Fan a ?crit : >> >> Hi, >> >> The TLS spec does not require a correct gmt_unix_time: >> [RFC 5246] "Clocks are not required to be set correctly by the >> basic TLS protocol; higher-level or application protocols may >> define additional requirements." >> >> Please don't have the application rely on the gmt_unix_time value. >> >> Xuelei >> >> On 8/11/2019 4:26 PM, Eug?ne Adell wrote: >>> Hello, >>> >>> When using the well-known javax.net.debug=all property we get outputs >>> similar to this : >>> >>> ... >>> Ignoring unsupported cipher suite: >>> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1 >>> Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 >>> for TLSv1.1 >>> Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 >>> for TLSv1.1 >>> %% No cached client session >>> update handshake state: client_hello[1] >>> upcoming handshake states: server_hello[2] >>> *** ClientHello, TLSv1.2 >>> RandomCookie: GMT: 1565495356 bytes = { 119, 88, 206, 84, 104, 18, >>> 56, 110, 157, 162, 50, 247, 142, 47, 46, 11, 133, 196, 21, 108, 17, >>> 205, 121, 220, 52, 127, 169, 241 } >>> Session ID: {} >>> Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, >>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, >>> TLS_RSA_WITH_AES_256_CBC_SHA256, >>> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, >>> ... >>> Compression Methods: { 0 } >>> Extension elliptic_curves, curve names: {secp256r1, secp384r1, >>> secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, >>> sect571r1, secp256k1} >>> Extension ec_point_formats, formats: [uncompressed] >>> Extension signature_algorithms, signature_algorithms: SHA512withECDSA, >>> SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, >>> SHA256withRSA, SHA256withDSA, SHA224withECDSA, SHA224withRSA, >>> SHA224withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA >>> Extension extended_master_secret >>> Extension server_name, server_name: [type=host_name (0), >>> value=bugs.openjdk.java.net] >>> *** >>> [write] MD5 and SHA1 hashes: len = 229 >>> 0000: 01 00 00 E1 03 03 5D 50 90 3C 77 58 CE 54 68 12 ......]P.>> 0010: 38 6E 9D A2 32 F7 8E 2F 2E 0B 85 C4 15 6C 11 CD 8n..2../.....l.. >>> 0020: 79 DC 34 7F A9 F1 00 00 56 C0 24 C0 28 00 3D C0 y.4.....V.$.(.=. >>> 0030: 26 C0 2A 00 6B 00 6A C0 0A C0 14 00 35 C0 05 C0 &.*.k.j.....5... >>> ... >>> >>> However converting the timestamp found in the RandomCookie 1565495356 >>> gives 5D4F903C and not 5D50903C, which is the value found in the debug >>> trace (line starting by "0000:") >>> This of course doesn't break anything but I guess this is not the >>> expected behaviour. >>> The problem is reproducible depending on the current time. From my >>> tests, the GMT value is wrong, and the value sent in the handshake >>> itself is right. Probably RandomCookie.print() is facing the >>> endianness problem, and I suggest the following patch that I >>> unit-tested but not in JSSE itself : >>> >>> --- a/RandomCookie.java 2019-08-12 00:43:56.458000000 +0200 >>> +++ b/RandomCookie.java 2019-08-12 01:18:06.874000000 +0200 >>> @@ -70,10 +70,10 @@ >>> void print(PrintStream s) { >>> int i, gmt_unix_time; >>> >>> - gmt_unix_time = random_bytes[0] << 24; >>> - gmt_unix_time += random_bytes[1] << 16; >>> - gmt_unix_time += random_bytes[2] << 8; >>> - gmt_unix_time += random_bytes[3]; >>> + gmt_unix_time = ((random_bytes[0] & 0xFF) << 24) | >>> + ((random_bytes[1] & 0xFF) << 16) | >>> + ((random_bytes[2] & 0xFF) << 8) | >>> + ((random_bytes[3] & 0xFF) << 0); >>> >>> s.print("GMT: " + gmt_unix_time + " "); >>> s.print("bytes = { "); >>> >>> >>> best regards >>> Eugene Adell >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Thu Oct 31 22:55:00 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 31 Oct 2019 15:55:00 -0700 Subject: the GMT timestamp given in the trace is sometimes wrong In-Reply-To: References: <24533013-df83-9b7e-63af-65b609462562@oracle.com> Message-ID: <728d4b1d-11fb-bf3a-c89e-31aff8431526@oracle.com> On 10/31/2019 3:44 PM, Bernd Eckenfels wrote: > It would make sense to no longer calculate and print the timestamp in > the debug log if we don?t want it to be relied upon. This would be less > missleading (and mopst likely the shifting logic can be removed?) > Yes. No timestamp, only 32 bytes random number in the debug log since JDK 11. Xuelei > > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > *Von:* security-dev im Auftrag > von Xuelei Fan > *Gesendet:* Donnerstag, Oktober 31, 2019 11:10 PM > *An:* Eug?ne Adell > *Cc:* security-dev at openjdk.java.net > *Betreff:* Re: the GMT timestamp given in the trace is sometimes wrong > The ClientHello.random has been changed to use "random number" since TLS > 1.3 (See RFC 8446). The 4 leading bytes are not more used to indicate > clock in the current implementation. For more details, please consider > this doc (https://tools.ietf.org/id/draft-mathewson-no-gmtunixtime-00.txt). > > Xuelei > > On 10/31/2019 2:36 PM, Eug?ne Adell wrote: > > Hello, > > > > with Java 8 and earlier (and probably some later that I didn't check), > > the timestamp is correct half of the time, incorrect the other half, > > because of the bad shifting that I pointed in my first post. One > > incorrect clock is not supposed to be correct 50% of the time, for > > example it would be 1 minute late all the time. > > > > With Java 11 the clock is always incorrect, and even it can't be > > considered a clock anymore when your clock is years late, it's still > > more consistent than the previous behaviour. > > > > "Please don't have the application rely on the gmt_unix_time value." > > Sure, and anyway a Java application cannot access to this value from > > what I know. Having a correct time is however useful when analyzing > > logs produced with javax.net.debug property, or correlating with a > > network capture. This is how I went to see that problem, by > > investigating an issue, and we shouldn't underestimate the very few > > tools that allow troubleshooting. > > > > best regards > > E.A. > > > > > > Le jeu. 31 oct. 2019 ? 21:50, Xuelei Fan a > ?crit : > >> > >> Hi, > >> > >> The TLS spec does not require a correct gmt_unix_time: > >> [RFC 5246] "Clocks are not required to be set correctly by the > >> basic TLS protocol; higher-level or application protocols may > >> define additional requirements." > >> > >> Please don't have the application rely on the gmt_unix_time value. > >> > >> Xuelei > >> > >> On 8/11/2019 4:26 PM, Eug?ne Adell wrote: > >>> Hello, > >>> > >>> When using the well-known javax.net.debug=all property we get outputs > >>> similar to this : > >>> > >>> ... > >>> Ignoring unsupported cipher suite: > >>> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1 > >>> Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 > >>> for TLSv1.1 > >>> Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 > >>> for TLSv1.1 > >>> %% No cached client session > >>> update handshake state: client_hello[1] > >>> upcoming handshake states: server_hello[2] > >>> *** ClientHello, TLSv1.2 > >>> RandomCookie: GMT: 1565495356 bytes = { 119, 88, 206, 84, 104, 18, > >>> 56, 110, 157, 162, 50, 247, 142, 47, 46, 11, 133, 196, 21, 108, 17, > >>> 205, 121, 220, 52, 127, 169, 241 } > >>> Session ID: {} > >>> Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, > >>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, > >>> TLS_RSA_WITH_AES_256_CBC_SHA256, > >>> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, > >>> ... > >>> Compression Methods: { 0 } > >>> Extension elliptic_curves, curve names: {secp256r1, secp384r1, > >>> secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, > >>> sect571r1, secp256k1} > >>> Extension ec_point_formats, formats: [uncompressed] > >>> Extension signature_algorithms, signature_algorithms: SHA512withECDSA, > >>> SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, > >>> SHA256withRSA, SHA256withDSA, SHA224withECDSA, SHA224withRSA, > >>> SHA224withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA > >>> Extension extended_master_secret > >>> Extension server_name, server_name: [type=host_name (0), > >>> value=bugs.openjdk.java.net] > >>> *** > >>> [write] MD5 and SHA1 hashes: len = 229 > >>> 0000: 01 00 00 E1 03 03 5D 50 90 3C 77 58 CE 54 68 12 ......]P. >>> 0010: 38 6E 9D A2 32 F7 8E 2F 2E 0B 85 C4 15 6C 11 CD 8n..2../.....l.. > >>> 0020: 79 DC 34 7F A9 F1 00 00 56 C0 24 C0 28 00 3D C0 y.4.....V.$.(.=. > >>> 0030: 26 C0 2A 00 6B 00 6A C0 0A C0 14 00 35 C0 05 C0 &.*.k.j.....5... > >>> ... > >>> > >>> However converting the timestamp found in the RandomCookie 1565495356 > >>> gives 5D4F903C and not 5D50903C, which is the value found in the debug > >>> trace (line starting by "0000:") > >>> This of course doesn't break anything but I guess this is not the > >>> expected behaviour. > >>> The problem is reproducible depending on the current time. From my > >>> tests, the GMT value is wrong, and the value sent in the handshake > >>> itself is right. Probably RandomCookie.print() is facing the > >>> endianness problem, and I suggest the following patch that I > >>> unit-tested but not in JSSE itself : > >>> > >>> --- a/RandomCookie.java 2019-08-12 00:43:56.458000000 +0200 > >>> +++ b/RandomCookie.java 2019-08-12 01:18:06.874000000 +0200 > >>> @@ -70,10 +70,10 @@ > >>> void print(PrintStream s) { > >>> int i, gmt_unix_time; > >>> > >>> - gmt_unix_time = random_bytes[0] << 24; > >>> - gmt_unix_time += random_bytes[1] << 16; > >>> - gmt_unix_time += random_bytes[2] << 8; > >>> - gmt_unix_time += random_bytes[3]; > >>> + gmt_unix_time = ((random_bytes[0] & 0xFF) << 24) | > >>> + ((random_bytes[1] & 0xFF) << 16) | > >>> + ((random_bytes[2] & 0xFF) << 8) | > >>> + ((random_bytes[3] & 0xFF) << 0); > >>> > >>> s.print("GMT: " + gmt_unix_time + " "); > >>> s.print("bytes = { "); > >>> > >>> > >>> best regards > >>> Eugene Adell > >>> From eugene.adell at gmail.com Thu Oct 31 23:03:29 2019 From: eugene.adell at gmail.com (=?UTF-8?Q?Eug=C3=A8ne_Adell?=) Date: Fri, 1 Nov 2019 00:03:29 +0100 Subject: the GMT timestamp given in the trace is sometimes wrong In-Reply-To: References: <24533013-df83-9b7e-63af-65b609462562@oracle.com> Message-ID: Hello, the capture I sent shows it's TLS 1.1 and not TLS 1.3 whose RFC doesn't mention gmt_unix. I opened this thread because the implementations of TLS 1.0/1.1/1.2 are not doing what is written in their RFCs, and I didn't say the implementation of TLS 1.3 was wrong. Besides, the log was produced with Java 8 which doesn't support TLS 1.3. I'm not opening a discussion whether gmt_unix is secure or not, it's beyond the discussion. The author of this draft forgets that a client which is not synchronized with an NTP server will see its clock deriving, making the fingerprinting hazardous, but he takes it for granted that clocks are not deriving and that he would track a client easily. Probably true on a short period of time, but in a single day you already have your clock derived of several seconds or even minutes. E.A. Le jeu. 31 oct. 2019 ? 23:09, Xuelei Fan a ?crit : > > The ClientHello.random has been changed to use "random number" since TLS > 1.3 (See RFC 8446). The 4 leading bytes are not more used to indicate > clock in the current implementation. For more details, please consider > this doc (https://tools.ietf.org/id/draft-mathewson-no-gmtunixtime-00.txt). > > Xuelei > > On 10/31/2019 2:36 PM, Eug?ne Adell wrote: > > Hello, > > > > with Java 8 and earlier (and probably some later that I didn't check), > > the timestamp is correct half of the time, incorrect the other half, > > because of the bad shifting that I pointed in my first post. One > > incorrect clock is not supposed to be correct 50% of the time, for > > example it would be 1 minute late all the time. > > > > With Java 11 the clock is always incorrect, and even it can't be > > considered a clock anymore when your clock is years late, it's still > > more consistent than the previous behaviour. > > > > "Please don't have the application rely on the gmt_unix_time value." > > Sure, and anyway a Java application cannot access to this value from > > what I know. Having a correct time is however useful when analyzing > > logs produced with javax.net.debug property, or correlating with a > > network capture. This is how I went to see that problem, by > > investigating an issue, and we shouldn't underestimate the very few > > tools that allow troubleshooting. > > > > best regards > > E.A. > > > > > > Le jeu. 31 oct. 2019 ? 21:50, Xuelei Fan a ?crit : > >> > >> Hi, > >> > >> The TLS spec does not require a correct gmt_unix_time: > >> [RFC 5246] "Clocks are not required to be set correctly by the > >> basic TLS protocol; higher-level or application protocols may > >> define additional requirements." > >> > >> Please don't have the application rely on the gmt_unix_time value. > >> > >> Xuelei > >> > >> On 8/11/2019 4:26 PM, Eug?ne Adell wrote: > >>> Hello, > >>> > >>> When using the well-known javax.net.debug=all property we get outputs > >>> similar to this : > >>> > >>> ... > >>> Ignoring unsupported cipher suite: > >>> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1 > >>> Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 > >>> for TLSv1.1 > >>> Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 > >>> for TLSv1.1 > >>> %% No cached client session > >>> update handshake state: client_hello[1] > >>> upcoming handshake states: server_hello[2] > >>> *** ClientHello, TLSv1.2 > >>> RandomCookie: GMT: 1565495356 bytes = { 119, 88, 206, 84, 104, 18, > >>> 56, 110, 157, 162, 50, 247, 142, 47, 46, 11, 133, 196, 21, 108, 17, > >>> 205, 121, 220, 52, 127, 169, 241 } > >>> Session ID: {} > >>> Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, > >>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, > >>> TLS_RSA_WITH_AES_256_CBC_SHA256, > >>> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, > >>> ... > >>> Compression Methods: { 0 } > >>> Extension elliptic_curves, curve names: {secp256r1, secp384r1, > >>> secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, > >>> sect571r1, secp256k1} > >>> Extension ec_point_formats, formats: [uncompressed] > >>> Extension signature_algorithms, signature_algorithms: SHA512withECDSA, > >>> SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, > >>> SHA256withRSA, SHA256withDSA, SHA224withECDSA, SHA224withRSA, > >>> SHA224withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA > >>> Extension extended_master_secret > >>> Extension server_name, server_name: [type=host_name (0), > >>> value=bugs.openjdk.java.net] > >>> *** > >>> [write] MD5 and SHA1 hashes: len = 229 > >>> 0000: 01 00 00 E1 03 03 5D 50 90 3C 77 58 CE 54 68 12 ......]P. >>> 0010: 38 6E 9D A2 32 F7 8E 2F 2E 0B 85 C4 15 6C 11 CD 8n..2../.....l.. > >>> 0020: 79 DC 34 7F A9 F1 00 00 56 C0 24 C0 28 00 3D C0 y.4.....V.$.(.=. > >>> 0030: 26 C0 2A 00 6B 00 6A C0 0A C0 14 00 35 C0 05 C0 &.*.k.j.....5... > >>> ... > >>> > >>> However converting the timestamp found in the RandomCookie 1565495356 > >>> gives 5D4F903C and not 5D50903C, which is the value found in the debug > >>> trace (line starting by "0000:") > >>> This of course doesn't break anything but I guess this is not the > >>> expected behaviour. > >>> The problem is reproducible depending on the current time. From my > >>> tests, the GMT value is wrong, and the value sent in the handshake > >>> itself is right. Probably RandomCookie.print() is facing the > >>> endianness problem, and I suggest the following patch that I > >>> unit-tested but not in JSSE itself : > >>> > >>> --- a/RandomCookie.java 2019-08-12 00:43:56.458000000 +0200 > >>> +++ b/RandomCookie.java 2019-08-12 01:18:06.874000000 +0200 > >>> @@ -70,10 +70,10 @@ > >>> void print(PrintStream s) { > >>> int i, gmt_unix_time; > >>> > >>> - gmt_unix_time = random_bytes[0] << 24; > >>> - gmt_unix_time += random_bytes[1] << 16; > >>> - gmt_unix_time += random_bytes[2] << 8; > >>> - gmt_unix_time += random_bytes[3]; > >>> + gmt_unix_time = ((random_bytes[0] & 0xFF) << 24) | > >>> + ((random_bytes[1] & 0xFF) << 16) | > >>> + ((random_bytes[2] & 0xFF) << 8) | > >>> + ((random_bytes[3] & 0xFF) << 0); > >>> > >>> s.print("GMT: " + gmt_unix_time + " "); > >>> s.print("bytes = { "); > >>> > >>> > >>> best regards > >>> Eugene Adell > >>> From yano-masanori at fujitsu.com Wed Oct 9 03:11:08 2019 From: yano-masanori at fujitsu.com (yano-masanori at fujitsu.com) Date: Wed, 09 Oct 2019 03:11:08 -0000 Subject: 8216012: Infinite loop in RSA KeyPairGenerator Message-ID: Hello. I would like to contribute for JDK-8216012. The cause of this problem is RSAKeyPairGenerator that doesn't check the public exponent even though the algorithm of rsa key generation can use only odd exponent number. To generate a KeyPair, the RSAKeyPairGenerator finds two random primes P and Q, and calculate Phi = (P - 1) * (Q - 1). If Phi is not relative prime to exponent, RSAKeyPairGenerator retry from the first. The value of Phi must be an even number because P and Q are odd numbers. If exponent is an even number, the greatest common divisor cannot be 1 because one of common divisors is 2 which is bigger than 1. Therefore, generateKeyPair() method of RSAKeyPairGenerator cannot exit the retrying loop. To solve this problem, I propose to check whether the public exponent is even number. Please sponsor the following change. diff --git a/src/java.base/share/classes/sun/security/rsa/RSAKeyPairGenerator.java b/src/java.base/share/classes/sun/security/rsa/RSAKeyPairGenerator.java --- a/src/java.base/share/classes/sun/security/rsa/RSAKeyPairGenerator.java +++ b/src/java.base/share/classes/sun/security/rsa/RSAKeyPairGenerator.java @@ -96,6 +96,10 @@ throw new InvalidAlgorithmParameterException ("Public exponent must be 3 or larger"); } + if (!tmpPublicExponent.testBit(0)) { + throw new InvalidAlgorithmParameterException + ("Public exponent must be an odd number"); + } if (tmpPublicExponent.bitLength() > tmpKeySize) { throw new InvalidAlgorithmParameterException ("Public exponent must be smaller than key size"); diff --git a/test/jdk/sun/security/rsa/TestKeyPairGeneratorExponent.java b/test/jdk/sun/security/rsa/TestKeyPairGeneratorExponent.java new file mode 100644 --- /dev/null +++ b/test/jdk/sun/security/rsa/TestKeyPairGeneratorExponent.java @@ -0,0 +1,65 @@ +import java.math.BigInteger; + +import java.security.*; +import java.security.interfaces.*; +import java.security.spec.*; + +/** + * @test + * @bug 8216012 + * @summary Tests the RSA public key exponent for KeyPairGenerator + * @run main/timeout=60 TestKeyPairGeneratorExponent + */ +public class TestKeyPairGeneratorExponent { + private static int keyLen = 512; + + private static BigInteger[] validExponents = new BigInteger[] { + RSAKeyGenParameterSpec.F0, + RSAKeyGenParameterSpec.F4, + // Since 512-bit exponent is larger than modulus, fails in RSAPublicKeyImpl.checkExponentRange(). + BigInteger.ONE.shiftLeft(keyLen - 1).subtract(BigInteger.ONE) + }; + + private static BigInteger[] invalidExponents = new BigInteger[] { + BigInteger.valueOf(-1), + BigInteger.ZERO, + BigInteger.ONE, + // 8216012: An even number causes infinite loop. + BigInteger.valueOf(4), + BigInteger.ONE.shiftLeft(keyLen) + }; + + public static void testValidExponents(KeyPairGenerator kpg, BigInteger exponent) { + try { + kpg.initialize(new RSAKeyGenParameterSpec(keyLen, exponent)); + kpg.generateKeyPair(); + } catch(InvalidAlgorithmParameterException iape){ + throw new RuntimeException("Unexpected Exception: " + iape); + } + } + + public static void testInvalidExponents(KeyPairGenerator kpg, BigInteger exponent) { + try { + kpg.initialize(new RSAKeyGenParameterSpec(keyLen, exponent)); + kpg.generateKeyPair(); + throw new RuntimeException("Expected InvalidAlgorithmParameterException was not thrown."); + } catch(InvalidAlgorithmParameterException iape){ + // Expected InvalidAlgorithmParameterException was thrown.OK + } + } + + public static void main(String[] args) throws Exception { + Provider provider = Security.getProvider("SunRsaSign"); + KeyPairGenerator kpg; + + for(BigInteger validExponent : validExponents) { + kpg = KeyPairGenerator.getInstance("RSA", provider); + testValidExponents(kpg, validExponent); + } + + for(BigInteger invalidExponent : invalidExponents) { + kpg = KeyPairGenerator.getInstance("RSA", provider); + testInvalidExponents(kpg, invalidExponent); + } + } +} Regards, Masanori Yano