From weijun.wang at oracle.com Wed Jan 2 02:59:26 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 2 Jan 2019 10:59:26 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20181231063640.GL22527@twosigma.com> References: <20181219203103.GK22527@twosigma.com> <20181231063640.GL22527@twosigma.com> Message-ID: > On Dec 31, 2018, at 2:36 PM, Nico Williams wrote: > > On Fri, Dec 28, 2018 at 09:07:04PM +0800, Weijun Wang wrote: >> If we are not going to use or implement new functions defined in RFC 5587, I >> doubt if this is useful. > > Using pointers to incomplete structs is much better than pointers to > void: you get static type safety. When we made that change in Solaris' > libgss we found at least one serious bug. > >> And I don't think we can rewrite existing declarations in gssapi.h to use >> these const types. Or can we? > > Actually, you can. Heimdal and MIT made those changes. Can you point out where they are using the new types in existing function declarations? I searched for gss_const_buffer_t in their repos and it only appears in new functions. I understand it's probably ABI-compatible to use the new types. I am OK with using them temporarily for compile check but feel uncomfortable to modify the existing gssapi.h, especially it is also used by the native bridge itself. Thanks, Max > > Nico > -- From Alan.Bateman at oracle.com Wed Jan 2 11:45:15 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 2 Jan 2019 11:45:15 +0000 Subject: RFR - CSR: 8213082: (zipfs) Add support for POSIX file permissions (was: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions) In-Reply-To: References: <6b4b78c731e24ef8aa45b6c048d017da@sap.com> <6dc8281e-b4ea-e27e-acdb-984612d91565@oracle.com> Message-ID: <61d492fa-5b08-7847-01f1-492725aae4a6@oracle.com> On 21/12/2018 13:43, Langer, Christoph wrote: > Hi Alan, > >> Adding support for POSIX file permissions to the zip APIs is problematic >> as we've been discussing here. There are security concerns and also >> concerns that how it interacts with JAR files and signed JAR in >> particular. I don't disagree that we can come to agreement on zipfs >> supporting a solution but I think we need to get the bigger picture on >> where this is going first. If the piece to change the java.util.zip APIs >> is dropped then it would make these discussions a lot simpler as it >> removes most of the security issues from the table. > Yes, please consider changes to java.util.zip APIs as dropped. At least for the moment. I'm not saying I won't ever get back to that topic but maybe an enhancement of jdk.zipfs is already sufficient to provide the required Posix permission support for the Java platform. > I've looked at the updated CSR. It would be good to include the spec changes, meaning the javadoc update to jdk.zipfs/module-info.java where it will document that it supports PosixFileAttributeView. I suspect there is also a discussion point around owner/group as I can't tell from the CSR if the UNIX extra fields are being used to encode the uid/gid (the original spec did not envisage supporting PosixFileAttributeView without also supporting file ownership). -Alan From xuelei.fan at oracle.com Wed Jan 2 15:56:00 2019 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Wed, 2 Jan 2019 07:56:00 -0800 Subject: [12] RFR 8215694: keytool cannot generate RSASSA-PSS certificates In-Reply-To: <1F1ABA02-BD59-4CB8-8C0F-8F52E6B7CF10@oracle.com> References: <1F1ABA02-BD59-4CB8-8C0F-8F52E6B7CF10@oracle.com> Message-ID: <364147ca-fab3-b93c-91d1-bcbf85bbc8c2@oracle.com> sigAlg.equalsIgnoreCase("RSASSA-PSS"): Do you really want to ignore the case? I used to think that an algorithm name is case sensitive. Main.java:1445 minor, 4 more indent? AlgorithmId.java:1073-1091: I may prefer to use cached parameters (for both AlgorithmParameters and AlgorithmParameterSpec) for each size, for performance. Xuelei On 12/21/2018 1:44 AM, Weijun Wang wrote: > Please take a review at > > https://cr.openjdk.java.net/~weijun/8215694/webrev.00/ > > This bug reveals several issues: > > 1. Encoding of the RSASSA-PSS signature algorithm in PKCS10 and X509CertImpl. > > 2. The missing of setParameter() call for PKCS10 and X509CertImpl. > > 3. All keytool commands of -genkeypair, -certreq, -gencert, -selfcert are affected. > > 4. Wrong NULL after encoding of RSASSA-PSS key algorithm. > > Please confirm this is safe to be fixed in JDK 12. > > Thanks, > Max > From Nico.Williams at twosigma.com Wed Jan 2 16:21:52 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Wed, 2 Jan 2019 16:21:52 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: References: <20181219203103.GK22527@twosigma.com> <20181231063640.GL22527@twosigma.com> Message-ID: <20190102162152.GM22527@twosigma.com> On Wed, Jan 02, 2019 at 10:59:26AM +0800, Weijun Wang wrote: > > On Dec 31, 2018, at 2:36 PM, Nico Williams wrote: > > On Fri, Dec 28, 2018 at 09:07:04PM +0800, Weijun Wang wrote: > >> If we are not going to use or implement new functions defined in RFC 5587, I > >> doubt if this is useful. > > > > Using pointers to incomplete structs is much better than pointers to > > void: you get static type safety. When we made that change in Solaris' > > libgss we found at least one serious bug. > > > >> And I don't think we can rewrite existing declarations in gssapi.h to use > >> these const types. Or can we? > > > > Actually, you can. Heimdal and MIT made those changes. > > Can you point out where they are using the new types in existing function > declarations? I searched for gss_const_buffer_t in their repos and it only > appears in new functions. I'll change Heimdal (I'm a maintainer). Thanks for noticing that. > I understand it's probably ABI-compatible to use the new types. I am OK with > using them temporarily for compile check but feel uncomfortable to modify the > existing gssapi.h, especially it is also used by the native bridge itself. It is both, an ABI- and a source-compatible change to make. Nico -- From sean.mullan at oracle.com Wed Jan 2 20:42:50 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 2 Jan 2019 15:42:50 -0500 Subject: RFR (12): 8215318: Amend the Standard Algorithm Names specification to clarify that names can be defined in later versions Message-ID: Please review this change to the Java Security Standard Algorithm Names specification [1] to clarify that standard names that are defined in later versions of SE are also supported in prior versions, as long as the applicable Security APIs are also supported. Please see the CSR for the motivation and exact wording changes: https://bugs.openjdk.java.net/browse/JDK-8215320 This change will also be included in the upcoming Maintenance Reviews of the Java SE 8 and 11 Platform JSRs. See [2] for more information. I have also included the raw diffs below: diff -r 8829e86def29 closed/src/java.base/share/specs/security/standard-names.md --- a/closed/src/java.base/share/specs/security/standard-names.md Thu Dec 20 14:21:16 2018 -0500 +++ b/closed/src/java.base/share/specs/security/standard-names.md Wed Jan 02 15:39:12 2019 -0500 @@ -20,6 +20,10 @@ The Java SE Security API requires and uses a set of standard names for algorithms, certificate and keystore types. +Names that are added to subsequent Java SE versions of this specification +also apply to this version of the specification if the Security APIs that +those names are defined for are supported. + In some cases naming conventions are given for forming names that are not explicitly listed, to facilitate name consistency across provider implementations. Items in angle brackets (such as `` and --Sean [1] https://docs.oracle.com/en/java/javase/11/docs/specs/security/standard-names.html [2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-December/000308.html From anthony.scarpino at oracle.com Wed Jan 2 21:02:40 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 2 Jan 2019 13:02:40 -0800 Subject: RFR (12): 8215318: Amend the Standard Algorithm Names specification to clarify that names can be defined in later versions In-Reply-To: References: Message-ID: <3e5a761d-87ce-205c-cd06-280b104138e4@oracle.com> Looks fine Tony On 1/2/19 12:42 PM, Sean Mullan wrote: > Please review this change to the Java Security Standard Algorithm Names > specification [1] to clarify that standard names that are defined in > later versions of SE are also supported in prior versions, as long as > the applicable Security APIs are also supported. > > Please see the CSR for the motivation and exact wording changes: > https://bugs.openjdk.java.net/browse/JDK-8215320 > > This change will also be included in the upcoming Maintenance Reviews of > the Java SE 8 and 11 Platform JSRs. See [2] for more information. > > I have also included the raw diffs below: > > diff -r 8829e86def29 > closed/src/java.base/share/specs/security/standard-names.md > --- a/closed/src/java.base/share/specs/security/standard-names.md Thu > Dec 20 14:21:16 2018 -0500 > +++ b/closed/src/java.base/share/specs/security/standard-names.md Wed > Jan 02 15:39:12 2019 -0500 > @@ -20,6 +20,10 @@ > ?The Java SE Security API requires and uses a set of standard names for > ?algorithms, certificate and keystore types. > > +Names that are added to subsequent Java SE versions of this specification > +also apply to this version of the specification if the Security APIs that > +those names are defined for are supported. > + > ?In some cases naming conventions are given for forming names that are not > ?explicitly listed, to facilitate name consistency across provider > ?implementations. Items in angle brackets (such as `` and > > --Sean > > [1] > https://docs.oracle.com/en/java/javase/11/docs/specs/security/standard-names.html > > [2] > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-December/000308.html > From iris.clark at oracle.com Wed Jan 2 21:37:23 2019 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 2 Jan 2019 13:37:23 -0800 (PST) Subject: RFR (12): 8215318: Amend the Standard Algorithm Names specification to clarify that names can be defined in later versions In-Reply-To: References: Message-ID: <61ac2c12-74f6-4c42-b85d-37a0b1ac7d9f@default> Hi, Sean. These changes look good. Thanks, iris -----Original Message----- From: Sean Mullan Sent: Wednesday, January 2, 2019 12:43 PM To: security Dev OpenJDK ; IRIS,CLARK Subject: RFR (12): 8215318: Amend the Standard Algorithm Names specification to clarify that names can be defined in later versions Please review this change to the Java Security Standard Algorithm Names specification [1] to clarify that standard names that are defined in later versions of SE are also supported in prior versions, as long as the applicable Security APIs are also supported. Please see the CSR for the motivation and exact wording changes: https://bugs.openjdk.java.net/browse/JDK-8215320 This change will also be included in the upcoming Maintenance Reviews of the Java SE 8 and 11 Platform JSRs. See [2] for more information. I have also included the raw diffs below: diff -r 8829e86def29 closed/src/java.base/share/specs/security/standard-names.md --- a/closed/src/java.base/share/specs/security/standard-names.md Thu Dec 20 14:21:16 2018 -0500 +++ b/closed/src/java.base/share/specs/security/standard-names.md Wed Jan 02 15:39:12 2019 -0500 @@ -20,6 +20,10 @@ The Java SE Security API requires and uses a set of standard names for algorithms, certificate and keystore types. +Names that are added to subsequent Java SE versions of this +specification also apply to this version of the specification if the +Security APIs that those names are defined for are supported. + In some cases naming conventions are given for forming names that are not explicitly listed, to facilitate name consistency across provider implementations. Items in angle brackets (such as `` and --Sean [1] https://docs.oracle.com/en/java/javase/11/docs/specs/security/standard-names.html [2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-December/000308.html From Nico.Williams at twosigma.com Wed Jan 2 22:23:41 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Wed, 2 Jan 2019 22:23:41 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20190102162152.GM22527@twosigma.com> References: <20181219203103.GK22527@twosigma.com> <20181231063640.GL22527@twosigma.com> <20190102162152.GM22527@twosigma.com> Message-ID: <20190102222341.GN22527@twosigma.com> On Wed, Jan 02, 2019 at 04:21:52PM +0000, Nico Williams wrote: > On Wed, Jan 02, 2019 at 10:59:26AM +0800, Weijun Wang wrote: > > > On Dec 31, 2018, at 2:36 PM, Nico Williams wrote: > > > On Fri, Dec 28, 2018 at 09:07:04PM +0800, Weijun Wang wrote: > > >> If we are not going to use or implement new functions defined in RFC 5587, I > > >> doubt if this is useful. > > > > > > Using pointers to incomplete structs is much better than pointers to > > > void: you get static type safety. When we made that change in Solaris' > > > libgss we found at least one serious bug. > > > > > >> And I don't think we can rewrite existing declarations in gssapi.h to use > > >> these const types. Or can we? > > > > > > Actually, you can. Heimdal and MIT made those changes. > > > > Can you point out where they are using the new types in existing function > > declarations? I searched for gss_const_buffer_t in their repos and it only > > appears in new functions. > > I'll change Heimdal (I'm a maintainer). Thanks for noticing that. Actually, Heimdal does constify older functions with the new gss_const_* typedefs, e.g.: https://github.com/heimdal/heimdal/blob/master/lib/gssapi/gssapi/gssapi.h#L473 MIT does not; I've told them, so hopefully they make this change as well. Nico -- From weijun.wang at oracle.com Wed Jan 2 23:39:19 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 3 Jan 2019 07:39:19 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20190102222341.GN22527@twosigma.com> References: <20181219203103.GK22527@twosigma.com> <20181231063640.GL22527@twosigma.com> <20190102162152.GM22527@twosigma.com> <20190102222341.GN22527@twosigma.com> Message-ID: <9D8EAAF2-220F-4206-9E25-2FD3366C72AF@oracle.com> > On Jan 3, 2019, at 6:23 AM, Nico Williams wrote: > > On Wed, Jan 02, 2019 at 04:21:52PM +0000, Nico Williams wrote: >> On Wed, Jan 02, 2019 at 10:59:26AM +0800, Weijun Wang wrote: >>>> On Dec 31, 2018, at 2:36 PM, Nico Williams wrote: >>>> On Fri, Dec 28, 2018 at 09:07:04PM +0800, Weijun Wang wrote: >>>>> If we are not going to use or implement new functions defined in RFC 5587, I >>>>> doubt if this is useful. >>>> >>>> Using pointers to incomplete structs is much better than pointers to >>>> void: you get static type safety. When we made that change in Solaris' >>>> libgss we found at least one serious bug. >>>> >>>>> And I don't think we can rewrite existing declarations in gssapi.h to use >>>>> these const types. Or can we? >>>> >>>> Actually, you can. Heimdal and MIT made those changes. >>> >>> Can you point out where they are using the new types in existing function >>> declarations? I searched for gss_const_buffer_t in their repos and it only >>> appears in new functions. >> >> I'll change Heimdal (I'm a maintainer). Thanks for noticing that. > > Actually, Heimdal does constify older functions with the new gss_const_* > typedefs, e.g.: > > https://github.com/heimdal/heimdal/blob/master/lib/gssapi/gssapi/gssapi.h#L473 You're right, I only searched for gss_const_buffer_t. --Max > > MIT does not; I've told them, so hopefully they make this change as well. > > Nico > -- From weijun.wang at oracle.com Thu Jan 3 10:10:32 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 3 Jan 2019 18:10:32 +0800 Subject: [12] RFR 8215694: keytool cannot generate RSASSA-PSS certificates In-Reply-To: <364147ca-fab3-b93c-91d1-bcbf85bbc8c2@oracle.com> References: <1F1ABA02-BD59-4CB8-8C0F-8F52E6B7CF10@oracle.com> <364147ca-fab3-b93c-91d1-bcbf85bbc8c2@oracle.com> Message-ID: > On Jan 2, 2019, at 11:56 PM, Xue-Lei Fan wrote: > > sigAlg.equalsIgnoreCase("RSASSA-PSS"): > Do you really want to ignore the case? I used to think that an algorithm name is case sensitive. getInstance(alg) is always case-insensitive. > > Main.java:1445 minor, 4 more indent? Then it's longer than 80 chars. How about I un-indent lines 1443 and 1444? > > AlgorithmId.java:1073-1091: > I may prefer to use cached parameters (for both AlgorithmParameters and AlgorithmParameterSpec) for each size, for performance. OK for AlgorithmParameterSpec. Which AlgorithmParameters do you mean? The one in SignatureUtil? Thanks, Max > > > Xuelei > > > On 12/21/2018 1:44 AM, Weijun Wang wrote: >> Please take a review at >> https://cr.openjdk.java.net/~weijun/8215694/webrev.00/ >> This bug reveals several issues: >> 1. Encoding of the RSASSA-PSS signature algorithm in PKCS10 and X509CertImpl. >> 2. The missing of setParameter() call for PKCS10 and X509CertImpl. >> 3. All keytool commands of -genkeypair, -certreq, -gencert, -selfcert are affected. >> 4. Wrong NULL after encoding of RSASSA-PSS key algorithm. >> Please confirm this is safe to be fixed in JDK 12. >> Thanks, >> Max From xuelei.fan at oracle.com Thu Jan 3 15:27:23 2019 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Thu, 3 Jan 2019 07:27:23 -0800 Subject: [12] RFR 8215694: keytool cannot generate RSASSA-PSS certificates In-Reply-To: References: <1F1ABA02-BD59-4CB8-8C0F-8F52E6B7CF10@oracle.com> <364147ca-fab3-b93c-91d1-bcbf85bbc8c2@oracle.com> Message-ID: On 1/3/2019 2:10 AM, Weijun Wang wrote: > > >> On Jan 2, 2019, at 11:56 PM, Xue-Lei Fan wrote: >> >> sigAlg.equalsIgnoreCase("RSASSA-PSS"): >> Do you really want to ignore the case? I used to think that an algorithm name is case sensitive. > > getInstance(alg) is always case-insensitive. > Hm, I missed it. >> >> Main.java:1445 minor, 4 more indent? > > Then it's longer than 80 chars. How about I un-indent lines 1443 and 1444? > maybe, use 4 white spaces? See also the following comment. >> >> AlgorithmId.java:1073-1091: >> I may prefer to use cached parameters (for both AlgorithmParameters and AlgorithmParameterSpec) for each size, for performance. > > OK for AlgorithmParameterSpec. Which AlgorithmParameters do you mean? The one in SignatureUtil? > Yes, replacing SignatureUtil.createAlgorithmParameters(). Then we don't need to worry about the indents above. Thanks, Xuelei > Thanks, > Max > > >> >> >> Xuelei >> >> >> On 12/21/2018 1:44 AM, Weijun Wang wrote: >>> Please take a review at >>> https://cr.openjdk.java.net/~weijun/8215694/webrev.00/ >>> This bug reveals several issues: >>> 1. Encoding of the RSASSA-PSS signature algorithm in PKCS10 and X509CertImpl. >>> 2. The missing of setParameter() call for PKCS10 and X509CertImpl. >>> 3. All keytool commands of -genkeypair, -certreq, -gencert, -selfcert are affected. >>> 4. Wrong NULL after encoding of RSASSA-PSS key algorithm. >>> Please confirm this is safe to be fixed in JDK 12. >>> Thanks, >>> Max > From Nico.Williams at twosigma.com Thu Jan 3 15:42:48 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Thu, 3 Jan 2019 15:42:48 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <9D8EAAF2-220F-4206-9E25-2FD3366C72AF@oracle.com> References: <20181219203103.GK22527@twosigma.com> <20181231063640.GL22527@twosigma.com> <20190102162152.GM22527@twosigma.com> <20190102222341.GN22527@twosigma.com> <9D8EAAF2-220F-4206-9E25-2FD3366C72AF@oracle.com> Message-ID: <20190103154248.GO22527@twosigma.com> Heimdal goes a bit too far. The input_cred_handle argument to gss_add_cred() should be gss_cred_id_t, not gss_const_cred_id_t, since if you don't give it an output_cred_handle pointer then gss_add-cred() mutates the input_cred_handle. From roger.calnan at oracle.com Thu Jan 3 16:51:45 2019 From: roger.calnan at oracle.com (Roger Calnan) Date: Thu, 3 Jan 2019 08:51:45 -0800 Subject: RFR: 8179943 Typo in javax.net.ssl.SSLSession.removeValue(String) method documentation Message-ID: please review straightforward fix in the javadoc for javax.net.ssl.SSLSession.removeValue Thanks, Roger https://bugs.openjdk.java.net/browse/JDK-8179943 Typo in javax.net.ssl.SSLSession.removeValue(String) method documentation diff -r 3d0f6ef91216 src/java.base/share/classes/javax/net/ssl/SSLSession.java --- a/src/java.base/share/classes/javax/net/ssl/SSLSession.java Wed Jan 02 13:37:55 2019 -0500 +++ b/src/java.base/share/classes/javax/net/ssl/SSLSession.java Wed Jan 02 13:19:38 2019 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -187,7 +187,7 @@ * Removes the object bound to the given name in the session's * application layer data. Does nothing if there is no object * bound to the given name. If the bound existing object - * implements the {@code SessionBindingListener} interface, + * implements the {@code SSLSessionBindingListener} interface, * it is notified appropriately. *

* For security reasons, the same named values may not be -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Thu Jan 3 17:01:53 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 3 Jan 2019 17:01:53 +0000 Subject: RFR: 8179943 Typo in javax.net.ssl.SSLSession.removeValue(String) method documentation In-Reply-To: References: Message-ID: Looks fine to me. I can sponsor this patch if required. regards, Sean. On 03/01/2019 16:51, Roger Calnan wrote: > please review straightforward fix in the javadoc > for?javax.net.ssl.SSLSession.removeValue > > Thanks, > > Roger > > *https://bugs.openjdk.java.net/browse/JDK-8179943?Typo in > javax.net.ssl.SSLSession.removeValue(String) method documentation* > * > * > diff -r 3d0f6ef91216 > src/java.base/share/classes/javax/net/ssl/SSLSession.java > --- a/src/java.base/share/classes/javax/net/ssl/SSLSession.javaWed Jan > 02 13:37:55 2019 -0500 > +++ b/src/java.base/share/classes/javax/net/ssl/SSLSession.javaWed Jan > 02 13:19:38 2019 -0800 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 1997, 2017, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1997, 2019, Oracle and/or its affiliates. All rights > reserved. > ??* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ??* > ??* This code is free software; you can redistribute it and/or modify it > @@ -187,7 +187,7 @@ > ? ? ??* Removes the object bound to the given name in the session's > ? ? ??* application layer data.??Does nothing if there is no object > ? ? ??* bound to the given name.??If the bound existing object > -?? ??* implements the {@code SessionBindingListener} interface, > +?? ??* implements the {@code SSLSessionBindingListener} interface, > ? ? ??* it is notified appropriately. > ? ? ??*

> ? ? ??* For security reasons, the same named values may not be -------------- next part -------------- An HTML attachment was scrubbed... URL: From amir.khassaia at gmail.com Fri Jan 4 04:24:10 2019 From: amir.khassaia at gmail.com (Amir Khassaia) Date: Fri, 4 Jan 2019 15:24:10 +1100 Subject: Not possible to disable new TLS extensions for TLS 1.2 connections Message-ID: Greetings, Can extra security properties controlling new TLS extensions be added to make some of the JSSE handshake more configurable? I'm finding some misbehaviour caused indirectly with an existing TLS client when moving to OpenJDK 11 whereas it works fine with 8,9,10, note that TLS 1.3 is not used, this is purely a compatibility of TLS 1.2 request where some of the extensions can be optional. Whilst it doesn't appear the JSSE implementation is doing anything out of compliance with the standard it seems to present a case of an existing endpoint whose interop is now affected and there could be many misbehaved implementations out there, perhaps ones in hardware etc, that may not handle unknown extensions well. For me the endpoint in question is doing XMPP+STARTTLS on talk.google.com:5222 Through wireshark/client hello dumps the main difference seems to be ordering of extensions and presence of extra two extensions: 1) Extension: supported_versions (len=3) Type: supported_versions (43) Length: 3 Supported Versions length: 2 Supported Version: TLS 1.2 (0x0303) 2) Extension: signature_algorithms_cert (len=34) Type: signature_algorithms_cert (50) Length: 34 Signature Hash Algorithms Length: 32 Signature Hash Algorithms (16 algorithms) Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503) Signature Hash Algorithm Hash: SHA384 (5) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603) Signature Hash Algorithm Hash: SHA512 (6) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: rsa_pss_rsae_sha256 (0x0804) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (4) Signature Algorithm: rsa_pss_rsae_sha384 (0x0805) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (5) Signature Algorithm: rsa_pss_rsae_sha512 (0x0806) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (6) Signature Algorithm: rsa_pss_pss_sha256 (0x0809) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (9) Signature Algorithm: rsa_pss_pss_sha384 (0x080a) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (10) Signature Algorithm: rsa_pss_pss_sha512 (0x080b) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (11) Signature Algorithm: rsa_pkcs1_sha256 (0x0401) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: rsa_pkcs1_sha384 (0x0501) Signature Hash Algorithm Hash: SHA384 (5) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: rsa_pkcs1_sha512 (0x0601) Signature Hash Algorithm Hash: SHA512 (6) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: SHA256 DSA (0x0402) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: DSA (2) Signature Algorithm: ecdsa_sha1 (0x0203) Signature Hash Algorithm Hash: SHA1 (2) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: rsa_pkcs1_sha1 (0x0201) Signature Hash Algorithm Hash: SHA1 (2) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: SHA1 DSA (0x0202) Signature Hash Algorithm Hash: SHA1 (2) Signature Hash Algorithm Signature: DSA (2) This triggers a completely bizarre SNI bug but nevertheless it works just fine as soon as JRE is swapped out. Debug output of failed case javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:53.937 AEDT|SSLCipher.java:437|jdk.tls.keyLimits: entry = AES/GCM/NoPadding KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472 javax.net.ssl|WARNING|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.273 AEDT|ServerNameExtension.java:255|Unable to indicate server name javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.273 AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: server_name javax.net.ssl|WARNING|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.314 AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is not supported by the underlying providers javax.net.ssl|WARNING|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.314 AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not supported by the underlying providers javax.net.ssl|INFO|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.327 AEDT|AlpnExtension.java:161|No available application protocols javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.327 AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: application_layer_protocol_negotiation javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.328 AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: renegotiation_info javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.353 AEDT|ClientHello.java:651|Produced ClientHello handshake message ( "ClientHello": { "client version" : "TLSv1.2", "random" : "3B 9C 31 FA 55 2B 09 81 5F 12 82 25 AD A6 47 8E 76 CA 80 BF 72 BB 6D 84 EF 92 3E 9E EC 7A D5 13", "session id" : "", "cipher suites" : "[TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(0xC02C), TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B), TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xC030), TLS_RSA_WITH_AES_256_GCM_SHA384(0x009D), TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384(0xC02E), TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384(0xC032), TLS_DHE_RSA_WITH_AES_256_GCM_SHA384(0x009F), TLS_DHE_DSS_WITH_AES_256_GCM_SHA384(0x00A3), TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F), TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C), TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256(0xC02D), TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256(0xC031), TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E), TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384(0xC024), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384(0xC028), TLS_RSA_WITH_AES_256_CBC_SHA256(0x003D), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384(0xC026), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384(0xC02A), TLS_DHE_RSA_WITH_AES_256_CBC_SHA256(0x006B), TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(0xC00A), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(0xC014), TLS_RSA_WITH_AES_256_CBC_SHA(0x0035), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA(0xC005), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA(0xC00F), TLS_DHE_RSA_WITH_AES_256_CBC_SHA(0x0039), TLS_DHE_DSS_WITH_AES_256_CBC_SHA(0x0038), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256(0xC025), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067), TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013), TLS_RSA_WITH_AES_128_CBC_SHA(0x002F), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(0xC004), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(0xC00E), TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033), TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032), TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]", "compression methods" : "00", "extensions" : [ "status_request (5)": { "certificate status type": ocsp "OCSP status request": { "responder_id": "request extensions": { } } }, "supported_groups (10)": { "versions": [secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] }, "ec_point_formats (11)": { "formats": [uncompressed] }, "signature_algorithms (13)": { "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1] }, "signature_algorithms_cert (50)": { "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1] }, "status_request_v2 (17)": { "cert status request": { "certificate status type": ocsp_multi "OCSP status request": { "responder_id": "request extensions": { } } } }, "extended_master_secret (23)": { }, "supported_versions (43)": { "versions": [TLSv1.2] } ] } ) javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.521 AEDT|ServerHello.java:866|Consuming ServerHello handshake message ( "ServerHello": { "server version" : "TLSv1.2", "random" : "5C 2E DF 63 7B 0F C0 81 8C 3D 26 84 4B C1 51 AB 82 8A 3A DF 4D F3 91 4E 45 34 D5 33 CA 1B 59 8E", "session id" : "C8 38 09 76 0A CF 61 C2 2D 29 37 F1 74 31 36 FD 2A 00 6A C7 B9 FE 85 9C 16 F6 7B 9F 10 27 70 51", "cipher suite" : "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F)", "compression methods" : "00", "extensions" : [ "extended_master_secret (23)": { }, "renegotiation_info (65,281)": { "renegotiated connection": [] }, "ec_point_formats (11)": { "formats": [uncompressed] } ] } ) javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.522 AEDT|SSLExtensions.java:148|Ignore unavailable extension: supported_versions javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.522 AEDT|ServerHello.java:962|Negotiated protocol version: TLSv1.2 javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.523 AEDT|SSLExtensions.java:167|Consumed extension: renegotiation_info javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.524 AEDT|SSLExtensions.java:148|Ignore unavailable extension: server_name javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.535 AEDT|SSLExtensions.java:148|Ignore unavailable extension: max_fragment_length javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.536 AEDT|SSLExtensions.java:148|Ignore unavailable extension: status_request javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.536 AEDT|SSLExtensions.java:167|Consumed extension: ec_point_formats javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.536 AEDT|SSLExtensions.java:148|Ignore unavailable extension: status_request_v2 javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.537 AEDT|SSLExtensions.java:167|Consumed extension: extended_master_secret javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.537 AEDT|SSLExtensions.java:167|Consumed extension: renegotiation_info javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.538 AEDT|SSLExtensions.java:182|Ignore unavailable extension: server_name javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.538 AEDT|SSLExtensions.java:182|Ignore unavailable extension: max_fragment_length javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.538 AEDT|SSLExtensions.java:182|Ignore unavailable extension: status_request javax.net.ssl|WARNING|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.538 AEDT|SSLExtensions.java:190|Ignore impact of unsupported extension: ec_point_formats javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.540 AEDT|SSLExtensions.java:182|Ignore unavailable extension: application_layer_protocol_negotiation javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.540 AEDT|SSLExtensions.java:182|Ignore unavailable extension: status_request_v2 javax.net.ssl|WARNING|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.543 AEDT|SSLExtensions.java:190|Ignore impact of unsupported extension: extended_master_secret javax.net.ssl|WARNING|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.543 AEDT|SSLExtensions.java:190|Ignore impact of unsupported extension: renegotiation_info javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.553 AEDT|CertificateMessage.java:358|Consuming server Certificate handshake message ( "Certificates": [ "certificate" : { "version" : "v3", "serial number" : "00 90 76 89 18 E9 33 93 A0", "signature algorithm": "SHA256withRSA", "issuer" : "CN=invalid2.invalid, OU="No SNI provided; please fix your client."", "not before" : "2015-01-01 11:00:00.000 AEDT", "not after" : "2030-01-01 11:00:00.000 AEDT", "subject" : "CN=invalid2.invalid, OU="No SNI provided; please fix your client."", "subject public key" : "RSA", "extensions" : [ { ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:true PathLen:2147483647 ] }, { ObjectId: 2.5.29.37 Criticality=false ExtendedKeyUsages [ serverAuth clientAuth ] }, { ObjectId: 2.5.29.15 Criticality=true KeyUsage [ DigitalSignature Key_Encipherment Key_CertSign ] }, { ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: BB 0F 38 96 6F 3E BE 4F 2B 46 D0 41 6A D4 AC B5 ..8.o>.O+F.Aj... ] ] } ]} ] ) javax.net.ssl|ERROR|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.615 AEDT|TransportContext.java:313|Fatal (CERTIFICATE_UNKNOWN): PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target ( "throwable" : { sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target I'm triggering this indirectly via use of XMPP library so I don't have a clean JSSE only sample (but it simply creates an SSLSocket from the default SSLContext and calls startHandshake) Regards, Amir -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Fri Jan 4 20:06:42 2019 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Fri, 4 Jan 2019 12:06:42 -0800 Subject: Not possible to disable new TLS extensions for TLS 1.2 connections In-Reply-To: References: Message-ID: <8a2dbb5d-dcf5-a0ff-7daa-e794e6bd1853@oracle.com> Hi Amir, What's the certificate used in the connection? It looks like a certificate issue per the debug log: "unable to find valid certification path to requested target" Please feel free file a bug if the certificate is not restricted by the signature_algorithms and signature_algorithms_cert extension. Thanks, Xuelei On 1/3/2019 8:24 PM, Amir Khassaia wrote: > Greetings, > > Can extra security properties controlling new TLS extensions be added to > make some of the JSSE handshake more configurable? > > I'm finding some misbehaviour caused indirectly with an existing TLS > client when moving to OpenJDK 11 whereas it works fine with 8,9,10, note > that TLS 1.3 is not used, this is purely a compatibility of TLS 1.2 > request where some of the extensions can be optional. > > Whilst it doesn't appear the JSSE implementation is doing anything out > of compliance with the standard it seems to present a case of an > existing endpoint whose interop is now affected and there could be many > misbehaved implementations out there, perhaps ones in hardware etc, that > may not handle unknown extensions well. > > For me the endpoint in question is doing XMPP+STARTTLS on > talk.google.com:5222 > > Through wireshark/client hello dumps the main difference seems to be > ordering of extensions and presence of extra two extensions: > > 1)? Extension: supported_versions (len=3) > ? ? ? ? ? ? Type: supported_versions (43) > ? ? ? ? ? ? Length: 3 > ? ? ? ? ? ? Supported Versions length: 2 > ? ? ? ? ? ? Supported Version: TLS 1.2 (0x0303) > > 2) Extension: signature_algorithms_cert (len=34) > ? ? ? ? ? ? Type: signature_algorithms_cert (50) > ? ? ? ? ? ? Length: 34 > ? ? ? ? ? ? Signature Hash Algorithms Length: 32 > ? ? ? ? ? ? Signature Hash Algorithms (16 algorithms) > ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA256 (4) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) > ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA384 (5) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) > ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA512 (6) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) > ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_rsae_sha256 (0x0804) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: Unknown (4) > ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_rsae_sha384 (0x0805) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: Unknown (5) > ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_rsae_sha512 (0x0806) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: Unknown (6) > ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_pss_sha256 (0x0809) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: Unknown (9) > ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_pss_sha384 (0x080a) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: Unknown (10) > ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_pss_sha512 (0x080b) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: Unknown (11) > ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha256 (0x0401) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA256 (4) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) > ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha384 (0x0501) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA384 (5) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) > ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha512 (0x0601) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA512 (6) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) > ? ? ? ? ? ? ? ? Signature Algorithm: SHA256 DSA (0x0402) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA256 (4) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: DSA (2) > ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_sha1 (0x0203) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA1 (2) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) > ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha1 (0x0201) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA1 (2) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) > ? ? ? ? ? ? ? ? Signature Algorithm: SHA1 DSA (0x0202) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA1 (2) > ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: DSA (2) > > This triggers a completely bizarre SNI bug but nevertheless it works > just fine as soon as JRE is swapped out. > > Debug output of failed case > > javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:53.937 > AEDT|SSLCipher.java:437|jdk.tls.keyLimits:? entry = AES/GCM/NoPadding > KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472 > javax.net.ssl|WARNING|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.273 > AEDT|ServerNameExtension.java:255|Unable to indicate server name > javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.273 > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: > server_name > javax.net.ssl|WARNING|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.314 > AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is not > supported by the underlying providers > javax.net.ssl|WARNING|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.314 > AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not > supported by the underlying providers > javax.net.ssl|INFO|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.327 > AEDT|AlpnExtension.java:161|No available application protocols > javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.327 > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: > application_layer_protocol_negotiation > javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.328 > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: > renegotiation_info > javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.353 > AEDT|ClientHello.java:651|Produced ClientHello handshake message ( > "ClientHello": { > ? "client version"? ? ? : "TLSv1.2", > ? "random"? ? ? ? ? ? ? : "3B 9C 31 FA 55 2B 09 81 5F 12 82 25 AD A6 47 > 8E 76 CA 80 BF 72 BB 6D 84 EF 92 3E 9E EC 7A D5 13", > ? "session id"? ? ? ? ? : "", > ? "cipher suites"? ? ? ?: > "[TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(0xC02C), > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B), > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xC030), > TLS_RSA_WITH_AES_256_GCM_SHA384(0x009D), > TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384(0xC02E), > TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384(0xC032), > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384(0x009F), > TLS_DHE_DSS_WITH_AES_256_GCM_SHA384(0x00A3), > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F), > TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C), > TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256(0xC02D), > TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256(0xC031), > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E), > TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2), > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384(0xC024), > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384(0xC028), > TLS_RSA_WITH_AES_256_CBC_SHA256(0x003D), > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384(0xC026), > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384(0xC02A), > TLS_DHE_RSA_WITH_AES_256_CBC_SHA256(0x006B), > TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A), > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(0xC00A), > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(0xC014), > TLS_RSA_WITH_AES_256_CBC_SHA(0x0035), > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA(0xC005), > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA(0xC00F), > TLS_DHE_RSA_WITH_AES_256_CBC_SHA(0x0039), > TLS_DHE_DSS_WITH_AES_256_CBC_SHA(0x0038), > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), > TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256(0xC025), > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), > TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067), > TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040), > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009), > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013), > TLS_RSA_WITH_AES_128_CBC_SHA(0x002F), > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(0xC004), > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(0xC00E), > TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033), > TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032), > TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]", > ? "compression methods" : "00", > ? "extensions"? ? ? ? ? : [ > ? ? "status_request (5)": { > ? ? ? "certificate status type": ocsp > ? ? ? "OCSP status request": { > ? ? ? ? "responder_id": > ? ? ? ? "request extensions": { > ? ? ? ? ? > ? ? ? ? } > ? ? ? } > ? ? }, > ? ? "supported_groups (10)": { > ? ? ? "versions": [secp256r1, secp384r1, secp521r1, sect283k1, > sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1, > ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] > ? ? }, > ? ? "ec_point_formats (11)": { > ? ? ? "formats": [uncompressed] > ? ? }, > ? ? "signature_algorithms (13)": { > ? ? ? "signature schemes": [ecdsa_secp256r1_sha256, > ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, > rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, > rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, > rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha1, > rsa_pkcs1_sha1, dsa_sha1] > ? ? }, > ? ? "signature_algorithms_cert (50)": { > ? ? ? "signature schemes": [ecdsa_secp256r1_sha256, > ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, > rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, > rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, > rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha1, > rsa_pkcs1_sha1, dsa_sha1] > ? ? }, > ? ? "status_request_v2 (17)": { > ? ? ? "cert status request": { > ? ? ? ? "certificate status type": ocsp_multi > ? ? ? ? "OCSP status request": { > ? ? ? ? ? "responder_id": > ? ? ? ? ? "request extensions": { > ? ? ? ? ? ? > ? ? ? ? ? } > ? ? ? ? } > ? ? ? } > ? ? }, > ? ? "extended_master_secret (23)": { > ? ? ? > ? ? }, > ? ? "supported_versions (43)": { > ? ? ? "versions": [TLSv1.2] > ? ? } > ? ] > } > ) > javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.521 > AEDT|ServerHello.java:866|Consuming ServerHello handshake message ( > "ServerHello": { > ? "server version"? ? ? : "TLSv1.2", > ? "random"? ? ? ? ? ? ? : "5C 2E DF 63 7B 0F C0 81 8C 3D 26 84 4B C1 51 > AB 82 8A 3A DF 4D F3 91 4E 45 34 D5 33 CA 1B 59 8E", > ? "session id"? ? ? ? ? : "C8 38 09 76 0A CF 61 C2 2D 29 37 F1 74 31 36 > FD 2A 00 6A C7 B9 FE 85 9C 16 F6 7B 9F 10 27 70 51", > ? "cipher suite"? ? ? ? : "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F)", > ? "compression methods" : "00", > ? "extensions"? ? ? ? ? : [ > ? ? "extended_master_secret (23)": { > ? ? ? > ? ? }, > ? ? "renegotiation_info (65,281)": { > ? ? ? "renegotiated connection": [] > ? ? }, > ? ? "ec_point_formats (11)": { > ? ? ? "formats": [uncompressed] > ? ? } > ? ] > } > ) > javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.522 > AEDT|SSLExtensions.java:148|Ignore unavailable extension: supported_versions > javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.522 > AEDT|ServerHello.java:962|Negotiated protocol version: TLSv1.2 > javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.523 > AEDT|SSLExtensions.java:167|Consumed extension: renegotiation_info > javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.524 > AEDT|SSLExtensions.java:148|Ignore unavailable extension: server_name > javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.535 > AEDT|SSLExtensions.java:148|Ignore unavailable extension: > max_fragment_length > javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.536 > AEDT|SSLExtensions.java:148|Ignore unavailable extension: status_request > javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.536 > AEDT|SSLExtensions.java:167|Consumed extension: ec_point_formats > javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.536 > AEDT|SSLExtensions.java:148|Ignore unavailable extension: status_request_v2 > javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.537 > AEDT|SSLExtensions.java:167|Consumed extension: extended_master_secret > javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.537 > AEDT|SSLExtensions.java:167|Consumed extension: renegotiation_info > javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.538 > AEDT|SSLExtensions.java:182|Ignore unavailable extension: server_name > javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.538 > AEDT|SSLExtensions.java:182|Ignore unavailable extension: > max_fragment_length > javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.538 > AEDT|SSLExtensions.java:182|Ignore unavailable extension: status_request > javax.net.ssl|WARNING|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.538 > AEDT|SSLExtensions.java:190|Ignore impact of unsupported extension: > ec_point_formats > javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.540 > AEDT|SSLExtensions.java:182|Ignore unavailable extension: > application_layer_protocol_negotiation > javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.540 > AEDT|SSLExtensions.java:182|Ignore unavailable extension: status_request_v2 > javax.net.ssl|WARNING|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.543 > AEDT|SSLExtensions.java:190|Ignore impact of unsupported extension: > extended_master_secret > javax.net.ssl|WARNING|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.543 > AEDT|SSLExtensions.java:190|Ignore impact of unsupported extension: > renegotiation_info > javax.net.ssl|DEBUG|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.553 > AEDT|CertificateMessage.java:358|Consuming server Certificate handshake > message ( > "Certificates": [ > ? "certificate" : { > ? ? "version"? ? ? ? ? ? : "v3", > ? ? "serial number"? ? ? : "00 90 76 89 18 E9 33 93 A0", > ? ? "signature algorithm": "SHA256withRSA", > ? ? "issuer"? ? ? ? ? ? ?: "CN=invalid2.invalid, OU="No SNI provided; > please fix your client."", > ? ? "not before"? ? ? ? ?: "2015-01-01 11:00:00.000 AEDT", > ? ? "not? after"? ? ? ? ?: "2030-01-01 11:00:00.000 AEDT", > ? ? "subject"? ? ? ? ? ? : "CN=invalid2.invalid, OU="No SNI provided; > please fix your client."", > ? ? "subject public key" : "RSA", > ? ? "extensions"? ? ? ? ?: [ > ? ? ? { > ? ? ? ? ObjectId: 2.5.29.19 Criticality=true > ? ? ? ? BasicConstraints:[ > ? ? ? ? ? CA:true > ? ? ? ? ? PathLen:2147483647 > ? ? ? ? ] > ? ? ? }, > ? ? ? { > ? ? ? ? ObjectId: 2.5.29.37 Criticality=false > ? ? ? ? ExtendedKeyUsages [ > ? ? ? ? ? serverAuth > ? ? ? ? ? clientAuth > ? ? ? ? ] > ? ? ? }, > ? ? ? { > ? ? ? ? ObjectId: 2.5.29.15 Criticality=true > ? ? ? ? KeyUsage [ > ? ? ? ? ? DigitalSignature > ? ? ? ? ? Key_Encipherment > ? ? ? ? ? Key_CertSign > ? ? ? ? ] > ? ? ? }, > ? ? ? { > ? ? ? ? ObjectId: 2.5.29.14 Criticality=false > ? ? ? ? SubjectKeyIdentifier [ > ? ? ? ? KeyIdentifier [ > ? ? ? ? 0000: BB 0F 38 96 6F 3E BE 4F? ?2B 46 D0 41 6A D4 AC B5 > ..8.o>.O+F.Aj... > ? ? ? ? ] > ? ? ? ? ] > ? ? ? } > ? ? ]} > ] > ) > javax.net.ssl|ERROR|0F|Smack Packet Reader (0)|2019-01-04 15:21:55.615 > AEDT|TransportContext.java:313|Fatal (CERTIFICATE_UNKNOWN): PKIX path > building failed: > sun.security.provider.certpath.SunCertPathBuilderException: unable to > find valid certification path to requested target ( > "throwable" : { > ? sun.security.validator.ValidatorException: PKIX path building failed: > sun.security.provider.certpath.SunCertPathBuilderException: unable to > find valid certification path to requested target > > I'm triggering this indirectly via use of XMPP library so I don't have a > clean JSSE only sample (but it simply creates an SSLSocket from the > default SSLContext and calls startHandshake) > > Regards, > Amir > From mbalao at redhat.com Fri Jan 4 21:25:37 2019 From: mbalao at redhat.com (Martin Balao) Date: Fri, 4 Jan 2019 18:25:37 -0300 Subject: RFR 6913047: SunPKCS11 memory leak In-Reply-To: References: <6b00e3d4-c795-f3e4-38ca-fa897f8680ea@oracle.com> <2a8e2986-631a-02f5-f419-e28c18232b33@oracle.com> <44a3e1c4-64ca-47bf-2061-4fe55fa7b827@oracle.com> <540e790d-1edf-732e-bb15-85537a6aa9c8@oracle.com> <566016d0-00ba-e938-693f-56948b9013da@oracle.com> <2ee1d1b8-91f5-f0c7-bd9f-31d7d20d472c@oracle.com> Message-ID: Hi Valerie, Is webrev.15 ready for approval? (CSR, patch) I've re-worked release notes a bit [0]. Thanks, Martin.- -- [0] - https://bugs.openjdk.java.net/browse/JDK-8215018 On Fri, Dec 7, 2018 at 11:17 AM Martin Balao wrote: > > Hi Valerie, > > On Thu, Dec 6, 2018 at 11:27 PM Valerie Peng > wrote: > > > > I suppose the changes in this update is just the system property > > renaming? I looked at the relevant files and they look fine. If you made > > more changes than this, please let me know and I will take a closer look > > at them. > > Yes, that's right. No changes other that those related to renaming and > documenting the property as requested in the CSR. > > > > > Don't forget to add a release note subtask for JDK-6913047 as it has a > > "release-note=yes" label. > > Will do. > > > > > I will re-run mach5 with this webrev.15 just to be safe. > > Thanks, > Martin.- From eric at metricspace.net Sat Jan 5 13:50:52 2019 From: eric at metricspace.net (Eric McCorkle) Date: Sat, 5 Jan 2019 08:50:52 -0500 Subject: New cryptographic primitives Message-ID: <0d7742cb-ca91-dfb5-1f37-c0847a121c56@metricspace.net> Hello, I've been out of the loop on OpenJDK development for some time, so I don't have an up-to-date knowledge on what cryptographic primitives have been added to the codebase recently, so forgive me if any of this is out-of-date. However, I understand there's been a move to add some more cryptographic primitives to the default JCA provider. I've spent the last year or so working on my own implementations of various primitives within the context of my own JCA provider implementation, and if there's enough interest, I'd be glad to contribute them back to OpenJDK. My project code can be found here: https://github.com/dsiproject/krypton Prime field arithmetic is here: https://github.com/dsiproject/primefields-java Elliptic curve primitive ops are here: https://github.com/dsiproject/safecurves-java What I have so far are the following: * ChaCha family stream ciphers * Salsa family stream ciphers * HC-256 stream cipher (another eSTREAM finalist) * SHA-3 (keccak) hash function[0] * BLAKE2b hash function * RipeMD-160 hash function Each implementation includes a test suite taken from test vectors found in RFCs or papers. I also have efficient, constant-time (in the context of side-channels) prime field operations over the following prime fields: * 2^130 - 5 * 2^221 - 3 * 2^222 - 117 * 2^251 - 9 * 2^255 - 19 * 2^382 - 105 * 2^383 - 187 * 2^414 - 17 * 2^511 - 187 * 2^521 - 1 These implementations are based on pseudo-mersenne prime arithmetic, which allows for implementations that avoid timing, branching, and memory side-channels. These implementations are thoroughly tested and documented. The field 2^130 - 5 corresponds to the Poly1305 MAC, and could be used in an implementation of that MAC (I've intended to do this, but haven't gotten to it yet). The remainder correspond to the following elliptic curves, all of which meet the criteria in the safecurves paper (see https://safecurves.cr.yp.to/): * M-221 * E-222 * Curve1174 * Curve25519 * E-382 * M-383 * Curve41417 * M-511 * E-521 I have implementations of elliptic curve group operations for these curves. The basic group operations are based on Edwards curve arithmetic (under the birationally-equivalent Edwards curves for M-221, Curve25519, M-383, and M-511). Group multiplication is accomplished using the single-coordinate Montgomery ladder (under the birationally-equivalent Montgomery curves for E-222, Curve1174, E-382, Curve41417, and E-521), followed by a y-coordinate recovery step. The single-coordinate ladder is also available, as this can be used to implement ECDH directly. These implementations are also free of timing, branching, and memory side-channels, and the implementations are also thoroughly tested and documented. Additionally, I provide implementations of the Elligator hash functions for all curves. For cofactor-4 curves (E-222, Curve1174, E-382, E-521), I provide subclasses that use Mike Hamburg's Decaf point compression technique[1, 2], which reduces the cofactor to 1. I do not have JCA providers for these curves, but it should be fairly straightforward to implement them (especially for ECDH, as I have a stress-test for that in the elliptic curve test suite) All of this is tested and working. I have plans to implement the following at some point, but haven't gotten to it: * Whirlpool hash * Skein hash (and the corresponding Threefish block cipher) * Poly1305 MAC * Twofish/Threefish block cipher (some work on threefish) * Serpent block cipher (some work on this) * SIDH, a post-quantum key agreement protocol * XMSS, a post-quantum stateful signing scheme * SPHINCS, a post-quantum stateless signing scheme * Some key derivation functions as hashes (particularly scrypt) So if there's any interest in the work I've done, I'd be happy to contribute any part of it back. Additionally, if there's interest in the work I've planned but haven't done, I'd be happy to collaborate with anyone to see it through. [0]: I have not implemented the weaker SHAKE variants, but that shouldn't be hard to do. [1]: Hamburg also describes a Montgomery ladder variant that works directly on Decaf-compressed points. I've got that mostly working, but there's a technique that's necessary to decode the final ladder, which the paper glosses over, which I haven't been able to get working in all cases. [2]: Henry de Valence has some work from the last year which describes a technique called Ristretto, which eliminates cofactors as high as 8. I've intended to try implementing this for the cofactor-8 curves (M-221, Curve25519, M-383, Curve41417, M-511) as soon as I get the Decaf formulas working. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From weijun.wang at oracle.com Mon Jan 7 00:56:58 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 7 Jan 2019 08:56:58 +0800 Subject: [12] RFR 8215694: keytool cannot generate RSASSA-PSS certificates In-Reply-To: References: <1F1ABA02-BD59-4CB8-8C0F-8F52E6B7CF10@oracle.com> <364147ca-fab3-b93c-91d1-bcbf85bbc8c2@oracle.com> Message-ID: <25B00D6E-6406-4B6D-90C8-B5F5B6D2A38E@oracle.com> Hi Xuelei, Webrev updated at https://cr.openjdk.java.net/~weijun/8215694/webrev.01 A new method AlgorithmId::getWithParameterSpec is added. I also cached 6 constants in AlgorithmId $PSSParamsHolder, although the static block inside it to generate the AlgorithmIds are a little heavy. We can extract the encoding lines inside PSSParameters::engineGetEncoded to create something like PSSParameterSpec::getEncoded(), but that will be an RFE. Thanks, Max > On Jan 3, 2019, at 11:27 PM, Xue-Lei Fan wrote: > > On 1/3/2019 2:10 AM, Weijun Wang wrote: >>> On Jan 2, 2019, at 11:56 PM, Xue-Lei Fan wrote: >>> >>> sigAlg.equalsIgnoreCase("RSASSA-PSS"): >>> Do you really want to ignore the case? I used to think that an algorithm name is case sensitive. >> getInstance(alg) is always case-insensitive. > Hm, I missed it. > >>> >>> Main.java:1445 minor, 4 more indent? >> Then it's longer than 80 chars. How about I un-indent lines 1443 and 1444? > maybe, use 4 white spaces? See also the following comment. > >>> >>> AlgorithmId.java:1073-1091: >>> I may prefer to use cached parameters (for both AlgorithmParameters and AlgorithmParameterSpec) for each size, for performance. >> OK for AlgorithmParameterSpec. Which AlgorithmParameters do you mean? The one in SignatureUtil? > Yes, replacing SignatureUtil.createAlgorithmParameters(). Then we don't need to worry about the indents above. > > Thanks, > Xuelei > >> Thanks, >> Max >>> >>> >>> Xuelei >>> >>> >>> On 12/21/2018 1:44 AM, Weijun Wang wrote: >>>> Please take a review at >>>> https://cr.openjdk.java.net/~weijun/8215694/webrev.00/ >>>> This bug reveals several issues: >>>> 1. Encoding of the RSASSA-PSS signature algorithm in PKCS10 and X509CertImpl. >>>> 2. The missing of setParameter() call for PKCS10 and X509CertImpl. >>>> 3. All keytool commands of -genkeypair, -certreq, -gencert, -selfcert are affected. >>>> 4. Wrong NULL after encoding of RSASSA-PSS key algorithm. >>>> Please confirm this is safe to be fixed in JDK 12. >>>> Thanks, >>>> Max From will.sargent at gmail.com Mon Jan 7 03:46:15 2019 From: will.sargent at gmail.com (Will Sargent) Date: Sun, 6 Jan 2019 19:46:15 -0800 Subject: JCA Provider Service Message-ID: Hi all, I've put together a small project that will autoload custom JCA providers, bypassing the need to append to the java.security.properties file (which is not well documented), allowing for some programmatic access, and adding some logging. https://github.com/tersesystems/jcaprovider It's published on bintray, and includes debugjsse, cloudfoundry, and bouncycastle as prebuilt provider implementations. Thanks, Will. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Jan 7 07:49:17 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 7 Jan 2019 07:49:17 +0000 Subject: JCA Provider Service In-Reply-To: References: Message-ID: On 07/01/2019 03:46, Will Sargent wrote: > Hi all, > > I've put together a small project that will autoload custom JCA > providers, bypassing the need to append to the > java.security.properties file (which is not well documented), allowing > for some programmatic access, and adding some logging. > Have you tried the service provider mechanism that was added in Java SE 9 to support loading JCE providers as services? -Alan From christoph.langer at sap.com Mon Jan 7 11:13:11 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 7 Jan 2019 11:13:11 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: Message-ID: <7b513a34196141f595cd5d194fb9d8a2@sap.com> Hi, I?ve amended the jdk.zipfs module documentation in src/jdk.zipfs/share/classes/module-info.java to document the new behavior (e.g. support of PosixFileAttributeView) as requested by Alan. I?ve also updated the CSR. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.4/ CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 Please review both, CSR and changeset and let me know if this is good now or what else needs to be addressed. Thanks and best regards, Christoph From: Volker Simonis Sent: Freitag, 21. Dezember 2018 17:34 To: Langer, Christoph Cc: Java Core Libs ; security-dev ; SHEN, XUEMING ; Alan Bateman ; nio-dev Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions Hi Christoph, thanks for updating the change. I think it is in a good state now and ready to go! Also the documentation in the CSR for this issue (https://bugs.openjdk.java.net/browse/JDK-8213082) is greatly appreciated and answers all the questions which have been raised so far. So if there are still any open questions I'd recommend that any potential reviewer consults the CSR at https://bugs.openjdk.java.net/browse/JDK-8213082 first. Thank you and best regards, Volker On Fri, Dec 21, 2018 at 3:31 PM Langer, Christoph > wrote: Hi all, here comes the updated webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.3/ I've rebased the change to the current state of the JDK depot. Thanks to Volker, the test has been enhanced and now also tests more copy operations (from zip file system to zip file system and from zip file system to default file system and back). The points below were also addressed: > ZipFileAttributeView.java > - can you please throw an AssertionError() for the default branch in > the switch expression in the "ZipFileAttributeView.name()". The default branch will return "basic". Looking at the code it should not be jumped to anyway. > ZipFileSystem.java > - please also put @Override annotations on the method implementations > from ZipFileAttributes (e.g. "compressedSize()", "crc()", etc...) and > a comment at the place where the implementation of the > "PosixFileAttributes" methods starts. Done, I also reordered the methods - first "basic" then "posix" then "zip". > ZipUtils.java > - just a question: isn't it possible to reuse > sun.nio.fs.UnixFileModeAttribute.toUnixMode() and the corresponding > constants from sun.nio.fs.UnixConstants instead of redefining them > here? You could export them from java.base to jdk.zipfs but the > problem is probably that at least sun.nio.fs.UnixConstants is a > generated class which only gets generated on Unix systems, right ? You've already answered yourself ?? These classes only exist on Unix type JDKs. > ZipFileAttributes.java > - it seems a little odd that you've added "setPermissions()" to > ZipFileAttributes. All the attribute classes (i.e. > BasicFileAttributes, PosixFileAttributes) have no setters. Isn't it > possible to implement "ZipFileAttributeView.setPermissions()" by > calling "path.setPermissions()" (as this is done in > "ZipFileAttributeView.setTimes()") and handle everything in > ZipFileSyste (as this is done with "setTimes()"). Good catch & thanks for providing the better implementation. I think this version is quite final now and thoroughly tested. I hope to get some valid reviews soon... Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.sargent at gmail.com Mon Jan 7 15:52:19 2019 From: will.sargent at gmail.com (Will Sargent) Date: Mon, 7 Jan 2019 07:52:19 -0800 Subject: JCA Provider Service In-Reply-To: References: Message-ID: I didn't know that a service provider mechanism was added in Java 9. The ServiceLoader pattern I'm using has been around since JDK 1.7 if that's what you mean: https://www.oracle.com/technetwork/articles/javase/extensible-137159.html I don't use Java 9, nor do I know any companies or individuals who use it. On Sun, Jan 6, 2019 at 11:49 PM Alan Bateman wrote: > On 07/01/2019 03:46, Will Sargent wrote: > > Hi all, > > > > I've put together a small project that will autoload custom JCA > > providers, bypassing the need to append to the > > java.security.properties file (which is not well documented), allowing > > for some programmatic access, and adding some logging. > > > Have you tried the service provider mechanism that was added in Java SE > 9 to support loading JCE providers as services? > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Jan 7 16:01:36 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 7 Jan 2019 16:01:36 +0000 Subject: JCA Provider Service In-Reply-To: References: Message-ID: <19d0bf1c-8742-641d-5e17-a7311005aadc@oracle.com> On 07/01/2019 15:52, Will Sargent wrote: > I didn't know that a service provider mechanism was added in Java 9.? > The ServiceLoader pattern I'm using has been around since JDK 1.7 if > that's what you mean: > > https://www.oracle.com/technetwork/articles/javase/extensible-137159.html > > I don't use Java 9, nor do I know any companies or individuals who use it. > Since JDK 9, you can deploy JCE providers on the class path or module path as service providers. This means JCE is using ServiceLoader to locate and load them. You may find this useful for what you are doing, once you get to a newer release. -Alan From will.sargent at gmail.com Mon Jan 7 17:16:49 2019 From: will.sargent at gmail.com (Will Sargent) Date: Mon, 7 Jan 2019 09:16:49 -0800 Subject: JCA Provider Service In-Reply-To: <19d0bf1c-8742-641d-5e17-a7311005aadc@oracle.com> References: <19d0bf1c-8742-641d-5e17-a7311005aadc@oracle.com> Message-ID: That's really fascinating, I had no idea. Looks like it's documented in Step 4: Create a Module Declaration for Your Provider with follow up in Step 8.1: Configure the Provider and Step 10: Run Your Test Programs . On Mon, Jan 7, 2019 at 8:01 AM Alan Bateman wrote: > On 07/01/2019 15:52, Will Sargent wrote: > > I didn't know that a service provider mechanism was added in Java 9. > > The ServiceLoader pattern I'm using has been around since JDK 1.7 if > > that's what you mean: > > > > > https://www.oracle.com/technetwork/articles/javase/extensible-137159.html > > > > I don't use Java 9, nor do I know any companies or individuals who use > it. > > > Since JDK 9, you can deploy JCE providers on the class path or module > path as service providers. This means JCE is using ServiceLoader to > locate and load them. You may find this useful for what you are doing, > once you get to a newer release. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Jan 7 19:09:44 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 7 Jan 2019 19:09:44 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <7b513a34196141f595cd5d194fb9d8a2@sap.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> Message-ID: On 07/01/2019 11:13, Langer, Christoph wrote: > > Hi, > > I?ve amended the jdk.zipfs module documentation in > src/jdk.zipfs/share/classes/module-info.java to document the new > behavior (e.g. support of PosixFileAttributeView) as requested by > Alan. I?ve also updated the CSR. > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.4/ > > > CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 > > > I think this is on the right path now. I'll start with the javadoc as that will take a few iterations and you'll need to get that agreed before finalizing the CSR. The proposed update starts out "Path objects residing in a zip file system ..." isn't quite right. I think you want start with something like "File systems created by the zip file system provider support the POSIX file attributes defined by the {@link PosixFileAttributeView}". I think the main issue that will need to be worked out is how the bulk read PosixFileAttributeView::readAttributes behaves when the zip entry doesn't have the external file attributes. UOE isn't right because UOE should be thrown or not thrown based on concrete/implementation type. One option is to throw IOE, another is to have it return a PosixFileAttributes that contains an empty permission set. The latter has the advantage that? you can pass the object to anything that excepts a BasicFileAttributes. Having set/getOwner throw UOE is okay. Once we have agreement on how the bulk read behaves then it should be easy to agree the javadoc change. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Mon Jan 7 19:26:46 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 7 Jan 2019 20:26:46 +0100 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> Message-ID: Hi Alan, thaks for looking at the javadoc/CSR. On Mon, Jan 7, 2019 at 8:10 PM Alan Bateman wrote: > > On 07/01/2019 11:13, Langer, Christoph wrote: > > Hi, > > > > I?ve amended the jdk.zipfs module documentation in src/jdk.zipfs/share/classes/module-info.java to document the new behavior (e.g. support of PosixFileAttributeView) as requested by Alan. I?ve also updated the CSR. > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.4/ > > CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 > > > I think this is on the right path now. I'll start with the javadoc as that will take a few iterations and you'll need to get that agreed before finalizing the CSR. > > The proposed update starts out "Path objects residing in a zip file system ..." isn't quite right. I think you want start with something like "File systems created by the zip file system provider support the POSIX file attributes defined by the {@link PosixFileAttributeView}". > > I think the main issue that will need to be worked out is how the bulk read PosixFileAttributeView::readAttributes behaves when the zip entry doesn't have the external file attributes. UOE isn't right because UOE should be thrown or not thrown based on concrete/implementation type. One option is to throw IOE, another is to have it return a PosixFileAttributes that contains an empty permission set. We considered this, but it is problematic because it is perfectly valid to have a file with external file attributes where none of the Posix attributes is actually set (i.e. an empty set of Posix files attributes). This wouldn't be distinguishable from the case where a file has no external file attributes. So it seems we have to resort to throwing an IOE? > The latter has the advantage that you can pass the object to anything that excepts a BasicFileAttributes. Having set/getOwner throw UOE is okay. Once we have agreement on how the bulk read behaves then it should be easy to agree the javadoc change. > > -Alan. From Alan.Bateman at oracle.com Mon Jan 7 20:46:07 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 7 Jan 2019 20:46:07 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> Message-ID: <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> On 07/01/2019 19:26, Volker Simonis wrote: > : > We considered this, but it is problematic because it is perfectly > valid to have a file with external file attributes where none of the > Posix attributes is actually set (i.e. an empty set of Posix files > attributes). This wouldn't be distinguishable from the case where a > file has no external file attributes. So it seems we have to resort to > throwing an IOE? > Maybe although it would be a bit awkward to deal with. The issues around this remind me a bit about mounting fat32 file systems on Linux or Unix systems where the fields in the stat structure are populated with default values. PosixFileAttributeView::readAttributes is? essentially the equivalent of a stat call. This might be something to look at for the file owner at least. -Alan From adam.petcher at oracle.com Mon Jan 7 23:34:25 2019 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 7 Jan 2019 18:34:25 -0500 Subject: New cryptographic primitives In-Reply-To: <0d7742cb-ca91-dfb5-1f37-c0847a121c56@metricspace.net> References: <0d7742cb-ca91-dfb5-1f37-c0847a121c56@metricspace.net> Message-ID: <6aba74a2-8f40-d1bf-8993-daa2f95198e6@oracle.com> Hi Eric, I don't immediately see anything in your list of implementations that we don't already have, and that we clearly need. But I would be interested in hearing from you or others about whether there is demand for these algorithms. The ones that are used in TLS 1.3 are valuable, but we already have implementations for all of them on your list. Your implementations may be faster than the ones in the JDK, in which case we may want to incorporate them (or at least the techniques used). If you benchmark your implementations and see an improvement, then we can figure out how to proceed. On 1/5/2019 8:50 AM, Eric McCorkle wrote: > Hello, > > I've been out of the loop on OpenJDK development for some time, so I > don't have an up-to-date knowledge on what cryptographic primitives have > been added to the codebase recently, so forgive me if any of this is > out-of-date. > > However, I understand there's been a move to add some more cryptographic > primitives to the default JCA provider. I've spent the last year or so > working on my own implementations of various primitives within the > context of my own JCA provider implementation, and if there's enough > interest, I'd be glad to contribute them back to OpenJDK. > > My project code can be found here: https://github.com/dsiproject/krypton > > Prime field arithmetic is here: > https://github.com/dsiproject/primefields-java > > Elliptic curve primitive ops are here: > https://github.com/dsiproject/safecurves-java > > > What I have so far are the following: > > * ChaCha family stream ciphers > * Salsa family stream ciphers > * HC-256 stream cipher (another eSTREAM finalist) > * SHA-3 (keccak) hash function[0] > * BLAKE2b hash function > * RipeMD-160 hash function > > Each implementation includes a test suite taken from test vectors found > in RFCs or papers. > > I also have efficient, constant-time (in the context of side-channels) > prime field operations over the following prime fields: > > * 2^130 - 5 > * 2^221 - 3 > * 2^222 - 117 > * 2^251 - 9 > * 2^255 - 19 > * 2^382 - 105 > * 2^383 - 187 > * 2^414 - 17 > * 2^511 - 187 > * 2^521 - 1 > > These implementations are based on pseudo-mersenne prime arithmetic, > which allows for implementations that avoid timing, branching, and > memory side-channels. These implementations are thoroughly tested and > documented. > > The field 2^130 - 5 corresponds to the Poly1305 MAC, and could be used > in an implementation of that MAC (I've intended to do this, but haven't > gotten to it yet). > > The remainder correspond to the following elliptic curves, all of which > meet the criteria in the safecurves paper (see > https://safecurves.cr.yp.to/): > > * M-221 > * E-222 > * Curve1174 > * Curve25519 > * E-382 > * M-383 > * Curve41417 > * M-511 > * E-521 > > I have implementations of elliptic curve group operations for these > curves. The basic group operations are based on Edwards curve > arithmetic (under the birationally-equivalent Edwards curves for M-221, > Curve25519, M-383, and M-511). Group multiplication is accomplished > using the single-coordinate Montgomery ladder (under the > birationally-equivalent Montgomery curves for E-222, Curve1174, E-382, > Curve41417, and E-521), followed by a y-coordinate recovery step. The > single-coordinate ladder is also available, as this can be used to > implement ECDH directly. > > These implementations are also free of timing, branching, and memory > side-channels, and the implementations are also thoroughly tested and > documented. > > Additionally, I provide implementations of the Elligator hash functions > for all curves. For cofactor-4 curves (E-222, Curve1174, E-382, E-521), > I provide subclasses that use Mike Hamburg's Decaf point compression > technique[1, 2], which reduces the cofactor to 1. > > I do not have JCA providers for these curves, but it should be fairly > straightforward to implement them (especially for ECDH, as I have a > stress-test for that in the elliptic curve test suite) > > > All of this is tested and working. I have plans to implement the > following at some point, but haven't gotten to it: > > * Whirlpool hash > * Skein hash (and the corresponding Threefish block cipher) > * Poly1305 MAC > * Twofish/Threefish block cipher (some work on threefish) > * Serpent block cipher (some work on this) > * SIDH, a post-quantum key agreement protocol > * XMSS, a post-quantum stateful signing scheme > * SPHINCS, a post-quantum stateless signing scheme > * Some key derivation functions as hashes (particularly scrypt) > > > So if there's any interest in the work I've done, I'd be happy to > contribute any part of it back. Additionally, if there's interest in > the work I've planned but haven't done, I'd be happy to collaborate with > anyone to see it through. > > > [0]: I have not implemented the weaker SHAKE variants, but that > shouldn't be hard to do. > > [1]: Hamburg also describes a Montgomery ladder variant that works > directly on Decaf-compressed points. I've got that mostly working, but > there's a technique that's necessary to decode the final ladder, which > the paper glosses over, which I haven't been able to get working in all > cases. > > [2]: Henry de Valence has some work from the last year which describes a > technique called Ristretto, which eliminates cofactors as high as 8. > I've intended to try implementing this for the cofactor-8 curves (M-221, > Curve25519, M-383, Curve41417, M-511) as soon as I get the Decaf > formulas working. > From christoph.langer at sap.com Tue Jan 8 08:27:07 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 8 Jan 2019 08:27:07 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> Message-ID: Hi Alan, Volker, thanks for bringing up these discussion points. I agree that we shall carefully revisit that. First of all, I'd like to point out that PosixFileAttributeView::readAttributes won't ever throw UOE with the proposed changes to zipfs. It should always return an object of type PosixFileAttributes which will be an incarnation of ZipFileSystem.Entry. The returned PosixFileAttributes(ZipFileSystem.Entry) object now implements 3 additional methods: owner(), group() and permissions(). I can see that UOE should only be thrown if something is not supported by an implementation at all. So it perfectly fits to owner() and group() because this is simply not implemented in zipfs (yet...). As for permissions, I then agree, UOE probably isn't the right thing to do because permissions will now be supported by zipfs. Still, we need to distinguish between the case where no permission information is present vs. an empty set of permissions that was explicitly stored. You brought up IOException as an alternative. But I think this is not really feasible for the following main reason: IOE is no RuntimeException, so it has to be declared for a method when it is thrown. PosixFileAttributes::permissions, however, does not declare IOE so far. And I don't think we can/want to modify the PosixFileAttributes interface for the sake of that zipfs implementation change. I think, we should look into using/returning null for "no permission information present". With that, the point is: What happens if we pass null to another PosixFileAttributeView::setPermissions implementation (or to Files::setPosixFilePermissions, which ends up there). For zipfs, with the proposed changeset, this would work perfectly fine. We translate the null value into (int)-1 for the "posixPerms" field of "Entry" and will then not set permission information in the zip file. But other places in the JDK that implement PosixFileAttributeView need some rework. Those are: src/java.base/unix/classes/sun/nio/fs/UnixFileAttributeViews.Posix src/java.base/unix/classes/sun/nio/fs/UnixSecureDirectoryStream.PosixFileAttributeViewImpl And we should amend the specs/doc for the following methods to define the handling of the null value as a noop: PosixFileAttributeView::setPermissions PosixFileAttributes::permissions Files::setPosixFilePermissions Files::getPosixFilePermissions In the implementation I can see that we modify the aforementioned places to handle null by translating it to (int)-1 in UnixFileModeAttribute::toUnixMode and then using this value as noop in 'setMode' resp. 'fchmod'. Do you think this is the right way to go? Should we maybe do the spec update of the permission methods in a separate change? Best regards Christoph > -----Original Message----- > From: Alan Bateman > Sent: Montag, 7. Januar 2019 21:46 > To: Volker Simonis > Cc: Langer, Christoph ; nio-dev dev at openjdk.java.net>; OpenJDK Dev list dev at openjdk.java.net>; Java Core Libs > Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions > > On 07/01/2019 19:26, Volker Simonis wrote: > > : > > We considered this, but it is problematic because it is perfectly > > valid to have a file with external file attributes where none of the > > Posix attributes is actually set (i.e. an empty set of Posix files > > attributes). This wouldn't be distinguishable from the case where a > > file has no external file attributes. So it seems we have to resort to > > throwing an IOE? > > > Maybe although it would be a bit awkward to deal with. The issues around > this remind me a bit about mounting fat32 file systems on Linux or Unix > systems where the fields in the stat structure are populated with > default values. PosixFileAttributeView::readAttributes is? essentially > the equivalent of a stat call. This might be something to look at for > the file owner at least. > > -Alan From valerie.peng at oracle.com Tue Jan 8 17:09:10 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 8 Jan 2019 09:09:10 -0800 Subject: RFR 6913047: SunPKCS11 memory leak In-Reply-To: References: <6b00e3d4-c795-f3e4-38ca-fa897f8680ea@oracle.com> <2a8e2986-631a-02f5-f419-e28c18232b33@oracle.com> <44a3e1c4-64ca-47bf-2061-4fe55fa7b827@oracle.com> <540e790d-1edf-732e-bb15-85537a6aa9c8@oracle.com> <566016d0-00ba-e938-693f-56948b9013da@oracle.com> <2ee1d1b8-91f5-f0c7-bd9f-31d7d20d472c@oracle.com> Message-ID: Hi Martin, The webrev.15 looks fine to me. The release note is mostly fine, I made some minor update to it. For the CSR, you should finalize it in order for it to be approved. The whole process should be explained in the pointer that I sent you earlier. I added myself to be the reviewer back in Dec already, so all you need to do now is to move the CSR to the "Finalized" state to signal that there is no more changes. In the mean time, which release are you targeting this to? You should update the "Fix Version" field of JDK-6913047 to keep various teams informed. Also, if this is for JDK 12, you need to watch out for the release schedule as RPD2 is fast approaching. After the CSR is approved, you can proceed with integration. However, given the extent of this change, please be really careful with potential code conflicts when merging. Double check everything to make sure you don't accidentally "undo" others' changes. Regards, Valerie On 1/4/2019 1:25 PM, Martin Balao wrote: > Hi Valerie, > > Is webrev.15 ready for approval? (CSR, patch) > > I've re-worked release notes a bit [0]. > > Thanks, > Martin.- > > -- > [0] - https://bugs.openjdk.java.net/browse/JDK-8215018 > > On Fri, Dec 7, 2018 at 11:17 AM Martin Balao wrote: >> Hi Valerie, >> >> On Thu, Dec 6, 2018 at 11:27 PM Valerie Peng >> wrote: >>> I suppose the changes in this update is just the system property >>> renaming? I looked at the relevant files and they look fine. If you made >>> more changes than this, please let me know and I will take a closer look >>> at them. >> Yes, that's right. No changes other that those related to renaming and >> documenting the property as requested in the CSR. >> >>> Don't forget to add a release note subtask for JDK-6913047 as it has a >>> "release-note=yes" label. >> Will do. >> >>> I will re-run mach5 with this webrev.15 just to be safe. >> Thanks, >> Martin.- From mbalao at redhat.com Tue Jan 8 19:35:14 2019 From: mbalao at redhat.com (Martin Balao) Date: Tue, 8 Jan 2019 16:35:14 -0300 Subject: RFR 6913047: SunPKCS11 memory leak In-Reply-To: References: <6b00e3d4-c795-f3e4-38ca-fa897f8680ea@oracle.com> <2a8e2986-631a-02f5-f419-e28c18232b33@oracle.com> <44a3e1c4-64ca-47bf-2061-4fe55fa7b827@oracle.com> <540e790d-1edf-732e-bb15-85537a6aa9c8@oracle.com> <566016d0-00ba-e938-693f-56948b9013da@oracle.com> <2ee1d1b8-91f5-f0c7-bd9f-31d7d20d472c@oracle.com> Message-ID: Hi Valerie, Thanks. I've moved the CSR to Finalized and will now wait for approval. Hope it is approved soon so I can integrate to baseline. I'll target JDK-13. Kind regards, Martin.- On Tue, Jan 8, 2019 at 2:11 PM Valerie Peng wrote: > > Hi Martin, > > The webrev.15 looks fine to me. The release note is mostly fine, I made > some minor update to it. > > For the CSR, you should finalize it in order for it to be approved. The > whole process should be explained in the pointer that I sent you > earlier. I added myself to be the reviewer back in Dec already, so all > you need to do now is to move the CSR to the "Finalized" state to signal > that there is no more changes. > > In the mean time, which release are you targeting this to? You should > update the "Fix Version" field of JDK-6913047 to keep various teams > informed. Also, if this is for JDK 12, you need to watch out for the > release schedule as RPD2 is fast approaching. > > After the CSR is approved, you can proceed with integration. However, > given the extent of this change, please be really careful with potential > code conflicts when merging. Double check everything to make sure you > don't accidentally "undo" others' changes. > > Regards, > > Valerie > > On 1/4/2019 1:25 PM, Martin Balao wrote: > > Hi Valerie, > > > > Is webrev.15 ready for approval? (CSR, patch) > > > > I've re-worked release notes a bit [0]. > > > > Thanks, > > Martin.- > > > > -- > > [0] - https://bugs.openjdk.java.net/browse/JDK-8215018 > > > > On Fri, Dec 7, 2018 at 11:17 AM Martin Balao wrote: > >> Hi Valerie, > >> > >> On Thu, Dec 6, 2018 at 11:27 PM Valerie Peng > >> wrote: > >>> I suppose the changes in this update is just the system property > >>> renaming? I looked at the relevant files and they look fine. If you made > >>> more changes than this, please let me know and I will take a closer look > >>> at them. > >> Yes, that's right. No changes other that those related to renaming and > >> documenting the property as requested in the CSR. > >> > >>> Don't forget to add a release note subtask for JDK-6913047 as it has a > >>> "release-note=yes" label. > >> Will do. > >> > >>> I will re-run mach5 with this webrev.15 just to be safe. > >> Thanks, > >> Martin.- From xuelei.fan at oracle.com Tue Jan 8 23:00:15 2019 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Tue, 8 Jan 2019 15:00:15 -0800 Subject: Code Review Request, JDK-8214418 HttpClient falls in running with 100% cpu usage after an error signalled on channel In-Reply-To: <9e7cd5a9-e236-1a3d-3045-770d8e7096bb@oracle.com> References: <9e7cd5a9-e236-1a3d-3045-770d8e7096bb@oracle.com> Message-ID: ping ... Xuelei On 12/22/2018 9:20 AM, Xue-Lei Fan wrote: > Hi, > > Could I get the update reviewed? > ?? http://cr.openjdk.java.net/~xuelei/8214418/webrev.00/ > > The reproducing testing case passed with the update. > > The issue is caused by the handshake status "NEED_WRAP" while the > connection is half-closed. An application may just call wrap() when the > handshake status is "NEED_WRAP". For compatibility, I changed the > handshake status from NEED_WRAP back to NOT_HANDSHAKING for inbound > half-closed connection.? An application can use > SSLEngine.isOutboundDone() for the determination if SSLEngine.wrap() > should be called. > > Thanks, > Xuelei > > From chris.hegarty at oracle.com Wed Jan 9 14:10:58 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 9 Jan 2019 14:10:58 +0000 Subject: Code Review Request, JDK-8214418 HttpClient falls in running with 100% cpu usage after an error signalled on channel In-Reply-To: References: <9e7cd5a9-e236-1a3d-3045-770d8e7096bb@oracle.com> Message-ID: <0a89c201-16d5-b66d-a2fb-64a307f1e221@oracle.com> Xuelei, Is it possible to update the synopsis of this bug to better reflect the underlying issue ( rather than one particular symptom )? Also, it is possible to construct a small, non-HTTP related, targeted test that verifies the fix? -Chris. On 08/01/2019 23:00, Xue-Lei Fan wrote: > ping ... > > Xuelei > > On 12/22/2018 9:20 AM, Xue-Lei Fan wrote: >> Hi, >> >> Could I get the update reviewed? >> ??? http://cr.openjdk.java.net/~xuelei/8214418/webrev.00/ >> >> The reproducing testing case passed with the update. >> >> The issue is caused by the handshake status "NEED_WRAP" while the >> connection is half-closed. An application may just call wrap() when >> the handshake status is "NEED_WRAP". For compatibility, I changed the >> handshake status from NEED_WRAP back to NOT_HANDSHAKING for inbound >> half-closed connection.? An application can use >> SSLEngine.isOutboundDone() for the determination if SSLEngine.wrap() >> should be called. >> >> Thanks, >> Xuelei >> >> From weijun.wang at oracle.com Wed Jan 9 14:59:18 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 9 Jan 2019 22:59:18 +0800 Subject: RFR 8215776: Keytool importkeystore may mix up certificate chain entries when DNs conflict Message-ID: <87E0531E-F7CE-4F32-86B7-4A3F3C1B842F@oracle.com> Please take a review at https://cr.openjdk.java.net/~weijun/8215776/webrev.00/ PKCS12KeyStore now can find certificate issuers more precisely using SubjectKeyIdentifier and AuthorityKeyIdentifier. I thought about using CertPath builder or checking signatures but those changes are too much. Thanks, Max From xuelei.fan at oracle.com Wed Jan 9 17:00:16 2019 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Wed, 9 Jan 2019 09:00:16 -0800 Subject: Code Review Request, JDK-8214418 half-closed SSLEnigne status may cause application dead loop In-Reply-To: <0a89c201-16d5-b66d-a2fb-64a307f1e221@oracle.com> References: <9e7cd5a9-e236-1a3d-3045-770d8e7096bb@oracle.com> <0a89c201-16d5-b66d-a2fb-64a307f1e221@oracle.com> Message-ID: On 1/9/2019 6:10 AM, Chris Hegarty wrote: > Xuelei, > > Is it possible to update the synopsis of this bug to better > reflect the underlying issue ( rather than one particular > symptom )? > Updated. > Also, it is possible to construct a small, non-HTTP related, > targeted test that verifies the fix? > There was an test update that covered the fix. Thanks, Xuelei > -Chris. > > On 08/01/2019 23:00, Xue-Lei Fan wrote: >> ping ... >> >> Xuelei >> >> On 12/22/2018 9:20 AM, Xue-Lei Fan wrote: >>> Hi, >>> >>> Could I get the update reviewed? >>> ??? http://cr.openjdk.java.net/~xuelei/8214418/webrev.00/ >>> >>> The reproducing testing case passed with the update. >>> >>> The issue is caused by the handshake status "NEED_WRAP" while the >>> connection is half-closed. An application may just call wrap() when >>> the handshake status is "NEED_WRAP". For compatibility, I changed the >>> handshake status from NEED_WRAP back to NOT_HANDSHAKING for inbound >>> half-closed connection.? An application can use >>> SSLEngine.isOutboundDone() for the determination if SSLEngine.wrap() >>> should be called. >>> >>> Thanks, >>> Xuelei >>> >>> From jamil.j.nimeh at oracle.com Wed Jan 9 18:38:24 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 9 Jan 2019 10:38:24 -0800 Subject: Code Review Request, JDK-8214418 HttpClient falls in running with 100% cpu usage after an error signalled on channel In-Reply-To: References: <9e7cd5a9-e236-1a3d-3045-770d8e7096bb@oracle.com> Message-ID: <19539781-bc02-c896-c348-9b5e3133cc66@oracle.com> Code changes look good to me. --Jamil On 1/8/2019 3:00 PM, Xue-Lei Fan wrote: > ping ... > > Xuelei > > On 12/22/2018 9:20 AM, Xue-Lei Fan wrote: >> Hi, >> >> Could I get the update reviewed? >> ??? http://cr.openjdk.java.net/~xuelei/8214418/webrev.00/ >> >> The reproducing testing case passed with the update. >> >> The issue is caused by the handshake status "NEED_WRAP" while the >> connection is half-closed. An application may just call wrap() when >> the handshake status is "NEED_WRAP". For compatibility, I changed the >> handshake status from NEED_WRAP back to NOT_HANDSHAKING for inbound >> half-closed connection.? An application can use >> SSLEngine.isOutboundDone() for the determination if SSLEngine.wrap() >> should be called. >> >> Thanks, >> Xuelei >> >> From daniel.fuchs at oracle.com Wed Jan 9 18:58:12 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 9 Jan 2019 18:58:12 +0000 Subject: Code Review Request, JDK-8214418 HttpClient falls in running with 100% cpu usage after an error signalled on channel In-Reply-To: <9e7cd5a9-e236-1a3d-3045-770d8e7096bb@oracle.com> References: <9e7cd5a9-e236-1a3d-3045-770d8e7096bb@oracle.com> Message-ID: <903c10ca-c2ec-9743-f2ff-4919c9bfa5e3@oracle.com> Hi Xuelei, On 22/12/2018 17:20, Xue-Lei Fan wrote: > The issue is caused by the handshake status "NEED_WRAP" while the > connection is half-closed. An application may just call wrap() when the > handshake status is "NEED_WRAP". For compatibility, I changed the > handshake status from NEED_WRAP back to NOT_HANDSHAKING for inbound > half-closed connection.? An application can use > SSLEngine.isOutboundDone() for the determination if SSLEngine.wrap() > should be called. For clarification: the logic for the application would be to call SSLEngine.isOutboundDone(), and if that is false, to call SSLEngine.wrap() in order to trigger the sending of the close notify response. Is my understanding correct? best regards, -- daniel From weijun.wang at oracle.com Thu Jan 10 02:27:10 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 10 Jan 2019 10:27:10 +0800 Subject: [12] RFR 8215694: keytool cannot generate RSASSA-PSS certificates In-Reply-To: <25B00D6E-6406-4B6D-90C8-B5F5B6D2A38E@oracle.com> References: <1F1ABA02-BD59-4CB8-8C0F-8F52E6B7CF10@oracle.com> <364147ca-fab3-b93c-91d1-bcbf85bbc8c2@oracle.com> <25B00D6E-6406-4B6D-90C8-B5F5B6D2A38E@oracle.com> Message-ID: Webrev updated again at https://cr.openjdk.java.net/~weijun/8215694/webrev.02 The major change this time is in PSSParameters.java. Instead of containing fields for the components of a PSSParameterSpec, it now contains the PSSParameterSpec itself directly. A new public static getEncoded() method is added so it can be called in AlgorithmId.java. The new getEncoded() method only writes non-default values into the encoding which conforms to the DER rule. I haven't enforced the same check on the read side (i.e. reject the input if a default value is encoded) for interoperability. Thanks, Max > On Jan 7, 2019, at 8:56 AM, Weijun Wang wrote: > > Hi Xuelei, > > Webrev updated at > > https://cr.openjdk.java.net/~weijun/8215694/webrev.01 > > A new method AlgorithmId::getWithParameterSpec is added. I also cached 6 constants in AlgorithmId $PSSParamsHolder, although the static block inside it to generate the AlgorithmIds are a little heavy. We can extract the encoding lines inside PSSParameters::engineGetEncoded to create something like PSSParameterSpec::getEncoded(), but that will be an RFE. > > Thanks, > Max > >> On Jan 3, 2019, at 11:27 PM, Xue-Lei Fan wrote: >> >> On 1/3/2019 2:10 AM, Weijun Wang wrote: >>>> On Jan 2, 2019, at 11:56 PM, Xue-Lei Fan wrote: >>>> >>>> sigAlg.equalsIgnoreCase("RSASSA-PSS"): >>>> Do you really want to ignore the case? I used to think that an algorithm name is case sensitive. >>> getInstance(alg) is always case-insensitive. >> Hm, I missed it. >> >>>> >>>> Main.java:1445 minor, 4 more indent? >>> Then it's longer than 80 chars. How about I un-indent lines 1443 and 1444? >> maybe, use 4 white spaces? See also the following comment. >> >>>> >>>> AlgorithmId.java:1073-1091: >>>> I may prefer to use cached parameters (for both AlgorithmParameters and AlgorithmParameterSpec) for each size, for performance. >>> OK for AlgorithmParameterSpec. Which AlgorithmParameters do you mean? The one in SignatureUtil? >> Yes, replacing SignatureUtil.createAlgorithmParameters(). Then we don't need to worry about the indents above. >> >> Thanks, >> Xuelei >> >>> Thanks, >>> Max >>>> >>>> >>>> Xuelei >>>> >>>> >>>> On 12/21/2018 1:44 AM, Weijun Wang wrote: >>>>> Please take a review at >>>>> https://cr.openjdk.java.net/~weijun/8215694/webrev.00/ >>>>> This bug reveals several issues: >>>>> 1. Encoding of the RSASSA-PSS signature algorithm in PKCS10 and X509CertImpl. >>>>> 2. The missing of setParameter() call for PKCS10 and X509CertImpl. >>>>> 3. All keytool commands of -genkeypair, -certreq, -gencert, -selfcert are affected. >>>>> 4. Wrong NULL after encoding of RSASSA-PSS key algorithm. >>>>> Please confirm this is safe to be fixed in JDK 12. >>>>> Thanks, >>>>> Max > From andrew_m_leonard at uk.ibm.com Thu Jan 10 09:43:10 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 10 Jan 2019 09:43:10 +0000 Subject: Is this a "bug"? =>JDK-8206925: Support the "certificate_authorities" extension Message-ID: https://bugs.openjdk.java.net/browse/JDK-8206925 Isn't this actually "required" by TLS 1.3? See https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.2.4 There's a known typo in https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.4.2.2 which from this comment: https://www.ietf.org/mail-archive/web/tls/current/msg23612.html indicates section 4.4.2.2 was a typo and "certificate_authorities" should be used instead of "trusted_ca_keys" Should JDK-8206925 be a "bug"? Thoughts? Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Fri Jan 11 01:26:43 2019 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Thu, 10 Jan 2019 17:26:43 -0800 Subject: Code Review Request, JDK-8214418 HttpClient falls in running with 100% cpu usage after an error signalled on channel In-Reply-To: <903c10ca-c2ec-9743-f2ff-4919c9bfa5e3@oracle.com> References: <9e7cd5a9-e236-1a3d-3045-770d8e7096bb@oracle.com> <903c10ca-c2ec-9743-f2ff-4919c9bfa5e3@oracle.com> Message-ID: On 1/9/2019 10:58 AM, Daniel Fuchs wrote: > Hi Xuelei, > > On 22/12/2018 17:20, Xue-Lei Fan wrote: >> The issue is caused by the handshake status "NEED_WRAP" while the >> connection is half-closed. An application may just call wrap() when >> the handshake status is "NEED_WRAP". For compatibility, I changed the >> handshake status from NEED_WRAP back to NOT_HANDSHAKING for inbound >> half-closed connection.? An application can use >> SSLEngine.isOutboundDone() for the determination if SSLEngine.wrap() >> should be called. > > For clarification: the logic for the application would be to call > SSLEngine.isOutboundDone(), and if that is false, to call > SSLEngine.wrap() in order to trigger the sending of the close notify > response. Is my understanding correct? > Yes. Thanks, Xuelei From weijun.wang at oracle.com Fri Jan 11 11:21:19 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 11 Jan 2019 19:21:19 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <4cf4a509-d155-e64c-dbb1-60b054c1c079@oracle.com> References: <4cf4a509-d155-e64c-dbb1-60b054c1c079@oracle.com> Message-ID: <343165D3-C2FB-4CD7-8C29-F3B659A1F8B4@oracle.com> Hi Valerie, Thanks for the feedback. Most accepted. Some comments below inline. I'll read Nico's feedback next and then upload a new webrev. > On Dec 20, 2018, at 3:51 AM, Valerie Peng wrote: > > Hi Max, > > Here are more comments/questions on : > > I am a bit unclear on the handling of the gss qop and MS qop. There are a few places where you seem to treat them as the same thing. But there are also cases where they seem unrelated as you didn't set one using the other and vice versa. > For all new/malloc calls, check for null return value before proceeding further. > > For gss APIs whose arguments are marked const, can we also do that here? I think it's clearer and helps code readability. > > Below are function-specific comments. > > - SecondsUntil: naming seems inconsistent, should start with lower case? Yes. > Based on the MS doc that I found https://msdn.microsoft.com/en-us/library/ms724284(v=VS.85).aspx, TimeStamp is same as FILETIME which you then copy the two fields into a ULARGE_INTEGER to do the 64-bit arithmetic, but through out the code, you seems to treat ULARGE_INTEGER and FILETIME as interchangeable and directly access the QuadPart field. MS doc has "Do not cast a pointer to a FILETIME structure to either a ULARGE_INTEGER* or __int64* value because it can cause alignment faults on 64-bit Windows." But I haven't casted a pointer like the doc says. Both structs have a QuadPart and I am just using it. In fact, I declare a new variable named uiLocal and assign the fields of nowLocal to it, and not just "uiLocal = (ULARGE_INTEGER*)&nowLocal". > In addition, the comment about AcquireCredentialsHandle may be incomplete, as gss_context_time also uses this method. The comment is about when called by AcquireCredentialsHandle the return value is strange (see https://stackoverflow.com/q/11028798/1061575). When called by gss_context_time, it's fine. I decide not to call it at all for AcquireCredentialsHandle and use the end time in the TGT as the expiry time of the credential. > -1 is returned if the FileTimeToLocalFileTime() call failed. I should check on it. > Also it seems that this method assumes that the passed-in "time" is always beyond the current time (line 291 - 296) which may not always be true? It's mainly for checking the strangeness of AcquireCredentialsHandle. Since I won't use this method for AcquireCredentialsHandle, I'll remove the lines. > > - gss_context_time: Shouldn't this method also check the tsExpiry value and return the GSS_S_CONTEXT_EXPIRED error code if applicable? Also the time_rec should be 0 if context has already expired. Yes. > > - gss_wrap_size_limit: based on the MS doc example: https://docs.microsoft.com/en-us/windows/desktop/secauthn/encrypting-a-message, it looks like the value is "cbMaximumMessage" of SecPkgContext_StreamSizes. Where is the documentation for the context_handle and its cbMaxMessage field? SecPkgContext_StreamSizes is only for Schannel (TLS). Kerberos uses SECPKG_ATTR_SIZES and I found out the SecPkgContext_Sizes cbMaxToken is the same as that in PSecPkgInfo. But I do realize that it should depend on input size, and I should be able to calculate it using the same logic to calculate output token size in gss_wrap. I tried wrapping 100K bytes and it works but the cbMaxToken is only 48K, so it seems this cbMaxToken value has nothing to with wrap tokens. > > - gss_get_mic: Some places you use SEC _SUCCESS macro and some plain if-else block. What is the criteria? If I only want to check success and failure, a SEC_SUCCESS is needed. Sometimes I also need to know additional information, like SEC_I_COMPLETE_NEEDED, SEC_E_OUT_OF_SEQUENCE. > In the SEC_SUCCESS macro, it's clearer to use SEC_E_OK instead of 0? OK. > Are we sure that the context handle already has the cbMaxSignature value? I saw that you make this call inside gss_init_sec_context() when the context is established. But do we need to handle the case that a half-established context is passed in? Should not crash even if user does that, right? I tried calling it at SEC_I_CONTINUE_NEEDED (mutual auth 1st call). All sizes are zero. This is enough to avoid a crash. > - gss_verify_mic: qop_state is optional and may be null. You should check the value before dereferencing it. Line 1262, should be SECBUFFER_VERSION instead of 0? Should we also check qop_state? Yes. > > - gss_wrap: Line 1347, since the order of data is 0-1-2, why the length addition is ordered 1-0-2? Seems more natural to use the same order. Move the assignment of conf_state (line 1329) after the if-block (line 1331). In addition, conf_state is optional and may be null. You should check the value before dereferencing it. Fixed. > Will continue reviewing the rest. > Thanks, > Valerie > > > > On 12/12/2018 2:20 PM, Valerie Peng wrote: >> Hi Max, >> >> >> >> - the DER related code is very hard to read... Would be nice to use constants/enum for commonly used tag or use some method to construct them. I've tried to add more comments. The numbers are not used much and defining them seems not worth it. >> - line 449, I think you mean to use "c" instead of "cred_handle" Yes. >> >> - gss_unwrap: add "const" to the 2nd and 3rd arguments? Isn't variable naming convention starts with lower case? the argument qop_state may be non-null but is not set? I've discussed with Nico on the const thing. I'll think more about it. Maybe I'll create a copy of gssapi.h for this library that uses the new const typedefs. Do you agree to modify the gssapi.h in the native bridge? I copied the the variable names from MSDN examples. Modified. I'll set qop_state. Maybe I thought it was useless. >> >> - gss_indicate_mechs: the SSPI docs that I found mentioned that you need to call FreeContextBuffer on pkgInfo after calling QuerySecurityPackageInfo(). Local variable "minor" not used and can be removed? Yes, and yes. >> - gss_inquire_names_for_mech: why does the PP output has "IMPLEMENTED" wording, other methods do not. Is this intentional? No. I added IMPLEMENTED and UNIMPLEMENTED at the beginning and modify them one by one. I missed this one. >> - gss_create_empty_oid_set: do we need to check the specified oid_set for existing content and free if not-empty before wiping it out? This is called by a few other gss api methods also, it may be better to defend against user errors. I dare not do that. The pointer might not be not been initialized at all. For example, in the newGSSOIDSet() function in NativeUtil.c. >> - gss_add_oid_set_member: add "const" to the 2nd argument? >> >> - gss_release_buffer: maybe set buffer->length = 0 outside the if-block. Do we need to check for GSS_C_NO_BUFFER in addition to null? Yes, and yes. >> >> - gss_display_status: add "const" to the 4th argument? As for the impl, I have a question, this particular method is for displaying text output for gssapi error codes, but the FormatMessage() call takes window specific message id. Are they the same? Yes. The SEC_SUCCESS macro always stores the windows error id into minor_status, and gss_display_status will return a readable message. Thanks, Max >> I am still going through the rest of sspi.cpp, but thought that I will send you what I have first. >> Good that you have this targeted to 13 as there is almost no time left for RFEs to get into JDK12. >> Thanks, >> Valerie >> >> >> On 11/19/2018 5:56 PM, Weijun Wang wrote: >>> Please take a review at >>> >>> >>> https://cr.openjdk.java.net/~weijun/6722928/webrev.01/ >>> >>> >>> We ported [1] the native GSS bridge to Windows in JDK 11, but user still have to download and install a native GSS-API library. This code change provides a native GSS-API library inside JDK that can be used without setting the "sun.security.jgss.lib" system property. It is based on Windows SSPI and now only supports the client side using the default credentials. >>> >>> No regression tests included. A Windows Active Directory server is needed. >>> >>> Thanks >>> Max >>> >>> [1] >>> https://bugs.openjdk.java.net/browse/JDK-8200468 From daniel.fuchs at oracle.com Fri Jan 11 11:45:44 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 11 Jan 2019 11:45:44 +0000 Subject: Code Review Request, JDK-8214418 HttpClient falls in running with 100% cpu usage after an error signalled on channel In-Reply-To: <9e7cd5a9-e236-1a3d-3045-770d8e7096bb@oracle.com> References: <9e7cd5a9-e236-1a3d-3045-770d8e7096bb@oracle.com> Message-ID: Hi Xuelei, This is not my area of expertise - so I'm going to rephrase what I understand (which may be wrong): SSLEngineImpl.java: This change makes sure that the SSLEngineResult::getStatus() returns Status.CLOSED when closure has been initiated, even if the engine is only half-closed at that time. This allows the application to complete the closure by looking at the state of the inbound/outbound. TransportContext.java: This change makes sure that the appropriate HandshakeStatus is returned to allow the completion of the closure: reading/sending the closure acknowledgement. If my understanding is correct - then I think this change is good. As far as I can see this is exactly what we are expecting in the java.net.http HttpClient SSLFlowDelegate, so that looks good to me! As Chris mentioned, it would be good to have a deterministic test to verify the behavior. best regards, -- daniel On 22/12/2018 17:20, Xue-Lei Fan wrote: > Hi, > > Could I get the update reviewed? > ?? http://cr.openjdk.java.net/~xuelei/8214418/webrev.00/ > > The reproducing testing case passed with the update. > > The issue is caused by the handshake status "NEED_WRAP" while the > connection is half-closed. An application may just call wrap() when the > handshake status is "NEED_WRAP". For compatibility, I changed the > handshake status from NEED_WRAP back to NOT_HANDSHAKING for inbound > half-closed connection.? An application can use > SSLEngine.isOutboundDone() for the determination if SSLEngine.wrap() > should be called. > > Thanks, > Xuelei > > From christoph.langer at sap.com Sat Jan 12 13:02:17 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sat, 12 Jan 2019 13:02:17 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> Message-ID: <5d28b0715d2041ff892a3c44e024f120@sap.com> Hi Alan, as I did not hear back from you I continued to work on the POSIX file permission support for zipfs and specified/implemented the value of 'null' for zip entries with no permission information associated (vs. UnsupportedOperationException). I updated the CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 And here is an updated webrev for the change: http://cr.openjdk.java.net/~clanger/webrevs/8213031.5/ I also changed the first part of the module-info documentation for jdk.zipfs, mentioning the URI scheme 'jar' and corrected the information about how the zip file system provider can be accessed and new zip filesystems can be created. Please kindly review this. Thank you and best regards Christoph > -----Original Message----- > From: Langer, Christoph > Sent: Dienstag, 8. Januar 2019 09:27 > To: 'Alan Bateman' ; Volker Simonis > > Cc: nio-dev ; OpenJDK Dev list dev at openjdk.java.net>; Java Core Libs > Subject: RE: RFR 8213031: (zipfs) Add support for POSIX file permissions > > Hi Alan, Volker, > > thanks for bringing up these discussion points. I agree that we shall carefully > revisit that. > > First of all, I'd like to point out that PosixFileAttributeView::readAttributes > won't ever throw UOE with the proposed changes to zipfs. It should always > return an object of type PosixFileAttributes which will be an incarnation of > ZipFileSystem.Entry. > > The returned PosixFileAttributes(ZipFileSystem.Entry) object now > implements 3 additional methods: owner(), group() and permissions(). I can > see that UOE should only be thrown if something is not supported by an > implementation at all. So it perfectly fits to owner() and group() because this > is simply not implemented in zipfs (yet...). As for permissions, I then agree, > UOE probably isn't the right thing to do because permissions will now be > supported by zipfs. > Still, we need to distinguish between the case where no permission > information is present vs. an empty set of permissions that was explicitly > stored. You brought up IOException as an alternative. But I think this is not > really feasible for the following main reason: IOE is no RuntimeException, so > it has to be declared for a method when it is thrown. > PosixFileAttributes::permissions, however, does not declare IOE so far. And I > don't think we can/want to modify the PosixFileAttributes interface for the > sake of that zipfs implementation change. > > I think, we should look into using/returning null for "no permission > information present". > > With that, the point is: What happens if we pass null to another > PosixFileAttributeView::setPermissions implementation (or to > Files::setPosixFilePermissions, which ends up there). For zipfs, with the > proposed changeset, this would work perfectly fine. We translate the null > value into (int)-1 for the "posixPerms" field of "Entry" and will then not set > permission information in the zip file. But other places in the JDK that > implement PosixFileAttributeView need some rework. Those are: > src/java.base/unix/classes/sun/nio/fs/UnixFileAttributeViews.Posix > src/java.base/unix/classes/sun/nio/fs/UnixSecureDirectoryStream.PosixFile > AttributeViewImpl > > And we should amend the specs/doc for the following methods to define > the handling of the null value as a noop: > PosixFileAttributeView::setPermissions > PosixFileAttributes::permissions > Files::setPosixFilePermissions > Files::getPosixFilePermissions > > In the implementation I can see that we modify the aforementioned places > to handle null by translating it to (int)-1 in > UnixFileModeAttribute::toUnixMode and then using this value as noop in > 'setMode' resp. 'fchmod'. > > Do you think this is the right way to go? Should we maybe do the spec > update of the permission methods in a separate change? > > Best regards > Christoph > > > -----Original Message----- > > From: Alan Bateman > > Sent: Montag, 7. Januar 2019 21:46 > > To: Volker Simonis > > Cc: Langer, Christoph ; nio-dev > dev at openjdk.java.net>; OpenJDK Dev list > dev at openjdk.java.net>; Java Core Libs > > Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions > > > > On 07/01/2019 19:26, Volker Simonis wrote: > > > : > > > We considered this, but it is problematic because it is perfectly > > > valid to have a file with external file attributes where none of the > > > Posix attributes is actually set (i.e. an empty set of Posix files > > > attributes). This wouldn't be distinguishable from the case where a > > > file has no external file attributes. So it seems we have to resort to > > > throwing an IOE? > > > > > Maybe although it would be a bit awkward to deal with. The issues around > > this remind me a bit about mounting fat32 file systems on Linux or Unix > > systems where the fields in the stat structure are populated with > > default values. PosixFileAttributeView::readAttributes is? essentially > > the equivalent of a stat call. This might be something to look at for > > the file owner at least. > > > > -Alan From lance.andersen at oracle.com Sat Jan 12 14:00:49 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Sat, 12 Jan 2019 09:00:49 -0500 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <5d28b0715d2041ff892a3c44e024f120@sap.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> Message-ID: <83AAC895-7B27-4874-B9A8-F08C89962F53@oracle.com> Hi Christoph > On Jan 12, 2019, at 8:02 AM, Langer, Christoph wrote: > > Hi Alan, > > as I did not hear back from you I continued to work on the POSIX file permission support for zipfs and specified/implemented the value of 'null' for zip entries with no permission information associated (vs. UnsupportedOperationException). > > I updated the CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 > And here is an updated webrev for the change: http://cr.openjdk.java.net/~clanger/webrevs/8213031.5/ > > I also changed the first part of the module-info documentation for jdk.zipfs, mentioning the URI scheme 'jar' and corrected the information about how the zip file system provider can be accessed and new zip filesystems can be > created. I think the above should be addressed via JDK-8182117 which I will be addressing and keep this focused on the POSIX file permission enhancements as I think it should be in its own CSR. Best Lance > > Please kindly review this. > > Thank you and best regards > Christoph > >> -----Original Message----- >> From: Langer, Christoph >> Sent: Dienstag, 8. Januar 2019 09:27 >> To: 'Alan Bateman' ; Volker Simonis >> >> Cc: nio-dev ; OpenJDK Dev list > dev at openjdk.java.net>; Java Core Libs >> Subject: RE: RFR 8213031: (zipfs) Add support for POSIX file permissions >> >> Hi Alan, Volker, >> >> thanks for bringing up these discussion points. I agree that we shall carefully >> revisit that. >> >> First of all, I'd like to point out that PosixFileAttributeView::readAttributes >> won't ever throw UOE with the proposed changes to zipfs. It should always >> return an object of type PosixFileAttributes which will be an incarnation of >> ZipFileSystem.Entry. >> >> The returned PosixFileAttributes(ZipFileSystem.Entry) object now >> implements 3 additional methods: owner(), group() and permissions(). I can >> see that UOE should only be thrown if something is not supported by an >> implementation at all. So it perfectly fits to owner() and group() because this >> is simply not implemented in zipfs (yet...). As for permissions, I then agree, >> UOE probably isn't the right thing to do because permissions will now be >> supported by zipfs. >> Still, we need to distinguish between the case where no permission >> information is present vs. an empty set of permissions that was explicitly >> stored. You brought up IOException as an alternative. But I think this is not >> really feasible for the following main reason: IOE is no RuntimeException, so >> it has to be declared for a method when it is thrown. >> PosixFileAttributes::permissions, however, does not declare IOE so far. And I >> don't think we can/want to modify the PosixFileAttributes interface for the >> sake of that zipfs implementation change. >> >> I think, we should look into using/returning null for "no permission >> information present". >> >> With that, the point is: What happens if we pass null to another >> PosixFileAttributeView::setPermissions implementation (or to >> Files::setPosixFilePermissions, which ends up there). For zipfs, with the >> proposed changeset, this would work perfectly fine. We translate the null >> value into (int)-1 for the "posixPerms" field of "Entry" and will then not set >> permission information in the zip file. But other places in the JDK that >> implement PosixFileAttributeView need some rework. Those are: >> src/java.base/unix/classes/sun/nio/fs/UnixFileAttributeViews.Posix >> src/java.base/unix/classes/sun/nio/fs/UnixSecureDirectoryStream.PosixFile >> AttributeViewImpl >> >> And we should amend the specs/doc for the following methods to define >> the handling of the null value as a noop: >> PosixFileAttributeView::setPermissions >> PosixFileAttributes::permissions >> Files::setPosixFilePermissions >> Files::getPosixFilePermissions >> >> In the implementation I can see that we modify the aforementioned places >> to handle null by translating it to (int)-1 in >> UnixFileModeAttribute::toUnixMode and then using this value as noop in >> 'setMode' resp. 'fchmod'. >> >> Do you think this is the right way to go? Should we maybe do the spec >> update of the permission methods in a separate change? >> >> Best regards >> Christoph >> >>> -----Original Message----- >>> From: Alan Bateman >>> Sent: Montag, 7. Januar 2019 21:46 >>> To: Volker Simonis >>> Cc: Langer, Christoph ; nio-dev >> dev at openjdk.java.net>; OpenJDK Dev list >> dev at openjdk.java.net>; Java Core Libs >>> Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions >>> >>> On 07/01/2019 19:26, Volker Simonis wrote: >>>> : >>>> We considered this, but it is problematic because it is perfectly >>>> valid to have a file with external file attributes where none of the >>>> Posix attributes is actually set (i.e. an empty set of Posix files >>>> attributes). This wouldn't be distinguishable from the case where a >>>> file has no external file attributes. So it seems we have to resort to >>>> throwing an IOE? >>>> >>> Maybe although it would be a bit awkward to deal with. The issues around >>> this remind me a bit about mounting fat32 file systems on Linux or Unix >>> systems where the fields in the stat structure are populated with >>> default values. PosixFileAttributeView::readAttributes is essentially >>> the equivalent of a stat call. This might be something to look at for >>> the file owner at least. >>> >>> -Alan Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From Alan.Bateman at oracle.com Sat Jan 12 14:00:40 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 12 Jan 2019 14:00:40 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <5d28b0715d2041ff892a3c44e024f120@sap.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> Message-ID: <220ab056-30d4-2d07-3a48-cad430500be1@oracle.com> On 12/01/2019 13:02, Langer, Christoph wrote: > Hi Alan, > > as I did not hear back from you I continued to work on the POSIX file permission support for zipfs and specified/implemented the value of 'null' for zip entries with no permission information associated (vs. UnsupportedOperationException). > > I will try to get time next week to reply to you on this. Part of the issue with your current approach is that it breaks PosixFileAttribtues. There are also issues trying to force the API to optionally support a subset of POSIX attributes on some zip entries and not on others. So several issues that will need consideration. -Alan From christoph.langer at sap.com Mon Jan 14 07:42:37 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 14 Jan 2019 07:42:37 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <83AAC895-7B27-4874-B9A8-F08C89962F53@oracle.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <83AAC895-7B27-4874-B9A8-F08C89962F53@oracle.com> Message-ID: Hi Lance, I was not aware of JDK-8182117 and by its description it does not fit exactly to the updates to jdk.zipfs module documentation that I propose. However, yes, it is probably a bit more natural to include that part in a potential patch for JDK-8182117. So, feel free to take this over into your work. Seeing how things are going with this POSIX permission topic, I?m sure you?ll be done with a patch for 8182117 much earlier than me ??. Best Christoph From: Lance Andersen Sent: Samstag, 12. Januar 2019 15:01 To: Langer, Christoph Cc: Alan Bateman ; nio-dev ; OpenJDK Dev list ; Java Core Libs Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions Hi Christoph On Jan 12, 2019, at 8:02 AM, Langer, Christoph > wrote: Hi Alan, as I did not hear back from you I continued to work on the POSIX file permission support for zipfs and specified/implemented the value of 'null' for zip entries with no permission information associated (vs. UnsupportedOperationException). I updated the CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 And here is an updated webrev for the change: http://cr.openjdk.java.net/~clanger/webrevs/8213031.5/ I also changed the first part of the module-info documentation for jdk.zipfs, mentioning the URI scheme 'jar' and corrected the information about how the zip file system provider can be accessed and new zip filesystems can be created. I think the above should be addressed via JDK-8182117 which I will be addressing and keep this focused on the POSIX file permission enhancements as I think it should be in its own CSR. Best Lance Please kindly review this. Thank you and best regards Christoph -----Original Message----- From: Langer, Christoph Sent: Dienstag, 8. Januar 2019 09:27 To: 'Alan Bateman' >; Volker Simonis > Cc: nio-dev >; OpenJDK Dev list >; Java Core Libs > Subject: RE: RFR 8213031: (zipfs) Add support for POSIX file permissions Hi Alan, Volker, thanks for bringing up these discussion points. I agree that we shall carefully revisit that. First of all, I'd like to point out that PosixFileAttributeView::readAttributes won't ever throw UOE with the proposed changes to zipfs. It should always return an object of type PosixFileAttributes which will be an incarnation of ZipFileSystem.Entry. The returned PosixFileAttributes(ZipFileSystem.Entry) object now implements 3 additional methods: owner(), group() and permissions(). I can see that UOE should only be thrown if something is not supported by an implementation at all. So it perfectly fits to owner() and group() because this is simply not implemented in zipfs (yet...). As for permissions, I then agree, UOE probably isn't the right thing to do because permissions will now be supported by zipfs. Still, we need to distinguish between the case where no permission information is present vs. an empty set of permissions that was explicitly stored. You brought up IOException as an alternative. But I think this is not really feasible for the following main reason: IOE is no RuntimeException, so it has to be declared for a method when it is thrown. PosixFileAttributes::permissions, however, does not declare IOE so far. And I don't think we can/want to modify the PosixFileAttributes interface for the sake of that zipfs implementation change. I think, we should look into using/returning null for "no permission information present". With that, the point is: What happens if we pass null to another PosixFileAttributeView::setPermissions implementation (or to Files::setPosixFilePermissions, which ends up there). For zipfs, with the proposed changeset, this would work perfectly fine. We translate the null value into (int)-1 for the "posixPerms" field of "Entry" and will then not set permission information in the zip file. But other places in the JDK that implement PosixFileAttributeView need some rework. Those are: src/java.base/unix/classes/sun/nio/fs/UnixFileAttributeViews.Posix src/java.base/unix/classes/sun/nio/fs/UnixSecureDirectoryStream.PosixFile AttributeViewImpl And we should amend the specs/doc for the following methods to define the handling of the null value as a noop: PosixFileAttributeView::setPermissions PosixFileAttributes::permissions Files::setPosixFilePermissions Files::getPosixFilePermissions In the implementation I can see that we modify the aforementioned places to handle null by translating it to (int)-1 in UnixFileModeAttribute::toUnixMode and then using this value as noop in 'setMode' resp. 'fchmod'. Do you think this is the right way to go? Should we maybe do the spec update of the permission methods in a separate change? Best regards Christoph -----Original Message----- From: Alan Bateman > Sent: Montag, 7. Januar 2019 21:46 To: Volker Simonis > Cc: Langer, Christoph >; nio-dev >; OpenJDK Dev list >; Java Core Libs > Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions On 07/01/2019 19:26, Volker Simonis wrote: : We considered this, but it is problematic because it is perfectly valid to have a file with external file attributes where none of the Posix attributes is actually set (i.e. an empty set of Posix files attributes). This wouldn't be distinguishable from the case where a file has no external file attributes. So it seems we have to resort to throwing an IOE? Maybe although it would be a bit awkward to deal with. The issues around this remind me a bit about mounting fat32 file systems on Linux or Unix systems where the fields in the stat structure are populated with default values. PosixFileAttributeView::readAttributes is essentially the equivalent of a stat call. This might be something to look at for the file owner at least. -Alan [cid:image001.gif at 01D4ABE5.198BA670] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 658 bytes Desc: image001.gif URL: From christoph.langer at sap.com Mon Jan 14 07:52:46 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 14 Jan 2019 07:52:46 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <220ab056-30d4-2d07-3a48-cad430500be1@oracle.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <220ab056-30d4-2d07-3a48-cad430500be1@oracle.com> Message-ID: Hi Alan, > I will try to get time next week to reply to you on this. Part of the > issue with your current approach is that it breaks PosixFileAttribtues. > There are also issues trying to force the API to optionally support a > subset of POSIX attributes on some zip entries and not on others. So > several issues that will need consideration. Thanks in advance for your work. Well, I can see that we could also support users/groups with zip files, which is also implemented in InfoZIP. Or we might add a Sub-Interface like PosixPermissionAttributes/PosixPermissionAttributesView. However, in any case, we have to find a way to deal with the optionality of any POSIX attributes in zip files. So, let's see what you come up with ?? /Christoph From Alan.Bateman at oracle.com Mon Jan 14 10:27:23 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Jan 2019 10:27:23 +0000 Subject: [12] RFR(S) 8216151: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.org.graalvm.compiler.debug In-Reply-To: <077fcff1-28fc-acbf-6a8b-c299978ae0a2@oracle.com> References: <077fcff1-28fc-acbf-6a8b-c299978ae0a2@oracle.com> Message-ID: On 13/01/2019 02:46, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8216151/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8216151 > > Have to update default.policy after changes in > jdk.internal.vm.compiler.management files done by JDK-8199755: "Update > Graal". > > Ran CheckAccessClassInPackagePermissions.java test. > cc'ing security-dev as that is where is the security policy file is maintained. One thing is double check is that code in jdk.internal.vm.compiler.management really needs to access members of classes in the listed packages. I ask because the module definition doesn't export some of these packages to jdk.internal.vm.compiler.management so they aren't accessible even when not running with a security manager. -Alan From vladimir.kozlov at oracle.com Mon Jan 14 17:39:10 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Jan 2019 09:39:10 -0800 Subject: [12] RFR(S) 8216151: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.org.graalvm.compiler.debug In-Reply-To: References: <077fcff1-28fc-acbf-6a8b-c299978ae0a2@oracle.com> Message-ID: Thank you, Alan On 1/14/19 2:27 AM, Alan Bateman wrote: > On 13/01/2019 02:46, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8216151/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8216151 >> >> Have to update default.policy after changes in jdk.internal.vm.compiler.management files done by JDK-8199755: "Update >> Graal". >> >> Ran CheckAccessClassInPackagePermissions.java test. >> > cc'ing security-dev as that is where is the security policy file is maintained. > > One thing is double check is that code in jdk.internal.vm.compiler.management really needs to access members of classes > in the listed packages. I ask because the module definition doesn't export some of these packages to > jdk.internal.vm.compiler.management so they aren't accessible even when not running with a security manager. I verified that all listed packages are used by compiler.management and I listed only needed in default.policy. I used CheckAccessClassInPackagePermissions.java test to find which permissions are needed. Thanks, Vladimir > > -Alan From mandy.chung at oracle.com Mon Jan 14 18:29:39 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 14 Jan 2019 10:29:39 -0800 Subject: [12] RFR(S) 8216151: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.org.graalvm.compiler.debug In-Reply-To: References: <077fcff1-28fc-acbf-6a8b-c299978ae0a2@oracle.com> Message-ID: On 1/14/19 9:39 AM, Vladimir Kozlov wrote: > Thank you, Alan > > On 1/14/19 2:27 AM, Alan Bateman wrote: >> On 13/01/2019 02:46, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/8216151/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8216151 >>> >>> Have to update default.policy after changes in >>> jdk.internal.vm.compiler.management files done by JDK-8199755: >>> "Update Graal". >>> >>> Ran CheckAccessClassInPackagePermissions.java test. >>> >> cc'ing security-dev as that is where is the security policy file is >> maintained. >> >> One thing is double check is that code in >> jdk.internal.vm.compiler.management really needs to access members of >> classes in the listed packages. I ask because the module definition >> doesn't export some of these packages to >> jdk.internal.vm.compiler.management so they aren't accessible even >> when not running with a security manager. > > I verified that all listed packages are used by compiler.management > and I listed only needed in default.policy. I used > CheckAccessClassInPackagePermissions.java test to find which > permissions are needed. > I reviewed the change and the list matches the list of qualified exports from jdk.internal.vm.compiler to jdk.internal.vm.compiler.management. The security team has been looking into removing the private VM call out to ClassLoader::checkPackageAccess.? When that's removed, we would not need to maintain these accessClassInPackage permission to access any new qualified exports. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Mon Jan 14 18:31:07 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Jan 2019 10:31:07 -0800 Subject: [12] RFR(S) 8216151: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.org.graalvm.compiler.debug In-Reply-To: References: <077fcff1-28fc-acbf-6a8b-c299978ae0a2@oracle.com> Message-ID: <2ad1f183-f3fd-eb0e-f56b-64c5746c6c08@oracle.com> Thank you Mandy for review. Vladimir On 1/14/19 10:29 AM, Mandy Chung wrote: > > > On 1/14/19 9:39 AM, Vladimir Kozlov wrote: >> Thank you, Alan >> >> On 1/14/19 2:27 AM, Alan Bateman wrote: >>> On 13/01/2019 02:46, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/8216151/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8216151 >>>> >>>> Have to update default.policy after changes in jdk.internal.vm.compiler.management files done by JDK-8199755: >>>> "Update Graal". >>>> >>>> Ran CheckAccessClassInPackagePermissions.java test. >>>> >>> cc'ing security-dev as that is where is the security policy file is maintained. >>> >>> One thing is double check is that code in jdk.internal.vm.compiler.management really needs to access members of >>> classes in the listed packages. I ask because the module definition doesn't export some of these packages to >>> jdk.internal.vm.compiler.management so they aren't accessible even when not running with a security manager. >> >> I verified that all listed packages are used by compiler.management and I listed only needed in default.policy. I used >> CheckAccessClassInPackagePermissions.java test to find which permissions are needed. >> > > I reviewed the change and the list matches the list of qualified exports from jdk.internal.vm.compiler to > jdk.internal.vm.compiler.management. > > The security team has been looking into removing the private VM call out to ClassLoader::checkPackageAccess.? When > that's removed, we would not need to maintain these accessClassInPackage permission to access any new qualified exports. > > Mandy From mbalao at redhat.com Mon Jan 14 18:49:13 2019 From: mbalao at redhat.com (Martin Balao) Date: Mon, 14 Jan 2019 15:49:13 -0300 Subject: RFR 8216597: SIGBUS in Java_sun_security_pkcs11_wrapper_PKCS11_getNativeKeyInfo after JDK-6913047 Message-ID: Hi, After integrating JDK-6913047 [0] [1], a bug affecting Solaris SPARC was found. See JDK-8216597 [2] for further details. This bug has been likely caused by an unaligned memory access. jdk-submit repo tests passed before integrating so it was not noticed. There are a few direct memory accesses when loading attribute values (obtained from the 1st query) to the info array buffer, pointed by nativeKeyInfoArrayRawCkAttributesPtr: (*(CK_ATTRIBUTE_PTR)nativeKeyInfoArrayRawCkAttributesPtr).type = (ckpAttributes+i)->type; (*(CK_ATTRIBUTE_PTR)nativeKeyInfoArrayRawCkAttributesPtr).ulValueLen = (ckpAttributes+i)->ulValueLen; (*(CK_ATTRIBUTE_PTR)nativeKeyInfoArrayRawCkAttributesPtr).pValue = nativeKeyInfoArrayRawDataPtr; (*(CK_ATTRIBUTE_PTR)nativeKeyInfoArrayRawCkAttributesPtr).pValue = 0; (*(CK_ATTRIBUTE_PTR)nativeKeyInfoArrayRawCkAttributesPtr).type = CKA_NETSCAPE_DB; There is also a direct read access: *(CK_BBOOL*)(((CK_ATTRIBUTE_PTR)(((CK_ATTRIBUTE_PTR)nativeKeyInfoArrayRawCkAttributes)+sensitiveAttributePosition))->pValue Whether or not these are 64-bit aligned depends on the value returned by GetByteArrayElements: if the buffer is not 8-bytes aligned (but 4), unaligned accesses would occur. This is unlikely though. Adding sizeof(unsigned long) to nativeKeyInfoArrayRawCkAttributesPtr first value should not cause issues because 1) sizeof(unsigned long) is 8 [3] and 2) CK_ATTRIBUTE alignment is 8 (larger member is a pointer). Looks to me that the problem is caused when reading the CK_BBOOL value. This is a pointer to the data side of the buffer and there are no alignment guarantees there at all: data is compacted (to save space). I cannot confirm because I'm unable to reproduce in my environment. However, and under the described hypothesis, I propose this patch: * http://cr.openjdk.java.net/~mbalao/webrevs/8216597/8216597.webrev.00/ * http://cr.openjdk.java.net/~mbalao/webrevs/8216597/8216597.webrev.00.zip Can someone try it? In case it fails again, I'd be grateful if someone can dump all the SPARC bytes of Java_sun_security_pkcs11_wrapper_PKCS11_getNativeKeyInfo function so I can see exactly what the instruction at 0x2e4 offset is (for the build without this patch). @David Holmes: even though wrappedKeySizeWrappedKeyArrayPtr may have an unaligned value, looks to me that it's not directly used to access memory but used through memcpy. Thanks, Martin.- -- [0] - https://bugs.openjdk.java.net/browse/JDK-6913047 [1] - http://hg.openjdk.java.net/jdk/jdk/rev/5170dc2bcf64 [2] - https://bugs.openjdk.java.net/browse/JDK-8216597 [3] - https://docs.oracle.com/cd/E18752_01/html/817-6223/chp-typeopexpr-2.html From david.holmes at oracle.com Tue Jan 15 01:47:57 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Jan 2019 11:47:57 +1000 Subject: RFR 8216597: SIGBUS in Java_sun_security_pkcs11_wrapper_PKCS11_getNativeKeyInfo after JDK-6913047 In-Reply-To: References: Message-ID: Hi Martin, I applied your patch and ran it through tier4 testing on sparc but it still exhibited the SIGBUS crashes. I can't help with the request to get a code dump sorry. David ----- PS. I don't follow security-dev. Thanks to Sean for the heads up. > Hi, > > After integrating JDK-6913047 [0] [1], a bug affecting Solaris SPARC was > found. See JDK-8216597 [2] for further details. > > This bug has been likely caused by an unaligned memory access. > jdk-submit repo tests passed before integrating so it was not noticed. > > There are a few direct memory accesses when loading attribute values > (obtained from the 1st query) to the info array buffer, pointed by > nativeKeyInfoArrayRawCkAttributesPtr: > > (*(CK_ATTRIBUTE_PTR)nativeKeyInfoArrayRawCkAttributesPtr).type = > (ckpAttributes+i)->type; > (*(CK_ATTRIBUTE_PTR)nativeKeyInfoArrayRawCkAttributesPtr).ulValueLen = > (ckpAttributes+i)->ulValueLen; > (*(CK_ATTRIBUTE_PTR)nativeKeyInfoArrayRawCkAttributesPtr).pValue = > nativeKeyInfoArrayRawDataPtr; > (*(CK_ATTRIBUTE_PTR)nativeKeyInfoArrayRawCkAttributesPtr).pValue = 0; > (*(CK_ATTRIBUTE_PTR)nativeKeyInfoArrayRawCkAttributesPtr).type = > CKA_NETSCAPE_DB; > > There is also a direct read access: > > *(CK_BBOOL*)(((CK_ATTRIBUTE_PTR)(((CK_ATTRIBUTE_PTR)nativeKeyInfoArrayRawCkAttributes)+sensitiveAttributePosition))->pValue > > Whether or not these are 64-bit aligned depends on the value returned by > GetByteArrayElements: if the buffer is not 8-bytes aligned (but 4), > unaligned accesses would occur. This is unlikely though. Adding > sizeof(unsigned long) to nativeKeyInfoArrayRawCkAttributesPtr first > value should not cause issues because 1) sizeof(unsigned long) is 8 [3] > and 2) CK_ATTRIBUTE alignment is 8 (larger member is a pointer). > > Looks to me that the problem is caused when reading the CK_BBOOL value. > This is a pointer to the data side of the buffer and there are no > alignment guarantees there at all: data is compacted (to save space). > > I cannot confirm because I'm unable to reproduce in my environment. > However, and under the described hypothesis, I propose this patch: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8216597/8216597.webrev.00/ > * http://cr.openjdk.java.net/~mbalao/webrevs/8216597/8216597.webrev.00.zip > > Can someone try it? > > In case it fails again, I'd be grateful if someone can dump all the > SPARC bytes of Java_sun_security_pkcs11_wrapper_PKCS11_getNativeKeyInfo > function so I can see exactly what the instruction at 0x2e4 offset is > (for the build without this patch). > > @David Holmes: even though wrappedKeySizeWrappedKeyArrayPtr may have an > unaligned value, looks to me that it's not directly used to access > memory but used through memcpy. > > Thanks, > Martin.- > > -- > [0] - https://bugs.openjdk.java.net/browse/JDK-6913047 > [1] - http://hg.openjdk.java.net/jdk/jdk/rev/5170dc2bcf64 > [2] - https://bugs.openjdk.java.net/browse/JDK-8216597 > [3] - > https://docs.oracle.com/cd/E18752_01/html/817-6223/chp-typeopexpr-2.html From andrew_m_leonard at uk.ibm.com Tue Jan 15 09:03:22 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 15 Jan 2019 09:03:22 +0000 Subject: Is TLS1.3 support missing the "certificate_authorities" extension? Message-ID: Re-posting this question.. Isn't the "certificate_authorities" extension mandatory for TLS1.3? https://bugs.openjdk.java.net/browse/JDK-8206925 See https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.2.4 There's a known typo in https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.4.2.2 which from this comment: https://www.ietf.org/mail-archive/web/tls/current/msg23612.html indicates section 4.4.2.2 was a typo and "certificate_authorities" should be used instead of "trusted_ca_keys" Should JDK-8206925 be a "bug"? Thoughts? Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Tue Jan 15 13:39:27 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 15 Jan 2019 08:39:27 -0500 Subject: Is TLS1.3 support missing the "certificate_authorities" extension? In-Reply-To: References: Message-ID: Hello, On 1/15/19 4:03 AM, Andrew Leonard wrote: > Re-posting this question.. > > Isn't the "certificate_authorities" extension mandatory for TLS1.3? The text in question says "SHOULD" and not "MUST" [1]. So while it is very desirable, I would not categorize this as a mandatory requirement. > > _https://bugs.openjdk.java.net/browse/JDK-8206925_ > > See _https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.2.4_ > There's a known typo in > _https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.4.2.2_ > which from this comment: > _https://www.ietf.org/mail-archive/web/tls/current/msg23612.html_ > indicates section 4.4.2.2 was a typo and "certificate_authorities" should > be used instead of "trusted_ca_keys" Note that your links above are referencing the Internet Draft. This has been corrected in the RFC: https://tools.ietf.org/html/rfc8446#section-4.4.2.2 > Should JDK-8206925 be a "bug"? Thoughts? It seems correct as an Enhancement. --Sean [1] https://tools.ietf.org/html/rfc2119 > > Many thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From andrew_m_leonard at uk.ibm.com Tue Jan 15 14:08:56 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 15 Jan 2019 14:08:56 +0000 Subject: Is TLS1.3 support missing the "certificate_authorities" extension? In-Reply-To: References: Message-ID: Thanks for the feedback Sean, Do we have a view on the "priority" for such an enhancement? While we don't support it, what won't work or is limited? Ajay? Cheers Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Sean Mullan To: Andrew Leonard , security-dev at openjdk.java.net Cc: Ajay Reddy , Alaine DeMyers Date: 15/01/2019 13:39 Subject: Re: Is TLS1.3 support missing the "certificate_authorities" extension? Hello, On 1/15/19 4:03 AM, Andrew Leonard wrote: > Re-posting this question.. > > Isn't the "certificate_authorities" extension mandatory for TLS1.3? The text in question says "SHOULD" and not "MUST" [1]. So while it is very desirable, I would not categorize this as a mandatory requirement. > > _https://bugs.openjdk.java.net/browse/JDK-8206925_ > > See _https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.2.4_ > There's a known typo in > _https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.4.2.2_ > which from this comment: > _https://www.ietf.org/mail-archive/web/tls/current/msg23612.html_ > indicates section 4.4.2.2 was a typo and "certificate_authorities" should > be used instead of "trusted_ca_keys" Note that your links above are referencing the Internet Draft. This has been corrected in the RFC: https://tools.ietf.org/html/rfc8446#section-4.4.2.2 > Should JDK-8206925 be a "bug"? Thoughts? It seems correct as an Enhancement. --Sean [1] https://tools.ietf.org/html/rfc2119 > > Many thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbalao at redhat.com Tue Jan 15 14:16:57 2019 From: mbalao at redhat.com (Martin Balao) Date: Tue, 15 Jan 2019 11:16:57 -0300 Subject: Is TLS1.3 support missing the "certificate_authorities" extension? In-Reply-To: References: Message-ID: Hi, I was working on an implementation of the Certificate Authorities TLS extension (former Trusted CAs) a few months ago. I stopped this work because of the integration of TLS 1.3. Here it's my latest patch: http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-8046295/webrev.03/ May be useful to resume the work. Note that this patch won't apply because code changed after TLS 1.3. Kind regards, Martin.- On 1/15/19 11:08 AM, Andrew Leonard wrote: > Thanks for the feedback Sean, > Do we have a view on the "priority" for such an enhancement? While we > don't support it, what won't work or is limited? Ajay? > Cheers > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: ? ? ? ?Sean Mullan > To: ? ? ? ?Andrew Leonard , > security-dev at openjdk.java.net > Cc: ? ? ? ?Ajay Reddy , Alaine DeMyers > > Date: ? ? ? ?15/01/2019 13:39 > Subject: ? ? ? ?Re: Is TLS1.3 support missing the > "certificate_authorities" extension? > ------------------------------------------------------------------------ > > > > Hello, > > On 1/15/19 4:03 AM, Andrew Leonard wrote: >> Re-posting this question.. >> >> Isn't the "certificate_authorities" extension mandatory for TLS1.3? > > The text in question says "SHOULD" and not "MUST" [1]. So while it is > very desirable, I would not categorize this as a mandatory requirement. > >> >> _https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8206925-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=oBlMiJsdliKXCh6xlsC6g8rXysVIW6yBnRhW7uyqc8U&s=fXR6uf8ytLCOekA3CJ9goijSOsnkE1wrBf0wfoa_czY&e= >> >> See _https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtls-2Dtls13-2D20-23section-2D4.2.4-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=oBlMiJsdliKXCh6xlsC6g8rXysVIW6yBnRhW7uyqc8U&s=4Znnq5ZgqzAESypi4g2C1Xd-Yr1FxK4cTa4_0k3amHs&e= >> There's a known typo in >> _https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtls-2Dtls13-2D20-23section-2D4.4.2.2-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=oBlMiJsdliKXCh6xlsC6g8rXysVIW6yBnRhW7uyqc8U&s=K7autmuNw1rTGW0J32W1bDIiQXN0s2OfUD5ueAK6z7o&e= >> which from this comment: >> _https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tls_current_msg23612.html-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=oBlMiJsdliKXCh6xlsC6g8rXysVIW6yBnRhW7uyqc8U&s=eagruzUipLL49ZtMHhrbAg3RIRRB1Ucbpx-VNLD6qvU&e= >> indicates section 4.4.2.2 was a typo and "certificate_authorities" should >> be used instead of "trusted_ca_keys" > > Note that your links above are referencing the Internet Draft. This has > been corrected in the RFC: > https://tools.ietf.org/html/rfc8446#section-4.4.2.2 > >> Should JDK-8206925 be a "bug"? Thoughts? > > It seems correct as an Enhancement. > > --Sean > > [1] https://tools.ietf.org/html/rfc2119 > >> >> Many thanks >> Andrew >> >> Andrew Leonard >> Java Runtimes Development >> IBM Hursley >> IBM United Kingdom Ltd >> Phone internal: 245913, external: 01962 815913 >> internet email: andrew_m_leonard at uk.ibm.com >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From mbalao at redhat.com Tue Jan 15 15:24:40 2019 From: mbalao at redhat.com (Martin Balao) Date: Tue, 15 Jan 2019 12:24:40 -0300 Subject: RFR 8217088: Disable JDK-6913047 fix (SunPKCS11 memory leak) after JDK-8216597 (SIGBUS error in getNativeKeyInfo) Message-ID: <9cfe6e3b-82aa-608d-541e-793b0bc060e9@redhat.com> Hi, Can I have a review for "JDK-8217088 - Disable JDK-6913047 fix (SunPKCS11 memory leak) after JDK-8216597 (SIGBUS error in getNativeKeyInfo)" [0]? * http://cr.openjdk.java.net/~mbalao/webrevs/8217088/8217088.webrev.00/ I'd be grateful if someone can run Solaris/SPARC-64 SunPKCS11 tests with this fix applied to make sure they pass. I don't have a proper environment to do it myself. Thanks, Martin.- -- [0] - https://bugs.openjdk.java.net/browse/JDK-8217088 From xuelei.fan at oracle.com Tue Jan 15 15:45:55 2019 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Tue, 15 Jan 2019 07:45:55 -0800 Subject: Code Review Request, JDK-8216045 The size of key_exchange may be wrong on FFDHE Message-ID: <58ea182b-1a0c-af6f-261f-566560682331@oracle.com> Hi, Could I have the update reviewed? http://cr.openjdk.java.net/~xuelei/8216045/webrev.00/ While getting the encoded public key for DH key exchange, the leading zeros of the key are not trimmed and the key bit size is used for byte size. John helped to verify the fix with the infra testing and fuzzing testing. I did not add a new unit test as it is not straightforward. Thanks, Xuelei From xuelei.fan at oracle.com Tue Jan 15 15:53:28 2019 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Tue, 15 Jan 2019 07:53:28 -0800 Subject: Is TLS1.3 support missing the "certificate_authorities" extension? In-Reply-To: References: Message-ID: Hi Andrew, If one point have more than one certificates, and one of the cert cannot be verified by the peer, there is an impact. Normally, I think the peer is configured to be able to validate the certificate. RFC 8466 marked this extension as a "MAY" level feature. Did you know any requirement in practice for this extension? It could be a priority of us if there is a serious impact. Thanks, Xuelei On 1/15/2019 6:08 AM, Andrew Leonard wrote: > Thanks for the feedback Sean, > Do we have a view on the "priority" for such an enhancement? While we > don't support it, what won't work or is limited? Ajay? > Cheers > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: Sean Mullan > To: Andrew Leonard , > security-dev at openjdk.java.net > Cc: Ajay Reddy , Alaine DeMyers > Date: 15/01/2019 13:39 > Subject: Re: Is TLS1.3 support missing the "certificate_authorities" > extension? > ------------------------------------------------------------------------ > > > > Hello, > > On 1/15/19 4:03 AM, Andrew Leonard wrote: >> Re-posting this question.. >> >> Isn't the "certificate_authorities" extension mandatory for TLS1.3? > > The text in question says "SHOULD" and not "MUST" [1]. So while it is > very desirable, I would not categorize this as a mandatory requirement. > >> >> _https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8206925-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=oBlMiJsdliKXCh6xlsC6g8rXysVIW6yBnRhW7uyqc8U&s=fXR6uf8ytLCOekA3CJ9goijSOsnkE1wrBf0wfoa_czY&e= >> >> See _https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtls-2Dtls13-2D20-23section-2D4.2.4-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=oBlMiJsdliKXCh6xlsC6g8rXysVIW6yBnRhW7uyqc8U&s=4Znnq5ZgqzAESypi4g2C1Xd-Yr1FxK4cTa4_0k3amHs&e= >> There's a known typo in >> _https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtls-2Dtls13-2D20-23section-2D4.4.2.2-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=oBlMiJsdliKXCh6xlsC6g8rXysVIW6yBnRhW7uyqc8U&s=K7autmuNw1rTGW0J32W1bDIiQXN0s2OfUD5ueAK6z7o&e= >> which from this comment: >> _https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tls_current_msg23612.html-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=oBlMiJsdliKXCh6xlsC6g8rXysVIW6yBnRhW7uyqc8U&s=eagruzUipLL49ZtMHhrbAg3RIRRB1Ucbpx-VNLD6qvU&e= >> indicates section 4.4.2.2 was a typo and "certificate_authorities" should >> be used instead of "trusted_ca_keys" > > Note that your links above are referencing the Internet Draft. This has > been corrected in the RFC: > https://tools.ietf.org/html/rfc8446#section-4.4.2.2 > >> Should JDK-8206925 be a "bug"? Thoughts? > > It seems correct as an Enhancement. > > --Sean > > [1] https://tools.ietf.org/html/rfc2119 > >> >> Many thanks >> Andrew >> >> Andrew Leonard >> Java Runtimes Development >> IBM Hursley >> IBM United Kingdom Ltd >> Phone internal: 245913, external: 01962 815913 >> internet email: andrew_m_leonard at uk.ibm.com >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From xuelei.fan at oracle.com Tue Jan 15 16:10:27 2019 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Tue, 15 Jan 2019 08:10:27 -0800 Subject: Is TLS1.3 support missing the "certificate_authorities" extension? In-Reply-To: References: Message-ID: <7aef573f-017f-672f-c684-84b9c0b42f8c@oracle.com> Hi Martin, Yes, we re-orged the code a lot for TLS 1.3. As you were already there, did you want to resume the work? I can sponsor for the code review. Thanks, Xuelei On 1/15/2019 6:16 AM, Martin Balao wrote: > Hi, > > I was working on an implementation of the Certificate Authorities TLS > extension (former Trusted CAs) a few months ago. I stopped this work > because of the integration of TLS 1.3. > > Here it's my latest patch: > http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-8046295/webrev.03/ > > May be useful to resume the work. Note that this patch won't apply > because code changed after TLS 1.3. > > Kind regards, > Martin.- > > On 1/15/19 11:08 AM, Andrew Leonard wrote: >> Thanks for the feedback Sean, >> Do we have a view on the "priority" for such an enhancement? While we >> don't support it, what won't work or is limited? Ajay? >> Cheers >> Andrew >> >> Andrew Leonard >> Java Runtimes Development >> IBM Hursley >> IBM United Kingdom Ltd >> Phone internal: 245913, external: 01962 815913 >> internet email: andrew_m_leonard at uk.ibm.com >> >> >> >> >> From: ? ? ? ?Sean Mullan >> To: ? ? ? ?Andrew Leonard , >> security-dev at openjdk.java.net >> Cc: ? ? ? ?Ajay Reddy , Alaine DeMyers >> >> Date: ? ? ? ?15/01/2019 13:39 >> Subject: ? ? ? ?Re: Is TLS1.3 support missing the >> "certificate_authorities" extension? >> ------------------------------------------------------------------------ >> >> >> >> Hello, >> >> On 1/15/19 4:03 AM, Andrew Leonard wrote: >>> Re-posting this question.. >>> >>> Isn't the "certificate_authorities" extension mandatory for TLS1.3? >> >> The text in question says "SHOULD" and not "MUST" [1]. So while it is >> very desirable, I would not categorize this as a mandatory requirement. >> >>> >>> _https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8206925-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=oBlMiJsdliKXCh6xlsC6g8rXysVIW6yBnRhW7uyqc8U&s=fXR6uf8ytLCOekA3CJ9goijSOsnkE1wrBf0wfoa_czY&e= >>> >>> See _https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtls-2Dtls13-2D20-23section-2D4.2.4-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=oBlMiJsdliKXCh6xlsC6g8rXysVIW6yBnRhW7uyqc8U&s=4Znnq5ZgqzAESypi4g2C1Xd-Yr1FxK4cTa4_0k3amHs&e= >>> There's a known typo in >>> _https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtls-2Dtls13-2D20-23section-2D4.4.2.2-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=oBlMiJsdliKXCh6xlsC6g8rXysVIW6yBnRhW7uyqc8U&s=K7autmuNw1rTGW0J32W1bDIiQXN0s2OfUD5ueAK6z7o&e= >>> which from this comment: >>> _https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tls_current_msg23612.html-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=oBlMiJsdliKXCh6xlsC6g8rXysVIW6yBnRhW7uyqc8U&s=eagruzUipLL49ZtMHhrbAg3RIRRB1Ucbpx-VNLD6qvU&e= >>> indicates section 4.4.2.2 was a typo and "certificate_authorities" should >>> be used instead of "trusted_ca_keys" >> >> Note that your links above are referencing the Internet Draft. This has >> been corrected in the RFC: >> https://tools.ietf.org/html/rfc8446#section-4.4.2.2 >> >>> Should JDK-8206925 be a "bug"? Thoughts? >> >> It seems correct as an Enhancement. >> >> --Sean >> >> [1] https://tools.ietf.org/html/rfc2119 >> >>> >>> Many thanks >>> Andrew >>> >>> Andrew Leonard >>> Java Runtimes Development >>> IBM Hursley >>> IBM United Kingdom Ltd >>> Phone internal: 245913, external: 01962 815913 >>> internet email: andrew_m_leonard at uk.ibm.com >>> >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> >> >> >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From sean.mullan at oracle.com Tue Jan 15 16:20:08 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 15 Jan 2019 11:20:08 -0500 Subject: RFR 8217088: Disable JDK-6913047 fix (SunPKCS11 memory leak) after JDK-8216597 (SIGBUS error in getNativeKeyInfo) In-Reply-To: <9cfe6e3b-82aa-608d-541e-793b0bc060e9@redhat.com> References: <9cfe6e3b-82aa-608d-541e-793b0bc060e9@redhat.com> Message-ID: <40f0df36-573b-dda4-21d4-fad83eb4caca@oracle.com> On 1/15/19 10:24 AM, Martin Balao wrote: > Hi, > > Can I have a review for "JDK-8217088 - Disable JDK-6913047 fix > (SunPKCS11 memory leak) after JDK-8216597 (SIGBUS error in > getNativeKeyInfo)" [0]? > > * http://cr.openjdk.java.net/~mbalao/webrevs/8217088/8217088.webrev.00/ This looks fine. Please add an appropriate noreg label to the bug since there is no regression test. > I'd be grateful if someone can run Solaris/SPARC-64 SunPKCS11 tests with > this fix applied to make sure they pass. I don't have a proper > environment to do it myself. Ok, I'll get back to you on that in a little while. --Sean > > Thanks, > Martin.- > > -- > [0] - https://bugs.openjdk.java.net/browse/JDK-8217088 > From sean.mullan at oracle.com Tue Jan 15 22:05:59 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 15 Jan 2019 17:05:59 -0500 Subject: RFR 8217088: Disable JDK-6913047 fix (SunPKCS11 memory leak) after JDK-8216597 (SIGBUS error in getNativeKeyInfo) In-Reply-To: <40f0df36-573b-dda4-21d4-fad83eb4caca@oracle.com> References: <9cfe6e3b-82aa-608d-541e-793b0bc060e9@redhat.com> <40f0df36-573b-dda4-21d4-fad83eb4caca@oracle.com> Message-ID: <6ed363f8-02ac-68a9-ca76-8eefa2238fed@oracle.com> On 1/15/19 11:20 AM, Sean Mullan wrote: > On 1/15/19 10:24 AM, Martin Balao wrote: >> Hi, >> >> Can I have a review for "JDK-8217088 - Disable JDK-6913047 fix >> (SunPKCS11 memory leak) after JDK-8216597 (SIGBUS error in >> getNativeKeyInfo)" [0]? >> >> ? * http://cr.openjdk.java.net/~mbalao/webrevs/8217088/8217088.webrev.00/ > > This looks fine. Please add an appropriate noreg label to the bug since > there is no regression test. Just "noreg" is not specific enough. You need to add one of the noreg- labels as documented in the JDK Developer's Guide [1] (see step 6). This is kind of a unique case, so I would add noreg-other and then add a comment explaining that existing tests passing on Solaris Sparc ensure that this workaround is working. > >> I'd be grateful if someone can run Solaris/SPARC-64 SunPKCS11 tests with >> this fix applied to make sure they pass. I don't have a proper >> environment to do it myself. > > Ok, I'll get back to you on that in a little while. Sorry for the delay. The tests finished. It looks good. There was one failure in tools/launcher/Test7029048.java, but this is a known issue: https://bugs.openjdk.java.net/browse/JDK-8216532 So you should be good to push. Thanks, Sean [1] http://openjdk.java.net/guide/changePlanning.html#bug > > --Sean > >> >> Thanks, >> Martin.- >> >> -- >> [0] - https://bugs.openjdk.java.net/browse/JDK-8217088 >> From mbalao at redhat.com Tue Jan 15 22:40:59 2019 From: mbalao at redhat.com (Martin Balao) Date: Tue, 15 Jan 2019 19:40:59 -0300 Subject: RFR 8217088: Disable JDK-6913047 fix (SunPKCS11 memory leak) after JDK-8216597 (SIGBUS error in getNativeKeyInfo) In-Reply-To: <6ed363f8-02ac-68a9-ca76-8eefa2238fed@oracle.com> References: <9cfe6e3b-82aa-608d-541e-793b0bc060e9@redhat.com> <40f0df36-573b-dda4-21d4-fad83eb4caca@oracle.com> <6ed363f8-02ac-68a9-ca76-8eefa2238fed@oracle.com> Message-ID: On 1/15/19 7:05 PM, Sean Mullan wrote: > On 1/15/19 11:20 AM, Sean Mullan wrote: > Just "noreg" is not specific enough. You need to add one of the > noreg- labels as documented in the JDK Developer's Guide [1] > (see step 6). This is kind of a unique case, so I would add noreg-other > and then add a comment explaining that existing tests passing on Solaris > Sparc ensure that this workaround is working. > Label changed, comment added. > > Sorry for the delay. The tests finished. It looks good. There was one > failure in tools/launcher/Test7029048.java, but this is a known issue: > https://bugs.openjdk.java.net/browse/JDK-8216532 > > So you should be good to push. > http://hg.openjdk.java.net/jdk/jdk/rev/142b179dd60e Thanks, Martin.- From xuelei.fan at oracle.com Wed Jan 16 03:15:05 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 15 Jan 2019 19:15:05 -0800 Subject: [12] RFR 8215694: keytool cannot generate RSASSA-PSS certificates In-Reply-To: <25B00D6E-6406-4B6D-90C8-B5F5B6D2A38E@oracle.com> References: <1F1ABA02-BD59-4CB8-8C0F-8F52E6B7CF10@oracle.com> <364147ca-fab3-b93c-91d1-bcbf85bbc8c2@oracle.com> <25B00D6E-6406-4B6D-90C8-B5F5B6D2A38E@oracle.com> Message-ID: Looks fine to me. I was wondering, if it is more simple to define PSSParamsHolder as an enum? Anyway, it is just very minor comment. You can leave it as it is. Thanks, Xuelei > Hi Xuelei, > > Webrev updated at > > https://cr.openjdk.java.net/~weijun/8215694/webrev.01 > > A new method AlgorithmId::getWithParameterSpec is added. I also cached 6 constants in AlgorithmId $PSSParamsHolder, although the static block inside it to generate the AlgorithmIds are a little heavy. We can extract the encoding lines inside PSSParameters::engineGetEncoded to create something like PSSParameterSpec::getEncoded(), but that will be an RFE. > > Thanks, > Max > >> On Jan 3, 2019, at 11:27 PM, Xue-Lei Fan wrote: >> >> On 1/3/2019 2:10 AM, Weijun Wang wrote: >>>> On Jan 2, 2019, at 11:56 PM, Xue-Lei Fan wrote: >>>> >>>> sigAlg.equalsIgnoreCase("RSASSA-PSS"): >>>> Do you really want to ignore the case? I used to think that an algorithm name is case sensitive. >>> getInstance(alg) is always case-insensitive. >> Hm, I missed it. >> >>>> >>>> Main.java:1445 minor, 4 more indent? >>> Then it's longer than 80 chars. How about I un-indent lines 1443 and 1444? >> maybe, use 4 white spaces? See also the following comment. >> >>>> >>>> AlgorithmId.java:1073-1091: >>>> I may prefer to use cached parameters (for both AlgorithmParameters and AlgorithmParameterSpec) for each size, for performance. >>> OK for AlgorithmParameterSpec. Which AlgorithmParameters do you mean? The one in SignatureUtil? >> Yes, replacing SignatureUtil.createAlgorithmParameters(). Then we don't need to worry about the indents above. >> >> Thanks, >> Xuelei >> >>> Thanks, >>> Max >>>> >>>> >>>> Xuelei >>>> >>>> >>>> On 12/21/2018 1:44 AM, Weijun Wang wrote: >>>>> Please take a review at >>>>> https://cr.openjdk.java.net/~weijun/8215694/webrev.00/ >>>>> This bug reveals several issues: >>>>> 1. Encoding of the RSASSA-PSS signature algorithm in PKCS10 and X509CertImpl. >>>>> 2. The missing of setParameter() call for PKCS10 and X509CertImpl. >>>>> 3. All keytool commands of -genkeypair, -certreq, -gencert, -selfcert are affected. >>>>> 4. Wrong NULL after encoding of RSASSA-PSS key algorithm. >>>>> Please confirm this is safe to be fixed in JDK 12. >>>>> Thanks, >>>>> Max > From weijun.wang at oracle.com Wed Jan 16 03:20:29 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 16 Jan 2019 11:20:29 +0800 Subject: [12] RFR 8215694: keytool cannot generate RSASSA-PSS certificates In-Reply-To: References: <1F1ABA02-BD59-4CB8-8C0F-8F52E6B7CF10@oracle.com> <364147ca-fab3-b93c-91d1-bcbf85bbc8c2@oracle.com> <25B00D6E-6406-4B6D-90C8-B5F5B6D2A38E@oracle.com> Message-ID: <1C466ADF-A934-43C4-A6E7-4F79E45B1E51@oracle.com> I don't use enum a lot, and we have 2 types of objects there. I'll keep it. Thanks, Max > On Jan 16, 2019, at 11:15 AM, Xuelei Fan wrote: > > Looks fine to me. > > I was wondering, if it is more simple to define PSSParamsHolder as an enum? Anyway, it is just very minor comment. You can leave it as it is. > > Thanks, > Xuelei > >> Hi Xuelei, >> Webrev updated at >> https://cr.openjdk.java.net/~weijun/8215694/webrev.01 >> A new method AlgorithmId::getWithParameterSpec is added. I also cached 6 constants in AlgorithmId $PSSParamsHolder, although the static block inside it to generate the AlgorithmIds are a little heavy. We can extract the encoding lines inside PSSParameters::engineGetEncoded to create something like PSSParameterSpec::getEncoded(), but that will be an RFE. >> Thanks, >> Max >>> On Jan 3, 2019, at 11:27 PM, Xue-Lei Fan wrote: >>> >>> On 1/3/2019 2:10 AM, Weijun Wang wrote: >>>>> On Jan 2, 2019, at 11:56 PM, Xue-Lei Fan wrote: >>>>> >>>>> sigAlg.equalsIgnoreCase("RSASSA-PSS"): >>>>> Do you really want to ignore the case? I used to think that an algorithm name is case sensitive. >>>> getInstance(alg) is always case-insensitive. >>> Hm, I missed it. >>> >>>>> >>>>> Main.java:1445 minor, 4 more indent? >>>> Then it's longer than 80 chars. How about I un-indent lines 1443 and 1444? >>> maybe, use 4 white spaces? See also the following comment. >>> >>>>> >>>>> AlgorithmId.java:1073-1091: >>>>> I may prefer to use cached parameters (for both AlgorithmParameters and AlgorithmParameterSpec) for each size, for performance. >>>> OK for AlgorithmParameterSpec. Which AlgorithmParameters do you mean? The one in SignatureUtil? >>> Yes, replacing SignatureUtil.createAlgorithmParameters(). Then we don't need to worry about the indents above. >>> >>> Thanks, >>> Xuelei >>> >>>> Thanks, >>>> Max >>>>> >>>>> >>>>> Xuelei >>>>> >>>>> >>>>> On 12/21/2018 1:44 AM, Weijun Wang wrote: >>>>>> Please take a review at >>>>>> https://cr.openjdk.java.net/~weijun/8215694/webrev.00/ >>>>>> This bug reveals several issues: >>>>>> 1. Encoding of the RSASSA-PSS signature algorithm in PKCS10 and X509CertImpl. >>>>>> 2. The missing of setParameter() call for PKCS10 and X509CertImpl. >>>>>> 3. All keytool commands of -genkeypair, -certreq, -gencert, -selfcert are affected. >>>>>> 4. Wrong NULL after encoding of RSASSA-PSS key algorithm. >>>>>> Please confirm this is safe to be fixed in JDK 12. >>>>>> Thanks, >>>>>> Max From xuelei.fan at oracle.com Wed Jan 16 03:28:37 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 15 Jan 2019 19:28:37 -0800 Subject: [12] RFR 8215694: keytool cannot generate RSASSA-PSS certificates In-Reply-To: <1C466ADF-A934-43C4-A6E7-4F79E45B1E51@oracle.com> References: <1F1ABA02-BD59-4CB8-8C0F-8F52E6B7CF10@oracle.com> <364147ca-fab3-b93c-91d1-bcbf85bbc8c2@oracle.com> <25B00D6E-6406-4B6D-90C8-B5F5B6D2A38E@oracle.com> <1C466ADF-A934-43C4-A6E7-4F79E45B1E51@oracle.com> Message-ID: <8936e2f9-f79f-5588-fc0b-302c569756bd@oracle.com> Okay. Xuelei On 1/15/2019 7:20 PM, Weijun Wang wrote: > I don't use enum a lot, and we have 2 types of objects there. I'll keep it. > > Thanks, > Max > >> On Jan 16, 2019, at 11:15 AM, Xuelei Fan wrote: >> >> Looks fine to me. >> >> I was wondering, if it is more simple to define PSSParamsHolder as an enum? Anyway, it is just very minor comment. You can leave it as it is. >> >> Thanks, >> Xuelei >> >>> Hi Xuelei, >>> Webrev updated at >>> https://cr.openjdk.java.net/~weijun/8215694/webrev.01 >>> A new method AlgorithmId::getWithParameterSpec is added. I also cached 6 constants in AlgorithmId $PSSParamsHolder, although the static block inside it to generate the AlgorithmIds are a little heavy. We can extract the encoding lines inside PSSParameters::engineGetEncoded to create something like PSSParameterSpec::getEncoded(), but that will be an RFE. >>> Thanks, >>> Max >>>> On Jan 3, 2019, at 11:27 PM, Xue-Lei Fan wrote: >>>> >>>> On 1/3/2019 2:10 AM, Weijun Wang wrote: >>>>>> On Jan 2, 2019, at 11:56 PM, Xue-Lei Fan wrote: >>>>>> >>>>>> sigAlg.equalsIgnoreCase("RSASSA-PSS"): >>>>>> Do you really want to ignore the case? I used to think that an algorithm name is case sensitive. >>>>> getInstance(alg) is always case-insensitive. >>>> Hm, I missed it. >>>> >>>>>> >>>>>> Main.java:1445 minor, 4 more indent? >>>>> Then it's longer than 80 chars. How about I un-indent lines 1443 and 1444? >>>> maybe, use 4 white spaces? See also the following comment. >>>> >>>>>> >>>>>> AlgorithmId.java:1073-1091: >>>>>> I may prefer to use cached parameters (for both AlgorithmParameters and AlgorithmParameterSpec) for each size, for performance. >>>>> OK for AlgorithmParameterSpec. Which AlgorithmParameters do you mean? The one in SignatureUtil? >>>> Yes, replacing SignatureUtil.createAlgorithmParameters(). Then we don't need to worry about the indents above. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>>> Thanks, >>>>> Max >>>>>> >>>>>> >>>>>> Xuelei >>>>>> >>>>>> >>>>>> On 12/21/2018 1:44 AM, Weijun Wang wrote: >>>>>>> Please take a review at >>>>>>> https://cr.openjdk.java.net/~weijun/8215694/webrev.00/ >>>>>>> This bug reveals several issues: >>>>>>> 1. Encoding of the RSASSA-PSS signature algorithm in PKCS10 and X509CertImpl. >>>>>>> 2. The missing of setParameter() call for PKCS10 and X509CertImpl. >>>>>>> 3. All keytool commands of -genkeypair, -certreq, -gencert, -selfcert are affected. >>>>>>> 4. Wrong NULL after encoding of RSASSA-PSS key algorithm. >>>>>>> Please confirm this is safe to be fixed in JDK 12. >>>>>>> Thanks, >>>>>>> Max > From weijun.wang at oracle.com Wed Jan 16 16:04:03 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 17 Jan 2019 00:04:03 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20181212004054.GG22527@twosigma.com> References: <20181128175551.GA13826@twosigma.com> <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com> <20181204203436.GA22527@twosigma.com> <20181206184824.GB22527@twosigma.com> <32999A4A-F6AA-4D6C-A664-F55160744F59@oracle.com> <20181212004054.GG22527@twosigma.com> Message-ID: <16911BAB-D924-402A-A51F-329B47EFDC3F@oracle.com> Hi Nico, Can you provide more explanation on below? I have't touched C/C++ for quite some time and I really forgot what extern "C" is for. I included it here only because it's also in gssapi.h and I thought I should make the declaration and implementation consistent. The getenv line compiles fine, and I am using VS2017. And I don't intend to make this C. So what's the formal way to do all these? Thanks, Max > On Dec 12, 2018, at 8:40 AM, Nico Williams wrote: > > --->#ifdef __cplusplus > extern "C" { > #endif /* __cplusplus */ > > The file extension is .cpp. > > // When KRB5_TRACE is set, debug info goes to stdout. The value is ignored. > --->char* trace = getenv("KRB5_TRACE"); > > Global variable initialization with non-const expressions is C++ but > not valid C. This is inside the extern "C" block. How does this > build? > > If you want this to be C, make the file extension .c and make sure it > builds with a C compiler. From christos at zoulas.com Wed Jan 16 16:12:00 2019 From: christos at zoulas.com (Christos Zoulas) Date: Wed, 16 Jan 2019 11:12:00 -0500 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <16911BAB-D924-402A-A51F-329B47EFDC3F@oracle.com> from Weijun Wang (Jan 17, 12:04am) Message-ID: <20190116161201.16F1417FDA1@rebar.astron.com> On Jan 17, 12:04am, weijun.wang at oracle.com (Weijun Wang) wrote: -- Subject: Re: RFR 6722928: Support SSPI as a native GSS-API provider | Hi Nico, | | Can you provide more explanation on below? I have't touched C/C++ for quite= | some time and I really forgot what extern "C" is for. I included it here o= | nly because it's also in gssapi.h and I thought I should make the declarati= | on and implementation consistent. I am not Nico, but: extern "C" ; or extern "C" { }; Tells the compiler that the functions/variables/types declared are supposed to follow "C" linkage conventions (they are meant to be used from "C" or compiled using a "C" compiler). For functions this means that their names don't get mangled, etc. I hope this helps, christos From Nico.Williams at twosigma.com Wed Jan 16 16:13:35 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Wed, 16 Jan 2019 16:13:35 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20190116161201.16F1417FDA1@rebar.astron.com> References: <16911BAB-D924-402A-A51F-329B47EFDC3F@oracle.com> <20190116161201.16F1417FDA1@rebar.astron.com> Message-ID: <20190116161335.GB27060@twosigma.com> On Wed, Jan 16, 2019 at 11:12:00AM -0500, Christos Zoulas wrote: > On Jan 17, 12:04am, weijun.wang at oracle.com (Weijun Wang) wrote: > -- Subject: Re: RFR 6722928: Support SSPI as a native GSS-API provider > > | Hi Nico, > | > | Can you provide more explanation on below? I have't touched C/C++ for quite= > | some time and I really forgot what extern "C" is for. I included it here o= > | nly because it's also in gssapi.h and I thought I should make the declarati= > | on and implementation consistent. > > I am not Nico, but: > > extern "C" ; > > or > > extern "C" { > > }; > > Tells the compiler that the functions/variables/types declared are supposed > to follow "C" linkage conventions (they are meant to be used from "C" or > compiled using a "C" compiler). For functions this means that their names > don't get mangled, etc. > > I hope this helps, Ah, and that code doesn't need to be C, so never mind that one comment of mine. Nico -- From weijun.wang at oracle.com Wed Jan 16 16:15:54 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 17 Jan 2019 00:15:54 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20190116161335.GB27060@twosigma.com> References: <16911BAB-D924-402A-A51F-329B47EFDC3F@oracle.com> <20190116161201.16F1417FDA1@rebar.astron.com> <20190116161335.GB27060@twosigma.com> Message-ID: <44B764F1-AF9A-4C41-B24B-848EC7555355@oracle.com> > On Jan 17, 2019, at 12:13 AM, Nico Williams wrote: > > On Wed, Jan 16, 2019 at 11:12:00AM -0500, Christos Zoulas wrote: >> On Jan 17, 12:04am, weijun.wang at oracle.com (Weijun Wang) wrote: >> -- Subject: Re: RFR 6722928: Support SSPI as a native GSS-API provider >> >> | Hi Nico, >> | >> | Can you provide more explanation on below? I have't touched C/C++ for quite= >> | some time and I really forgot what extern "C" is for. I included it here o= >> | nly because it's also in gssapi.h and I thought I should make the declarati= >> | on and implementation consistent. >> >> I am not Nico, but: >> >> extern "C" ; >> >> or >> >> extern "C" { >> >> }; >> >> Tells the compiler that the functions/variables/types declared are supposed >> to follow "C" linkage conventions (they are meant to be used from "C" or >> compiled using a "C" compiler). For functions this means that their names >> don't get mangled, etc. >> >> I hope this helps, > > Ah, and that code doesn't need to be C, so never mind that one comment > of mine. So I can just throw away the 'extern "c"' line? > > Nico > -- From Nico.Williams at twosigma.com Wed Jan 16 16:20:08 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Wed, 16 Jan 2019 16:20:08 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <44B764F1-AF9A-4C41-B24B-848EC7555355@oracle.com> References: <16911BAB-D924-402A-A51F-329B47EFDC3F@oracle.com> <20190116161201.16F1417FDA1@rebar.astron.com> <20190116161335.GB27060@twosigma.com> <44B764F1-AF9A-4C41-B24B-848EC7555355@oracle.com> Message-ID: <20190116162008.GC27060@twosigma.com> On Thu, Jan 17, 2019 at 12:15:54AM +0800, Weijun Wang wrote: > So I can just throw away the 'extern "c"' line? No, no need. From xuelei.fan at oracle.com Wed Jan 16 17:49:43 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 16 Jan 2019 09:49:43 -0800 Subject: RFR 8215776: Keytool importkeystore may mix up certificate chain entries when DNs conflict In-Reply-To: <87E0531E-F7CE-4F32-86B7-4A3F3C1B842F@oracle.com> References: <87E0531E-F7CE-4F32-86B7-4A3F3C1B842F@oracle.com> Message-ID: <9e41b753-aeb7-a09c-f221-e464327e9e90@oracle.com> Hi Max, I did not look into the detailed implementation of findIssuer() yet. Have you considered to use java.security.cert.X509CertSelector? Thanks, Xuelei On 1/9/2019 6:59 AM, Weijun Wang wrote: > Please take a review at > > https://cr.openjdk.java.net/~weijun/8215776/webrev.00/ > > PKCS12KeyStore now can find certificate issuers more precisely using SubjectKeyIdentifier and AuthorityKeyIdentifier. I thought about using CertPath builder or checking signatures but those changes are too much. > > Thanks, > Max > From jamil.j.nimeh at oracle.com Wed Jan 16 18:19:56 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 16 Jan 2019 10:19:56 -0800 Subject: Code Review Request, JDK-8216045 The size of key_exchange may be wrong on FFDHE In-Reply-To: <58ea182b-1a0c-af6f-261f-566560682331@oracle.com> References: <58ea182b-1a0c-af6f-261f-566560682331@oracle.com> Message-ID: <2cb9115a-f0a6-93f8-7d1d-8972f0284059@oracle.com> Hi Xuelei, this looks good to me. --Jamil On 1/15/2019 7:45 AM, Xue-Lei Fan wrote: > Hi, > > Could I have the update reviewed? > ?? http://cr.openjdk.java.net/~xuelei/8216045/webrev.00/ > > While getting the encoded public key for DH key exchange,? the leading > zeros of the key are not trimmed and the key bit size is used for byte > size. > > John helped to verify the fix with the infra testing and fuzzing > testing.? I did not add a new unit test as it is not straightforward. > > Thanks, > Xuelei From sean.mullan at oracle.com Wed Jan 16 19:53:39 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 16 Jan 2019 14:53:39 -0500 Subject: [12] RFR: 8216280: Allow later Symantec Policy distrust date for two Apple SubCAs Message-ID: <707b8a88-24f3-60cd-46af-a9100622996b@oracle.com> Please review this change to allow a later Symantec Policy distrust date for two Apple subordinate CAs. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8216280/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8216280 For some background, the JDK will stop trusting TLS Server certificates chaining back to Symantec roots, in line with similar plans announced by Google, Mozilla, Apple, and Microsoft. The list of affected certificates includes certificates branded as GeoTrust, Thawte, and VeriSign, which were managed by Symantec. Any TLS Server certificate issued after April 16, 2019 will be restricted. This change has already been implemented and is in JDK 12 (see JDK-8207258 for more info). Apple are actively working with DigiCert on a transition plan and have requested a later distrust date: December 31, 2019. This later distrust date would only apply to TLS Server certificates issued from (or chaining back to) two Apple subordinate CAs: "Apple IST CA 2 - G1" and "Apple IST CA 8 - G1" issued by GeoTrust root CAs. Any certificate issued after that date will be distrusted. This change would be in line with other vendors such as Mozilla that have granted similar exemptions to these Apple subCAs. Thanks, Sean From weijun.wang at oracle.com Thu Jan 17 03:41:38 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 17 Jan 2019 11:41:38 +0800 Subject: RFR 8215776: Keytool importkeystore may mix up certificate chain entries when DNs conflict In-Reply-To: <9e41b753-aeb7-a09c-f221-e464327e9e90@oracle.com> References: <87E0531E-F7CE-4F32-86B7-4A3F3C1B842F@oracle.com> <9e41b753-aeb7-a09c-f221-e464327e9e90@oracle.com> Message-ID: <8945E624-FE60-44C2-AADA-0D69B61244C7@oracle.com> I'll take a look. I thought java.security.cert.X509CertSelector is used by CertPath validators and builders internally and never thought it can be called directly. Thanks, Max > On Jan 17, 2019, at 1:49 AM, Xuelei Fan wrote: > > Hi Max, > > I did not look into the detailed implementation of findIssuer() yet. Have you considered to use java.security.cert.X509CertSelector? > > Thanks, > Xuelei > > On 1/9/2019 6:59 AM, Weijun Wang wrote: >> Please take a review at >> https://cr.openjdk.java.net/~weijun/8215776/webrev.00/ >> PKCS12KeyStore now can find certificate issuers more precisely using SubjectKeyIdentifier and AuthorityKeyIdentifier. I thought about using CertPath builder or checking signatures but those changes are too much. >> Thanks, >> Max From sha.jiang at oracle.com Thu Jan 17 08:26:33 2019 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Thu, 17 Jan 2019 16:26:33 +0800 Subject: RFR[12] JDK-8203687: javax/net/ssl/compatibility/Compatibility.java supports TLS 1.3 Message-ID: Hi, The patch adds TLS 1.3 cases for test javax/net/ssl/compatibility/Compatibility.java. Beside this enhancement, it also changes the test on the following points: 1. Re-generate all certificates to use key size 2048 and SHA256 rather than 1024 and SHA1. And new RSA signed EC key certificates are added. 2. Each JDK build should check if a cipher suite is supported by itself. It's really unnecessary to maintain a predefined table for it. 3. Uses classes in javax/net/ssl/TLSCommon for defined protocols and cipher suites. And also adds a new common class for key algorithm. 4. Correct some statements in README. Webrev: http://cr.openjdk.java.net/~jjiang/8203687/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8203687 Best regards, John Jiang From weijun.wang at oracle.com Thu Jan 17 15:19:14 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 17 Jan 2019 23:19:14 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20181212004054.GG22527@twosigma.com> References: <20181128175551.GA13826@twosigma.com> <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com> <20181204203436.GA22527@twosigma.com> <20181206184824.GB22527@twosigma.com> <32999A4A-F6AA-4D6C-A664-F55160744F59@oracle.com> <20181212004054.GG22527@twosigma.com> Message-ID: Webrev updated at https://cr.openjdk.java.net/~weijun/6722928/webrev.03 Changes since webrev.02: - gss_name_struct, gss_ctx_id_struct, and gss_cred_id_struct defined and gssapi.h is updated to use them to define pointer types gss_name_t, gss_cred_id_t, and gss_ctx_id_t. - small bug found in NativeFunc.h with the new types above defined. - A bug found in NegTokenTarg.java. The responseToken field was duplicated as the mechListMIC field. I don't know the history but this could not be correct. Others in sspi.cpp: - debug output not on stderr. - Since AcquireCredentialsHandle cannot return a useful timestamp, use the endTime in TGT. - No more translation between krb5 token and SPNEGO token. SEC_WINNT_AUTH_IDENTITY_EX.PackageList is now used to only enable kerberos in SPNEGO. Thus gss_cred_id_struct contains 2 CredHandles now. - Other fine tuning. For example, all functions and variables now start with lowercase letters. Thanks Max From dennis at gesker.com Thu Jan 17 17:00:39 2019 From: dennis at gesker.com (Dennis Gesker) Date: Thu, 17 Jan 2019 10:00:39 -0700 Subject: JDK-8215102 (Follow-up) Message-ID: Good Morning, Alan. Added the -Djavax.net.debug=all option to my Wildfly startup and waited for the pool to close a connection to MySql at AWS. TXT file attached. javac 11.0.1 mysql jdbc driver 8.0.13 wildfly 15.0.1 --drg -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Thu Jan 17 18:00:00 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 17 Jan 2019 10:00:00 -0800 Subject: RFR[12] JDK-8203687: javax/net/ssl/compatibility/Compatibility.java supports TLS 1.3 In-Reply-To: References: Message-ID: Hi John, Looks fine to me except a minor format comment. Would you mind check the line length and limit to 80 characters each line? For example, using "\" join multiple lines together. // openssl req -x509 -new -key key.pem \ // -subj "/CN=RSA-2048-SHA256" -sha256 -out cer.pem Thanks, Xuelei On 1/17/2019 12:26 AM, sha.jiang at oracle.com wrote: > Hi, > The patch adds TLS 1.3 cases for test > javax/net/ssl/compatibility/Compatibility.java. > Beside this enhancement, it also changes the test on the following points: > 1. Re-generate all certificates to use key size 2048 and SHA256 rather > than 1024 and SHA1. And new RSA signed EC key certificates are added. > 2. Each JDK build should check if a cipher suite is supported by itself. > It's really unnecessary to maintain a predefined table for it. > 3. Uses classes in javax/net/ssl/TLSCommon for defined protocols and > cipher suites. And also adds a new common class for key algorithm. > 4. Correct some statements in README. > > Webrev: http://cr.openjdk.java.net/~jjiang/8203687/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8203687 > > Best regards, > John Jiang > From sean.coffey at oracle.com Thu Jan 17 18:20:00 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 17 Jan 2019 18:20:00 +0000 Subject: [12] RFR: 8216280: Allow later Symantec Policy distrust date for two Apple SubCAs In-Reply-To: <707b8a88-24f3-60cd-46af-a9100622996b@oracle.com> References: <707b8a88-24f3-60cd-46af-a9100622996b@oracle.com> Message-ID: <3dcdec88-188c-e7cd-c26b-e2343957f07d@oracle.com> Looks good to me Sean. regards, Sean. On 16/01/2019 19:53, Sean Mullan wrote: > Please review this change to allow a later Symantec Policy distrust > date for two Apple subordinate CAs. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8216280/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8216280 > > For some background, the JDK will stop trusting TLS Server > certificates chaining back to Symantec roots, in line with similar > plans announced by Google, Mozilla, Apple, and Microsoft. The list of > affected certificates includes certificates branded as GeoTrust, > Thawte, and VeriSign, which were managed by Symantec. Any TLS Server > certificate issued after April 16, 2019 will be restricted. This > change has already been implemented and is in JDK 12 (see JDK-8207258 > for more info). > > Apple are actively working with DigiCert on a transition plan and have > requested a later distrust date: December 31, 2019. This later > distrust date would only apply to TLS Server certificates issued from > (or chaining back to) two Apple subordinate CAs: "Apple IST CA 2 - G1" > and "Apple IST CA 8 - G1" issued by GeoTrust root CAs. Any certificate > issued after that date will be distrusted. This change would be in > line with other vendors such as Mozilla that have granted similar > exemptions to these Apple subCAs. > > Thanks, > Sean From sean.mullan at oracle.com Thu Jan 17 18:22:55 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 17 Jan 2019 13:22:55 -0500 Subject: [13] RFR 8215937: Check usages of security-related Resources files In-Reply-To: <204CAB4B-B666-4B26-84E0-3F47875B3122@oracle.com> References: <204CAB4B-B666-4B26-84E0-3F47875B3122@oracle.com> Message-ID: This is a nice cleanup. Just a couple of comments: - Update copyrights now that it is 2019 - For the test, is the source code always guaranteed to be there? I was not sure if that was a requirement. Or does the test still pass if it can't find the source code? Thanks, Sean On 12/27/18 3:11 AM, Weijun Wang wrote: > Please take a review at > > https://cr.openjdk.java.net/~weijun/8215937/webrev.00/ > > A new Usages.java test is added to make sure the strings in various Resources.java files are exactly what are used in security-related source files, no more no less. > > Two old tests are removed. NewNamesFormat.java checks for format and Usages.java covers it. NewResourcesNames.java is a manual test and is too stale and not easy to run. > > Several calls in keytool and jarsigner are modified to follow a more consistent calling convention (always rb.getString(string_literal)) so that they can be detected by Usages.java more easily. There are still several places in PolicyFile.java calling 'LocalizedMessage.getNonlocalized(POLICY + "...", source)' but I left them unchanged and dealt with it specially in Usages.java. > > Many useless strings in Resources.java files are removed. I've double checked each and made sure the related calls were removed some time ago. > > Thanks > Max > From philipp.kunz at paratix.ch Thu Jan 17 18:44:25 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Thu, 17 Jan 2019 19:44:25 +0100 Subject: Jarsigner compatibility issue invalidating existing signatures Message-ID: <1547750665.2438.29.camel@paratix.ch> Hi, Related to JDK-6372077 i found that jarsigner breaks existing signatures in cases the binary manifest encoding changes for individual sections. That has potential to become more popular after JDK-6372077 changed the line width from 70 to 72 bytes. Signing a jarfile already signed with a pre-6372077 / JDK before 11 jarsigner again with a different signer with another jarsigner version that has JDK-6372077 / JDK 11 or later will invalidate many existing signatures. This affects individual section names as with the jar file contents file names which can be expected to exceed 66 bytes of length of their names often as well as digest headers with longer digest values such as SHA-512. Apart from that, it can also happen if someone changed the line breaks (crlf to lf or cr) or some line break positions before signing again with a different signer. The same does not apply to manifest main attributes. Special treatment is in place for those near JarSigner#findHeaderEnd. I wouldn't know why not also for individual sections where all the jar file signed content files' digests are. In course of developing this patch I also encountered a few other related issues. - Manifest copy constructor does not deeply copy individual section Attributes but instead only copies the list of sections. See ManifestCopyConstructor test - ManifestDigester confuses manifest main attributes with an individual section name of "Manifest-Main-Attributes". See ManifestMainAttributesDigest test - ManifestDigester fails to digest manifests that end with \r with an array index out of bounds exception and such jar files cannot be signed. See LineBreaks test - JarSigner accepts an existing digest for a jar entry even if the (upper/lower) case of the base64 encoded form?does not match. See ExistingManifestDigestEntryDontIgnoreCase test - Compatibility test fails to detect such an incompatibility as mentioned. The chosen approach was to re-use Manifest-Digester to identify the input portions for the digests and extend it so that it can reproduce them if a section is unmodified to write unmodified portions of a manifest. This made JarSigner#findHeaderEnd redundant as now replaced with ManifestDigester#findSection. See FindHeaderEndVsManifestDigesterFindFirstSection test. All existing and the new tests show it actually works. There are a few API changes and sure more opportunities to optimize, refacter, add more test coverage, personal preferences, project conventions, and so on. Possibly, oldStyle or workaround could be removed from ManifestDigester, first. Or a DigestOutputStream could be created that does not wrap another OutputStream, only is one. Another point might be that the Compatibility test now takes longer than before and because I don't know all the parameters, for example the number of JDKs tested and if minor versions are included, and therefore don't know if it wouldn't take too long the way it is now. If you run the tests against the current code base, getMainAttsEntry will not be found in ManifestMainAttributes, so replace it with "get(ManifestDigester.MF_MAIN_ATTRS,?" above. These comments are not intended to be kept after compatibility with existing code has been established. Probably that one whole test is obsolete once manifest main attributes confusion in ManifestDigester is resolved. There still are some other TODOs non of which too scary or intended to leave like that where I see potential for improvement and I'd appreciate guidance. Recently I read that JDK 8 is still the most used major version, possibly even much more so in production environments where signed jars are typically expected to be found. If this patch could be backported to JDK 11 where?JDK-6372077 was introduced and which is an LTS release, I figure we might save a few people some trouble with unexpectedly invalid signatures. But one step after another. I'm curiously looking forward to any kind of feedback. I cannot create an issue for it because I don't have the permissions and I haven't found so far anything related either. Is this the right mailing list or shall I post it to core-libs-dev or another one as well? Would someone volunteer to sponsor? Regards, Philipp https://bugs.openjdk.java.net/browse/JDK-6372077 https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051 707.html -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: jarsignerbreaksexistingsignatures.patch Type: text/x-patch Size: 106427 bytes Desc: not available URL: From Nico.Williams at twosigma.com Thu Jan 17 19:04:36 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Thu, 17 Jan 2019 19:04:36 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: References: <20181128175551.GA13826@twosigma.com> <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com> <20181204203436.GA22527@twosigma.com> <20181206184824.GB22527@twosigma.com> <32999A4A-F6AA-4D6C-A664-F55160744F59@oracle.com> <20181212004054.GG22527@twosigma.com> Message-ID: <20190117190436.GD27060@twosigma.com> On Thu, Jan 17, 2019 at 11:19:14PM +0800, Weijun Wang wrote: > Webrev updated at > > https://cr.openjdk.java.net/~weijun/6722928/webrev.03 > > Changes since webrev.02: > > - gss_name_struct, gss_ctx_id_struct, and gss_cred_id_struct defined and > gssapi.h is updated to use them to define pointer types gss_name_t, > gss_cred_id_t, and gss_ctx_id_t. Excellent. And then you can actually define those structures and avoid casting these pointers' types. > - No more translation between krb5 token and SPNEGO token. > SEC_WINNT_AUTH_IDENTITY_EX.PackageList is now used to only enable kerberos > in SPNEGO. Thus gss_cred_id_struct contains 2 CredHandles now. Nice! That's great. Thanks so much for doing that. I'll review this next week, Nico -- From ivan.gerasimov at oracle.com Thu Jan 17 21:32:49 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 17 Jan 2019 13:32:49 -0800 Subject: RFR (XS) 8217344 : Make comparison overflow-aware in ECDHKeyAgreement.engineGenerateSecret() Message-ID: <41a17a30-c364-b016-1857-4bf37df002cd@oracle.com> Hello! Would you please help review a trivial fix to avoid a possible arithmetic overflow in comparison? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8217344 WEBREV: http://cr.openjdk.java.net/~igerasim/8217344/00/webrev/ Thanks in advance! -- With kind regards, Ivan Gerasimov From sean.mullan at oracle.com Thu Jan 17 22:38:03 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 17 Jan 2019 17:38:03 -0500 Subject: RFR (12): 8215318: Amend the Standard Algorithm Names specification to clarify that names can be defined in later versions In-Reply-To: <61ac2c12-74f6-4c42-b85d-37a0b1ac7d9f@default> References: <61ac2c12-74f6-4c42-b85d-37a0b1ac7d9f@default> Message-ID: <692ebee1-6617-4c48-08ae-d29b1d56a5c3@oracle.com> To address some concerns raised during the CSR [1] review, I have adjusted the proposed wording to recommend that, as a best practice (and not as a requirement), implementations should use standard names for additional algorithms that they choose to support if those standard names are defined in later versions of the Java Security Standard Algorithm Names specification. I have also added text to recommend that the algorithms that an implementation supports be documented in release notes or a separate document similar to the JDK Providers guide. Please let me know if you have any comments on this updated text, which is as follows: "Note that an SE implementation may support additional algorithms that are not defined in this specification. As a best practice, if an algorithm is defined in a subsequent version of this specification and an implementation of an earlier specification supports that algorithm, the implementation should use the standard name of the algorithm that is defined in the subsequent specification. Each SE implementation should also document the algorithms that it supports or adds support for in subsequent update releases. The algorithms may be documented in release notes or in a separate document such as the JDK Security Providers document." Thanks, Sean [1] https://bugs.openjdk.java.net/browse/JDK-8215320 On 1/2/19 4:37 PM, Iris Clark wrote: > Hi, Sean. > > These changes look good. > > Thanks, > iris > > -----Original Message----- > From: Sean Mullan > Sent: Wednesday, January 2, 2019 12:43 PM > To: security Dev OpenJDK ; IRIS,CLARK > Subject: RFR (12): 8215318: Amend the Standard Algorithm Names specification to clarify that names can be defined in later versions > > Please review this change to the Java Security Standard Algorithm Names specification [1] to clarify that standard names that are defined in later versions of SE are also supported in prior versions, as long as the applicable Security APIs are also supported. > > Please see the CSR for the motivation and exact wording changes: > https://bugs.openjdk.java.net/browse/JDK-8215320 > > This change will also be included in the upcoming Maintenance Reviews of the Java SE 8 and 11 Platform JSRs. See [2] for more information. > > I have also included the raw diffs below: > > diff -r 8829e86def29 > closed/src/java.base/share/specs/security/standard-names.md > --- a/closed/src/java.base/share/specs/security/standard-names.md > Thu Dec 20 14:21:16 2018 -0500 > +++ b/closed/src/java.base/share/specs/security/standard-names.md > Wed Jan 02 15:39:12 2019 -0500 > @@ -20,6 +20,10 @@ > The Java SE Security API requires and uses a set of standard names for > algorithms, certificate and keystore types. > > +Names that are added to subsequent Java SE versions of this > +specification also apply to this version of the specification if the > +Security APIs that those names are defined for are supported. > + > In some cases naming conventions are given for forming names that are not > explicitly listed, to facilitate name consistency across provider > implementations. Items in angle brackets (such as `` and > > --Sean > > [1] > https://docs.oracle.com/en/java/javase/11/docs/specs/security/standard-names.html > [2] > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-December/000308.html > From sha.jiang at oracle.com Thu Jan 17 23:42:23 2019 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Fri, 18 Jan 2019 07:42:23 +0800 Subject: RFR[12] JDK-8203687: javax/net/ssl/compatibility/Compatibility.java supports TLS 1.3 In-Reply-To: References: Message-ID: <4188e790-0dba-f4f5-fdaf-07f7bda81603@oracle.com> Hi Xuelei, On 2019/1/18 02:00, Xuelei Fan wrote: > Hi John, > > Looks fine to me except a minor format comment. > > Would you mind check the line length and limit to 80 characters each > line? > > For example, using "\"? join multiple lines together. > ??? // openssl req -x509 -new -key key.pem \ > ??? //???? -subj "/CN=RSA-2048-SHA256" -sha256 -out cer.pem I should stick to this convention. Please review this new webrev: http://cr.openjdk.java.net/~jjiang/8203687/webrev.01/ Only Cert.java is updated. Best regards, John Jiang > > Thanks, > Xuelei > > On 1/17/2019 12:26 AM, sha.jiang at oracle.com wrote: >> Hi, >> The patch adds TLS 1.3 cases for test >> javax/net/ssl/compatibility/Compatibility.java. >> Beside this enhancement, it also changes the test on the following >> points: >> 1. Re-generate all certificates to use key size 2048 and SHA256 >> rather than 1024 and SHA1. And new RSA signed EC key certificates are >> added. >> 2. Each JDK build should check if a cipher suite is supported by >> itself. It's really unnecessary to maintain a predefined table for it. >> 3. Uses classes in javax/net/ssl/TLSCommon for defined protocols and >> cipher suites. And also adds a new common class for key algorithm. >> 4. Correct some statements in README. >> >> Webrev: http://cr.openjdk.java.net/~jjiang/8203687/webrev.00/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8203687 >> >> Best regards, >> John Jiang >> > From weijun.wang at oracle.com Fri Jan 18 02:23:03 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 18 Jan 2019 10:23:03 +0800 Subject: [13] RFR 8215937: Check usages of security-related Resources files In-Reply-To: References: <204CAB4B-B666-4B26-84E0-3F47875B3122@oracle.com> Message-ID: <750E3A41-8D1C-4F9E-A854-253AB335AD87@oracle.com> > On Jan 18, 2019, at 2:22 AM, Sean Mullan wrote: > > This is a nice cleanup. Just a couple of comments: > > - Update copyrights now that it is 2019 Will change. > > - For the test, is the source code always guaranteed to be there? I was not sure if that was a requirement. Or does the test still pass if it can't find the source code? 132 public static void main(String[] args) { 133 if (Files.exists(SRC)) { 134 MAP.forEach(Usages::check); 135 } else { 136 System.out.println("No src directory. Test skipped."); 137 } 138 } But I remember asked about a similar case before and with Mach5 the src/ directory is always available. Thanks, Max > > Thanks, > Sean > > On 12/27/18 3:11 AM, Weijun Wang wrote: >> Please take a review at >> https://cr.openjdk.java.net/~weijun/8215937/webrev.00/ >> A new Usages.java test is added to make sure the strings in various Resources.java files are exactly what are used in security-related source files, no more no less. >> Two old tests are removed. NewNamesFormat.java checks for format and Usages.java covers it. NewResourcesNames.java is a manual test and is too stale and not easy to run. >> Several calls in keytool and jarsigner are modified to follow a more consistent calling convention (always rb.getString(string_literal)) so that they can be detected by Usages.java more easily. There are still several places in PolicyFile.java calling 'LocalizedMessage.getNonlocalized(POLICY + "...", source)' but I left them unchanged and dealt with it specially in Usages.java. >> Many useless strings in Resources.java files are removed. I've double checked each and made sure the related calls were removed some time ago. >> Thanks >> Max From xuelei.fan at oracle.com Fri Jan 18 05:57:09 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 17 Jan 2019 21:57:09 -0800 Subject: RFR[12] JDK-8203687: javax/net/ssl/compatibility/Compatibility.java supports TLS 1.3 In-Reply-To: <4188e790-0dba-f4f5-fdaf-07f7bda81603@oracle.com> References: <4188e790-0dba-f4f5-fdaf-07f7bda81603@oracle.com> Message-ID: <74ea7b17-2a3c-4b91-097d-8331c66e0479@oracle.com> Thanks for the update. No more comments. Xuelei On 1/17/2019 3:42 PM, sha.jiang at oracle.com wrote: > Hi Xuelei, > > On 2019/1/18 02:00, Xuelei Fan wrote: >> Hi John, >> >> Looks fine to me except a minor format comment. >> >> Would you mind check the line length and limit to 80 characters each >> line? >> >> For example, using "\"? join multiple lines together. >> ??? // openssl req -x509 -new -key key.pem \ >> ??? //???? -subj "/CN=RSA-2048-SHA256" -sha256 -out cer.pem > > I should stick to this convention. > Please review this new webrev: > http://cr.openjdk.java.net/~jjiang/8203687/webrev.01/ > Only Cert.java is updated. > > Best regards, > John Jiang > >> >> Thanks, >> Xuelei >> >> On 1/17/2019 12:26 AM, sha.jiang at oracle.com wrote: >>> Hi, >>> The patch adds TLS 1.3 cases for test >>> javax/net/ssl/compatibility/Compatibility.java. >>> Beside this enhancement, it also changes the test on the following >>> points: >>> 1. Re-generate all certificates to use key size 2048 and SHA256 >>> rather than 1024 and SHA1. And new RSA signed EC key certificates are >>> added. >>> 2. Each JDK build should check if a cipher suite is supported by >>> itself. It's really unnecessary to maintain a predefined table for it. >>> 3. Uses classes in javax/net/ssl/TLSCommon for defined protocols and >>> cipher suites. And also adds a new common class for key algorithm. >>> 4. Correct some statements in README. >>> >>> Webrev: http://cr.openjdk.java.net/~jjiang/8203687/webrev.00/ >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8203687 >>> >>> Best regards, >>> John Jiang >>> >> From weijun.wang at oracle.com Fri Jan 18 10:41:34 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 18 Jan 2019 18:41:34 +0800 Subject: Jarsigner compatibility issue invalidating existing signatures In-Reply-To: <1547750665.2438.29.camel@paratix.ch> References: <1547750665.2438.29.camel@paratix.ch> Message-ID: <62761D0E-482B-4B54-989F-8518C442A6AE@oracle.com> Hi Philipp, Thanks for the report. I've filed https://bugs.openjdk.java.net/browse/JDK-8217375 and post your patch at https://cr.openjdk.java.net/~weijun/8217375/webrev.00/ Some comments: 1. While the updated Manifest constructor is good, it's an API change. To avoid this change if we want to backport the change to JDK 11, in JarSigner::sign0, we can create oldManifest using mfRawBytes again. 2. Those TODOs, do you really need to do anything? Thanks, Max > On Jan 18, 2019, at 2:44 AM, Philipp Kunz wrote: > > Hi, > > Related to JDK-6372077 i found that jarsigner breaks existing signatures in cases the binary manifest encoding changes for individual sections. > That has potential to become more popular after JDK-6372077 changed the line width from 70 to 72 bytes. Signing a jarfile already signed with a pre-6372077 / JDK before 11 jarsigner again with a different signer with another jarsigner version that has JDK-6372077 / JDK 11 or later will invalidate many existing signatures. This affects individual section names as with the jar file contents file names which can be expected to exceed 66 bytes of length of their names often as well as digest headers with longer digest values such as SHA-512. Apart from that, it can also happen if someone changed the line breaks (crlf to lf or cr) or some line break positions before signing again with a different signer. > > The same does not apply to manifest main attributes. Special treatment is in place for those near JarSigner#findHeaderEnd. I wouldn't know why not also for individual sections where all the jar file signed content files' digests are. > > In course of developing this patch I also encountered a few other related issues. > - Manifest copy constructor does not deeply copy individual section Attributes but instead only copies the list of sections. See ManifestCopyConstructor test > - ManifestDigester confuses manifest main attributes with an individual section name of "Manifest-Main-Attributes". See ManifestMainAttributesDigest test > - ManifestDigester fails to digest manifests that end with \r with an array index out of bounds exception and such jar files cannot be signed. See LineBreaks test > - JarSigner accepts an existing digest for a jar entry even if the (upper/lower) case of the base64 encoded form does not match. See ExistingManifestDigestEntryDontIgnoreCase test > - Compatibility test fails to detect such an incompatibility as mentioned. > > The chosen approach was to re-use Manifest-Digester to identify the input portions for the digests and extend it so that it can reproduce them if a section is unmodified to write unmodified portions of a manifest. > This made JarSigner#findHeaderEnd redundant as now replaced with ManifestDigester#findSection. See FindHeaderEndVsManifestDigesterFindFirstSection test. > > All existing and the new tests show it actually works. There are a few API changes and sure more opportunities to optimize, refacter, add more test coverage, personal preferences, project conventions, and so on. Possibly, oldStyle or workaround could be removed from ManifestDigester, first. Or a DigestOutputStream could be created that does not wrap another OutputStream, only is one. Another point might be that the Compatibility test now takes longer than before and because I don't know all the parameters, for example the number of JDKs tested and if minor versions are included, and therefore don't know if it wouldn't take too long the way it is now. If you run the tests against the current code base, getMainAttsEntry will not be found in ManifestMainAttributes, so replace it with "get(ManifestDigester.MF_MAIN_ATTRS, " above. These comments are not intended to be kept after compatibility with existing code has been established. Probably that one whole test is obsolete once manifest main attributes confusion in ManifestDigester is resolved. There still are some other TODOs non of which too scary or intended to leave like that where I see potential for improvement and I'd appreciate guidance. > > Recently I read that JDK 8 is still the most used major version, possibly even much more so in production environments where signed jars are typically expected to be found. If this patch could be backported to JDK 11 where JDK-6372077 was introduced and which is an LTS release, I figure we might save a few people some trouble with unexpectedly invalid signatures. But one step after another. I'm curiously looking forward to any kind of feedback. I cannot create an issue for it because I don't have the permissions and I haven't found so far anything related either. Is this the right mailing list or shall I post it to core-libs-dev or another one as well? Would someone volunteer to sponsor? > > Regards, > Philipp > > > https://bugs.openjdk.java.net/browse/JDK-6372077 > https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051707.html > > > From Alan.Bateman at oracle.com Fri Jan 18 14:35:54 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 18 Jan 2019 14:35:54 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <5d28b0715d2041ff892a3c44e024f120@sap.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> Message-ID: <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> On 12/01/2019 13:02, Langer, Christoph wrote: > Hi Alan, > > as I did not hear back from you I continued to work on the POSIX file permission support for zipfs and specified/implemented the value of 'null' for zip entries with no permission information associated (vs. UnsupportedOperationException). > > I updated the CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 > I don't think zipfs can support PosixFileAttributeView in this way because zip entries can only support a subset of the attributes that the view defines. Retrofitting optionality to allow it be used in a degraded manner would be an incompatible change and of course creates usability issues. The owner, group and permissions methods defined by PosixFileAttributes cannot return null or throw exceptions. I think the approach to explore are: 1. zipfs supports PosixFileAttributeView without subsetting. If readAttribute(file, BasicFileAttributes.class) succeeds then readAttribute(file, PosixFileAttributes.class) should also succeed, even if there aren't permissions encoded in the zip entry's external file attributes. It would mean that owner and group return default values, and permissions may return a default value. It does mean you can't distinguish the default value from "no permissions" but there is precedence for that, e.g. mount a FAT32 file system on Linux or Unix systems and `stat` a file to have the stat structure populated with default uid, gid and mode bits. 2. zipfs defines a new FileAttributeView that defines read and write access to permissions stored in a zip entry's external file attribute. As it's a new view then it can define the behavior for the case that the zip entry doesn't have permissions. Furthermore it does not need to extend BasicFileAttributeView so doesn't need to be concerned with bulk access, nor concerned with group/owner. As you know, the attributes API allows for both type safe and dynamic access so you have a choice as to whether to support both or just dynamic access. With the first then jdk.zipfs would export a package with a public interface that defines the view. If someone wants type safe access to the permissions attribute then you need to import the class. The alternative is to not export any packages but just define the view in the module-info. The view its name and define the name/type of the permissions attribute, it will also define how it behaves when the external attributes aren't populated. In usage terms it means reading the permissions will be something like Files.readAttribute(file, "zip:permissions") and casting the value to Set - not pretty but it avoids depending on a JDK-specific API. I think it would be good to explore these options and maybe we can converge on an approach in the coming weeks. -Alan From adam.petcher at oracle.com Fri Jan 18 15:27:19 2019 From: adam.petcher at oracle.com (Adam Petcher) Date: Fri, 18 Jan 2019 10:27:19 -0500 Subject: RFR (XS) 8217344 : Make comparison overflow-aware in ECDHKeyAgreement.engineGenerateSecret() In-Reply-To: <41a17a30-c364-b016-1857-4bf37df002cd@oracle.com> References: <41a17a30-c364-b016-1857-4bf37df002cd@oracle.com> Message-ID: <7d17fa98-c760-e07a-462c-9a76815feb3d@oracle.com> Looks good to me. On 1/17/2019 4:32 PM, Ivan Gerasimov wrote: > Hello! > > Would you please help review a trivial fix to avoid a possible > arithmetic overflow in comparison? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8217344 > WEBREV: http://cr.openjdk.java.net/~igerasim/8217344/00/webrev/ > > Thanks in advance! > From sean.mullan at oracle.com Fri Jan 18 16:09:40 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 18 Jan 2019 11:09:40 -0500 Subject: [13] RFR 8215937: Check usages of security-related Resources files In-Reply-To: <750E3A41-8D1C-4F9E-A854-253AB335AD87@oracle.com> References: <204CAB4B-B666-4B26-84E0-3F47875B3122@oracle.com> <750E3A41-8D1C-4F9E-A854-253AB335AD87@oracle.com> Message-ID: <9166d42d-2736-83b2-7207-da56c98703e2@oracle.com> On 1/17/19 9:23 PM, Weijun Wang wrote: > > >> On Jan 18, 2019, at 2:22 AM, Sean Mullan wrote: >> >> This is a nice cleanup. Just a couple of comments: >> >> - Update copyrights now that it is 2019 > > Will change. > >> >> - For the test, is the source code always guaranteed to be there? I was not sure if that was a requirement. Or does the test still pass if it can't find the source code? > > 132 public static void main(String[] args) { > 133 if (Files.exists(SRC)) { > 134 MAP.forEach(Usages::check); > 135 } else { > 136 System.out.println("No src directory. Test skipped."); > 137 } > 138 } Ok, good. --Sean > > But I remember asked about a similar case before and with Mach5 the src/ directory is always available. > > Thanks, > Max > >> >> Thanks, >> Sean >> >> On 12/27/18 3:11 AM, Weijun Wang wrote: >>> Please take a review at >>> https://cr.openjdk.java.net/~weijun/8215937/webrev.00/ >>> A new Usages.java test is added to make sure the strings in various Resources.java files are exactly what are used in security-related source files, no more no less. >>> Two old tests are removed. NewNamesFormat.java checks for format and Usages.java covers it. NewResourcesNames.java is a manual test and is too stale and not easy to run. >>> Several calls in keytool and jarsigner are modified to follow a more consistent calling convention (always rb.getString(string_literal)) so that they can be detected by Usages.java more easily. There are still several places in PolicyFile.java calling 'LocalizedMessage.getNonlocalized(POLICY + "...", source)' but I left them unchanged and dealt with it specially in Usages.java. >>> Many useless strings in Resources.java files are removed. I've double checked each and made sure the related calls were removed some time ago. >>> Thanks >>> Max > From sgehwolf at redhat.com Fri Jan 18 17:07:32 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 18 Jan 2019 18:07:32 +0100 Subject: JDK-8215102 (Follow-up) In-Reply-To: References: Message-ID: <07e6daa4a6a83133acb80d8a065836e13637b866.camel@redhat.com> On Thu, 2019-01-17 at 10:00 -0700, Dennis Gesker wrote: [...] > Added the -Djavax.net.debug=all option to my Wildfly startup and > waited for the pool to close a connection to MySql at AWS. > > TXT file attached. > > javac 11.0.1 > mysql jdbc driver 8.0.13 > wildfly 15.0.1 > > --drg Unfortunately the txt file got stripped by the mailing list. Would you be able to upload it somewhere and post a link? Thanks, Severin From dennis at gesker.com Sat Jan 19 19:08:08 2019 From: dennis at gesker.com (Dennis Gesker) Date: Sat, 19 Jan 2019 12:08:08 -0700 Subject: JDK-8215102 (Follow-up) In-Reply-To: <07e6daa4a6a83133acb80d8a065836e13637b866.camel@redhat.com> References: <07e6daa4a6a83133acb80d8a065836e13637b866.camel@redhat.com> Message-ID: Hi Severin: A link to the txt file via Google Drive his here . I appreciate you and Alan taking a look. Especially, information submitted from someone who is not a part of openjdk project. I do hope the debug info helps. Let me know anything else you need and I will do my best to provide it. And, should your team decide to open a new ticket or reopen this original ticket in the JIRA could you add me to the ticket? BTW, (off topic), would your recommend submitting a contributor application to the openjdk project so bug reports can be submitted directly? The dev group at my company is VERY small (and this message to your group at the project is from my personal email) but I'd be glad to submit bug reports as we come across them in our day to day use of Java. Cordially, Dennis dennis at gesker.com On Fri, Jan 18, 2019 at 10:07 AM Severin Gehwolf wrote: > On Thu, 2019-01-17 at 10:00 -0700, Dennis Gesker wrote: > [...] > > Added the -Djavax.net.debug=all option to my Wildfly startup and > > waited for the pool to close a connection to MySql at AWS. > > > > TXT file attached. > > > > javac 11.0.1 > > mysql jdbc driver 8.0.13 > > wildfly 15.0.1 > > > > --drg > > Unfortunately the txt file got stripped by the mailing list. Would you > be able to upload it somewhere and post a link? > > Thanks, > Severin > > -- Dennis R. Gesker [image: LinkedIn] [image: WordPress] [image: Gesker] [image: GPG_PGP] [image: dennis at gesker.com] ?Be without fear in the face of your enemies. Be brave and upright that God may love thee. Speak the truth always, even if it leads to your death. Safeguard the helpless and do no wrong ? that is your oath.?* -The Knight?s Oath (Kingdom of Heaven)* -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- 9:44:26,287 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.287 MST|SSLSocketOutputRecord.java:310|WRITE: TLS13 application_data, length = 44 09:44:26,288 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.287 MST|SSLCipher.java:2020|Plaintext before ENCRYPTION ( 09:44:26,288 ERROR [stderr] (Periodic Recovery) 0000: 50 00 00 00 08 00 00 00 00 42 00 00 00 0C 00 00 P........B...... 09:44:26,288 ERROR [stderr] (Periodic Recovery) 0010: 00 00 00 00 00 00 44 00 00 00 06 50 00 45 00 00 ......D....P.E.. 09:44:26,288 ERROR [stderr] (Periodic Recovery) 0020: 00 09 00 00 00 00 01 53 00 00 00 04 17 00 00 00 .......S........ 09:44:26,288 ERROR [stderr] (Periodic Recovery) 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 ............. 09:44:26,288 ERROR [stderr] (Periodic Recovery) ) 09:44:26,288 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.288 MST|SSLSocketOutputRecord.java:324|Raw write ( 09:44:26,288 ERROR [stderr] (Periodic Recovery) 0000: 17 03 03 00 4D 1B CD C3 D7 E9 09 72 2E 51 36 55 ....M......r.Q6U 09:44:26,288 ERROR [stderr] (Periodic Recovery) 0010: 59 D7 64 E8 80 28 F4 3A 48 7D 21 9B BF 0A 37 8F Y.d..(.:H.!...7. 09:44:26,288 ERROR [stderr] (Periodic Recovery) 0020: 74 23 C4 04 44 A3 30 6A 72 B5 5B 22 06 9C EE 06 t#..D.0jr.[".... 09:44:26,288 ERROR [stderr] (Periodic Recovery) 0030: 41 83 7F 10 49 29 B6 17 A3 46 24 BC 01 4D 7D 28 A...I)...F$..M.( 09:44:26,288 ERROR [stderr] (Periodic Recovery) 0040: 32 2E CA 92 DF 30 F6 A0 2F B7 CE 23 10 48 A1 B7 2....0../..#.H.. 09:44:26,288 ERROR [stderr] (Periodic Recovery) 0050: FB 3A .: 09:44:26,288 ERROR [stderr] (Periodic Recovery) ) 09:44:26,289 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.289 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,289 ERROR [stderr] (Periodic Recovery) 0000: 17 03 03 00 2B ....+ 09:44:26,289 ERROR [stderr] (Periodic Recovery) ) 09:44:26,289 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.289 MST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 43 09:44:26,289 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.289 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,289 ERROR [stderr] (Periodic Recovery) 0000: 77 B2 87 B3 93 28 C1 C0 C6 38 51 F3 3C 12 BE 88 w....(...8Q.<... 09:44:26,289 ERROR [stderr] (Periodic Recovery) 0010: A7 D3 1B 3A C7 82 BA 07 15 09 A8 41 F0 48 E7 7A ...:.......A.H.z 09:44:26,289 ERROR [stderr] (Periodic Recovery) 0020: 54 E6 F5 47 74 FF 52 D2 4A 2B 27 T..Gt.R.J+' 09:44:26,289 ERROR [stderr] (Periodic Recovery) ) 09:44:26,289 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.289 MST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 43 09:44:26,289 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.289 MST|SSLCipher.java:1915|Plaintext after DECRYPTION ( 09:44:26,289 ERROR [stderr] (Periodic Recovery) 0000: 31 00 00 00 04 32 00 00 00 04 6E 00 00 00 04 49 1....2....n....I 09:44:26,289 ERROR [stderr] (Periodic Recovery) 0010: 00 00 00 04 5A 00 00 00 05 49 ....Z....I 09:44:26,289 ERROR [stderr] (Periodic Recovery) ) 09:44:26,291 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.291 MST|SSLSocketOutputRecord.java:310|WRITE: TLS13 application_data, length = 44 09:44:26,291 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.291 MST|SSLCipher.java:2020|Plaintext before ENCRYPTION ( 09:44:26,291 ERROR [stderr] (Periodic Recovery) 0000: 50 00 00 00 08 00 00 00 00 42 00 00 00 0C 00 00 P........B...... 09:44:26,291 ERROR [stderr] (Periodic Recovery) 0010: 00 00 00 00 00 00 44 00 00 00 06 50 00 45 00 00 ......D....P.E.. 09:44:26,291 ERROR [stderr] (Periodic Recovery) 0020: 00 09 00 00 00 00 01 53 00 00 00 04 17 00 00 00 .......S........ 09:44:26,291 ERROR [stderr] (Periodic Recovery) 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 ............. 09:44:26,291 ERROR [stderr] (Periodic Recovery) ) 09:44:26,291 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.291 MST|SSLSocketOutputRecord.java:324|Raw write ( 09:44:26,291 ERROR [stderr] (Periodic Recovery) 0000: 17 03 03 00 4D 0F FE B7 BE F9 24 EC 0B 58 03 76 ....M.....$..X.v 09:44:26,291 ERROR [stderr] (Periodic Recovery) 0010: A1 53 95 29 92 87 0F C2 77 EC C1 56 69 BB 16 5F .S.)....w..Vi.._ 09:44:26,291 ERROR [stderr] (Periodic Recovery) 0020: 6B AD 2C 0F 19 60 FF 85 C2 34 8A 57 53 20 DF 08 k.,..`...4.WS .. 09:44:26,291 ERROR [stderr] (Periodic Recovery) 0030: 20 A3 E5 6E FC 69 FC C3 8D 03 67 18 EC 40 B1 C7 ..n.i....g.. at .. 09:44:26,291 ERROR [stderr] (Periodic Recovery) 0040: EB 2C BC A0 3B 60 44 0A EE 7A F6 E4 C6 29 2E F8 .,..;`D..z...).. 09:44:26,292 ERROR [stderr] (Periodic Recovery) 0050: 92 24 .$ 09:44:26,292 ERROR [stderr] (Periodic Recovery) ) 09:44:26,292 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.292 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,292 ERROR [stderr] (Periodic Recovery) 0000: 17 03 03 00 2B ....+ 09:44:26,292 ERROR [stderr] (Periodic Recovery) ) 09:44:26,292 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.292 MST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 43 09:44:26,292 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.292 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,292 ERROR [stderr] (Periodic Recovery) 0000: 9D 72 EA 29 AE EB 4F 6C 86 E0 97 45 51 9D 42 C2 .r.)..Ol...EQ.B. 09:44:26,292 ERROR [stderr] (Periodic Recovery) 0010: 4D 67 29 4C 76 14 95 73 6D B4 93 07 DD 33 08 D1 Mg)Lv..sm....3.. 09:44:26,292 ERROR [stderr] (Periodic Recovery) 0020: 2A 0A 2E 60 00 87 B2 B9 C0 36 44 *..`.....6D 09:44:26,292 ERROR [stderr] (Periodic Recovery) ) 09:44:26,292 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.292 MST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 43 09:44:26,292 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.292 MST|SSLCipher.java:1915|Plaintext after DECRYPTION ( 09:44:26,292 ERROR [stderr] (Periodic Recovery) 0000: 31 00 00 00 04 32 00 00 00 04 6E 00 00 00 04 49 1....2....n....I 09:44:26,292 ERROR [stderr] (Periodic Recovery) 0010: 00 00 00 04 5A 00 00 00 05 49 ....Z....I 09:44:26,292 ERROR [stderr] (Periodic Recovery) ) 09:44:26,293 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.293 MST|SSLSocketOutputRecord.java:310|WRITE: TLS13 application_data, length = 44 09:44:26,293 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.293 MST|SSLCipher.java:2020|Plaintext before ENCRYPTION ( 09:44:26,293 ERROR [stderr] (Periodic Recovery) 0000: 50 00 00 00 08 00 00 00 00 42 00 00 00 0C 00 00 P........B...... 09:44:26,293 ERROR [stderr] (Periodic Recovery) 0010: 00 00 00 00 00 00 44 00 00 00 06 50 00 45 00 00 ......D....P.E.. 09:44:26,293 ERROR [stderr] (Periodic Recovery) 0020: 00 09 00 00 00 00 01 53 00 00 00 04 17 00 00 00 .......S........ 09:44:26,293 ERROR [stderr] (Periodic Recovery) 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 ............. 09:44:26,293 ERROR [stderr] (Periodic Recovery) ) 09:44:26,294 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.294 MST|SSLSocketOutputRecord.java:324|Raw write ( 09:44:26,294 ERROR [stderr] (Periodic Recovery) 0000: 17 03 03 00 4D 48 C7 C1 46 E3 89 B6 68 E0 A4 B8 ....MH..F...h... 09:44:26,294 ERROR [stderr] (Periodic Recovery) 0010: 85 F7 76 45 40 15 20 A9 97 E0 1D 3F FF 15 86 AD ..vE at . ....?.... 09:44:26,294 ERROR [stderr] (Periodic Recovery) 0020: 63 0E AB 46 29 60 EC 04 45 B1 6B 6B 2C CC E7 CF c..F)`..E.kk,... 09:44:26,294 ERROR [stderr] (Periodic Recovery) 0030: 3C 1A A1 E1 45 D2 7D F2 A6 92 D4 88 37 CF AC 0B <...E.......7... 09:44:26,294 ERROR [stderr] (Periodic Recovery) 0040: E9 45 18 80 58 ED D4 8E 43 8D 9B E0 CF 95 20 6E .E..X...C..... n 09:44:26,294 ERROR [stderr] (Periodic Recovery) 0050: A0 B3 .. 09:44:26,294 ERROR [stderr] (Periodic Recovery) ) 09:44:26,294 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.294 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,295 ERROR [stderr] (Periodic Recovery) 0000: 17 03 03 00 2B ....+ 09:44:26,295 ERROR [stderr] (Periodic Recovery) ) 09:44:26,295 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.295 MST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 43 09:44:26,295 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.295 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,295 ERROR [stderr] (Periodic Recovery) 0000: EA 36 05 B3 39 0A 9C 41 F0 12 C7 CD 13 A5 79 29 .6..9..A......y) 09:44:26,295 ERROR [stderr] (Periodic Recovery) 0010: 6C E3 26 63 62 67 B3 B5 6B 5A 1A 84 C4 63 91 63 l.&cbg..kZ...c.c 09:44:26,295 ERROR [stderr] (Periodic Recovery) 0020: 73 6D A2 0B 4D 9C F4 FE F0 76 8F sm..M....v. 09:44:26,295 ERROR [stderr] (Periodic Recovery) ) 09:44:26,295 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.295 MST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 43 09:44:26,295 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.295 MST|SSLCipher.java:1915|Plaintext after DECRYPTION ( 09:44:26,295 ERROR [stderr] (Periodic Recovery) 0000: 31 00 00 00 04 32 00 00 00 04 6E 00 00 00 04 49 1....2....n....I 09:44:26,295 ERROR [stderr] (Periodic Recovery) 0010: 00 00 00 04 5A 00 00 00 05 49 ....Z....I 09:44:26,295 ERROR [stderr] (Periodic Recovery) ) 09:44:26,296 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.296 MST|SSLSocketOutputRecord.java:310|WRITE: TLS13 application_data, length = 44 09:44:26,301 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.296 MST|SSLCipher.java:2020|Plaintext before ENCRYPTION ( 09:44:26,301 ERROR [stderr] (Periodic Recovery) 0000: 50 00 00 00 08 00 00 00 00 42 00 00 00 0C 00 00 P........B...... 09:44:26,301 ERROR [stderr] (Periodic Recovery) 0010: 00 00 00 00 00 00 44 00 00 00 06 50 00 45 00 00 ......D....P.E.. 09:44:26,301 ERROR [stderr] (Periodic Recovery) 0020: 00 09 00 00 00 00 01 53 00 00 00 04 17 00 00 00 .......S........ 09:44:26,301 ERROR [stderr] (Periodic Recovery) 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 ............. 09:44:26,301 ERROR [stderr] (Periodic Recovery) ) 09:44:26,302 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.302 MST|SSLSocketOutputRecord.java:324|Raw write ( 09:44:26,302 ERROR [stderr] (Periodic Recovery) 0000: 17 03 03 00 4D AB 8E 2B E0 C1 26 3C 53 50 EE 76 ....M..+..&ZZp.... ....*.. 09:44:26,306 ERROR [stderr] (Periodic Recovery) 0020: 4E 80 C2 9C 4F N...O 09:44:26,306 ERROR [stderr] (Periodic Recovery) ) 09:44:26,447 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.447 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,447 ERROR [stderr] (Periodic Recovery) 0000: 17 03 01 00 20 .... 09:44:26,447 ERROR [stderr] (Periodic Recovery) ) 09:44:26,448 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.448 MST|SSLSocketInputRecord.java:213|READ: TLSv1 application_data, length = 32 09:44:26,448 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.448 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,448 ERROR [stderr] (Periodic Recovery) 0000: C5 2C 71 2C 25 D0 C9 CB 99 BE 96 1A D7 23 1F 16 .,q,%........#.. 09:44:26,448 ERROR [stderr] (Periodic Recovery) 0010: 28 32 CC 44 9D 66 FC C4 05 01 13 67 5D D9 02 A7 (2.D.f.....g]... 09:44:26,448 ERROR [stderr] (Periodic Recovery) ) 09:44:26,448 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.448 MST|SSLSocketInputRecord.java:249|READ: TLSv1 application_data, length = 32 09:44:26,448 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.448 MST|SSLCipher.java:1041|Padded plaintext after DECRYPTION ( 09:44:26,448 ERROR [stderr] (Periodic Recovery) 0000: 1E 41 17 0E 4B E6 2B AF AD 0D 47 94 80 50 E2 29 .A..K.+...G..P.) 09:44:26,448 ERROR [stderr] (Periodic Recovery) 0010: 50 21 AC E1 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B P!.............. 09:44:26,448 ERROR [stderr] (Periodic Recovery) ) 09:44:26,448 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.448 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,448 ERROR [stderr] (Periodic Recovery) 0000: 17 03 01 00 20 .... 09:44:26,448 ERROR [stderr] (Periodic Recovery) ) 09:44:26,448 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.448 MST|SSLSocketInputRecord.java:213|READ: TLSv1 application_data, length = 32 09:44:26,449 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.449 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,449 ERROR [stderr] (Periodic Recovery) 0000: 59 92 F2 A6 D5 58 B9 6A D8 AD 4A E2 84 41 F0 6C Y....X.j..J..A.l 09:44:26,449 ERROR [stderr] (Periodic Recovery) 0010: 83 B5 B6 C5 C2 27 E2 88 DE E7 78 78 E8 6E DB B4 .....'....xx.n.. 09:44:26,449 ERROR [stderr] (Periodic Recovery) ) 09:44:26,449 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.449 MST|SSLSocketInputRecord.java:249|READ: TLSv1 application_data, length = 32 09:44:26,449 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.449 MST|SSLCipher.java:1041|Padded plaintext after DECRYPTION ( 09:44:26,449 ERROR [stderr] (Periodic Recovery) 0000: 07 00 00 01 00 00 00 02 00 00 00 95 6A 2F 49 84 ............j/I. 09:44:26,449 ERROR [stderr] (Periodic Recovery) 0010: 00 3B 30 3C 23 1D E2 CE 9C 52 DA A0 A2 EF 3A 00 .;0<#....R....:. 09:44:26,449 ERROR [stderr] (Periodic Recovery) ) 09:44:26,450 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.449 MST|SSLSocketOutputRecord.java:310|WRITE: TLS13 application_data, length = 44 09:44:26,450 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.450 MST|SSLCipher.java:2020|Plaintext before ENCRYPTION ( 09:44:26,450 ERROR [stderr] (Periodic Recovery) 0000: 50 00 00 00 08 00 00 00 00 42 00 00 00 0C 00 00 P........B...... 09:44:26,450 ERROR [stderr] (Periodic Recovery) 0010: 00 00 00 00 00 00 44 00 00 00 06 50 00 45 00 00 ......D....P.E.. 09:44:26,450 ERROR [stderr] (Periodic Recovery) 0020: 00 09 00 00 00 00 01 53 00 00 00 04 17 00 00 00 .......S........ 09:44:26,450 ERROR [stderr] (Periodic Recovery) 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 ............. 09:44:26,450 ERROR [stderr] (Periodic Recovery) ) 09:44:26,450 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.450 MST|SSLSocketOutputRecord.java:324|Raw write ( 09:44:26,450 ERROR [stderr] (Periodic Recovery) 0000: 17 03 03 00 4D 0F 24 A4 C5 7F FD 77 81 E5 C6 84 ....M.$....w.... 09:44:26,450 ERROR [stderr] (Periodic Recovery) 0010: EC CC 91 42 F6 6E 81 CC 1A 74 C0 4E B5 C5 CD 84 ...B.n...t.N.... 09:44:26,450 ERROR [stderr] (Periodic Recovery) 0020: 2B 87 07 4B 62 56 C4 69 BF 76 FD A0 2E 80 AD 5A +..KbV.i.v.....Z 09:44:26,450 ERROR [stderr] (Periodic Recovery) 0030: 02 25 B9 D8 B7 C2 8C EB 9A 48 14 74 C6 96 8C D1 .%.......H.t.... 09:44:26,450 ERROR [stderr] (Periodic Recovery) 0040: 81 6C 62 40 55 37 B1 2E C9 FF FF 12 48 67 55 66 .lb at U7......HgUf 09:44:26,450 ERROR [stderr] (Periodic Recovery) 0050: 9A B6 .. 09:44:26,450 ERROR [stderr] (Periodic Recovery) ) 09:44:26,450 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.450 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,450 ERROR [stderr] (Periodic Recovery) 0000: 17 03 03 00 2B ....+ 09:44:26,450 ERROR [stderr] (Periodic Recovery) ) 09:44:26,451 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.450 MST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 43 09:44:26,451 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.451 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,451 ERROR [stderr] (Periodic Recovery) 0000: 60 06 35 86 35 D6 54 0B 0C BD 03 1B 70 B7 01 90 `.5.5.T.....p... 09:44:26,451 ERROR [stderr] (Periodic Recovery) 0010: 49 B9 F4 F7 A4 BE 31 A2 3C 76 9C 1E FC 9E 12 7A I.....1....4. 09:44:26,454 ERROR [stderr] (Periodic Recovery) ) 09:44:26,455 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.455 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,455 ERROR [stderr] (Periodic Recovery) 0000: 17 03 03 00 4C ....L 09:44:26,455 ERROR [stderr] (Periodic Recovery) ) 09:44:26,455 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.455 MST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 76 09:44:26,456 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.455 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,456 ERROR [stderr] (Periodic Recovery) 0000: 33 2C B1 22 C2 CD AE 50 65 31 29 D3 AF D7 A5 17 3,."...Pe1)..... 09:44:26,456 ERROR [stderr] (Periodic Recovery) 0010: 95 6A 38 61 6C 48 ED 25 7F 4F FE 4C F2 4F 29 A5 .j8alH.%.O.L.O). 09:44:26,456 ERROR [stderr] (Periodic Recovery) 0020: 05 C2 75 39 39 91 60 AB CB CE C5 54 0C 53 07 1D ..u99.`....T.S.. 09:44:26,456 ERROR [stderr] (Periodic Recovery) 0030: A3 0A B8 C6 13 2A 92 C4 3D 05 3A 2F 33 D8 C3 C0 .....*..=.:/3... 09:44:26,456 ERROR [stderr] (Periodic Recovery) 0040: 20 AD 48 DE BE DA D4 FD C1 D1 FC 7E .H......... 09:44:26,456 ERROR [stderr] (Periodic Recovery) ) 09:44:26,456 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.456 MST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 76 09:44:26,456 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.456 MST|SSLCipher.java:1915|Plaintext after DECRYPTION ( 09:44:26,456 ERROR [stderr] (Periodic Recovery) 0000: 31 00 00 00 04 32 00 00 00 04 54 00 00 00 1C 00 1....2....T..... 09:44:26,456 ERROR [stderr] (Periodic Recovery) 0010: 01 67 69 64 00 00 00 2D 89 00 02 00 00 00 19 FF .gid...-........ 09:44:26,456 ERROR [stderr] (Periodic Recovery) 0020: FF FF FF FF FF 00 00 43 00 00 00 0D 53 45 4C 45 .......C....SELE 09:44:26,456 ERROR [stderr] (Periodic Recovery) 0030: 43 54 20 30 00 5A 00 00 00 05 49 CT 0.Z....I 09:44:26,456 ERROR [stderr] (Periodic Recovery) ) 09:44:26,457 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.457 MST|SSLSocketOutputRecord.java:310|WRITE: TLS13 application_data, length = 113 09:44:26,457 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.457 MST|SSLCipher.java:2020|Plaintext before ENCRYPTION ( 09:44:26,457 ERROR [stderr] (Periodic Recovery) 0000: 50 00 00 00 4D 00 53 45 4C 45 43 54 20 67 69 64 P...M.SELECT gid 09:44:26,457 ERROR [stderr] (Periodic Recovery) 0010: 20 46 52 4F 4D 20 70 67 5F 70 72 65 70 61 72 65 FROM pg_prepare 09:44:26,457 ERROR [stderr] (Periodic Recovery) 0020: 64 5F 78 61 63 74 73 20 77 68 65 72 65 20 64 61 d_xacts where da 09:44:26,457 ERROR [stderr] (Periodic Recovery) 0030: 74 61 62 61 73 65 20 3D 20 63 75 72 72 65 6E 74 tabase = current 09:44:26,457 ERROR [stderr] (Periodic Recovery) 0040: 5F 64 61 74 61 62 61 73 65 28 29 00 00 00 42 00 _database()...B. 09:44:26,457 ERROR [stderr] (Periodic Recovery) 0050: 00 00 0C 00 00 00 00 00 00 00 00 44 00 00 00 06 ...........D.... 09:44:26,457 ERROR [stderr] (Periodic Recovery) 0060: 50 00 45 00 00 00 09 00 00 00 00 00 53 00 00 00 P.E.........S... 09:44:26,457 ERROR [stderr] (Periodic Recovery) 0070: 04 17 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 09:44:26,457 ERROR [stderr] (Periodic Recovery) 0080: 00 00 .. 09:44:26,457 ERROR [stderr] (Periodic Recovery) ) 09:44:26,457 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.457 MST|SSLSocketOutputRecord.java:324|Raw write ( 09:44:26,457 ERROR [stderr] (Periodic Recovery) 0000: 17 03 03 00 92 49 A9 F2 F5 A8 4A FD 32 EB B1 43 .....I....J.2..C 09:44:26,457 ERROR [stderr] (Periodic Recovery) 0010: A2 DE 2E 7E 12 93 A4 B3 66 C7 41 30 9E 3F 46 C4 ........f.A0.?F. 09:44:26,458 ERROR [stderr] (Periodic Recovery) 0020: 77 9D 5A 3A 39 53 2F 51 BE 9F 22 E7 92 2B 96 F6 w.Z:9S/Q.."..+.. 09:44:26,458 ERROR [stderr] (Periodic Recovery) 0030: 62 DD 8F 9D 0A 25 92 5E 78 34 6F 4E D0 73 3A 9C b....%.^x4oN.s:. 09:44:26,458 ERROR [stderr] (Periodic Recovery) 0040: E5 2E 9B 31 9F 9D 28 8E 65 A1 19 9F D3 3B 8D 8E ...1..(.e....;.. 09:44:26,458 ERROR [stderr] (Periodic Recovery) 0050: CC 04 E6 EB F9 72 2C B8 78 8D 82 DB 06 19 99 BF .....r,.x....... 09:44:26,458 ERROR [stderr] (Periodic Recovery) 0060: B1 DC FB 5C DD E9 D3 5C C1 78 E3 9E 18 85 09 63 ...\...\.x.....c 09:44:26,458 ERROR [stderr] (Periodic Recovery) 0070: C6 93 CC C9 8A FB 01 45 AA 63 FD 70 71 96 2F F6 .......E.c.pq./. 09:44:26,458 ERROR [stderr] (Periodic Recovery) 0080: 96 9C FD 43 B1 55 01 A6 E4 CE 70 E2 94 DB 3A 0E ...C.U....p...:. 09:44:26,458 ERROR [stderr] (Periodic Recovery) 0090: 54 F9 6A 4E C0 DC 74 T.jN..t 09:44:26,458 ERROR [stderr] (Periodic Recovery) ) 09:44:26,458 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.458 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,458 ERROR [stderr] (Periodic Recovery) 0000: 17 03 03 00 4C ....L 09:44:26,458 ERROR [stderr] (Periodic Recovery) ) 09:44:26,458 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.458 MST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 76 09:44:26,459 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.458 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,459 ERROR [stderr] (Periodic Recovery) 0000: 32 B5 18 A6 66 17 08 D9 19 B3 AC D9 7E 26 05 92 2...f........&.. 09:44:26,459 ERROR [stderr] (Periodic Recovery) 0010: B2 E0 FD 76 4C E1 83 99 9F B3 B5 4C 96 C6 8A 16 ...vL......L.... 09:44:26,459 ERROR [stderr] (Periodic Recovery) 0020: 2E 4D 60 D9 11 13 20 C8 14 EE B1 72 57 17 06 30 .M`... ....rW..0 09:44:26,459 ERROR [stderr] (Periodic Recovery) 0030: 9F 46 B4 CD 95 46 5A 91 23 43 5F 3F CF D7 EF 5F .F...FZ.#C_?..._ 09:44:26,459 ERROR [stderr] (Periodic Recovery) 0040: 24 3F 9F 1B 5C F5 7A 5C DD CF 70 AA $?..\.z\..p. 09:44:26,459 ERROR [stderr] (Periodic Recovery) ) 09:44:26,459 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.459 MST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 76 09:44:26,459 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.459 MST|SSLCipher.java:1915|Plaintext after DECRYPTION ( 09:44:26,459 ERROR [stderr] (Periodic Recovery) 0000: 31 00 00 00 04 32 00 00 00 04 54 00 00 00 1C 00 1....2....T..... 09:44:26,459 ERROR [stderr] (Periodic Recovery) 0010: 01 67 69 64 00 00 00 2D 89 00 02 00 00 00 19 FF .gid...-........ 09:44:26,459 ERROR [stderr] (Periodic Recovery) 0020: FF FF FF FF FF 00 00 43 00 00 00 0D 53 45 4C 45 .......C....SELE 09:44:26,459 ERROR [stderr] (Periodic Recovery) 0030: 43 54 20 30 00 5A 00 00 00 05 49 CT 0.Z....I 09:44:26,459 ERROR [stderr] (Periodic Recovery) ) 09:44:26,460 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.459 MST|SSLSocketOutputRecord.java:310|WRITE: TLS13 application_data, length = 113 09:44:26,460 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.460 MST|SSLCipher.java:2020|Plaintext before ENCRYPTION ( 09:44:26,460 ERROR [stderr] (Periodic Recovery) 0000: 50 00 00 00 4D 00 53 45 4C 45 43 54 20 67 69 64 P...M.SELECT gid 09:44:26,460 ERROR [stderr] (Periodic Recovery) 0010: 20 46 52 4F 4D 20 70 67 5F 70 72 65 70 61 72 65 FROM pg_prepare 09:44:26,460 ERROR [stderr] (Periodic Recovery) 0020: 64 5F 78 61 63 74 73 20 77 68 65 72 65 20 64 61 d_xacts where da 09:44:26,460 ERROR [stderr] (Periodic Recovery) 0030: 74 61 62 61 73 65 20 3D 20 63 75 72 72 65 6E 74 tabase = current 09:44:26,460 ERROR [stderr] (Periodic Recovery) 0040: 5F 64 61 74 61 62 61 73 65 28 29 00 00 00 42 00 _database()...B. 09:44:26,460 ERROR [stderr] (Periodic Recovery) 0050: 00 00 0C 00 00 00 00 00 00 00 00 44 00 00 00 06 ...........D.... 09:44:26,460 ERROR [stderr] (Periodic Recovery) 0060: 50 00 45 00 00 00 09 00 00 00 00 00 53 00 00 00 P.E.........S... 09:44:26,460 ERROR [stderr] (Periodic Recovery) 0070: 04 17 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 09:44:26,460 ERROR [stderr] (Periodic Recovery) 0080: 00 00 .. 09:44:26,460 ERROR [stderr] (Periodic Recovery) ) 09:44:26,460 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.460 MST|SSLSocketOutputRecord.java:324|Raw write ( 09:44:26,460 ERROR [stderr] (Periodic Recovery) 0000: 17 03 03 00 92 41 44 45 F9 36 58 C9 6E 81 40 D8 .....ADE.6X.n. at . 09:44:26,460 ERROR [stderr] (Periodic Recovery) 0010: 24 AE BA 4F 2C D4 94 A5 95 62 FC FA 4B 5A 37 FB $..O,....b..KZ7. 09:44:26,460 ERROR [stderr] (Periodic Recovery) 0020: BB 7C EF 72 82 67 E7 9F EC 0D CB E6 C4 BB 6E FA ...r.g........n. 09:44:26,460 ERROR [stderr] (Periodic Recovery) 0030: 0C 8A 71 F9 11 B9 59 6C BD 92 B4 FD 16 F7 E2 A2 ..q...Yl........ 09:44:26,460 ERROR [stderr] (Periodic Recovery) 0040: 76 94 50 17 8E C8 DF 2B B2 3D 73 C6 8D 96 73 FC v.P....+.=s...s. 09:44:26,460 ERROR [stderr] (Periodic Recovery) 0050: 31 20 B2 FF 6E 6D B2 ED B2 67 30 3A 9B 18 D0 BA 1 ..nm...g0:.... 09:44:26,460 ERROR [stderr] (Periodic Recovery) 0060: 05 E3 5B 88 64 03 04 B0 41 F4 39 0A 16 79 C1 AE ..[.d...A.9..y.. 09:44:26,460 ERROR [stderr] (Periodic Recovery) 0070: 2D 67 CA A6 B0 B1 92 94 7A 5A B8 E1 A6 36 0B DC -g......zZ...6.. 09:44:26,460 ERROR [stderr] (Periodic Recovery) 0080: 00 63 B5 11 B8 1B FE E5 00 9A CD 9A 87 B2 DB 1B .c.............. 09:44:26,460 ERROR [stderr] (Periodic Recovery) 0090: 5F 97 80 76 66 E3 E7 _..vf.. 09:44:26,460 ERROR [stderr] (Periodic Recovery) ) 09:44:26,463 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.463 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,463 ERROR [stderr] (Periodic Recovery) 0000: 17 03 03 00 4C ....L 09:44:26,463 ERROR [stderr] (Periodic Recovery) ) 09:44:26,463 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.463 MST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 76 09:44:26,463 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.463 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,463 ERROR [stderr] (Periodic Recovery) 0000: C0 7B D7 CE 4C 79 37 DB CE 56 80 5F 5C 49 1D 7E ....Ly7..V._\I.. 09:44:26,463 ERROR [stderr] (Periodic Recovery) 0010: 8C 64 07 E5 C0 98 6B F8 88 D1 01 4F 11 08 E1 A6 .d....k....O.... 09:44:26,463 ERROR [stderr] (Periodic Recovery) 0020: F3 6B 8B 26 DB 8B 89 7F 4A D0 5E 42 ED 8B 28 9B .k.&....J.^B..(. 09:44:26,463 ERROR [stderr] (Periodic Recovery) 0030: 80 AD 3C B0 22 97 C6 6C 91 D7 CC 2C 4D 51 38 E1 ..<."..l...,MQ8. 09:44:26,463 ERROR [stderr] (Periodic Recovery) 0040: F1 8D AB 58 1D 1B 99 51 A3 DA 26 1C ...X...Q..&. 09:44:26,464 ERROR [stderr] (Periodic Recovery) ) 09:44:26,464 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.464 MST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 76 09:44:26,464 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.464 MST|SSLCipher.java:1915|Plaintext after DECRYPTION ( 09:44:26,464 ERROR [stderr] (Periodic Recovery) 0000: 31 00 00 00 04 32 00 00 00 04 54 00 00 00 1C 00 1....2....T..... 09:44:26,464 ERROR [stderr] (Periodic Recovery) 0010: 01 67 69 64 00 00 00 2D 89 00 02 00 00 00 19 FF .gid...-........ 09:44:26,464 ERROR [stderr] (Periodic Recovery) 0020: FF FF FF FF FF 00 00 43 00 00 00 0D 53 45 4C 45 .......C....SELE 09:44:26,464 ERROR [stderr] (Periodic Recovery) 0030: 43 54 20 30 00 5A 00 00 00 05 49 CT 0.Z....I 09:44:26,464 ERROR [stderr] (Periodic Recovery) ) 09:44:26,464 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.464 MST|SSLSocketOutputRecord.java:310|WRITE: TLS13 application_data, length = 113 09:44:26,465 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.464 MST|SSLCipher.java:2020|Plaintext before ENCRYPTION ( 09:44:26,465 ERROR [stderr] (Periodic Recovery) 0000: 50 00 00 00 4D 00 53 45 4C 45 43 54 20 67 69 64 P...M.SELECT gid 09:44:26,465 ERROR [stderr] (Periodic Recovery) 0010: 20 46 52 4F 4D 20 70 67 5F 70 72 65 70 61 72 65 FROM pg_prepare 09:44:26,465 ERROR [stderr] (Periodic Recovery) 0020: 64 5F 78 61 63 74 73 20 77 68 65 72 65 20 64 61 d_xacts where da 09:44:26,465 ERROR [stderr] (Periodic Recovery) 0030: 74 61 62 61 73 65 20 3D 20 63 75 72 72 65 6E 74 tabase = current 09:44:26,465 ERROR [stderr] (Periodic Recovery) 0040: 5F 64 61 74 61 62 61 73 65 28 29 00 00 00 42 00 _database()...B. 09:44:26,465 ERROR [stderr] (Periodic Recovery) 0050: 00 00 0C 00 00 00 00 00 00 00 00 44 00 00 00 06 ...........D.... 09:44:26,465 ERROR [stderr] (Periodic Recovery) 0060: 50 00 45 00 00 00 09 00 00 00 00 00 53 00 00 00 P.E.........S... 09:44:26,465 ERROR [stderr] (Periodic Recovery) 0070: 04 17 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 09:44:26,465 ERROR [stderr] (Periodic Recovery) 0080: 00 00 .. 09:44:26,465 ERROR [stderr] (Periodic Recovery) ) 09:44:26,466 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.466 MST|SSLSocketOutputRecord.java:324|Raw write ( 09:44:26,466 ERROR [stderr] (Periodic Recovery) 0000: 17 03 03 00 92 87 8B 5F 6C 50 75 09 17 0C 4F 05 ......._lPu...O. 09:44:26,466 ERROR [stderr] (Periodic Recovery) 0010: 4F D6 86 07 49 2E 34 8E 7A 84 0D 4B F1 53 87 5B O...I.4.z..K.S.[ 09:44:26,466 ERROR [stderr] (Periodic Recovery) 0020: 5D 63 97 50 D5 67 DE E6 27 81 7D 94 CD F7 4E 63 ]c.P.g..'.....Nc 09:44:26,466 ERROR [stderr] (Periodic Recovery) 0030: 4E 75 F1 27 F0 4E D2 AE 7E 2C 06 71 42 77 D1 A3 Nu.'.N...,.qBw.. 09:44:26,466 ERROR [stderr] (Periodic Recovery) 0040: AE CE 79 75 E5 17 70 1E 06 EC 8F 9D 9F 46 45 8D ..yu..p......FE. 09:44:26,466 ERROR [stderr] (Periodic Recovery) 0050: 48 3C 14 52 AB 25 9B 0F 5B 2F D4 6A 61 E3 30 A5 H<.R.%..[/.ja.0. 09:44:26,466 ERROR [stderr] (Periodic Recovery) 0060: 36 42 52 FE 40 5D A7 25 4A EE F8 5F EF 05 F5 F5 6BR.@].%J.._.... 09:44:26,466 ERROR [stderr] (Periodic Recovery) 0070: DA D2 4F BA 9E 1E 09 21 FD 5A 5B E1 90 78 6F D3 ..O....!.Z[..xo. 09:44:26,466 ERROR [stderr] (Periodic Recovery) 0080: DB 7F 18 12 C8 4C A1 4F 58 15 50 57 F0 B8 1F 9E .....L.OX.PW.... 09:44:26,466 ERROR [stderr] (Periodic Recovery) 0090: 7E 3D F0 C9 28 87 AE .=..(.. 09:44:26,466 ERROR [stderr] (Periodic Recovery) ) 09:44:26,466 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.466 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,466 ERROR [stderr] (Periodic Recovery) 0000: 17 03 03 00 4C ....L 09:44:26,466 ERROR [stderr] (Periodic Recovery) ) 09:44:26,466 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.466 MST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 76 09:44:26,466 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.466 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,466 ERROR [stderr] (Periodic Recovery) 0000: 5A 5A CA CB 39 70 C7 E3 A5 03 4F A5 3B C3 EF 50 ZZ..9p....O.;..P 09:44:26,466 ERROR [stderr] (Periodic Recovery) 0010: 22 FA DC 6F 9E 1A BC 90 32 53 DC E8 E8 5C EA 2A "..o....2S...\.* 09:44:26,466 ERROR [stderr] (Periodic Recovery) 0020: 1F 64 8D 62 C3 2E 95 BE 37 CE 23 56 84 B6 73 7A .d.b....7.#V..sz 09:44:26,466 ERROR [stderr] (Periodic Recovery) 0030: EB 75 A4 96 F1 CC C9 02 08 EE 00 74 07 E1 6F 56 .u.........t..oV 09:44:26,466 ERROR [stderr] (Periodic Recovery) 0040: 24 95 FD B0 40 3E 97 9F 9A A3 FA E2 $...@>...... 09:44:26,466 ERROR [stderr] (Periodic Recovery) ) 09:44:26,467 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.466 MST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 76 09:44:26,467 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.467 MST|SSLCipher.java:1915|Plaintext after DECRYPTION ( 09:44:26,467 ERROR [stderr] (Periodic Recovery) 0000: 31 00 00 00 04 32 00 00 00 04 54 00 00 00 1C 00 1....2....T..... 09:44:26,467 ERROR [stderr] (Periodic Recovery) 0010: 01 67 69 64 00 00 00 2D 89 00 02 00 00 00 19 FF .gid...-........ 09:44:26,467 ERROR [stderr] (Periodic Recovery) 0020: FF FF FF FF FF 00 00 43 00 00 00 0D 53 45 4C 45 .......C....SELE 09:44:26,467 ERROR [stderr] (Periodic Recovery) 0030: 43 54 20 30 00 5A 00 00 00 05 49 CT 0.Z....I 09:44:26,467 ERROR [stderr] (Periodic Recovery) ) 09:44:26,467 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.467 MST|SSLSocketOutputRecord.java:310|WRITE: TLS10 application_data, length = 1 09:44:26,468 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.467 MST|SSLCipher.java:1173|Padded plaintext before ENCRYPTION ( 09:44:26,468 ERROR [stderr] (Periodic Recovery) 0000: 0B E3 37 44 2A 17 00 A4 21 E7 69 B8 E8 0C DD 52 ..7D*...!.i....R 09:44:26,468 ERROR [stderr] (Periodic Recovery) 0010: 81 A5 15 5C 70 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A ...\p........... 09:44:26,468 ERROR [stderr] (Periodic Recovery) ) 09:44:26,468 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.468 MST|SSLSocketOutputRecord.java:324|Raw write ( 09:44:26,468 ERROR [stderr] (Periodic Recovery) 0000: 17 03 01 00 20 74 D4 C2 7D CA FF D6 0C 0C E3 C0 .... t.......... 09:44:26,468 ERROR [stderr] (Periodic Recovery) 0010: 50 79 EA 3C 24 D6 9F 17 B8 3B B8 5B 90 44 4D 5A Py.<$....;.[.DMZ 09:44:26,468 ERROR [stderr] (Periodic Recovery) 0020: 4B FA 8E 2F FD K../. 09:44:26,468 ERROR [stderr] (Periodic Recovery) ) 09:44:26,468 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.468 MST|SSLSocketOutputRecord.java:310|WRITE: TLS10 application_data, length = 14 09:44:26,468 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.468 MST|SSLCipher.java:1173|Padded plaintext before ENCRYPTION ( 09:44:26,468 ERROR [stderr] (Periodic Recovery) 0000: 00 00 00 03 58 41 20 52 45 43 4F 56 45 52 C4 C1 ....XA RECOVER.. 09:44:26,468 ERROR [stderr] (Periodic Recovery) 0010: C7 24 2E C0 DF 82 E9 6B E3 79 C8 E2 FE 94 A6 C2 .$.....k.y...... 09:44:26,468 ERROR [stderr] (Periodic Recovery) 0020: 7D 5F 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D ._.............. 09:44:26,468 ERROR [stderr] (Periodic Recovery) ) 09:44:26,468 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.468 MST|SSLSocketOutputRecord.java:324|Raw write ( 09:44:26,468 ERROR [stderr] (Periodic Recovery) 0000: 17 03 01 00 30 29 B0 1A 2A 35 82 23 C8 7F BE F7 ....0)..*5.#.... 09:44:26,468 ERROR [stderr] (Periodic Recovery) 0010: A2 BC 4D 4B C1 21 18 77 4D D7 91 EC 8E 6E F2 B4 ..MK.!.wM....n.. 09:44:26,468 ERROR [stderr] (Periodic Recovery) 0020: 15 CC AB 7C 19 3C CA 76 4E 87 E5 76 77 BE 01 2E .....<.vN..vw... 09:44:26,468 ERROR [stderr] (Periodic Recovery) 0030: 4A 51 63 27 C6 JQc'. 09:44:26,468 ERROR [stderr] (Periodic Recovery) ) 09:44:26,602 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.602 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,602 ERROR [stderr] (Periodic Recovery) 0000: 17 03 01 00 20 .... 09:44:26,602 ERROR [stderr] (Periodic Recovery) ) 09:44:26,602 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.602 MST|SSLSocketInputRecord.java:213|READ: TLSv1 application_data, length = 32 09:44:26,602 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.602 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,602 ERROR [stderr] (Periodic Recovery) 0000: 82 66 38 70 20 09 A2 2A 6A CD 28 B3 28 E0 C9 C8 .f8p ..*j.(.(... 09:44:26,602 ERROR [stderr] (Periodic Recovery) 0010: 56 D1 C1 E5 C1 48 48 DD D8 4E 62 DA AA 0E 10 07 V....HH..Nb..... 09:44:26,602 ERROR [stderr] (Periodic Recovery) ) 09:44:26,602 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.602 MST|SSLSocketInputRecord.java:249|READ: TLSv1 application_data, length = 32 09:44:26,603 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.602 MST|SSLCipher.java:1041|Padded plaintext after DECRYPTION ( 09:44:26,603 ERROR [stderr] (Periodic Recovery) 0000: 89 64 BC C0 44 9B D0 2B 7B 70 15 DF 21 5D 20 21 .d..D..+.p..!] ! 09:44:26,603 ERROR [stderr] (Periodic Recovery) 0010: 9B 02 BF 17 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B ................ 09:44:26,603 ERROR [stderr] (Periodic Recovery) ) 09:44:26,603 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.603 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,603 ERROR [stderr] (Periodic Recovery) 0000: 17 03 01 00 C0 ..... 09:44:26,603 ERROR [stderr] (Periodic Recovery) ) 09:44:26,603 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.603 MST|SSLSocketInputRecord.java:213|READ: TLSv1 application_data, length = 192 09:44:26,603 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.603 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,603 ERROR [stderr] (Periodic Recovery) 0000: 91 55 F3 BD ED 63 16 64 49 43 D1 76 3D 48 71 F7 .U...c.dIC.v=Hq. 09:44:26,603 ERROR [stderr] (Periodic Recovery) 0010: 23 CE 9B D1 7C 89 E6 51 F2 47 1D A1 C8 72 60 81 #......Q.G...r`. 09:44:26,603 ERROR [stderr] (Periodic Recovery) 0020: 75 00 4B 0B 9D FA 1F E8 8A A8 CF BD C0 41 81 46 u.K..........A.F 09:44:26,603 ERROR [stderr] (Periodic Recovery) 0030: 09 92 12 89 F7 BD 8C 63 FB 61 2F 7C 38 F3 01 B6 .......c.a/.8... 09:44:26,603 ERROR [stderr] (Periodic Recovery) 0040: 7B 1E 6A D9 41 6A 76 31 D6 1F 6D 09 A9 80 36 48 ..j.Ajv1..m...6H 09:44:26,603 ERROR [stderr] (Periodic Recovery) 0050: BF DC 1F E5 99 DE C2 8F EA A7 E2 F1 DF CA A6 33 ...............3 09:44:26,603 ERROR [stderr] (Periodic Recovery) 0060: CB B4 BF 66 1D 0B EA AD E5 50 29 6D 25 37 9A CC ...f.....P)m%7.. 09:44:26,603 ERROR [stderr] (Periodic Recovery) 0070: 79 4E 86 4B F5 FB 2B 96 A2 1A 5B 29 FC 15 6B 96 yN.K..+...[)..k. 09:44:26,603 ERROR [stderr] (Periodic Recovery) 0080: D3 50 1B 63 41 83 27 D9 7F 81 CA 4C 71 7B EC 37 .P.cA.'....Lq..7 09:44:26,603 ERROR [stderr] (Periodic Recovery) 0090: 93 FF B1 E9 9D A1 5E 3B 2D 16 72 31 69 B1 5B 67 ......^;-.r1i.[g 09:44:26,603 ERROR [stderr] (Periodic Recovery) 00A0: 9D FC 19 0A 23 0E 9C 2F 24 09 73 89 97 02 6E DC ....#../$.s...n. 09:44:26,603 ERROR [stderr] (Periodic Recovery) 00B0: 3C 6F 4D 6D FA 5B D0 38 84 3F CE D1 D3 B5 73 E7 .lHh.FP.. 09:44:26,606 ERROR [stderr] (Periodic Recovery) 0080: FE F5 46 CE AA FC 30 22 93 2C 23 21 C4 30 E2 25 ..F...0".,#!.0.% 09:44:26,606 ERROR [stderr] (Periodic Recovery) 0090: 21 C6 15 66 79 C5 CF !..fy.. 09:44:26,606 ERROR [stderr] (Periodic Recovery) ) 09:44:26,606 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.606 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,606 ERROR [stderr] (Periodic Recovery) 0000: 17 03 03 00 4C ....L 09:44:26,606 ERROR [stderr] (Periodic Recovery) ) 09:44:26,607 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.606 MST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 76 09:44:26,607 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.607 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,607 ERROR [stderr] (Periodic Recovery) 0000: F3 58 51 DD 1C 1D 9F 7E 50 9E E9 F7 C2 23 A4 61 .XQ.....P....#.a 09:44:26,607 ERROR [stderr] (Periodic Recovery) 0010: DE 54 39 F0 02 0F 56 64 E3 A9 33 7A 7E 1B 4F BC .T9...Vd..3z..O. 09:44:26,607 ERROR [stderr] (Periodic Recovery) 0020: 16 16 0B A3 E9 E8 C8 A7 59 1A 49 2F 94 A6 DA DD ........Y.I/.... 09:44:26,607 ERROR [stderr] (Periodic Recovery) 0030: 9F 08 DF 36 67 B4 78 54 5E A6 59 28 98 06 62 DB ...6g.xT^.Y(..b. 09:44:26,607 ERROR [stderr] (Periodic Recovery) 0040: 30 A1 5A 40 21 B5 73 3F D8 4C 80 1F 0.Z@!.s?.L.. 09:44:26,607 ERROR [stderr] (Periodic Recovery) ) 09:44:26,607 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.607 MST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 76 09:44:26,607 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.607 MST|SSLCipher.java:1915|Plaintext after DECRYPTION ( 09:44:26,607 ERROR [stderr] (Periodic Recovery) 0000: 31 00 00 00 04 32 00 00 00 04 54 00 00 00 1C 00 1....2....T..... 09:44:26,607 ERROR [stderr] (Periodic Recovery) 0010: 01 67 69 64 00 00 00 2D 89 00 02 00 00 00 19 FF .gid...-........ 09:44:26,607 ERROR [stderr] (Periodic Recovery) 0020: FF FF FF FF FF 00 00 43 00 00 00 0D 53 45 4C 45 .......C....SELE 09:44:26,607 ERROR [stderr] (Periodic Recovery) 0030: 43 54 20 30 00 5A 00 00 00 05 49 CT 0.Z....I 09:44:26,607 ERROR [stderr] (Periodic Recovery) ) 09:44:26,608 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.607 MST|SSLSocketOutputRecord.java:310|WRITE: TLS13 application_data, length = 113 09:44:26,608 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.608 MST|SSLCipher.java:2020|Plaintext before ENCRYPTION ( 09:44:26,608 ERROR [stderr] (Periodic Recovery) 0000: 50 00 00 00 4D 00 53 45 4C 45 43 54 20 67 69 64 P...M.SELECT gid 09:44:26,608 ERROR [stderr] (Periodic Recovery) 0010: 20 46 52 4F 4D 20 70 67 5F 70 72 65 70 61 72 65 FROM pg_prepare 09:44:26,608 ERROR [stderr] (Periodic Recovery) 0020: 64 5F 78 61 63 74 73 20 77 68 65 72 65 20 64 61 d_xacts where da 09:44:26,608 ERROR [stderr] (Periodic Recovery) 0030: 74 61 62 61 73 65 20 3D 20 63 75 72 72 65 6E 74 tabase = current 09:44:26,608 ERROR [stderr] (Periodic Recovery) 0040: 5F 64 61 74 61 62 61 73 65 28 29 00 00 00 42 00 _database()...B. 09:44:26,608 ERROR [stderr] (Periodic Recovery) 0050: 00 00 0C 00 00 00 00 00 00 00 00 44 00 00 00 06 ...........D.... 09:44:26,608 ERROR [stderr] (Periodic Recovery) 0060: 50 00 45 00 00 00 09 00 00 00 00 00 53 00 00 00 P.E.........S... 09:44:26,608 ERROR [stderr] (Periodic Recovery) 0070: 04 17 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 09:44:26,608 ERROR [stderr] (Periodic Recovery) 0080: 00 00 .. 09:44:26,608 ERROR [stderr] (Periodic Recovery) ) 09:44:26,608 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.608 MST|SSLSocketOutputRecord.java:324|Raw write ( 09:44:26,608 ERROR [stderr] (Periodic Recovery) 0000: 17 03 03 00 92 77 2B 4B 2A 19 B4 84 98 0A 1E A4 .....w+K*....... 09:44:26,609 ERROR [stderr] (Periodic Recovery) 0010: FC 38 C3 19 2C 72 2E 4C D3 90 C5 6A 0F 97 B1 18 .8..,r.L...j.... 09:44:26,609 ERROR [stderr] (Periodic Recovery) 0020: 6F 4C B6 45 CE 2D 5E E0 67 14 29 C8 31 45 E5 BB oL.E.-^.g.).1E.. 09:44:26,609 ERROR [stderr] (Periodic Recovery) 0030: E9 F8 6A 20 F9 52 DC F3 D6 EA 83 B0 66 C9 DC B1 ..j .R......f... 09:44:26,609 ERROR [stderr] (Periodic Recovery) 0040: 4A 7D 65 14 39 DD 79 3A 50 6A 86 74 00 13 98 72 J.e.9.y:Pj.t...r 09:44:26,609 ERROR [stderr] (Periodic Recovery) 0050: 45 B2 33 2B 57 AD 1F 35 FA AE 84 25 C9 E0 75 D4 E.3+W..5...%..u. 09:44:26,609 ERROR [stderr] (Periodic Recovery) 0060: 7E 00 C0 F7 93 CD 97 0D 69 44 9D A8 E4 AD D0 C1 ........iD...... 09:44:26,609 ERROR [stderr] (Periodic Recovery) 0070: 34 53 06 8B 50 41 33 0D D4 C9 57 FD 2E D4 09 3D 4S..PA3...W....= 09:44:26,609 ERROR [stderr] (Periodic Recovery) 0080: CB 86 FE 2D BF 87 AB 47 5A 9D 5B DA 46 91 1A 2F ...-...GZ.[.F../ 09:44:26,609 ERROR [stderr] (Periodic Recovery) 0090: 2D 24 3C B3 FA 11 B3 -$<.... 09:44:26,609 ERROR [stderr] (Periodic Recovery) ) 09:44:26,609 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.609 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,609 ERROR [stderr] (Periodic Recovery) 0000: 17 03 03 00 4C ....L 09:44:26,609 ERROR [stderr] (Periodic Recovery) ) 09:44:26,609 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.609 MST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 76 09:44:26,609 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.609 MST|SSLSocketInputRecord.java:458|Raw read ( 09:44:26,609 ERROR [stderr] (Periodic Recovery) 0000: FB 0F 11 9D 82 36 E0 D5 4A A9 4B 49 F8 02 5A 87 .....6..J.KI..Z. 09:44:26,609 ERROR [stderr] (Periodic Recovery) 0010: 0A A3 00 4C 6C 80 38 4B 16 DD A8 9C C4 C3 DD 01 ...Ll.8K........ 09:44:26,609 ERROR [stderr] (Periodic Recovery) 0020: 01 91 06 D8 6A 56 1A 45 B7 8A 01 E3 60 5B BF 0B ....jV.E....`[.. 09:44:26,609 ERROR [stderr] (Periodic Recovery) 0030: B5 8C 72 67 DC 60 3B EF 83 F2 B5 30 92 AD 4D 92 ..rg.`;....0..M. 09:44:26,609 ERROR [stderr] (Periodic Recovery) 0040: D0 3B 97 16 2C 41 DE A4 22 89 2E BC .;..,A.."... 09:44:26,609 ERROR [stderr] (Periodic Recovery) ) 09:44:26,609 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.609 MST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 76 09:44:26,610 ERROR [stderr] (Periodic Recovery) javax.net.ssl|DEBUG|9D|Periodic Recovery|2019-01-17 09:44:26.610 MST|SSLCipher.java:1915|Plaintext after DECRYPTION ( 09:44:26,610 ERROR [stderr] (Periodic Recovery) 0000: 31 00 00 00 04 32 00 00 00 04 54 00 00 00 1C 00 1....2....T..... 09:44:26,610 ERROR [stderr] (Periodic Recovery) 0010: 01 67 69 64 00 00 00 2D 89 00 02 00 00 00 19 FF .gid...-........ 09:44:26,610 ERROR [stderr] (Periodic Recovery) 0020: FF FF FF FF FF 00 00 43 00 00 00 0D 53 45 4C 45 .......C....SELE 09:44:26,610 ERROR [stderr] (Periodic Recovery) 0030: 43 54 20 30 00 5A 00 00 00 05 49 CT 0.Z....I 09:44:26,610 ERROR [stderr] (Periodic Recovery) ) From philipp.kunz at paratix.ch Sun Jan 20 08:20:14 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Sun, 20 Jan 2019 09:20:14 +0100 Subject: ManifestDigester fails with a manifest ending in CR Message-ID: <1547972414.2363.9.camel@paratix.ch> Hi, ManifestDigester fails to digest manifests that end with \r with an array index out of bounds exception and such jar files cannot be signed. I cannot create a bug myself because I don't have the privileges and could therefore not add the proper @bug tag to the test yet. Philipp Following up in smaller parts https://mail.openjdk.java.net/pipermail/security-dev/2019-January/01919 3.html Possibly related: https://bugs.openjdk.java.net/browse/JDK-8200530 https://bugs.openjdk.java.net/browse/JDK-6954621 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: manifestdigesterlinebreaks.patch Type: text/x-patch Size: 5963 bytes Desc: not available URL: From weijun.wang at oracle.com Sun Jan 20 09:27:47 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 20 Jan 2019 17:27:47 +0800 Subject: ManifestDigester fails with a manifest ending in CR In-Reply-To: <1547972414.2363.9.camel@paratix.ch> References: <1547972414.2363.9.camel@paratix.ch> Message-ID: <85CB8E69-66A9-4E28-BC93-3FD9DEE58E41@oracle.com> Hi Philipp This fix is also part of another fix you proposed for jarsigner re-signing. Shall we fix it in one big changeset? IMO this is not serious enough to be included in JDK 12 and let?s fix all in JDK 13. Thanks Max > ? 2019?1?20??16:20?Philipp Kunz ??? > > Hi, > ManifestDigester fails to digest manifests that end with \r with an array index out of bounds exception and such jar files cannot be signed. > I cannot create a bug myself because I don't have the privileges and could therefore not add the proper @bug tag to the test yet. > Philipp > > Following up in smaller parts > https://mail.openjdk.java.net/pipermail/security-dev/2019-January/019193.html > > Possibly related: > https://bugs.openjdk.java.net/browse/JDK-8200530 > https://bugs.openjdk.java.net/browse/JDK-6954621 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philipp.kunz at paratix.ch Sun Jan 20 21:28:49 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Sun, 20 Jan 2019 22:28:49 +0100 Subject: ManifestDigester fails with a manifest ending in CR In-Reply-To: <85CB8E69-66A9-4E28-BC93-3FD9DEE58E41@oracle.com> References: <1547972414.2363.9.camel@paratix.ch> <85CB8E69-66A9-4E28-BC93-3FD9DEE58E41@oracle.com> Message-ID: <1548019729.2363.13.camel@paratix.ch> Hi Max, I started to split the issue because it became too complex for me all at once, I must admit, hoping being able to cope with it better in smaller tasks. I fully agree that it is neither serious nor urgent enough to solve it independently but it would help at least me to keep the overview better organized. If you don't object I would suggest another separate bug and patch for ManifestDigester confusing "Manifest-Main-Attributes individual section with main attributes, also neither?serious nor urgent. This one and manifest ending in \r would then fall away from JDK-8217375. I would personally welcome to see the jar signing update incompatibility JDK-8217375 fixed in JDK 11 because I suggested the change that introduced the bug there originally but that does not necessarily require also to backport the \r and the "Manifest-Main- Attributes"-confusion bugs. By splitting up JDK-8217375 as suggested we would also get the suitable set of changes to backport. I'm flattered that you ask for my opinion how to proceed but I cannot decide this alone. I hope I described one option a bit clearer. It might be worth two more bugs in jira or would this unnecessarily spoil it? Philipp On Sun, 2019-01-20 at 17:27 +0800, Weijun Wang wrote: > Hi Philipp? > > This fix is also part of another fix you proposed for jarsigner re- > signing. Shall we fix it in one big changeset? IMO this is not > serious enough to be included in JDK 12 and let?s fix all in JDK 13.? > > Thanks > Max > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amir.khassaia at gmail.com Sun Jan 20 23:03:05 2019 From: amir.khassaia at gmail.com (Amir Khassaia) Date: Mon, 21 Jan 2019 10:03:05 +1100 Subject: Not possible to disable new TLS extensions for TLS 1.2 connections Message-ID: Greetings Xuelei, To follow up on this, the certificate in the connection is a red herring and not important. It's actually a very unusual behaviour by talk.google.com endpoint to encapsulate an error message inside a certificate. As per the output I included: *"certificate" : { *>* "version" : "v3", *>* "serial number" : "00 90 76 89 18 E9 33 93 A0", *>* "signature algorithm": "SHA256withRSA", *>* "issuer" : "CN=invalid2.invalid, OU="No SNI provided; *>* please fix your client."", *>* "not before" : "2015-01-01 11:00:00.000 AEDT", *>* "not after" : "2030-01-01 11:00:00.000 AEDT", *>* "subject" : "CN=invalid2.invalid, OU="No SNI provided; *>* please fix your client."",* This certificate simply masks the TLS interoperability issue as an untrusted certificate issue. The fact is, some of the extensions sent by JSSE are changes to TLS 1.2 to support TLS 1.3, this however affects some clients adversely in practice and usually JDK provides properties to turn new enhancements off and work around such behaviour, for the extensions I mentioned this is not provided and hence they are always sent for client sockets unless TLSv1.2 is not in use. The impact to us is that upgrading to JDK11 means for some endpoints or devices that are not 100% compliant to the spec the security is reduced as we have to now work around to drop connections to these to TLSv1.1 or TLS1.0 or not to move to Java 11 at all. My request is simply to have all of the new extensions configurable on individual basis so that they can be turned off if needed for compatibility just like most other security enhancements that were delivered in the past. It appears some of the issues can come from - inclusion of RSASSA-PSS alg in TLS 1.2 handshakes but these can disabled at least -signature_algorithms_cert and supported_versions extensions which seem to be hardcoded for TLS 1.2 (I was not able to conclusively identify which of these caused my troubles) https://tools.ietf.org/html/rfc8446#section-1.3 does say that TLS 1.2 clients are affected but in an optional manner.Just today I've encountered another Java 11 interop issue with TLS but this time with a physical device which can have a long shelf life yet running a simple client socket handshake abruptly terminates the connection upon client hello (no server_hello at all), and downgrading the JRE below 11 works fine. I'm including a trace for that as well: javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.395 AEDT|SSLCipher.java:437|jdk.tls.keyLimits: entry = AES/GCM/NoPadding KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472 javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.433 AEDT|ServerNameExtension.java:255|Unable to indicate server name javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: server_name javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: status_request javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.443 AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is not supported by the underlying providers javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.444 AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not supported by the underlying providers javax.net.ssl|INFO|01|main|2019-01-08 13:40:14.449 AEDT|AlpnExtension.java:161|No available application protocols javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.449 AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: application_layer_protocol_negotiation javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.450 AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: status_request_v2 javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.453 AEDT|ClientHello.java:651|Produced ClientHello handshake message ( "ClientHello": { "client version" : "TLSv1.2", "random" : "1A BA E8 FC 59 00 AB DF 9A 1A 07 94 24 7F 34 3D 0B D2 7D 10 72 52 54 CD 44 43 62 E8 8B 42 C6 68", "session id" : "", "cipher suites" : "[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), TLS_RSA_WITH_AES_128_CBC_SHA(0x002F)]", "compression methods" : "00", "extensions" : [ "supported_groups (10)": { "versions": [secp256r1, secp384r1, secp521r1, secp160k1] }, "ec_point_formats (11)": { "formats": [uncompressed] }, "signature_algorithms (13)": { "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5] }, "signature_algorithms_cert (50)": { "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5] }, "extended_master_secret (23)": { }, "supported_versions (43)": { "versions": [TLSv1.2, TLSv1.1] }, "renegotiation_info (65,281)": { "renegotiated connection": [] } ] } ) javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.455 AEDT|Alert.java:232|Received alert message ( "Alert": { "level" : "fatal", "description": "handshake_failure" } ) javax.net.ssl|ERROR|01|main|2019-01-08 13:40:14.456 AEDT|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE): Received fatal alert: handshake_failure ( "throwable" : { javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) at SslSocketClient.main(SslSocketClient.kt:47)} ) javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 AEDT|SSLSocketImpl.java:1361|close the underlying socket javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 AEDT|SSLSocketImpl.java:1380|close the SSL connection (initiative) Exception in thread "main" javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) at SslSocketClient.main(SslSocketClient.kt:47) I've sent my reply earlier but neither got it posted nor denied notification so trying again. -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Sun Jan 20 23:36:44 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 20 Jan 2019 15:36:44 -0800 Subject: Not possible to disable new TLS extensions for TLS 1.2 connections In-Reply-To: References: Message-ID: <1f4b323a-7a98-35c6-8501-f88c6cc2208b@oracle.com> Hi Amir, Normally, the extension should have no impact if it cannot be recognized by the server.?? It's good to be able to disable extensions if not needed.?? I need to evaluate the priority of it although.? Did you have a simple test code that I can reproduce the issue? Thanks, Xuelei On 1/20/2019 3:03 PM, Amir Khassaia wrote: > Greetings Xuelei, > To follow up on this, the certificate in the connection is a red > herring and not important. It's actually a very unusual behaviour by > talk.google.com ?endpoint to encapsulate an > error message inside a certificate. > > As per the output I included: > /"certificate" : { />/? ? "version"? ? ? ? ? ? : "v3", />/? ? "serial number"? ? ? : "00 90 76 89 18 E9 33 93 A0", />/? ? "signature algorithm": "SHA256withRSA", />/? ? "issuer"? ? ? ? ? ? ?: "CN=invalid2.invalid, OU="No SNI provided; />/please fix your client."", />/? ? "not before"? ? ? ? ?: "2015-01-01 11:00:00.000 AEDT", />/? ? "not? after"? ? ? ? ?: "2030-01-01 11:00:00.000 AEDT", />/? ? "subject"? ? ? ? ? ? : "CN=invalid2.invalid, OU="No SNI provided; />/please fix your client."",/ > // > This certificate simply masks the TLS interoperability issue as an > untrusted certificate issue. > The fact is, some of the extensions sent by JSSE are changes to TLS > 1.2 to support TLS 1.3, this however affects some clients adversely in > practice and usually JDK provides properties to turn new enhancements > off and work around such behaviour, for the extensions I mentioned > this is not provided and hence they are always sent for client sockets > unless TLSv1.2 is not in use. > > The impact to us is that upgrading to JDK11 means for some endpoints > or devices that are not 100% compliant to the spec the security is > reduced as we have to now work around to drop connections to these to > TLSv1.1 or TLS1.0 or not to move to Java 11 at all. > My request is simply to have all of the new extensions configurable on > individual basis so that they can be turned off if needed for > compatibility just like most other security enhancements that were > delivered in the past. > It appears some of the issues can come from > > - inclusion of RSASSA-PSS alg in TLS 1.2 handshakes but these can > disabled at least > > -signature_algorithms_cert and supported_versions extensions which > seem to be hardcoded for TLS 1.2 (I was not able to conclusively > identify which of these caused my troubles) > > https://tools.ietf.org/html/rfc8446#section-1.3?does say that TLS 1.2 > clients are affected but in an optional manner.Just today I've > encountered another Java 11 interop issue with TLS but this time with > a physical device which can have a long shelf life yet running a > simple client socket handshake abruptly terminates the connection upon > client hello (no server_hello at all), and downgrading the JRE below > 11 works fine. I'm including a trace for that as well: > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.395 > AEDT|SSLCipher.java:437|jdk.tls.keyLimits: ?entry = AES/GCM/NoPadding > KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472 > > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.433 > AEDT|ServerNameExtension.java:255|Unable to indicate server name > > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: > server_name > > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: > status_request > > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.443 > AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is not > supported by the underlying providers > > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.444 > AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not > supported by the underlying providers > > javax.net.ssl|INFO|01|main|2019-01-08 13:40:14.449 > AEDT|AlpnExtension.java:161|No available application protocols > > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.449 > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: > application_layer_protocol_negotiation > > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.450 > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: > status_request_v2 > > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.453 > AEDT|ClientHello.java:651|Produced ClientHello handshake message ( > > "ClientHello": { > > ? "client version" ? ? ?: "TLSv1.2", > > ? "random" ? ? ? ? ? ? ?: "1A BA E8 FC 59 00 AB DF 9A 1A 07 94 24 7F > 34 3D 0B D2 7D 10 72 52 54 CD 44 43 62 E8 8B 42 C6 68", > > ? "session id" ? ? ? ? ?: "", > > ? "cipher suites" ? ? ? : > "[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), > TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), > TLS_RSA_WITH_AES_128_CBC_SHA(0x002F)]", > > ? "compression methods" : "00", > > ? "extensions" ? ? ? ? ?: [ > > ? ? "supported_groups (10)": { > > ? ? ? "versions": [secp256r1, secp384r1, secp521r1, secp160k1] > > ? ? }, > > ? ? "ec_point_formats (11)": { > > ? ? ? "formats": [uncompressed] > > ? ? }, > > ? ? "signature_algorithms (13)": { > > ? ? ? "signature schemes": [ecdsa_secp256r1_sha256, > ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, > rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, > rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, > rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, > rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5] > > ? ? }, > > ? ? "signature_algorithms_cert (50)": { > > ? ? ? "signature schemes": [ecdsa_secp256r1_sha256, > ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, > rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, > rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, > rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, > rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5] > > ? ? }, > > ? ? "extended_master_secret (23)": { > > ? ? ? > > ? ? }, > > ? ? "supported_versions (43)": { > > ? ? ? "versions": [TLSv1.2, TLSv1.1] > > ? ? }, > > ? ? "renegotiation_info (65,281)": { > > ? ? ? "renegotiated connection": [] > > ? ? } > > ? ] > > } > > ) > > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.455 > AEDT|Alert.java:232|Received alert message ( > > "Alert": { > > ? "level" ? ? ?: "fatal", > > ? "description": "handshake_failure" > > } > > ) > > javax.net.ssl|ERROR|01|main|2019-01-08 13:40:14.456 > AEDT|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE): Received > fatal alert: handshake_failure ( > > "throwable" : { > > ? javax.net.ssl.SSLHandshakeException: Received fatal alert: > handshake_failure > > ? ? at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) > > ? ? at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) > > ? ? at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) > > ? ? at > java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) > > ? ? at > java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) > > ? ? at > java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) > > ? ? at > java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) > > ? ? at > java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) > > ? ? at > java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) > > ? ? at SslSocketClient.main(SslSocketClient.kt:47)} > > > ) > > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 > AEDT|SSLSocketImpl.java:1361|close the underlying socket > > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 > AEDT|SSLSocketImpl.java:1380|close the SSL connection (initiative) > > Exception in thread "main" javax.net.ssl.SSLHandshakeException: > Received fatal alert: handshake_failure > > ? at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) > > ? at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) > > ? at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) > > ? at > java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) > > ? at > java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) > > ? at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) > > ? at > java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) > > ? at > java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) > > ? at > java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) > > ? at SslSocketClient.main(SslSocketClient.kt:47) > > > > > I've sent my reply earlier but neither got it posted nor denied > notification so trying again. -------------- next part -------------- An HTML attachment was scrubbed... URL: From amir.khassaia at gmail.com Mon Jan 21 00:10:38 2019 From: amir.khassaia at gmail.com (Amir Khassaia) Date: Mon, 21 Jan 2019 11:10:38 +1100 Subject: Not possible to disable new TLS extensions for TLS 1.2 connections In-Reply-To: <1f4b323a-7a98-35c6-8501-f88c6cc2208b@oracle.com> References: <1f4b323a-7a98-35c6-8501-f88c6cc2208b@oracle.com> Message-ID: Xuelei, I have a sample socket client for the device TLS issue but its not very helpful as any socket client created on top of JDK will do, the last problem was apparent only when talking to a specific hardware device which refused to negotiate TLS session (I've seen several odd TLS implementations that were intolerant to Java changes in various ways over the years and compatibility could always be assured through config changes, this time around less so). Some of the hardware TLS stacks can range from small oddities to being completely broken by small changes as they can contain outdated and poorly implemented TLS stacks that are very sensitive so even a small change can break them and thats why its always important to have levers provided to control almost every aspect of the handshake. I have a sample in my gist ( https://gist.github.com/amir-khassaia/04347ca88526f4b958b3326968a905c0), apologies its in Kotlin. When ran with java 8, 9, 10 there were no issues. With java 11 this worked on most devices but I've had a device at a remote location that was not in my control that I've had to diagnose the handshake failure on using java 11 it was intolerant to TLS 1.2 client hello from Java 11 but fine with TLS 1.1 as the new extensions are not present. It would be fine with TLS 1.2 client hello from Java 10 and earlier as I mentioned. Javax.net.debug output ------------------------------- javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.395 AEDT|SSLCipher.java:437|jdk.tls.keyLimits: entry = AES/GCM/NoPadding KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472 javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.433 AEDT|ServerNameExtension.java:255|Unable to indicate server name javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: server_name javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: status_request javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.443 AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is not supported by the underlying providers javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.444 AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not supported by the underlying providers javax.net.ssl|INFO|01|main|2019-01-08 13:40:14.449 AEDT|AlpnExtension.java:161|No available application protocols javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.449 AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: application_layer_protocol_negotiation javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.450 AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: status_request_v2 javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.453 AEDT|ClientHello.java:651|Produced ClientHello handshake message ( "ClientHello": { "client version" : "TLSv1.2", "random" : "1A BA E8 FC 59 00 AB DF 9A 1A 07 94 24 7F 34 3D 0B D2 7D 10 72 52 54 CD 44 43 62 E8 8B 42 C6 68", "session id" : "", "cipher suites" : "[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), TLS_RSA_WITH_AES_128_CBC_SHA(0x002F)]", "compression methods" : "00", "extensions" : [ "supported_groups (10)": { "versions": [secp256r1, secp384r1, secp521r1, secp160k1] }, "ec_point_formats (11)": { "formats": [uncompressed] }, "signature_algorithms (13)": { "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5] }, "signature_algorithms_cert (50)": { "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5] }, "extended_master_secret (23)": { }, "supported_versions (43)": { "versions": [TLSv1.2, TLSv1.1] }, "renegotiation_info (65,281)": { "renegotiated connection": [] } ] } ) javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.455 AEDT|Alert.java:232|Received alert message ( "Alert": { "level" : "fatal", "description": "handshake_failure" } ) javax.net.ssl|ERROR|01|main|2019-01-08 13:40:14.456 AEDT|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE): Received fatal alert: handshake_failure ( "throwable" : { javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) at SslSocketClient.main(SslSocketClient.kt:47)} ) javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 AEDT|SSLSocketImpl.java:1361|close the underlying socket javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 AEDT|SSLSocketImpl.java:1380|close the SSL connection (initiative) Exception in thread "main" javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) at SslSocketClient.main(SslSocketClient.kt:47) Wireshark TLS 1.2 Java 8 client hello ------------------------------------------------- Secure Sockets Layer TLSv1.2 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 157 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 153 Version: TLS 1.2 (0x0303) Random: 5c34044c709feae39585e4db8e41b0170fbf9fa428b38941... GMT Unix Time: Jan 8, 2019 13:00:44.000000000 AUS Eastern Daylight Time Random Bytes: 709feae39585e4db8e41b0170fbf9fa428b38941983ddb53... Session ID Length: 0 Cipher Suites Length: 44 Cipher Suites (22 suites) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c) Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025) Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004) Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c) Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02d) Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 (0xc031) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (0x00a2) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 68 Extension: supported_groups (len=22) Type: supported_groups (10) Length: 22 Supported Groups List Length: 20 Supported Groups (10 groups) Supported Group: secp256r1 (0x0017) Supported Group: secp384r1 (0x0018) Supported Group: secp521r1 (0x0019) Supported Group: sect283k1 (0x0009) Supported Group: sect283r1 (0x000a) Supported Group: sect409k1 (0x000b) Supported Group: sect409r1 (0x000c) Supported Group: sect571k1 (0x000d) Supported Group: sect571r1 (0x000e) Supported Group: secp256k1 (0x0016) Extension: ec_point_formats (len=2) Type: ec_point_formats (11) Length: 2 EC point formats Length: 1 Elliptic curves point formats (1) EC point format: uncompressed (0) Extension: signature_algorithms (len=28) Type: signature_algorithms (13) Length: 28 Signature Hash Algorithms Length: 26 Signature Hash Algorithms (13 algorithms) Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603) Signature Hash Algorithm Hash: SHA512 (6) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: rsa_pkcs1_sha512 (0x0601) Signature Hash Algorithm Hash: SHA512 (6) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503) Signature Hash Algorithm Hash: SHA384 (5) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: rsa_pkcs1_sha384 (0x0501) Signature Hash Algorithm Hash: SHA384 (5) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: rsa_pkcs1_sha256 (0x0401) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: SHA256 DSA (0x0402) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: DSA (2) Signature Algorithm: SHA224 ECDSA (0x0303) Signature Hash Algorithm Hash: SHA224 (3) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: SHA224 RSA (0x0301) Signature Hash Algorithm Hash: SHA224 (3) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: SHA224 DSA (0x0302) Signature Hash Algorithm Hash: SHA224 (3) Signature Hash Algorithm Signature: DSA (2) Signature Algorithm: ecdsa_sha1 (0x0203) Signature Hash Algorithm Hash: SHA1 (2) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: rsa_pkcs1_sha1 (0x0201) Signature Hash Algorithm Hash: SHA1 (2) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: SHA1 DSA (0x0202) Signature Hash Algorithm Hash: SHA1 (2) Signature Hash Algorithm Signature: DSA (2) Extension: extended_master_secret (len=0) Type: extended_master_secret (23) Length: 0 Wireshark Java 11 TLS 1.2 Client hello ---------------------------------------------------- Secure Sockets Layer TLSv1.2 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 185 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 181 Version: TLS 1.2 (0x0303) Random: 37f32691301b6b9d45bb62c6268915819881b8ebd95f152c... GMT Unix Time: Sep 30, 1999 19:00:01.000000000 AUS Eastern Standard Time Random Bytes: 301b6b9d45bb62c6268915819881b8ebd95f152c41c7e483... Session ID Length: 0 Cipher Suites Length: 10 Cipher Suites (5 suites) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c) Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 130 Extension: supported_groups (len=10) Type: supported_groups (10) Length: 10 Supported Groups List Length: 8 Supported Groups (4 groups) Supported Group: secp256r1 (0x0017) Supported Group: secp384r1 (0x0018) Supported Group: secp521r1 (0x0019) Supported Group: secp160k1 (0x000f) Extension: ec_point_formats (len=2) Type: ec_point_formats (11) Length: 2 EC point formats Length: 1 Elliptic curves point formats (1) EC point format: uncompressed (0) Extension: signature_algorithms (len=42) Type: signature_algorithms (13) Length: 42 Signature Hash Algorithms Length: 40 Signature Hash Algorithms (20 algorithms) Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503) Signature Hash Algorithm Hash: SHA384 (5) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603) Signature Hash Algorithm Hash: SHA512 (6) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: rsa_pss_rsae_sha256 (0x0804) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (4) Signature Algorithm: rsa_pss_rsae_sha384 (0x0805) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (5) Signature Algorithm: rsa_pss_rsae_sha512 (0x0806) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (6) Signature Algorithm: rsa_pss_pss_sha256 (0x0809) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (9) Signature Algorithm: rsa_pss_pss_sha384 (0x080a) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (10) Signature Algorithm: rsa_pss_pss_sha512 (0x080b) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (11) Signature Algorithm: rsa_pkcs1_sha256 (0x0401) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: rsa_pkcs1_sha384 (0x0501) Signature Hash Algorithm Hash: SHA384 (5) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: rsa_pkcs1_sha512 (0x0601) Signature Hash Algorithm Hash: SHA512 (6) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: SHA256 DSA (0x0402) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: DSA (2) Signature Algorithm: SHA224 ECDSA (0x0303) Signature Hash Algorithm Hash: SHA224 (3) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: SHA224 RSA (0x0301) Signature Hash Algorithm Hash: SHA224 (3) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: SHA224 DSA (0x0302) Signature Hash Algorithm Hash: SHA224 (3) Signature Hash Algorithm Signature: DSA (2) Signature Algorithm: ecdsa_sha1 (0x0203) Signature Hash Algorithm Hash: SHA1 (2) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: rsa_pkcs1_sha1 (0x0201) Signature Hash Algorithm Hash: SHA1 (2) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: SHA1 DSA (0x0202) Signature Hash Algorithm Hash: SHA1 (2) Signature Hash Algorithm Signature: DSA (2) Signature Algorithm: MD5 RSA (0x0101) Signature Hash Algorithm Hash: MD5 (1) Signature Hash Algorithm Signature: RSA (1) Extension: signature_algorithms_cert (len=42) Type: signature_algorithms_cert (50) Length: 42 Signature Hash Algorithms Length: 40 Signature Hash Algorithms (20 algorithms) Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503) Signature Hash Algorithm Hash: SHA384 (5) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603) Signature Hash Algorithm Hash: SHA512 (6) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: rsa_pss_rsae_sha256 (0x0804) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (4) Signature Algorithm: rsa_pss_rsae_sha384 (0x0805) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (5) Signature Algorithm: rsa_pss_rsae_sha512 (0x0806) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (6) Signature Algorithm: rsa_pss_pss_sha256 (0x0809) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (9) Signature Algorithm: rsa_pss_pss_sha384 (0x080a) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (10) Signature Algorithm: rsa_pss_pss_sha512 (0x080b) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (11) Signature Algorithm: rsa_pkcs1_sha256 (0x0401) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: rsa_pkcs1_sha384 (0x0501) Signature Hash Algorithm Hash: SHA384 (5) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: rsa_pkcs1_sha512 (0x0601) Signature Hash Algorithm Hash: SHA512 (6) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: SHA256 DSA (0x0402) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: DSA (2) Signature Algorithm: SHA224 ECDSA (0x0303) Signature Hash Algorithm Hash: SHA224 (3) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: SHA224 RSA (0x0301) Signature Hash Algorithm Hash: SHA224 (3) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: SHA224 DSA (0x0302) Signature Hash Algorithm Hash: SHA224 (3) Signature Hash Algorithm Signature: DSA (2) Signature Algorithm: ecdsa_sha1 (0x0203) Signature Hash Algorithm Hash: SHA1 (2) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: rsa_pkcs1_sha1 (0x0201) Signature Hash Algorithm Hash: SHA1 (2) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: SHA1 DSA (0x0202) Signature Hash Algorithm Hash: SHA1 (2) Signature Hash Algorithm Signature: DSA (2) Signature Algorithm: MD5 RSA (0x0101) Signature Hash Algorithm Hash: MD5 (1) Signature Hash Algorithm Signature: RSA (1) Extension: extended_master_secret (len=0) Type: extended_master_secret (23) Length: 0 Extension: supported_versions (len=5) Type: supported_versions (43) Length: 5 Supported Versions length: 4 Supported Version: TLS 1.2 (0x0303) Supported Version: TLS 1.1 (0x0302) Extension: renegotiation_info (len=1) Type: renegotiation_info (65281) Length: 1 Renegotiation Info extension Renegotiation info extension length: 0 On Mon, Jan 21, 2019 at 10:37 AM Xuelei Fan wrote: > Hi Amir, > > Normally, the extension should have no impact if it cannot be recognized > by the server. It's good to be able to disable extensions if not > needed. I need to evaluate the priority of it although. Did you have a > simple test code that I can reproduce the issue? > > Thanks, > > Xuelei > On 1/20/2019 3:03 PM, Amir Khassaia wrote: > > Greetings Xuelei, > To follow up on this, the certificate in the connection is a red herring > and not important. It's actually a very unusual behaviour by > talk.google.com endpoint to encapsulate an error message inside a > certificate. > > As per the output I included: > > *"certificate" : { > *>* "version" : "v3", > *>* "serial number" : "00 90 76 89 18 E9 33 93 A0", > *>* "signature algorithm": "SHA256withRSA", > *>* "issuer" : "CN=invalid2.invalid, OU="No SNI provided; > *>* please fix your client."", > *>* "not before" : "2015-01-01 11:00:00.000 AEDT", > *>* "not after" : "2030-01-01 11:00:00.000 AEDT", > *>* "subject" : "CN=invalid2.invalid, OU="No SNI provided; > *>* please fix your client."",* > > This certificate simply masks the TLS interoperability issue as an untrusted certificate issue. > > The fact is, some of the extensions sent by JSSE are changes to TLS 1.2 to > support TLS 1.3, this however affects some clients adversely in practice > and usually JDK provides properties to turn new enhancements off and work > around such behaviour, for the extensions I mentioned this is not provided > and hence they are always sent for client sockets unless TLSv1.2 is not in > use. > > The impact to us is that upgrading to JDK11 means for some endpoints or > devices that are not 100% compliant to the spec the security is reduced as > we have to now work around to drop connections to these to TLSv1.1 or > TLS1.0 or not to move to Java 11 at all. > > My request is simply to have all of the new extensions configurable on individual basis so that they can be turned off if needed for compatibility just like most other security enhancements that were delivered in the past. > > It appears some of the issues can come from > > - inclusion of RSASSA-PSS alg in TLS 1.2 handshakes but these can disabled > at least > > -signature_algorithms_cert and supported_versions extensions which seem to > be hardcoded for TLS 1.2 (I was not able to conclusively identify which of > these caused my troubles) > > https://tools.ietf.org/html/rfc8446#section-1.3 does say that TLS 1.2 > clients are affected but in an optional manner.Just today I've encountered > another Java 11 interop issue with TLS but this time with a physical device > which can have a long shelf life yet running a simple client socket > handshake abruptly terminates the connection upon client hello (no > server_hello at all), and downgrading the JRE below 11 works fine. I'm > including a trace for that as well: > > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.395 > AEDT|SSLCipher.java:437|jdk.tls.keyLimits: entry = AES/GCM/NoPadding > KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472 > > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.433 > AEDT|ServerNameExtension.java:255|Unable to indicate server name > > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: > server_name > > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: > status_request > > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.443 > AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is not > supported by the underlying providers > > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.444 > AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not supported > by the underlying providers > > javax.net.ssl|INFO|01|main|2019-01-08 13:40:14.449 > AEDT|AlpnExtension.java:161|No available application protocols > > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.449 > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: > application_layer_protocol_negotiation > > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.450 > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: > status_request_v2 > > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.453 > AEDT|ClientHello.java:651|Produced ClientHello handshake message ( > > "ClientHello": { > > "client version" : "TLSv1.2", > > "random" : "1A BA E8 FC 59 00 AB DF 9A 1A 07 94 24 7F 34 3D > 0B D2 7D 10 72 52 54 CD 44 43 62 E8 8B 42 C6 68", > > "session id" : "", > > "cipher suites" : > "[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), > TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), > TLS_RSA_WITH_AES_128_CBC_SHA(0x002F)]", > > "compression methods" : "00", > > "extensions" : [ > > "supported_groups (10)": { > > "versions": [secp256r1, secp384r1, secp521r1, secp160k1] > > }, > > "ec_point_formats (11)": { > > "formats": [uncompressed] > > }, > > "signature_algorithms (13)": { > > "signature schemes": [ecdsa_secp256r1_sha256, > ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, > rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, > rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, > rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, > ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5] > > }, > > "signature_algorithms_cert (50)": { > > "signature schemes": [ecdsa_secp256r1_sha256, > ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, > rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, > rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, > rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, > ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5] > > }, > > "extended_master_secret (23)": { > > > > }, > > "supported_versions (43)": { > > "versions": [TLSv1.2, TLSv1.1] > > }, > > "renegotiation_info (65,281)": { > > "renegotiated connection": [] > > } > > ] > > } > > ) > > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.455 > AEDT|Alert.java:232|Received alert message ( > > "Alert": { > > "level" : "fatal", > > "description": "handshake_failure" > > } > > ) > > javax.net.ssl|ERROR|01|main|2019-01-08 13:40:14.456 > AEDT|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE): Received fatal > alert: handshake_failure ( > > "throwable" : { > > javax.net.ssl.SSLHandshakeException: Received fatal alert: > handshake_failure > > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) > > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) > > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) > > at > java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) > > at > java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) > > at > java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) > > at > java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) > > at > java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) > > at > java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) > > at SslSocketClient.main(SslSocketClient.kt:47)} > > > ) > > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 > AEDT|SSLSocketImpl.java:1361|close the underlying socket > > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 > AEDT|SSLSocketImpl.java:1380|close the SSL connection (initiative) > > Exception in thread "main" javax.net.ssl.SSLHandshakeException: Received > fatal alert: handshake_failure > > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) > > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) > > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) > > at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) > > at > java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) > > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) > > at > java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) > > at > java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) > > at > java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) > > at SslSocketClient.main(SslSocketClient.kt:47) > > > > > I've sent my reply earlier but neither got it posted nor denied > notification so trying again. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Jan 21 00:58:24 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 21 Jan 2019 08:58:24 +0800 Subject: ManifestDigester fails with a manifest ending in CR In-Reply-To: <1548019729.2363.13.camel@paratix.ch> References: <1547972414.2363.9.camel@paratix.ch> <85CB8E69-66A9-4E28-BC93-3FD9DEE58E41@oracle.com> <1548019729.2363.13.camel@paratix.ch> Message-ID: <3B9DE791-9F08-4A45-9415-E311F516F947@oracle.com> > On Jan 21, 2019, at 5:28 AM, Philipp Kunz wrote: > > Hi Max, > > I started to split the issue because it became too complex for me all at once, I must admit, hoping being able to cope with it better in smaller tasks. I fully agree that it is neither serious nor urgent enough to solve it independently but it would help at least me to keep the overview better organized. > > If you don't object I would suggest another separate bug and patch for ManifestDigester confusing "Manifest-Main-Attributes individual section with main attributes, also neither serious nor urgent. This one and manifest ending in \r would then fall away from JDK-8217375. > > I would personally welcome to see the jar signing update incompatibility JDK-8217375 fixed in JDK 11 because I suggested the change that introduced the bug there originally but that does not necessarily require also to backport the \r and the "Manifest-Main-Attributes"-confusion bugs. By splitting up JDK-8217375 as suggested we would also get the suitable set of changes to backport. It looks you are thinking of 3 changes: 1. Fixing "if ((i < len) && (rawBytes[i+1] == '\n'))". 2. Make a separate field for "Manifest-Main-Attributes" out of Map. 3. Keeping raw bytes for each section Although #2 is an enhancement (not a bug), #3 depends on #2 to make the code looking clear. So I assume you will want to backport both #2 and #3. As for #1, it's a separate issue, but the line itself is an obvious error and I cannot see a risk fixing it. Therefore, although it's generally a good idea to deal with different issues separately, in this case it's probably not really necessary. You talked about other findings in ManifestDigester about line endings. If it touched the same code then we might want to consider fixing it at the same time. If you can apply the JDK 13 patch directly to JDK 11 with no change, that will be the best. It will give sustaining engineers much more confidence in backporting the fix. Thanks, Max > > I'm flattered that you ask for my opinion how to proceed but I cannot decide this alone. I hope I described one option a bit clearer. It might be worth two more bugs in jira or would this unnecessarily spoil it? > > Philipp > > > On Sun, 2019-01-20 at 17:27 +0800, Weijun Wang wrote: >> Hi Philipp >> >> This fix is also part of another fix you proposed for jarsigner re-signing. Shall we fix it in one big changeset? IMO this is not serious enough to be included in JDK 12 and let?s fix all in JDK 13. >> >> Thanks >> Max >> From weijun.wang at oracle.com Mon Jan 21 01:11:04 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 21 Jan 2019 09:11:04 +0800 Subject: ManifestDigester fails with a manifest ending in CR In-Reply-To: <3B9DE791-9F08-4A45-9415-E311F516F947@oracle.com> References: <1547972414.2363.9.camel@paratix.ch> <85CB8E69-66A9-4E28-BC93-3FD9DEE58E41@oracle.com> <1548019729.2363.13.camel@paratix.ch> <3B9DE791-9F08-4A45-9415-E311F516F947@oracle.com> Message-ID: > On Jan 21, 2019, at 8:58 AM, Weijun Wang wrote: > >> >> On Jan 21, 2019, at 5:28 AM, Philipp Kunz wrote: >> >> Hi Max, >> >> I started to split the issue because it became too complex for me all at once, I must admit, hoping being able to cope with it better in smaller tasks. I fully agree that it is neither serious nor urgent enough to solve it independently but it would help at least me to keep the overview better organized. >> >> If you don't object I would suggest another separate bug and patch for ManifestDigester confusing "Manifest-Main-Attributes individual section with main attributes, also neither serious nor urgent. This one and manifest ending in \r would then fall away from JDK-8217375. >> >> I would personally welcome to see the jar signing update incompatibility JDK-8217375 fixed in JDK 11 because I suggested the change that introduced the bug there originally but that does not necessarily require also to backport the \r and the "Manifest-Main-Attributes"-confusion bugs. By splitting up JDK-8217375 as suggested we would also get the suitable set of changes to backport. > > > It looks you are thinking of 3 changes: > > 1. Fixing "if ((i < len) && (rawBytes[i+1] == '\n'))". > > 2. Make a separate field for "Manifest-Main-Attributes" out of Map. > > 3. Keeping raw bytes for each section > > Although #2 is an enhancement (not a bug), #3 depends on #2 to make the code looking clear. So I assume you will want to backport both #2 and #3. > > As for #1, it's a separate issue, but the line itself is an obvious error and I cannot see a risk fixing it. > > Therefore, although it's generally a good idea to deal with different issues separately, in this case it's probably not really necessary. > > You talked about other findings in ManifestDigester about line endings. If it touched the same code then we might want to consider fixing it at the same time. If you can apply the JDK 13 patch directly to JDK 11 with no change, that will be the best. It will give sustaining engineers much more confidence in backporting the fix. Or, if your other fix is complicated and it only deals with alternative line endings (which is not common in the real world), it can be a different changeset, but make sure it's after the fix you want to backport into JDK 11. Even though, if one day we find another bug that should be backported into JDK 11 but it depends on your new change, we will need to decide how to backport it cleanly. Thanks, Max > > Thanks, > Max > > > >> >> I'm flattered that you ask for my opinion how to proceed but I cannot decide this alone. I hope I described one option a bit clearer. It might be worth two more bugs in jira or would this unnecessarily spoil it? >> >> Philipp >> >> >> On Sun, 2019-01-20 at 17:27 +0800, Weijun Wang wrote: >>> Hi Philipp >>> >>> This fix is also part of another fix you proposed for jarsigner re-signing. Shall we fix it in one big changeset? IMO this is not serious enough to be included in JDK 12 and let?s fix all in JDK 13. >>> >>> Thanks >>> Max From sgehwolf at redhat.com Mon Jan 21 09:09:59 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 21 Jan 2019 10:09:59 +0100 Subject: JDK-8215102 (Follow-up) In-Reply-To: References: <07e6daa4a6a83133acb80d8a065836e13637b866.camel@redhat.com> Message-ID: <367cf00106cd91678df4cd5f68f710647ac1515d.camel@redhat.com> Hi Dennis, On Sat, 2019-01-19 at 12:08 -0700, Dennis Gesker wrote: > Hi Severin: > > A link to the txt file via Google Drive his here. "Sorry, the file you have requested does not exist." Could you please upload it somewhere less restricted? Maybe https://paste.fedoraproject.org/ or something similar? I guess if you include me directly, a file attachment would work too... It's the mailing lists which strip attachments. > I appreciate you and Alan taking a look. Especially, information > submitted from someone who is not a part of openjdk project. > I do hope the debug info helps. Let me know anything else you need > and I will do my best to provide it. Sure. I'll be mostly doing the intermediary work: getting the info added to the bug, though. > And, should your team decide to open a new ticket or reopen this > original ticket in the JIRA could you add me to the ticket? You'd have to become OpenJDK author for this[1]. It's not terribly difficult, but it's somewhat of an entry barrier I understand. > BTW, (off topic), would your recommend submitting a contributor > application to the openjdk project so bug reports can be submitted > directly? If you intend to submit the occasional bug report and fix it's easier for you long-term to attempt to become OpenJDK author (which requires signing the OCA[2]). > The dev group at my company is VERY small (and this message to your > group at the project is from my personal email) but I'd be glad to > submit bug reports as we come across them in our day to day use of > Java. If there are good reproducers for bugs this would be very welcome. Thanks for investing some time in this! Cheers, Severin [1] http://openjdk.java.net/bylaws#author http://openjdk.java.net/projects/#project-author [2] http://oss.oracle.com/oca.pdf > Cordially, > Dennis > dennis at gesker.com > > On Fri, Jan 18, 2019 at 10:07 AM Severin Gehwolf > wrote: > > On Thu, 2019-01-17 at 10:00 -0700, Dennis Gesker wrote: > > [...] > > > Added the -Djavax.net.debug=all option to my Wildfly startup and > > > waited for the pool to close a connection to MySql at AWS. > > > > > > TXT file attached. > > > > > > javac 11.0.1 > > > mysql jdbc driver 8.0.13 > > > wildfly 15.0.1 > > > > > > --drg > > > > Unfortunately the txt file got stripped by the mailing list. Would > > you > > be able to upload it somewhere and post a link? > > > > Thanks, > > Severin > > > > From christoph.langer at sap.com Mon Jan 21 09:17:09 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 21 Jan 2019 09:17:09 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> Message-ID: Hi Alan, first of all, thank you for your input on this. > I think the approach to explore are: > > 1. zipfs supports PosixFileAttributeView without subsetting. If > readAttribute(file, BasicFileAttributes.class) succeeds then > readAttribute(file, PosixFileAttributes.class) should also succeed, even > if there aren't permissions encoded in the zip entry's external file > attributes. It would mean that owner and group return default values, > and permissions may return a default value. It does mean you can't > distinguish the default value from "no permissions" but there is > precedence for that, e.g. mount a FAT32 file system on Linux or Unix > systems and `stat` a file to have the stat structure populated with > default uid, gid and mode bits. OK, I can see the point that in a PosixFileAttributeView as it is, there's no place for optionality/null values. However, with this approach the benefits would be that Files::get/setPosixPermissions would work and that's why I think we should pursue this. The challenge will be to find reasonable defaults. > 2. zipfs defines a new FileAttributeView that defines read and write > access to permissions stored in a zip entry's external file attribute. > As it's a new view then it can define the behavior for the case that the > zip entry doesn't have permissions. Furthermore it does not need to > extend BasicFileAttributeView so doesn't need to be concerned with bulk > access, nor concerned with group/owner. As you know, the attributes API > allows for both type safe and dynamic access so you have a choice as to > whether to support both or just dynamic access. With the first then > jdk.zipfs would export a package with a public interface that defines > the view. If someone wants type safe access to the permissions attribute > then you need to import the class. The alternative is to not export any > packages but just define the view in the module-info. The view its name > and define the name/type of the permissions attribute, it will also > define how it behaves when the external attributes aren't populated. In > usage terms it means reading the permissions will be something like > Files.readAttribute(file, "zip:permissions") and casting the value to > Set - not pretty but it avoids depending on a > JDK-specific API. For this approach, there are 2 things I dislike. The first is that I don't think we should export named packages from module jdk.zipfs that people would develop Java code against while not being in the Java API. And secondly, this way would not support using Files::set/getPosixPermissions since the specification/implementation of that utility method explicitly refers to PosixFileAttributeView. I can imagine something like this: Zipfs by default implements an own view that offers dynamic, not type safe access to "zip:permissions" and we'll document this. If a user of zipfs wants to see full PosixFileAttributeView support with default values, then we should allow for a creation attribute for the zipfs that can control this. Maybe we can even allow specifying default values for user, group and permissions via zipfs attributes. I'll work to develop the patch into this direction unless you tell me that this idea is bogus (if so, then I hope it be soon ??) Thanks Christoph From weijun.wang at oracle.com Mon Jan 21 10:05:15 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 21 Jan 2019 18:05:15 +0800 Subject: RFR 8215776: Keytool importkeystore may mix up certificate chain entries when DNs conflict In-Reply-To: <8945E624-FE60-44C2-AADA-0D69B61244C7@oracle.com> References: <87E0531E-F7CE-4F32-86B7-4A3F3C1B842F@oracle.com> <9e41b753-aeb7-a09c-f221-e464327e9e90@oracle.com> <8945E624-FE60-44C2-AADA-0D69B61244C7@oracle.com> Message-ID: I tried something like this: private X509Certificate findIssuer(X509Certificate input) { X509CertSelector selector = new X509CertSelector(); selector.setSubject(input.getIssuerX500Principal()); byte[] issuerIdExtension = input.getExtensionValue("2.5.29.35"); if (issuerIdExtension != null) { try { byte[] issuerId = new AuthorityKeyIdentifierExtension( false, new DerValue(issuerIdExtension).getOctetString()) .getEncodedKeyIdentifier(); selector.setSubjectKeyIdentifier(issuerId); } catch (IOException e) { // ignored. issuerId is still null } } for (X509Certificate cert : allCerts) { if (selector.match(cert)) { return cert; } } return null; } but it seems it cannot deal with the case where a cert has the correct subject but no SKID extension. Or do you think this should never happen? Thanks Max > On Jan 17, 2019, at 11:41 AM, Weijun Wang wrote: > > I'll take a look. I thought java.security.cert.X509CertSelector is used by CertPath validators and builders internally and never thought it can be called directly. > > Thanks, > Max > >> On Jan 17, 2019, at 1:49 AM, Xuelei Fan wrote: >> >> Hi Max, >> >> I did not look into the detailed implementation of findIssuer() yet. Have you considered to use java.security.cert.X509CertSelector? >> >> Thanks, >> Xuelei >> >> On 1/9/2019 6:59 AM, Weijun Wang wrote: >>> Please take a review at >>> https://cr.openjdk.java.net/~weijun/8215776/webrev.00/ >>> PKCS12KeyStore now can find certificate issuers more precisely using SubjectKeyIdentifier and AuthorityKeyIdentifier. I thought about using CertPath builder or checking signatures but those changes are too much. >>> Thanks, >>> Max > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Jan 21 14:16:03 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Jan 2019 14:16:03 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> Message-ID: On 21/01/2019 09:17, Langer, Christoph wrote: > : > OK, I can see the point that in a PosixFileAttributeView as it is, there's no place for optionality/null values. However, with this approach the benefits would be that Files::get/setPosixPermissions would work and that's why I think we should pursue this. The challenge will be to find reasonable defaults. That is how extensions are suppose to work. I think Sherman has looked at exporting zipfs specific FileAttributeViews a couple of times. Yes, it doesn't mean compiling against a JDK-specific API but we have several JDK specific modules that export APIs. > : > > I can imagine something like this: > Zipfs by default implements an own view that offers dynamic, not type safe access to "zip:permissions" and we'll document this. If a user of zipfs wants to see full PosixFileAttributeView support with default values, then we should allow for a creation attribute for the zipfs that can control this. Maybe we can even allow specifying default values for user, group and permissions via zipfs attributes. The configuration parameters that you specify to newFileSystem can work like mount options so provide some way to specify defaults may be useful. When you mount a fat32 file system on a Linux/Unix system then you can usually configure things like the umask which may give you ideas. -Alan From dennis at gesker.com Mon Jan 21 14:57:58 2019 From: dennis at gesker.com (Dennis Gesker) Date: Mon, 21 Jan 2019 07:57:58 -0700 Subject: JDK-8215102 (Follow-up) In-Reply-To: <367cf00106cd91678df4cd5f68f710647ac1515d.camel@redhat.com> References: <07e6daa4a6a83133acb80d8a065836e13637b866.camel@redhat.com> <367cf00106cd91678df4cd5f68f710647ac1515d.camel@redhat.com> Message-ID: Pasted: https://paste.fedoraproject.org/paste/vEvp9RwN2rVvIKGiC0IvEQ On Mon, Jan 21, 2019 at 2:10 AM Severin Gehwolf wrote: > Hi Dennis, > > On Sat, 2019-01-19 at 12:08 -0700, Dennis Gesker wrote: > > Hi Severin: > > > > A link to the txt file via Google Drive his here. > > "Sorry, the file you have requested does not exist." > > Could you please upload it somewhere less restricted? Maybe > https://paste.fedoraproject.org/ > > or something similar? > > I guess if you include me directly, a file attachment would work too... > It's the mailing lists which strip attachments. > > > I appreciate you and Alan taking a look. Especially, information > > submitted from someone who is not a part of openjdk project. > > I do hope the debug info helps. Let me know anything else you need > > and I will do my best to provide it. > > Sure. I'll be mostly doing the intermediary work: getting the info > added to the bug, though. > > > And, should your team decide to open a new ticket or reopen this > > original ticket in the JIRA could you add me to the ticket? > > You'd have to become OpenJDK author for this[1]. It's not terribly > difficult, but it's somewhat of an entry barrier I understand. > > > BTW, (off topic), would your recommend submitting a contributor > > application to the openjdk project so bug reports can be submitted > > directly? > > If you intend to submit the occasional bug report and fix it's easier > for you long-term to attempt to become OpenJDK author (which requires > signing the OCA[2]). > > > The dev group at my company is VERY small (and this message to your > > group at the project is from my personal email) but I'd be glad to > > submit bug reports as we come across them in our day to day use of > > Java. > > If there are good reproducers for bugs this would be very welcome. > Thanks for investing some time in this! > > Cheers, > Severin > > [1] http://openjdk.java.net/bylaws#author > > http://openjdk.java.net/projects/#project-author > > [2] http://oss.oracle.com/oca.pdf > > > > Cordially, > > Dennis > > dennis at gesker.com > > > > On Fri, Jan 18, 2019 at 10:07 AM Severin Gehwolf > > wrote: > > > On Thu, 2019-01-17 at 10:00 -0700, Dennis Gesker wrote: > > > [...] > > > > Added the -Djavax.net.debug=all option to my Wildfly startup and > > > > waited for the pool to close a connection to MySql at AWS. > > > > > > > > TXT file attached. > > > > > > > > javac 11.0.1 > > > > mysql jdbc driver 8.0.13 > > > > wildfly 15.0.1 > > > > > > > > --drg > > > > > > Unfortunately the txt file got stripped by the mailing list. Would > > > you > > > be able to upload it somewhere and post a link? > > > > > > Thanks, > > > Severin > > > > > > > > > -- Dennis R. Gesker [image: LinkedIn] [image: WordPress] [image: Gesker] [image: GPG_PGP] [image: dennis at gesker.com] ?Be without fear in the face of your enemies. Be brave and upright that God may love thee. Speak the truth always, even if it leads to your death. Safeguard the helpless and do no wrong ? that is your oath.?* -The Knight?s Oath (Kingdom of Heaven)* -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgehwolf at redhat.com Mon Jan 21 16:22:58 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 21 Jan 2019 17:22:58 +0100 Subject: JDK-8215102 (Follow-up) In-Reply-To: References: <07e6daa4a6a83133acb80d8a065836e13637b866.camel@redhat.com> <367cf00106cd91678df4cd5f68f710647ac1515d.camel@redhat.com> Message-ID: On Mon, 2019-01-21 at 07:57 -0700, Dennis Gesker wrote: > > Pasted: > > https://paste.fedoraproject.org/paste/vEvp9RwN2rVvIKGiC0IvEQ Is this the full trace? I don't see any exceptions happening in the log. Am I missing something? Thanks, Severin > On Mon, Jan 21, 2019 at 2:10 AM Severin Gehwolf > wrote: > > Hi Dennis, > > > > On Sat, 2019-01-19 at 12:08 -0700, Dennis Gesker wrote: > > > Hi Severin: > > > > > > A link to the txt file via Google Drive his here. > > > > "Sorry, the file you have requested does not exist." > > > > Could you please upload it somewhere less restricted? Maybe > > https://paste.fedoraproject.org/ or something similar? > > > > I guess if you include me directly, a file attachment would work > > too... > > It's the mailing lists which strip attachments. > > > > > I appreciate you and Alan taking a look. Especially, information > > > submitted from someone who is not a part of openjdk project. > > > I do hope the debug info helps. Let me know anything else you > > need > > > and I will do my best to provide it. > > > > Sure. I'll be mostly doing the intermediary work: getting the info > > added to the bug, though. > > > > > And, should your team decide to open a new ticket or reopen this > > > original ticket in the JIRA could you add me to the ticket? > > > > You'd have to become OpenJDK author for this[1]. It's not terribly > > difficult, but it's somewhat of an entry barrier I understand. > > > > > BTW, (off topic), would your recommend submitting a contributor > > > application to the openjdk project so bug reports can be > > submitted > > > directly? > > > > If you intend to submit the occasional bug report and fix it's > > easier > > for you long-term to attempt to become OpenJDK author (which > > requires > > signing the OCA[2]). > > > > > The dev group at my company is VERY small (and this message to > > your > > > group at the project is from my personal email) but I'd be glad > > to > > > submit bug reports as we come across them in our day to day use > > of > > > Java. > > > > If there are good reproducers for bugs this would be very welcome. > > Thanks for investing some time in this! > > > > Cheers, > > Severin > > > > [1] http://openjdk.java.net/bylaws#author > > http://openjdk.java.net/projects/#project-author > > [2] http://oss.oracle.com/oca.pdf > > > > > Cordially, > > > Dennis > > > dennis at gesker.com > > > > > > On Fri, Jan 18, 2019 at 10:07 AM Severin Gehwolf < > > sgehwolf at redhat.com > > > > wrote: > > > > On Thu, 2019-01-17 at 10:00 -0700, Dennis Gesker wrote: > > > > [...] > > > > > Added the -Djavax.net.debug=all option to my Wildfly startup > > and > > > > > waited for the pool to close a connection to MySql at AWS. > > > > > > > > > > TXT file attached. > > > > > > > > > > javac 11.0.1 > > > > > mysql jdbc driver 8.0.13 > > > > > wildfly 15.0.1 > > > > > > > > > > --drg > > > > > > > > Unfortunately the txt file got stripped by the mailing list. > > Would > > > > you > > > > be able to upload it somewhere and post a link? > > > > > > > > Thanks, > > > > Severin > > > > > > > > > > > > > > From xuelei.fan at oracle.com Mon Jan 21 17:39:55 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 21 Jan 2019 09:39:55 -0800 Subject: RFR 8215776: Keytool importkeystore may mix up certificate chain entries when DNs conflict In-Reply-To: References: <87E0531E-F7CE-4F32-86B7-4A3F3C1B842F@oracle.com> <9e41b753-aeb7-a09c-f221-e464327e9e90@oracle.com> <8945E624-FE60-44C2-AADA-0D69B61244C7@oracle.com> Message-ID: <68dde8e9-3801-0b37-09ee-cfe489939ac0@oracle.com> > but it seems it cannot deal with the case where a cert has the correct subject but no SKID extension. Or do you think this should never happen? It could happen, especially for self-signed cert.? See also, the sun.security.provider.certpath.ForwardBuilder#PKIXCertComparator. Xuelei On 1/21/2019 2:05 AM, Weijun Wang wrote: > I tried something like this: > > private X509Certificate findIssuer(X509Certificate input) { > > X509CertSelector selector =new X509CertSelector(); selector.setSubject(input.getIssuerX500Principal()); byte[]issuerIdExtension =input.getExtensionValue("2.5.29.35"); if (issuerIdExtension !=null) { > try { > byte[]issuerId =new AuthorityKeyIdentifierExtension( > false, new DerValue(issuerIdExtension).getOctetString()) > .getEncodedKeyIdentifier(); selector.setSubjectKeyIdentifier(issuerId); }catch (IOException e) { > // ignored. issuerId is still null } > } > > for (X509Certificate cert :allCerts) { > if (selector.match(cert)) { > return cert; } > } > return null; } > but it seems it cannot deal with the case where a cert has the correct > subject but no SKID extension. Or do you think this should never happen? > > Thanks > Max > >> On Jan 17, 2019, at 11:41 AM, Weijun Wang > > wrote: >> >> I'll take a look. I thought java.security.cert.X509CertSelector is >> used by CertPath validators and builders internally and never thought >> it can be called directly. >> >> Thanks, >> Max >> >>> On Jan 17, 2019, at 1:49 AM, Xuelei Fan >> > wrote: >>> >>> Hi Max, >>> >>> I did not look into the detailed implementation of findIssuer() yet. >>> Have you considered to use java.security.cert.X509CertSelector? >>> >>> Thanks, >>> Xuelei >>> >>> On 1/9/2019 6:59 AM, Weijun Wang wrote: >>>> Please take a review at >>>> https://cr.openjdk.java.net/~weijun/8215776/webrev.00/ >>>> PKCS12KeyStore now can find certificate issuers more precisely >>>> using SubjectKeyIdentifier and AuthorityKeyIdentifier. I thought >>>> about using CertPath builder or checking signatures?but those >>>> changes are too much. >>>> Thanks, >>>> Max >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Mon Jan 21 18:02:24 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 21 Jan 2019 10:02:24 -0800 Subject: Not possible to disable new TLS extensions for TLS 1.2 connections In-Reply-To: References: <1f4b323a-7a98-35c6-8501-f88c6cc2208b@oracle.com> Message-ID: Hi Amir, I can see the problem for incompatible impl.? Would you mind submit an OpenJDK enhancement for a workaround? Thanks & Regards, Xuelei On 1/20/2019 4:10 PM, Amir Khassaia wrote: > Xuelei, > > I have a sample socket client for the device TLS issue but its not > very helpful as any socket client created on top of JDK will do, the > last problem was apparent only when talking to a specific hardware > device which refused to negotiate TLS session (I've seen several odd > TLS implementations that were intolerant to Java changes in various > ways over the years and compatibility could always be assured through > config changes, this time around less so). > > Some of the hardware TLS stacks can range from small oddities to being > completely broken by small changes as they can contain outdated and > poorly implemented TLS stacks that are very sensitive so even a small > change can break them and thats why its always important to have > levers provided to control almost every aspect of the handshake. > > I have a sample in my gist > (https://gist.github.com/amir-khassaia/04347ca88526f4b958b3326968a905c0), > apologies its in Kotlin. When ran with java 8, 9, 10 there were no > issues. With java 11 this worked on most devices but I've had a device > at a remote location that was not in my control that I've had to > diagnose the handshake failure on using java 11 it was intolerant to > TLS 1.2 client hello from Java 11 but fine with TLS 1.1 as the new > extensions are not present. It would be fine with TLS 1.2 client hello > from Java 10 and earlier as I mentioned. > > Javax.net.debug output > ------------------------------- > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.395 > AEDT|SSLCipher.java:437|jdk.tls.keyLimits: ?entry = AES/GCM/NoPadding > KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472 > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.433 > AEDT|ServerNameExtension.java:255|Unable to indicate server name > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: > server_name > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: > status_request > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.443 > AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is not > supported by the underlying providers > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.444 > AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not > supported by the underlying providers > javax.net.ssl|INFO|01|main|2019-01-08 13:40:14.449 > AEDT|AlpnExtension.java:161|No available application protocols > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.449 > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: > application_layer_protocol_negotiation > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.450 > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: > status_request_v2 > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.453 > AEDT|ClientHello.java:651|Produced ClientHello handshake message ( > "ClientHello": { > ? "client version" ? ? ?: "TLSv1.2", > ? "random" ? ? ? ? ? ? ?: "1A BA E8 FC 59 00 AB DF 9A 1A 07 94 24 7F > 34 3D 0B D2 7D 10 72 52 54 CD 44 43 62 E8 8B 42 C6 68", > ? "session id" ? ? ? ? ?: "", > ? "cipher suites" ? ? ? : > "[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), > TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), > TLS_RSA_WITH_AES_128_CBC_SHA(0x002F)]", > ? "compression methods" : "00", > ? "extensions" ? ? ? ? ?: [ > ? ? "supported_groups (10)": { > ? ? ? "versions": [secp256r1, secp384r1, secp521r1, secp160k1] > ? ? }, > ? ? "ec_point_formats (11)": { > ? ? ? "formats": [uncompressed] > ? ? }, > ? ? "signature_algorithms (13)": { > ? ? ? "signature schemes": [ecdsa_secp256r1_sha256, > ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, > rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, > rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, > rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, > rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5] > ? ? }, > ? ? "signature_algorithms_cert (50)": { > ? ? ? "signature schemes": [ecdsa_secp256r1_sha256, > ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, > rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, > rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, > rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, > rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5] > ? ? }, > ? ? "extended_master_secret (23)": { > ? ? ? > ? ? }, > ? ? "supported_versions (43)": { > ? ? ? "versions": [TLSv1.2, TLSv1.1] > ? ? }, > ? ? "renegotiation_info (65,281)": { > ? ? ? "renegotiated connection": [] > ? ? } > ? ] > } > ) > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.455 > AEDT|Alert.java:232|Received alert message ( > "Alert": { > ? "level" ? ? ?: "fatal", > ? "description": "handshake_failure" > } > ) > javax.net.ssl|ERROR|01|main|2019-01-08 13:40:14.456 > AEDT|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE): Received > fatal alert: handshake_failure ( > "throwable" : { > ? javax.net.ssl.SSLHandshakeException: Received fatal alert: > handshake_failure > ? at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) > ? at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) > ? at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) > ? at > java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) > ? at > java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) > ? at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) > ? at > java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) > ? at > java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) > ? at > java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) > ? at SslSocketClient.main(SslSocketClient.kt:47)} > > ) > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 > AEDT|SSLSocketImpl.java:1361|close the underlying socket > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 > AEDT|SSLSocketImpl.java:1380|close the SSL connection (initiative) > Exception in thread "main" javax.net.ssl.SSLHandshakeException: > Received fatal alert: handshake_failure > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) > at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) > at > java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) > at > java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) > at > java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) > at > java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) > at SslSocketClient.main(SslSocketClient.kt:47) > > > > > Wireshark TLS 1.2 Java 8 client hello > ------------------------------------------------- > Secure Sockets Layer > ? ? TLSv1.2 Record Layer: Handshake Protocol: Client Hello > ? ? ? ? Content Type: Handshake (22) > ? ? ? ? Version: TLS 1.2 (0x0303) > ? ? ? ? Length: 157 > ? ? ? ? Handshake Protocol: Client Hello > ? ? ? ? ? ? Handshake Type: Client Hello (1) > ? ? ? ? ? ? Length: 153 > ? ? ? ? ? ? Version: TLS 1.2 (0x0303) > ? ? ? ? ? ? Random: 5c34044c709feae39585e4db8e41b0170fbf9fa428b38941... > ? ? ? ? ? ? ? ? GMT Unix Time: Jan? 8, 2019 13:00:44.000000000 AUS > Eastern Daylight Time > ? ? ? ? ? ? ? ? Random Bytes: > 709feae39585e4db8e41b0170fbf9fa428b38941983ddb53... > ? ? ? ? ? ? Session ID Length: 0 > ? ? ? ? ? ? Cipher Suites Length: 44 > ? ? ? ? ? ? Cipher Suites (22 suites) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 > (0xc023) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 > (0xc027) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 > (0xc025) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 > (0xc029) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA > (0xc009) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 > (0xc02b) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > (0xc02f) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 > (0xc02d) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 > (0xc031) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (0x00a2) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) > ? ? ? ? ? ? Compression Methods Length: 1 > ? ? ? ? ? ? Compression Methods (1 method) > ? ? ? ? ? ? ? ? Compression Method: null (0) > ? ? ? ? ? ? Extensions Length: 68 > ? ? ? ? ? ? Extension: supported_groups (len=22) > ? ? ? ? ? ? ? ? Type: supported_groups (10) > ? ? ? ? ? ? ? ? Length: 22 > ? ? ? ? ? ? ? ? Supported Groups List Length: 20 > ? ? ? ? ? ? ? ? Supported Groups (10 groups) > ? ? ? ? ? ? ? ? ? ? Supported Group: secp256r1 (0x0017) > ? ? ? ? ? ? ? ? ? ? Supported Group: secp384r1 (0x0018) > ? ? ? ? ? ? ? ? ? ? Supported Group: secp521r1 (0x0019) > ? ? ? ? ? ? ? ? ? ? Supported Group: sect283k1 (0x0009) > ? ? ? ? ? ? ? ? ? ? Supported Group: sect283r1 (0x000a) > ? ? ? ? ? ? ? ? ? ? Supported Group: sect409k1 (0x000b) > ? ? ? ? ? ? ? ? ? ? Supported Group: sect409r1 (0x000c) > ? ? ? ? ? ? ? ? ? ? Supported Group: sect571k1 (0x000d) > ? ? ? ? ? ? ? ? ? ? Supported Group: sect571r1 (0x000e) > ? ? ? ? ? ? ? ? ? ? Supported Group: secp256k1 (0x0016) > ? ? ? ? ? ? Extension: ec_point_formats (len=2) > ? ? ? ? ? ? ? ? Type: ec_point_formats (11) > ? ? ? ? ? ? ? ? Length: 2 > ? ? ? ? ? ? ? ? EC point formats Length: 1 > ? ? ? ? ? ? ? ? Elliptic curves point formats (1) > ? ? ? ? ? ? ? ? ? ? EC point format: uncompressed (0) > ? ? ? ? ? ? Extension: signature_algorithms (len=28) > ? ? ? ? ? ? ? ? Type: signature_algorithms (13) > ? ? ? ? ? ? ? ? Length: 28 > ? ? ? ? ? ? ? ? Signature Hash Algorithms Length: 26 > ? ? ? ? ? ? ? ? Signature Hash Algorithms (13 algorithms) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA512 (6) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha512 (0x0601) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA512 (6) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA384 (5) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha384 (0x0501) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA384 (5) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA256 (4) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha256 (0x0401) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA256 (4) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA256 DSA (0x0402) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA256 (4) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: DSA (2) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA224 ECDSA (0x0303) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA224 (3) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA224 RSA (0x0301) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA224 (3) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA224 DSA (0x0302) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA224 (3) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: DSA (2) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_sha1 (0x0203) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA1 (2) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha1 (0x0201) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA1 (2) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA1 DSA (0x0202) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA1 (2) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: DSA (2) > ? ? ? ? ? ? Extension: extended_master_secret (len=0) > ? ? ? ? ? ? ? ? Type: extended_master_secret (23) > ? ? ? ? ? ? ? ? Length: 0 > > > > Wireshark Java 11 TLS 1.2 Client hello > ---------------------------------------------------- > Secure Sockets Layer > ? ? TLSv1.2 Record Layer: Handshake Protocol: Client Hello > ? ? ? ? Content Type: Handshake (22) > ? ? ? ? Version: TLS 1.2 (0x0303) > ? ? ? ? Length: 185 > ? ? ? ? Handshake Protocol: Client Hello > ? ? ? ? ? ? Handshake Type: Client Hello (1) > ? ? ? ? ? ? Length: 181 > ? ? ? ? ? ? Version: TLS 1.2 (0x0303) > ? ? ? ? ? ? Random: 37f32691301b6b9d45bb62c6268915819881b8ebd95f152c... > ? ? ? ? ? ? ? ? GMT Unix Time: Sep 30, 1999 19:00:01.000000000 AUS > Eastern Standard Time > ? ? ? ? ? ? ? ? Random Bytes: > 301b6b9d45bb62c6268915819881b8ebd95f152c41c7e483... > ? ? ? ? ? ? Session ID Length: 0 > ? ? ? ? ? ? Cipher Suites Length: 10 > ? ? ? ? ? ? Cipher Suites (5 suites) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 > (0xc023) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 > (0xc027) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 > (0xc029) > ? ? ? ? ? ? ? ? Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) > ? ? ? ? ? ? Compression Methods Length: 1 > ? ? ? ? ? ? Compression Methods (1 method) > ? ? ? ? ? ? ? ? Compression Method: null (0) > ? ? ? ? ? ? Extensions Length: 130 > ? ? ? ? ? ? Extension: supported_groups (len=10) > ? ? ? ? ? ? ? ? Type: supported_groups (10) > ? ? ? ? ? ? ? ? Length: 10 > ? ? ? ? ? ? ? ? Supported Groups List Length: 8 > ? ? ? ? ? ? ? ? Supported Groups (4 groups) > ? ? ? ? ? ? ? ? ? ? Supported Group: secp256r1 (0x0017) > ? ? ? ? ? ? ? ? ? ? Supported Group: secp384r1 (0x0018) > ? ? ? ? ? ? ? ? ? ? Supported Group: secp521r1 (0x0019) > ? ? ? ? ? ? ? ? ? ? Supported Group: secp160k1 (0x000f) > ? ? ? ? ? ? Extension: ec_point_formats (len=2) > ? ? ? ? ? ? ? ? Type: ec_point_formats (11) > ? ? ? ? ? ? ? ? Length: 2 > ? ? ? ? ? ? ? ? EC point formats Length: 1 > ? ? ? ? ? ? ? ? Elliptic curves point formats (1) > ? ? ? ? ? ? ? ? ? ? EC point format: uncompressed (0) > ? ? ? ? ? ? Extension: signature_algorithms (len=42) > ? ? ? ? ? ? ? ? Type: signature_algorithms (13) > ? ? ? ? ? ? ? ? Length: 42 > ? ? ? ? ? ? ? ? Signature Hash Algorithms Length: 40 > ? ? ? ? ? ? ? ? Signature Hash Algorithms (20 algorithms) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA256 (4) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA384 (5) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA512 (6) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_rsae_sha256 (0x0804) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: Unknown (4) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_rsae_sha384 (0x0805) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: Unknown (5) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_rsae_sha512 (0x0806) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: Unknown (6) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_pss_sha256 (0x0809) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: Unknown (9) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_pss_sha384 (0x080a) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: Unknown (10) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_pss_sha512 (0x080b) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: Unknown (11) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha256 (0x0401) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA256 (4) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha384 (0x0501) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA384 (5) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha512 (0x0601) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA512 (6) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA256 DSA (0x0402) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA256 (4) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: DSA (2) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA224 ECDSA (0x0303) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA224 (3) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA224 RSA (0x0301) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA224 (3) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA224 DSA (0x0302) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA224 (3) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: DSA (2) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_sha1 (0x0203) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA1 (2) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha1 (0x0201) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA1 (2) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA1 DSA (0x0202) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA1 (2) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: DSA (2) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: MD5 RSA (0x0101) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: MD5 (1) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) > ? ? ? ? ? ? Extension: signature_algorithms_cert (len=42) > ? ? ? ? ? ? ? ? Type: signature_algorithms_cert (50) > ? ? ? ? ? ? ? ? Length: 42 > ? ? ? ? ? ? ? ? Signature Hash Algorithms Length: 40 > ? ? ? ? ? ? ? ? Signature Hash Algorithms (20 algorithms) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA256 (4) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA384 (5) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA512 (6) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_rsae_sha256 (0x0804) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: Unknown (4) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_rsae_sha384 (0x0805) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: Unknown (5) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_rsae_sha512 (0x0806) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: Unknown (6) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_pss_sha256 (0x0809) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: Unknown (9) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_pss_sha384 (0x080a) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: Unknown (10) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_pss_sha512 (0x080b) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: Unknown (11) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha256 (0x0401) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA256 (4) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha384 (0x0501) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA384 (5) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha512 (0x0601) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA512 (6) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA256 DSA (0x0402) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA256 (4) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: DSA (2) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA224 ECDSA (0x0303) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA224 (3) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA224 RSA (0x0301) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA224 (3) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA224 DSA (0x0302) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA224 (3) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: DSA (2) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_sha1 (0x0203) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA1 (2) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha1 (0x0201) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA1 (2) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA1 DSA (0x0202) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA1 (2) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: DSA (2) > ? ? ? ? ? ? ? ? ? ? Signature Algorithm: MD5 RSA (0x0101) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: MD5 (1) > ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) > ? ? ? ? ? ? Extension: extended_master_secret (len=0) > ? ? ? ? ? ? ? ? Type: extended_master_secret (23) > ? ? ? ? ? ? ? ? Length: 0 > ? ? ? ? ? ? Extension: supported_versions (len=5) > ? ? ? ? ? ? ? ? Type: supported_versions (43) > ? ? ? ? ? ? ? ? Length: 5 > ? ? ? ? ? ? ? ? Supported Versions length: 4 > ? ? ? ? ? ? ? ? Supported Version: TLS 1.2 (0x0303) > ? ? ? ? ? ? ? ? Supported Version: TLS 1.1 (0x0302) > ? ? ? ? ? ? Extension: renegotiation_info (len=1) > ? ? ? ? ? ? ? ? Type: renegotiation_info (65281) > ? ? ? ? ? ? ? ? Length: 1 > ? ? ? ? ? ? ? ? Renegotiation Info extension > ? ? ? ? ? ? ? ? ? ? Renegotiation info extension length: 0 > > > > > > > On Mon, Jan 21, 2019 at 10:37 AM Xuelei Fan > wrote: > > Hi Amir, > > Normally, the extension should have no impact if it cannot be > recognized by the server.?? It's good to be able to disable > extensions if not needed.?? I need to evaluate the priority of it > although.? Did you have a simple test code that I can reproduce > the issue? > > Thanks, > > Xuelei > > On 1/20/2019 3:03 PM, Amir Khassaia wrote: >> Greetings Xuelei, >> To follow up on this, the certificate in the connection is a red >> herring and not important. It's actually a very unusual behaviour >> by talk.google.com ?endpoint to >> encapsulate an error message inside a certificate. >> >> As per the output I included: >> /"certificate" : { />/? ? "version"? ? ? ? ? ? : "v3", />/? ? "serial number"? ? ? : "00 90 76 89 18 E9 33 93 A0", />/? ? "signature algorithm": "SHA256withRSA", />/? ? "issuer"? ? ? ? ? ? ?: "CN=invalid2.invalid, OU="No SNI >> provided; />/please fix your client."", />/? ? "not before"? ? ? ? ?: "2015-01-01 11:00:00.000 AEDT", />/? ? "not? after"? ? ? ? ?: "2030-01-01 11:00:00.000 AEDT", />/? ? "subject"? ? ? ? ? ? : "CN=invalid2.invalid, OU="No SNI >> provided; />/please fix your client."",/ >> // >> This certificate simply masks the TLS interoperability issue as >> an untrusted certificate issue. >> The fact is, some of the extensions sent by JSSE are changes to >> TLS 1.2 to support TLS 1.3, this however affects some clients >> adversely in practice and usually JDK provides properties to turn >> new enhancements off and work around such behaviour, for the >> extensions I mentioned this is not provided and hence they are >> always sent for client sockets unless TLSv1.2 is not in use. >> >> The impact to us is that upgrading to JDK11 means for some >> endpoints or devices that are not 100% compliant to the spec the >> security is reduced as we have to now work around to drop >> connections to these to TLSv1.1 or TLS1.0 or not to move to Java >> 11 at all. >> My request is simply to have all of the new extensions >> configurable on individual basis so that they can be turned off >> if needed for compatibility just like most other security >> enhancements that were delivered in the past. >> It appears some of the issues can come from >> >> - inclusion of RSASSA-PSS alg in TLS 1.2 handshakes but these can >> disabled at least >> >> -signature_algorithms_cert and supported_versions extensions >> which seem to be hardcoded for TLS 1.2 (I was not able to >> conclusively identify which of these caused my troubles) >> >> https://tools.ietf.org/html/rfc8446#section-1.3?does say that TLS >> 1.2 clients are affected but in an optional manner.Just today >> I've encountered another Java 11 interop issue with TLS but this >> time with a physical device which can have a long shelf life yet >> running a simple client socket handshake abruptly terminates the >> connection upon client hello (no server_hello at all), and >> downgrading the JRE below 11 works fine. I'm including a trace >> for that as well: javax.net.ssl|DEBUG|01|main|2019-01-08 >> 13:40:14.395 AEDT|SSLCipher.java:437|jdk.tls.keyLimits: ?entry = >> AES/GCM/NoPadding KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = >> 137438953472 >> >> javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.433 >> AEDT|ServerNameExtension.java:255|Unable to indicate server name >> >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 >> AEDT|SSLExtensions.java:235|Ignore, context unavailable >> extension: server_name >> >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 >> AEDT|SSLExtensions.java:235|Ignore, context unavailable >> extension: status_request >> >> javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.443 >> AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is >> not supported by the underlying providers >> >> javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.444 >> AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not >> supported by the underlying providers >> >> javax.net.ssl|INFO|01|main|2019-01-08 13:40:14.449 >> AEDT|AlpnExtension.java:161|No available application protocols >> >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.449 >> AEDT|SSLExtensions.java:235|Ignore, context unavailable >> extension: application_layer_protocol_negotiation >> >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.450 >> AEDT|SSLExtensions.java:235|Ignore, context unavailable >> extension: status_request_v2 >> >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.453 >> AEDT|ClientHello.java:651|Produced ClientHello handshake message ( >> >> "ClientHello": { >> >> ? "client version" ? ? ?: "TLSv1.2", >> >> ? "random" ? ? ? ? ? ? ?: "1A BA E8 FC 59 00 AB DF 9A 1A 07 94 24 >> 7F 34 3D 0B D2 7D 10 72 52 54 CD 44 43 62 E8 8B 42 C6 68", >> >> ? "session id" ? ? ? ? ?: "", >> >> ? "cipher suites" ? ? ? : >> "[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), >> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), >> TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), >> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), >> TLS_RSA_WITH_AES_128_CBC_SHA(0x002F)]", >> >> ? "compression methods" : "00", >> >> ? "extensions" ? ? ? ? ?: [ >> >> ? ? "supported_groups (10)": { >> >> ? ? ? "versions": [secp256r1, secp384r1, secp521r1, secp160k1] >> >> ? ? }, >> >> ? ? "ec_point_formats (11)": { >> >> ? ? ? "formats": [uncompressed] >> >> ? ? }, >> >> ? ? "signature_algorithms (13)": { >> >> ? ? ? "signature schemes": [ecdsa_secp256r1_sha256, >> ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, >> rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, >> rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, >> rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, >> ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, >> dsa_sha1, rsa_md5] >> >> ? ? }, >> >> ? ? "signature_algorithms_cert (50)": { >> >> ? ? ? "signature schemes": [ecdsa_secp256r1_sha256, >> ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, >> rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, >> rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, >> rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, >> ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, >> dsa_sha1, rsa_md5] >> >> ? ? }, >> >> ? ? "extended_master_secret (23)": { >> >> ? ? ? >> >> ? ? }, >> >> ? ? "supported_versions (43)": { >> >> ? ? ? "versions": [TLSv1.2, TLSv1.1] >> >> ? ? }, >> >> ? ? "renegotiation_info (65,281)": { >> >> ? ? ? "renegotiated connection": [] >> >> ? ? } >> >> ? ] >> >> } >> >> ) >> >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.455 >> AEDT|Alert.java:232|Received alert message ( >> >> "Alert": { >> >> ? "level" ? ? ?: "fatal", >> >> ? "description": "handshake_failure" >> >> } >> >> ) >> >> javax.net.ssl|ERROR|01|main|2019-01-08 13:40:14.456 >> AEDT|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE): >> Received fatal alert: handshake_failure ( >> >> "throwable" : { >> >> ? javax.net.ssl.SSLHandshakeException: Received fatal alert: >> handshake_failure >> >> ? ? at >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >> >> ? ? at >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >> >> ? ? at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >> >> ? ? at >> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) >> >> ? ? at >> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) >> >> ? ? at >> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >> >> ? ? at >> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) >> >> ? ? at >> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) >> >> ? ? at >> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) >> >> ? ? at SslSocketClient.main(SslSocketClient.kt:47)} >> >> >> ) >> >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 >> AEDT|SSLSocketImpl.java:1361|close the underlying socket >> >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 >> AEDT|SSLSocketImpl.java:1380|close the SSL connection (initiative) >> >> Exception in thread "main" javax.net.ssl.SSLHandshakeException: >> Received fatal alert: handshake_failure >> >> ? at >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >> >> ? at >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >> >> ? at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >> >> ? at >> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) >> >> ? at >> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) >> >> ? at >> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >> >> ? at >> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) >> >> ? at >> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) >> >> ? at >> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) >> >> ? at SslSocketClient.main(SslSocketClient.kt:47) >> >> >> >> >> I've sent my reply earlier but neither got it posted nor denied >> notification so trying again. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amir.khassaia at gmail.com Mon Jan 21 21:29:44 2019 From: amir.khassaia at gmail.com (Amir Khassaia) Date: Tue, 22 Jan 2019 08:29:44 +1100 Subject: Not possible to disable new TLS extensions for TLS 1.2 connections In-Reply-To: References: <1f4b323a-7a98-35c6-8501-f88c6cc2208b@oracle.com> Message-ID: Thanks Xuelei, Do you mean to create an RFE at openjdk https://bugs.openjdk.java.net/ ? On Tue, Jan 22, 2019 at 5:02 AM Xuelei Fan wrote: > Hi Amir, > > I can see the problem for incompatible impl. Would you mind submit an > OpenJDK enhancement for a workaround? > > Thanks & Regards, > > Xuelei > On 1/20/2019 4:10 PM, Amir Khassaia wrote: > > Xuelei, > > I have a sample socket client for the device TLS issue but its not very > helpful as any socket client created on top of JDK will do, the last > problem was apparent only when talking to a specific hardware device which > refused to negotiate TLS session (I've seen several odd TLS implementations > that were intolerant to Java changes in various ways over the years and > compatibility could always be assured through config changes, this time > around less so). > > Some of the hardware TLS stacks can range from small oddities to being > completely broken by small changes as they can contain outdated and poorly > implemented TLS stacks that are very sensitive so even a small change can > break them and thats why its always important to have levers provided to > control almost every aspect of the handshake. > > I have a sample in my gist ( > https://gist.github.com/amir-khassaia/04347ca88526f4b958b3326968a905c0), > apologies its in Kotlin. When ran with java 8, 9, 10 there were no issues. > With java 11 this worked on most devices but I've had a device at a remote > location that was not in my control that I've had to diagnose the handshake > failure on using java 11 it was intolerant to TLS 1.2 client hello from > Java 11 but fine with TLS 1.1 as the new extensions are not present. It > would be fine with TLS 1.2 client hello from Java 10 and earlier as I > mentioned. > > Javax.net.debug output > ------------------------------- > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.395 > AEDT|SSLCipher.java:437|jdk.tls.keyLimits: entry = AES/GCM/NoPadding > KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472 > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.433 > AEDT|ServerNameExtension.java:255|Unable to indicate server name > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: > server_name > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: > status_request > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.443 > AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is not > supported by the underlying providers > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.444 > AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not supported > by the underlying providers > javax.net.ssl|INFO|01|main|2019-01-08 13:40:14.449 > AEDT|AlpnExtension.java:161|No available application protocols > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.449 > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: > application_layer_protocol_negotiation > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.450 > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: > status_request_v2 > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.453 > AEDT|ClientHello.java:651|Produced ClientHello handshake message ( > "ClientHello": { > "client version" : "TLSv1.2", > "random" : "1A BA E8 FC 59 00 AB DF 9A 1A 07 94 24 7F 34 3D > 0B D2 7D 10 72 52 54 CD 44 43 62 E8 8B 42 C6 68", > "session id" : "", > "cipher suites" : > "[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), > TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), > TLS_RSA_WITH_AES_128_CBC_SHA(0x002F)]", > "compression methods" : "00", > "extensions" : [ > "supported_groups (10)": { > "versions": [secp256r1, secp384r1, secp521r1, secp160k1] > }, > "ec_point_formats (11)": { > "formats": [uncompressed] > }, > "signature_algorithms (13)": { > "signature schemes": [ecdsa_secp256r1_sha256, > ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, > rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, > rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, > rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, > ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5] > }, > "signature_algorithms_cert (50)": { > "signature schemes": [ecdsa_secp256r1_sha256, > ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, > rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, > rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, > rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, > ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5] > }, > "extended_master_secret (23)": { > > }, > "supported_versions (43)": { > "versions": [TLSv1.2, TLSv1.1] > }, > "renegotiation_info (65,281)": { > "renegotiated connection": [] > } > ] > } > ) > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.455 > AEDT|Alert.java:232|Received alert message ( > "Alert": { > "level" : "fatal", > "description": "handshake_failure" > } > ) > javax.net.ssl|ERROR|01|main|2019-01-08 13:40:14.456 > AEDT|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE): Received fatal > alert: handshake_failure ( > "throwable" : { > javax.net.ssl.SSLHandshakeException: Received fatal alert: > handshake_failure > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) > at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) > at > java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) > at > java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) > at > java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) > at > java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) > at SslSocketClient.main(SslSocketClient.kt:47)} > > ) > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 > AEDT|SSLSocketImpl.java:1361|close the underlying socket > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 > AEDT|SSLSocketImpl.java:1380|close the SSL connection (initiative) > Exception in thread "main" javax.net.ssl.SSLHandshakeException: Received > fatal alert: handshake_failure > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) > at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) > at > java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) > at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) > at > java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) > at > java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) > at SslSocketClient.main(SslSocketClient.kt:47) > > > > > Wireshark TLS 1.2 Java 8 client hello > ------------------------------------------------- > Secure Sockets Layer > TLSv1.2 Record Layer: Handshake Protocol: Client Hello > Content Type: Handshake (22) > Version: TLS 1.2 (0x0303) > Length: 157 > Handshake Protocol: Client Hello > Handshake Type: Client Hello (1) > Length: 153 > Version: TLS 1.2 (0x0303) > Random: 5c34044c709feae39585e4db8e41b0170fbf9fa428b38941... > GMT Unix Time: Jan 8, 2019 13:00:44.000000000 AUS Eastern > Daylight Time > Random Bytes: > 709feae39585e4db8e41b0170fbf9fa428b38941983ddb53... > Session ID Length: 0 > Cipher Suites Length: 44 > Cipher Suites (22 suites) > Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 > (0xc023) > Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 > (0xc027) > Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c) > Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 > (0xc025) > Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029) > Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067) > Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040) > Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) > Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) > Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) > Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004) > Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e) > Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) > Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) > Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 > (0xc02b) > Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > (0xc02f) > Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c) > Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 > (0xc02d) > Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 (0xc031) > Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e) > Cipher Suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (0x00a2) > Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) > Compression Methods Length: 1 > Compression Methods (1 method) > Compression Method: null (0) > Extensions Length: 68 > Extension: supported_groups (len=22) > Type: supported_groups (10) > Length: 22 > Supported Groups List Length: 20 > Supported Groups (10 groups) > Supported Group: secp256r1 (0x0017) > Supported Group: secp384r1 (0x0018) > Supported Group: secp521r1 (0x0019) > Supported Group: sect283k1 (0x0009) > Supported Group: sect283r1 (0x000a) > Supported Group: sect409k1 (0x000b) > Supported Group: sect409r1 (0x000c) > Supported Group: sect571k1 (0x000d) > Supported Group: sect571r1 (0x000e) > Supported Group: secp256k1 (0x0016) > Extension: ec_point_formats (len=2) > Type: ec_point_formats (11) > Length: 2 > EC point formats Length: 1 > Elliptic curves point formats (1) > EC point format: uncompressed (0) > Extension: signature_algorithms (len=28) > Type: signature_algorithms (13) > Length: 28 > Signature Hash Algorithms Length: 26 > Signature Hash Algorithms (13 algorithms) > Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603) > Signature Hash Algorithm Hash: SHA512 (6) > Signature Hash Algorithm Signature: ECDSA (3) > Signature Algorithm: rsa_pkcs1_sha512 (0x0601) > Signature Hash Algorithm Hash: SHA512 (6) > Signature Hash Algorithm Signature: RSA (1) > Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503) > Signature Hash Algorithm Hash: SHA384 (5) > Signature Hash Algorithm Signature: ECDSA (3) > Signature Algorithm: rsa_pkcs1_sha384 (0x0501) > Signature Hash Algorithm Hash: SHA384 (5) > Signature Hash Algorithm Signature: RSA (1) > Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) > Signature Hash Algorithm Hash: SHA256 (4) > Signature Hash Algorithm Signature: ECDSA (3) > Signature Algorithm: rsa_pkcs1_sha256 (0x0401) > Signature Hash Algorithm Hash: SHA256 (4) > Signature Hash Algorithm Signature: RSA (1) > Signature Algorithm: SHA256 DSA (0x0402) > Signature Hash Algorithm Hash: SHA256 (4) > Signature Hash Algorithm Signature: DSA (2) > Signature Algorithm: SHA224 ECDSA (0x0303) > Signature Hash Algorithm Hash: SHA224 (3) > Signature Hash Algorithm Signature: ECDSA (3) > Signature Algorithm: SHA224 RSA (0x0301) > Signature Hash Algorithm Hash: SHA224 (3) > Signature Hash Algorithm Signature: RSA (1) > Signature Algorithm: SHA224 DSA (0x0302) > Signature Hash Algorithm Hash: SHA224 (3) > Signature Hash Algorithm Signature: DSA (2) > Signature Algorithm: ecdsa_sha1 (0x0203) > Signature Hash Algorithm Hash: SHA1 (2) > Signature Hash Algorithm Signature: ECDSA (3) > Signature Algorithm: rsa_pkcs1_sha1 (0x0201) > Signature Hash Algorithm Hash: SHA1 (2) > Signature Hash Algorithm Signature: RSA (1) > Signature Algorithm: SHA1 DSA (0x0202) > Signature Hash Algorithm Hash: SHA1 (2) > Signature Hash Algorithm Signature: DSA (2) > Extension: extended_master_secret (len=0) > Type: extended_master_secret (23) > Length: 0 > > > > Wireshark Java 11 TLS 1.2 Client hello > ---------------------------------------------------- > Secure Sockets Layer > TLSv1.2 Record Layer: Handshake Protocol: Client Hello > Content Type: Handshake (22) > Version: TLS 1.2 (0x0303) > Length: 185 > Handshake Protocol: Client Hello > Handshake Type: Client Hello (1) > Length: 181 > Version: TLS 1.2 (0x0303) > Random: 37f32691301b6b9d45bb62c6268915819881b8ebd95f152c... > GMT Unix Time: Sep 30, 1999 19:00:01.000000000 AUS Eastern > Standard Time > Random Bytes: > 301b6b9d45bb62c6268915819881b8ebd95f152c41c7e483... > Session ID Length: 0 > Cipher Suites Length: 10 > Cipher Suites (5 suites) > Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 > (0xc023) > Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 > (0xc027) > Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c) > Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029) > Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) > Compression Methods Length: 1 > Compression Methods (1 method) > Compression Method: null (0) > Extensions Length: 130 > Extension: supported_groups (len=10) > Type: supported_groups (10) > Length: 10 > Supported Groups List Length: 8 > Supported Groups (4 groups) > Supported Group: secp256r1 (0x0017) > Supported Group: secp384r1 (0x0018) > Supported Group: secp521r1 (0x0019) > Supported Group: secp160k1 (0x000f) > Extension: ec_point_formats (len=2) > Type: ec_point_formats (11) > Length: 2 > EC point formats Length: 1 > Elliptic curves point formats (1) > EC point format: uncompressed (0) > Extension: signature_algorithms (len=42) > Type: signature_algorithms (13) > Length: 42 > Signature Hash Algorithms Length: 40 > Signature Hash Algorithms (20 algorithms) > Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) > Signature Hash Algorithm Hash: SHA256 (4) > Signature Hash Algorithm Signature: ECDSA (3) > Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503) > Signature Hash Algorithm Hash: SHA384 (5) > Signature Hash Algorithm Signature: ECDSA (3) > Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603) > Signature Hash Algorithm Hash: SHA512 (6) > Signature Hash Algorithm Signature: ECDSA (3) > Signature Algorithm: rsa_pss_rsae_sha256 (0x0804) > Signature Hash Algorithm Hash: Unknown (8) > Signature Hash Algorithm Signature: Unknown (4) > Signature Algorithm: rsa_pss_rsae_sha384 (0x0805) > Signature Hash Algorithm Hash: Unknown (8) > Signature Hash Algorithm Signature: Unknown (5) > Signature Algorithm: rsa_pss_rsae_sha512 (0x0806) > Signature Hash Algorithm Hash: Unknown (8) > Signature Hash Algorithm Signature: Unknown (6) > Signature Algorithm: rsa_pss_pss_sha256 (0x0809) > Signature Hash Algorithm Hash: Unknown (8) > Signature Hash Algorithm Signature: Unknown (9) > Signature Algorithm: rsa_pss_pss_sha384 (0x080a) > Signature Hash Algorithm Hash: Unknown (8) > Signature Hash Algorithm Signature: Unknown (10) > Signature Algorithm: rsa_pss_pss_sha512 (0x080b) > Signature Hash Algorithm Hash: Unknown (8) > Signature Hash Algorithm Signature: Unknown (11) > Signature Algorithm: rsa_pkcs1_sha256 (0x0401) > Signature Hash Algorithm Hash: SHA256 (4) > Signature Hash Algorithm Signature: RSA (1) > Signature Algorithm: rsa_pkcs1_sha384 (0x0501) > Signature Hash Algorithm Hash: SHA384 (5) > Signature Hash Algorithm Signature: RSA (1) > Signature Algorithm: rsa_pkcs1_sha512 (0x0601) > Signature Hash Algorithm Hash: SHA512 (6) > Signature Hash Algorithm Signature: RSA (1) > Signature Algorithm: SHA256 DSA (0x0402) > Signature Hash Algorithm Hash: SHA256 (4) > Signature Hash Algorithm Signature: DSA (2) > Signature Algorithm: SHA224 ECDSA (0x0303) > Signature Hash Algorithm Hash: SHA224 (3) > Signature Hash Algorithm Signature: ECDSA (3) > Signature Algorithm: SHA224 RSA (0x0301) > Signature Hash Algorithm Hash: SHA224 (3) > Signature Hash Algorithm Signature: RSA (1) > Signature Algorithm: SHA224 DSA (0x0302) > Signature Hash Algorithm Hash: SHA224 (3) > Signature Hash Algorithm Signature: DSA (2) > Signature Algorithm: ecdsa_sha1 (0x0203) > Signature Hash Algorithm Hash: SHA1 (2) > Signature Hash Algorithm Signature: ECDSA (3) > Signature Algorithm: rsa_pkcs1_sha1 (0x0201) > Signature Hash Algorithm Hash: SHA1 (2) > Signature Hash Algorithm Signature: RSA (1) > Signature Algorithm: SHA1 DSA (0x0202) > Signature Hash Algorithm Hash: SHA1 (2) > Signature Hash Algorithm Signature: DSA (2) > Signature Algorithm: MD5 RSA (0x0101) > Signature Hash Algorithm Hash: MD5 (1) > Signature Hash Algorithm Signature: RSA (1) > Extension: signature_algorithms_cert (len=42) > Type: signature_algorithms_cert (50) > Length: 42 > Signature Hash Algorithms Length: 40 > Signature Hash Algorithms (20 algorithms) > Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) > Signature Hash Algorithm Hash: SHA256 (4) > Signature Hash Algorithm Signature: ECDSA (3) > Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503) > Signature Hash Algorithm Hash: SHA384 (5) > Signature Hash Algorithm Signature: ECDSA (3) > Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603) > Signature Hash Algorithm Hash: SHA512 (6) > Signature Hash Algorithm Signature: ECDSA (3) > Signature Algorithm: rsa_pss_rsae_sha256 (0x0804) > Signature Hash Algorithm Hash: Unknown (8) > Signature Hash Algorithm Signature: Unknown (4) > Signature Algorithm: rsa_pss_rsae_sha384 (0x0805) > Signature Hash Algorithm Hash: Unknown (8) > Signature Hash Algorithm Signature: Unknown (5) > Signature Algorithm: rsa_pss_rsae_sha512 (0x0806) > Signature Hash Algorithm Hash: Unknown (8) > Signature Hash Algorithm Signature: Unknown (6) > Signature Algorithm: rsa_pss_pss_sha256 (0x0809) > Signature Hash Algorithm Hash: Unknown (8) > Signature Hash Algorithm Signature: Unknown (9) > Signature Algorithm: rsa_pss_pss_sha384 (0x080a) > Signature Hash Algorithm Hash: Unknown (8) > Signature Hash Algorithm Signature: Unknown (10) > Signature Algorithm: rsa_pss_pss_sha512 (0x080b) > Signature Hash Algorithm Hash: Unknown (8) > Signature Hash Algorithm Signature: Unknown (11) > Signature Algorithm: rsa_pkcs1_sha256 (0x0401) > Signature Hash Algorithm Hash: SHA256 (4) > Signature Hash Algorithm Signature: RSA (1) > Signature Algorithm: rsa_pkcs1_sha384 (0x0501) > Signature Hash Algorithm Hash: SHA384 (5) > Signature Hash Algorithm Signature: RSA (1) > Signature Algorithm: rsa_pkcs1_sha512 (0x0601) > Signature Hash Algorithm Hash: SHA512 (6) > Signature Hash Algorithm Signature: RSA (1) > Signature Algorithm: SHA256 DSA (0x0402) > Signature Hash Algorithm Hash: SHA256 (4) > Signature Hash Algorithm Signature: DSA (2) > Signature Algorithm: SHA224 ECDSA (0x0303) > Signature Hash Algorithm Hash: SHA224 (3) > Signature Hash Algorithm Signature: ECDSA (3) > Signature Algorithm: SHA224 RSA (0x0301) > Signature Hash Algorithm Hash: SHA224 (3) > Signature Hash Algorithm Signature: RSA (1) > Signature Algorithm: SHA224 DSA (0x0302) > Signature Hash Algorithm Hash: SHA224 (3) > Signature Hash Algorithm Signature: DSA (2) > Signature Algorithm: ecdsa_sha1 (0x0203) > Signature Hash Algorithm Hash: SHA1 (2) > Signature Hash Algorithm Signature: ECDSA (3) > Signature Algorithm: rsa_pkcs1_sha1 (0x0201) > Signature Hash Algorithm Hash: SHA1 (2) > Signature Hash Algorithm Signature: RSA (1) > Signature Algorithm: SHA1 DSA (0x0202) > Signature Hash Algorithm Hash: SHA1 (2) > Signature Hash Algorithm Signature: DSA (2) > Signature Algorithm: MD5 RSA (0x0101) > Signature Hash Algorithm Hash: MD5 (1) > Signature Hash Algorithm Signature: RSA (1) > Extension: extended_master_secret (len=0) > Type: extended_master_secret (23) > Length: 0 > Extension: supported_versions (len=5) > Type: supported_versions (43) > Length: 5 > Supported Versions length: 4 > Supported Version: TLS 1.2 (0x0303) > Supported Version: TLS 1.1 (0x0302) > Extension: renegotiation_info (len=1) > Type: renegotiation_info (65281) > Length: 1 > Renegotiation Info extension > Renegotiation info extension length: 0 > > > > > > > On Mon, Jan 21, 2019 at 10:37 AM Xuelei Fan wrote: > >> Hi Amir, >> >> Normally, the extension should have no impact if it cannot be recognized >> by the server. It's good to be able to disable extensions if not >> needed. I need to evaluate the priority of it although. Did you have a >> simple test code that I can reproduce the issue? >> >> Thanks, >> >> Xuelei >> On 1/20/2019 3:03 PM, Amir Khassaia wrote: >> >> Greetings Xuelei, >> To follow up on this, the certificate in the connection is a red herring >> and not important. It's actually a very unusual behaviour by >> talk.google.com endpoint to encapsulate an error message inside a >> certificate. >> >> As per the output I included: >> >> *"certificate" : { >> *>* "version" : "v3", >> *>* "serial number" : "00 90 76 89 18 E9 33 93 A0", >> *>* "signature algorithm": "SHA256withRSA", >> *>* "issuer" : "CN=invalid2.invalid, OU="No SNI provided; >> *>* please fix your client."", >> *>* "not before" : "2015-01-01 11:00:00.000 AEDT", >> *>* "not after" : "2030-01-01 11:00:00.000 AEDT", >> *>* "subject" : "CN=invalid2.invalid, OU="No SNI provided; >> *>* please fix your client."",* >> >> This certificate simply masks the TLS interoperability issue as an untrusted certificate issue. >> >> The fact is, some of the extensions sent by JSSE are changes to TLS 1.2 >> to support TLS 1.3, this however affects some clients adversely in practice >> and usually JDK provides properties to turn new enhancements off and work >> around such behaviour, for the extensions I mentioned this is not provided >> and hence they are always sent for client sockets unless TLSv1.2 is not in >> use. >> >> The impact to us is that upgrading to JDK11 means for some endpoints or >> devices that are not 100% compliant to the spec the security is reduced as >> we have to now work around to drop connections to these to TLSv1.1 or >> TLS1.0 or not to move to Java 11 at all. >> >> My request is simply to have all of the new extensions configurable on individual basis so that they can be turned off if needed for compatibility just like most other security enhancements that were delivered in the past. >> >> It appears some of the issues can come from >> >> - inclusion of RSASSA-PSS alg in TLS 1.2 handshakes but these can >> disabled at least >> >> -signature_algorithms_cert and supported_versions extensions which seem >> to be hardcoded for TLS 1.2 (I was not able to conclusively identify which >> of these caused my troubles) >> >> https://tools.ietf.org/html/rfc8446#section-1.3 does say that TLS 1.2 >> clients are affected but in an optional manner.Just today I've encountered >> another Java 11 interop issue with TLS but this time with a physical device >> which can have a long shelf life yet running a simple client socket >> handshake abruptly terminates the connection upon client hello (no >> server_hello at all), and downgrading the JRE below 11 works fine. I'm >> including a trace for that as well: javax.net.ssl|DEBUG|01|main|2019-01-08 >> 13:40:14.395 AEDT|SSLCipher.java:437|jdk.tls.keyLimits: entry = >> AES/GCM/NoPadding KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472 >> >> javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.433 >> AEDT|ServerNameExtension.java:255|Unable to indicate server name >> >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 >> AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: >> server_name >> >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 >> AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: >> status_request >> >> javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.443 >> AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is not >> supported by the underlying providers >> >> javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.444 >> AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not supported >> by the underlying providers >> >> javax.net.ssl|INFO|01|main|2019-01-08 13:40:14.449 >> AEDT|AlpnExtension.java:161|No available application protocols >> >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.449 >> AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: >> application_layer_protocol_negotiation >> >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.450 >> AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: >> status_request_v2 >> >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.453 >> AEDT|ClientHello.java:651|Produced ClientHello handshake message ( >> >> "ClientHello": { >> >> "client version" : "TLSv1.2", >> >> "random" : "1A BA E8 FC 59 00 AB DF 9A 1A 07 94 24 7F 34 >> 3D 0B D2 7D 10 72 52 54 CD 44 43 62 E8 8B 42 C6 68", >> >> "session id" : "", >> >> "cipher suites" : >> "[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), >> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), >> TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), >> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), >> TLS_RSA_WITH_AES_128_CBC_SHA(0x002F)]", >> >> "compression methods" : "00", >> >> "extensions" : [ >> >> "supported_groups (10)": { >> >> "versions": [secp256r1, secp384r1, secp521r1, secp160k1] >> >> }, >> >> "ec_point_formats (11)": { >> >> "formats": [uncompressed] >> >> }, >> >> "signature_algorithms (13)": { >> >> "signature schemes": [ecdsa_secp256r1_sha256, >> ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, >> rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, >> rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, >> rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, >> ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5] >> >> }, >> >> "signature_algorithms_cert (50)": { >> >> "signature schemes": [ecdsa_secp256r1_sha256, >> ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, >> rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, >> rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, >> rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, >> ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5] >> >> }, >> >> "extended_master_secret (23)": { >> >> >> >> }, >> >> "supported_versions (43)": { >> >> "versions": [TLSv1.2, TLSv1.1] >> >> }, >> >> "renegotiation_info (65,281)": { >> >> "renegotiated connection": [] >> >> } >> >> ] >> >> } >> >> ) >> >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.455 >> AEDT|Alert.java:232|Received alert message ( >> >> "Alert": { >> >> "level" : "fatal", >> >> "description": "handshake_failure" >> >> } >> >> ) >> >> javax.net.ssl|ERROR|01|main|2019-01-08 13:40:14.456 >> AEDT|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE): Received fatal >> alert: handshake_failure ( >> >> "throwable" : { >> >> javax.net.ssl.SSLHandshakeException: Received fatal alert: >> handshake_failure >> >> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >> >> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >> >> at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >> >> at >> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) >> >> at >> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) >> >> at >> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >> >> at >> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) >> >> at >> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) >> >> at >> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) >> >> at SslSocketClient.main(SslSocketClient.kt:47)} >> >> >> ) >> >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 >> AEDT|SSLSocketImpl.java:1361|close the underlying socket >> >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 >> AEDT|SSLSocketImpl.java:1380|close the SSL connection (initiative) >> >> Exception in thread "main" javax.net.ssl.SSLHandshakeException: Received >> fatal alert: handshake_failure >> >> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >> >> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >> >> at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >> >> at >> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) >> >> at >> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) >> >> at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >> >> at >> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) >> >> at >> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) >> >> at >> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) >> >> at SslSocketClient.main(SslSocketClient.kt:47) >> >> >> >> >> I've sent my reply earlier but neither got it posted nor denied >> notification so trying again. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Jan 22 00:38:58 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 22 Jan 2019 08:38:58 +0800 Subject: RFR 8215776: Keytool importkeystore may mix up certificate chain entries when DNs conflict In-Reply-To: <68dde8e9-3801-0b37-09ee-cfe489939ac0@oracle.com> References: <87E0531E-F7CE-4F32-86B7-4A3F3C1B842F@oracle.com> <9e41b753-aeb7-a09c-f221-e464327e9e90@oracle.com> <8945E624-FE60-44C2-AADA-0D69B61244C7@oracle.com> <68dde8e9-3801-0b37-09ee-cfe489939ac0@oracle.com> Message-ID: <02A90389-495D-4D4D-81C3-41B93A0174CB@oracle.com> So what do you think of my original webrev? It only compares KID and subject/issuer, not caring about other extensions (like BC). Thanks, Max > On Jan 22, 2019, at 1:39 AM, Xuelei Fan wrote: > > > but it seems it cannot deal with the case where a cert has the correct subject but no SKID extension. Or do you think this should never happen? > It could happen, especially for self-signed cert. See also, the sun.security.provider.certpath.ForwardBuilder#PKIXCertComparator. > Xuelei > On 1/21/2019 2:05 AM, Weijun Wang wrote: >> ; >> >> but it seems it cannot deal with the case where a cert has the correct subject but no SKID extension. Or do you think this should never happen? >> >> Thanks >> Max >> >>> On Jan 17, 2019, at 11:41 AM, Weijun Wang wrote: >>> >>> I'll take a look. I thought java.security.cert.X509CertSelector is used by CertPath validators and builders internally and never thought it can be called directly. >>> >>> Thanks, >>> Max >>> >>>> On Jan 17, 2019, at 1:49 AM, Xuelei Fan wrote: >>>> >>>> Hi Max, >>>> >>>> I did not look into the detailed implementation of findIssuer() yet. Have you considered to use java.security.cert.X509CertSelector? >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 1/9/2019 6:59 AM, Weijun Wang wrote: >>>>> Please take a review at >>>>> https://cr.openjdk.java.net/~weijun/8215776/webrev.00/ >>>>> PKCS12KeyStore now can find certificate issuers more precisely using SubjectKeyIdentifier and AuthorityKeyIdentifier. I thought about using CertPath builder or checking signatures but those changes are too much. >>>>> Thanks, >>>>> Max >>> >> From xuelei.fan at oracle.com Tue Jan 22 01:53:27 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 21 Jan 2019 17:53:27 -0800 Subject: Not possible to disable new TLS extensions for TLS 1.2 connections In-Reply-To: References: <1f4b323a-7a98-35c6-8501-f88c6cc2208b@oracle.com> Message-ID: <2b6f970c-38bd-9102-2e09-79212e13ac82@oracle.com> On 1/21/2019 1:29 PM, Amir Khassaia wrote: > Thanks Xuelei, > Do you mean to create an RFE at openjdk https://bugs.openjdk.java.net/ ? > Yes if you have an OpenJDK account.? Otherwise, please use bugreport.java.com Thanks, Xuelei > > > On Tue, Jan 22, 2019 at 5:02 AM Xuelei Fan > wrote: > > Hi Amir, > > I can see the problem for incompatible impl.? Would you mind > submit an OpenJDK enhancement for a workaround? > > Thanks & Regards, > > Xuelei > > On 1/20/2019 4:10 PM, Amir Khassaia wrote: >> Xuelei, >> >> I have a sample socket client for the device TLS issue but its >> not very helpful as any socket client created on top of JDK will >> do, the last problem was apparent only when talking to a specific >> hardware device which refused to negotiate TLS session (I've seen >> several odd TLS implementations that were intolerant to Java >> changes in various ways over the years and compatibility could >> always be assured through config changes, this time around less so). >> >> Some of the hardware TLS stacks can range from small oddities to >> being completely broken by small changes as they can contain >> outdated and poorly implemented TLS stacks that are very >> sensitive so even a small change can break them and thats why its >> always important to have levers provided to control almost every >> aspect of the handshake. >> >> I have a sample in my gist >> (https://gist.github.com/amir-khassaia/04347ca88526f4b958b3326968a905c0), >> apologies its in Kotlin. When ran with java 8, 9, 10 there were >> no issues. With java 11 this worked on most devices but I've had >> a device at a remote location that was not in my control that >> I've had to diagnose the handshake failure on using java 11 it >> was intolerant to TLS 1.2 client hello from Java 11 but fine with >> TLS 1.1 as the new extensions are not present. It would be fine >> with TLS 1.2 client hello from Java 10 and earlier as I mentioned. >> >> Javax.net.debug output >> ------------------------------- >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.395 >> AEDT|SSLCipher.java:437|jdk.tls.keyLimits: ?entry = >> AES/GCM/NoPadding KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = >> 137438953472 >> javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.433 >> AEDT|ServerNameExtension.java:255|Unable to indicate server name >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 >> AEDT|SSLExtensions.java:235|Ignore, context unavailable >> extension: server_name >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 >> AEDT|SSLExtensions.java:235|Ignore, context unavailable >> extension: status_request >> javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.443 >> AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is >> not supported by the underlying providers >> javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.444 >> AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not >> supported by the underlying providers >> javax.net.ssl|INFO|01|main|2019-01-08 13:40:14.449 >> AEDT|AlpnExtension.java:161|No available application protocols >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.449 >> AEDT|SSLExtensions.java:235|Ignore, context unavailable >> extension: application_layer_protocol_negotiation >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.450 >> AEDT|SSLExtensions.java:235|Ignore, context unavailable >> extension: status_request_v2 >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.453 >> AEDT|ClientHello.java:651|Produced ClientHello handshake message ( >> "ClientHello": { >> ? "client version" ? ? ?: "TLSv1.2", >> ? "random" ? ? ? ? ? ? ?: "1A BA E8 FC 59 00 AB DF 9A 1A 07 94 24 >> 7F 34 3D 0B D2 7D 10 72 52 54 CD 44 43 62 E8 8B 42 C6 68", >> ? "session id" ? ? ? ? ?: "", >> ? "cipher suites" ? ? ? : >> "[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), >> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), >> TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), >> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), >> TLS_RSA_WITH_AES_128_CBC_SHA(0x002F)]", >> ? "compression methods" : "00", >> ? "extensions" ? ? ? ? ?: [ >> ? ? "supported_groups (10)": { >> ? ? ? "versions": [secp256r1, secp384r1, secp521r1, secp160k1] >> ? ? }, >> ? ? "ec_point_formats (11)": { >> ? ? ? "formats": [uncompressed] >> ? ? }, >> ? ? "signature_algorithms (13)": { >> ? ? ? "signature schemes": [ecdsa_secp256r1_sha256, >> ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, >> rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, >> rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, >> rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, >> ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, >> dsa_sha1, rsa_md5] >> ? ? }, >> ? ? "signature_algorithms_cert (50)": { >> ? ? ? "signature schemes": [ecdsa_secp256r1_sha256, >> ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, >> rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, >> rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, >> rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, >> ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, >> dsa_sha1, rsa_md5] >> ? ? }, >> ? ? "extended_master_secret (23)": { >> ? ? ? >> ? ? }, >> ? ? "supported_versions (43)": { >> ? ? ? "versions": [TLSv1.2, TLSv1.1] >> ? ? }, >> ? ? "renegotiation_info (65,281)": { >> ? ? ? "renegotiated connection": [] >> ? ? } >> ? ] >> } >> ) >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.455 >> AEDT|Alert.java:232|Received alert message ( >> "Alert": { >> ? "level" ? ? ?: "fatal", >> ? "description": "handshake_failure" >> } >> ) >> javax.net.ssl|ERROR|01|main|2019-01-08 13:40:14.456 >> AEDT|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE): >> Received fatal alert: handshake_failure ( >> "throwable" : { >> ? javax.net.ssl.SSLHandshakeException: Received fatal alert: >> handshake_failure >> ? at >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >> ? at >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >> ? at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >> ? at >> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) >> ? at >> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) >> ? at >> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >> ? at >> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) >> ? at >> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) >> ? at >> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) >> ? at SslSocketClient.main(SslSocketClient.kt:47)} >> >> ) >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 >> AEDT|SSLSocketImpl.java:1361|close the underlying socket >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 >> AEDT|SSLSocketImpl.java:1380|close the SSL connection (initiative) >> Exception in thread "main" javax.net.ssl.SSLHandshakeException: >> Received fatal alert: handshake_failure >> at >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >> at >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >> at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >> at >> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) >> at >> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) >> at >> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >> at >> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) >> at >> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) >> at >> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) >> at SslSocketClient.main(SslSocketClient.kt:47) >> >> >> >> >> Wireshark TLS 1.2 Java 8 client hello >> ------------------------------------------------- >> Secure Sockets Layer >> ? ? TLSv1.2 Record Layer: Handshake Protocol: Client Hello >> ? ? ? ? Content Type: Handshake (22) >> ? ? ? ? Version: TLS 1.2 (0x0303) >> ? ? ? ? Length: 157 >> ? ? ? ? Handshake Protocol: Client Hello >> ? ? ? ? ? ? Handshake Type: Client Hello (1) >> ? ? ? ? ? ? Length: 153 >> ? ? ? ? ? ? Version: TLS 1.2 (0x0303) >> ? ? ? ? ? ? Random: >> 5c34044c709feae39585e4db8e41b0170fbf9fa428b38941... >> ? ? ? ? ? ? ? ? GMT Unix Time: Jan 8, 2019 13:00:44.000000000 AUS >> Eastern Daylight Time >> ? ? ? ? ? ? ? ? Random Bytes: >> 709feae39585e4db8e41b0170fbf9fa428b38941983ddb53... >> ? ? ? ? ? ? Session ID Length: 0 >> ? ? ? ? ? ? Cipher Suites Length: 44 >> ? ? ? ? ? ? Cipher Suites (22 suites) >> ? ? ? ? ? ? ? ? Cipher Suite: >> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) >> ? ? ? ? ? ? ? ? Cipher Suite: >> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) >> ? ? ? ? ? ? ? ? Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 >> (0x003c) >> ? ? ? ? ? ? ? ? Cipher Suite: >> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025) >> ? ? ? ? ? ? ? ? Cipher Suite: >> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029) >> ? ? ? ? ? ? ? ? Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 >> (0x0067) >> ? ? ? ? ? ? ? ? Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 >> (0x0040) >> ? ? ? ? ? ? ? ? Cipher Suite: >> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) >> ? ? ? ? ? ? ? ? Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA >> (0xc013) >> ? ? ? ? ? ? ? ? Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) >> ? ? ? ? ? ? ? ? Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA >> (0xc004) >> ? ? ? ? ? ? ? ? Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA >> (0xc00e) >> ? ? ? ? ? ? ? ? Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA >> (0x0033) >> ? ? ? ? ? ? ? ? Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA >> (0x0032) >> ? ? ? ? ? ? ? ? Cipher Suite: >> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) >> ? ? ? ? ? ? ? ? Cipher Suite: >> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) >> ? ? ? ? ? ? ? ? Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 >> (0x009c) >> ? ? ? ? ? ? ? ? Cipher Suite: >> TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02d) >> ? ? ? ? ? ? ? ? Cipher Suite: >> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 (0xc031) >> ? ? ? ? ? ? ? ? Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 >> (0x009e) >> ? ? ? ? ? ? ? ? Cipher Suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 >> (0x00a2) >> ? ? ? ? ? ? ? ? Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV >> (0x00ff) >> ? ? ? ? ? ? Compression Methods Length: 1 >> ? ? ? ? ? ? Compression Methods (1 method) >> ? ? ? ? ? ? ? ? Compression Method: null (0) >> ? ? ? ? ? ? Extensions Length: 68 >> ? ? ? ? ? ? Extension: supported_groups (len=22) >> ? ? ? ? ? ? ? ? Type: supported_groups (10) >> ? ? ? ? ? ? ? ? Length: 22 >> ? ? ? ? ? ? ? ? Supported Groups List Length: 20 >> ? ? ? ? ? ? ? ? Supported Groups (10 groups) >> ? ? ? ? ? ? ? ? ? ? Supported Group: secp256r1 (0x0017) >> ? ? ? ? ? ? ? ? ? ? Supported Group: secp384r1 (0x0018) >> ? ? ? ? ? ? ? ? ? ? Supported Group: secp521r1 (0x0019) >> ? ? ? ? ? ? ? ? ? ? Supported Group: sect283k1 (0x0009) >> ? ? ? ? ? ? ? ? ? ? Supported Group: sect283r1 (0x000a) >> ? ? ? ? ? ? ? ? ? ? Supported Group: sect409k1 (0x000b) >> ? ? ? ? ? ? ? ? ? ? Supported Group: sect409r1 (0x000c) >> ? ? ? ? ? ? ? ? ? ? Supported Group: sect571k1 (0x000d) >> ? ? ? ? ? ? ? ? ? ? Supported Group: sect571r1 (0x000e) >> ? ? ? ? ? ? ? ? ? ? Supported Group: secp256k1 (0x0016) >> ? ? ? ? ? ? Extension: ec_point_formats (len=2) >> ? ? ? ? ? ? ? ? Type: ec_point_formats (11) >> ? ? ? ? ? ? ? ? Length: 2 >> ? ? ? ? ? ? ? ? EC point formats Length: 1 >> ? ? ? ? ? ? ? ? Elliptic curves point formats (1) >> ? ? ? ? ? ? ? ? ? ? EC point format: uncompressed (0) >> ? ? ? ? ? ? Extension: signature_algorithms (len=28) >> ? ? ? ? ? ? ? ? Type: signature_algorithms (13) >> ? ? ? ? ? ? ? ? Length: 28 >> ? ? ? ? ? ? ? ? Signature Hash Algorithms Length: 26 >> ? ? ? ? ? ? ? ? Signature Hash Algorithms (13 algorithms) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_secp521r1_sha512 >> (0x0603) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA512 (6) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha512 (0x0601) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA512 (6) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_secp384r1_sha384 >> (0x0503) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA384 (5) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha384 (0x0501) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA384 (5) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_secp256r1_sha256 >> (0x0403) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA256 (4) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha256 (0x0401) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA256 (4) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA256 DSA (0x0402) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA256 (4) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: DSA (2) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA224 ECDSA (0x0303) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA224 (3) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA224 RSA (0x0301) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA224 (3) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA224 DSA (0x0302) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA224 (3) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: DSA (2) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_sha1 (0x0203) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA1 (2) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha1 (0x0201) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA1 (2) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA1 DSA (0x0202) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA1 (2) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: DSA (2) >> ? ? ? ? ? ? Extension: extended_master_secret (len=0) >> ? ? ? ? ? ? ? ? Type: extended_master_secret (23) >> ? ? ? ? ? ? ? ? Length: 0 >> >> >> >> Wireshark Java 11 TLS 1.2 Client hello >> ---------------------------------------------------- >> Secure Sockets Layer >> ? ? TLSv1.2 Record Layer: Handshake Protocol: Client Hello >> ? ? ? ? Content Type: Handshake (22) >> ? ? ? ? Version: TLS 1.2 (0x0303) >> ? ? ? ? Length: 185 >> ? ? ? ? Handshake Protocol: Client Hello >> ? ? ? ? ? ? Handshake Type: Client Hello (1) >> ? ? ? ? ? ? Length: 181 >> ? ? ? ? ? ? Version: TLS 1.2 (0x0303) >> ? ? ? ? ? ? Random: >> 37f32691301b6b9d45bb62c6268915819881b8ebd95f152c... >> ? ? ? ? ? ? ? ? GMT Unix Time: Sep 30, 1999 19:00:01.000000000 >> AUS Eastern Standard Time >> ? ? ? ? ? ? ? ? Random Bytes: >> 301b6b9d45bb62c6268915819881b8ebd95f152c41c7e483... >> ? ? ? ? ? ? Session ID Length: 0 >> ? ? ? ? ? ? Cipher Suites Length: 10 >> ? ? ? ? ? ? Cipher Suites (5 suites) >> ? ? ? ? ? ? ? ? Cipher Suite: >> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) >> ? ? ? ? ? ? ? ? Cipher Suite: >> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) >> ? ? ? ? ? ? ? ? Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 >> (0x003c) >> ? ? ? ? ? ? ? ? Cipher Suite: >> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029) >> ? ? ? ? ? ? ? ? Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) >> ? ? ? ? ? ? Compression Methods Length: 1 >> ? ? ? ? ? ? Compression Methods (1 method) >> ? ? ? ? ? ? ? ? Compression Method: null (0) >> ? ? ? ? ? ? Extensions Length: 130 >> ? ? ? ? ? ? Extension: supported_groups (len=10) >> ? ? ? ? ? ? ? ? Type: supported_groups (10) >> ? ? ? ? ? ? ? ? Length: 10 >> ? ? ? ? ? ? ? ? Supported Groups List Length: 8 >> ? ? ? ? ? ? ? ? Supported Groups (4 groups) >> ? ? ? ? ? ? ? ? ? ? Supported Group: secp256r1 (0x0017) >> ? ? ? ? ? ? ? ? ? ? Supported Group: secp384r1 (0x0018) >> ? ? ? ? ? ? ? ? ? ? Supported Group: secp521r1 (0x0019) >> ? ? ? ? ? ? ? ? ? ? Supported Group: secp160k1 (0x000f) >> ? ? ? ? ? ? Extension: ec_point_formats (len=2) >> ? ? ? ? ? ? ? ? Type: ec_point_formats (11) >> ? ? ? ? ? ? ? ? Length: 2 >> ? ? ? ? ? ? ? ? EC point formats Length: 1 >> ? ? ? ? ? ? ? ? Elliptic curves point formats (1) >> ? ? ? ? ? ? ? ? ? ? EC point format: uncompressed (0) >> ? ? ? ? ? ? Extension: signature_algorithms (len=42) >> ? ? ? ? ? ? ? ? Type: signature_algorithms (13) >> ? ? ? ? ? ? ? ? Length: 42 >> ? ? ? ? ? ? ? ? Signature Hash Algorithms Length: 40 >> ? ? ? ? ? ? ? ? Signature Hash Algorithms (20 algorithms) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_secp256r1_sha256 >> (0x0403) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA256 (4) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_secp384r1_sha384 >> (0x0503) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA384 (5) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_secp521r1_sha512 >> (0x0603) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA512 (6) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_rsae_sha256 (0x0804) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: >> Unknown (4) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_rsae_sha384 (0x0805) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: >> Unknown (5) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_rsae_sha512 (0x0806) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: >> Unknown (6) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_pss_sha256 (0x0809) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: >> Unknown (9) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_pss_sha384 (0x080a) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: >> Unknown (10) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_pss_sha512 (0x080b) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: >> Unknown (11) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha256 (0x0401) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA256 (4) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha384 (0x0501) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA384 (5) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha512 (0x0601) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA512 (6) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA256 DSA (0x0402) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA256 (4) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: DSA (2) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA224 ECDSA (0x0303) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA224 (3) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA224 RSA (0x0301) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA224 (3) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA224 DSA (0x0302) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA224 (3) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: DSA (2) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_sha1 (0x0203) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA1 (2) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha1 (0x0201) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA1 (2) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA1 DSA (0x0202) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA1 (2) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: DSA (2) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: MD5 RSA (0x0101) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: MD5 (1) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) >> ? ? ? ? ? ? Extension: signature_algorithms_cert (len=42) >> ? ? ? ? ? ? ? ? Type: signature_algorithms_cert (50) >> ? ? ? ? ? ? ? ? Length: 42 >> ? ? ? ? ? ? ? ? Signature Hash Algorithms Length: 40 >> ? ? ? ? ? ? ? ? Signature Hash Algorithms (20 algorithms) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_secp256r1_sha256 >> (0x0403) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA256 (4) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_secp384r1_sha384 >> (0x0503) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA384 (5) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_secp521r1_sha512 >> (0x0603) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA512 (6) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_rsae_sha256 (0x0804) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: >> Unknown (4) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_rsae_sha384 (0x0805) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: >> Unknown (5) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_rsae_sha512 (0x0806) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: >> Unknown (6) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_pss_sha256 (0x0809) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: >> Unknown (9) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_pss_sha384 (0x080a) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: >> Unknown (10) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pss_pss_sha512 (0x080b) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: Unknown (8) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: >> Unknown (11) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha256 (0x0401) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA256 (4) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha384 (0x0501) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA384 (5) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha512 (0x0601) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA512 (6) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA256 DSA (0x0402) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA256 (4) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: DSA (2) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA224 ECDSA (0x0303) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA224 (3) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA224 RSA (0x0301) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA224 (3) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA224 DSA (0x0302) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA224 (3) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: DSA (2) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: ecdsa_sha1 (0x0203) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA1 (2) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: ECDSA (3) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: rsa_pkcs1_sha1 (0x0201) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA1 (2) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: SHA1 DSA (0x0202) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: SHA1 (2) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: DSA (2) >> ? ? ? ? ? ? ? ? ? ? Signature Algorithm: MD5 RSA (0x0101) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Hash: MD5 (1) >> ? ? ? ? ? ? ? ? ? ? ? ? Signature Hash Algorithm Signature: RSA (1) >> ? ? ? ? ? ? Extension: extended_master_secret (len=0) >> ? ? ? ? ? ? ? ? Type: extended_master_secret (23) >> ? ? ? ? ? ? ? ? Length: 0 >> ? ? ? ? ? ? Extension: supported_versions (len=5) >> ? ? ? ? ? ? ? ? Type: supported_versions (43) >> ? ? ? ? ? ? ? ? Length: 5 >> ? ? ? ? ? ? ? ? Supported Versions length: 4 >> ? ? ? ? ? ? ? ? Supported Version: TLS 1.2 (0x0303) >> ? ? ? ? ? ? ? ? Supported Version: TLS 1.1 (0x0302) >> ? ? ? ? ? ? Extension: renegotiation_info (len=1) >> ? ? ? ? ? ? ? ? Type: renegotiation_info (65281) >> ? ? ? ? ? ? ? ? Length: 1 >> ? ? ? ? ? ? ? ? Renegotiation Info extension >> ? ? ? ? ? ? ? ? ? ? Renegotiation info extension length: 0 >> >> >> >> >> >> >> On Mon, Jan 21, 2019 at 10:37 AM Xuelei Fan >> > wrote: >> >> Hi Amir, >> >> Normally, the extension should have no impact if it cannot be >> recognized by the server.?? It's good to be able to disable >> extensions if not needed. I need to evaluate the priority of >> it although. Did you have a simple test code that I can >> reproduce the issue? >> >> Thanks, >> >> Xuelei >> >> On 1/20/2019 3:03 PM, Amir Khassaia wrote: >>> Greetings Xuelei, >>> To follow up on this, the certificate in the connection is a >>> red herring and not important. It's actually a very unusual >>> behaviour by talk.google.com >>> ?endpoint to encapsulate an error >>> message inside a certificate. >>> >>> As per the output I included: >>> /"certificate" : { />/? ? "version"? ? ? ? ? ? : "v3", />/? ? "serial number"? ? ? : "00 90 76 89 18 E9 33 93 A0", />/? ? "signature algorithm": "SHA256withRSA", />/? ? "issuer"? ? ? ? ? ? ?: "CN=invalid2.invalid, OU="No SNI >>> provided; />/please fix your client."", />/? ? "not before"? ? ? ? ?: "2015-01-01 11:00:00.000 AEDT", />/? ? "not? after"? ? ? ? ?: "2030-01-01 11:00:00.000 AEDT", />/? ? "subject"? ? ? ? ? ? : "CN=invalid2.invalid, OU="No SNI >>> provided; />/please fix your client."",/ >>> // >>> This certificate simply masks the TLS interoperability issue >>> as an untrusted certificate issue. >>> The fact is, some of the extensions sent by JSSE are changes >>> to TLS 1.2 to support TLS 1.3, this however affects some >>> clients adversely in practice and usually JDK provides >>> properties to turn new enhancements off and work around such >>> behaviour, for the extensions I mentioned this is not >>> provided and hence they are always sent for client sockets >>> unless TLSv1.2 is not in use. >>> >>> The impact to us is that upgrading to JDK11 means for some >>> endpoints or devices that are not 100% compliant to the spec >>> the security is reduced as we have to now work around to >>> drop connections to these to TLSv1.1 or TLS1.0 or not to >>> move to Java 11 at all. >>> My request is simply to have all of the new extensions >>> configurable on individual basis so that they can be turned >>> off if needed for compatibility just like most other >>> security enhancements that were delivered in the past. >>> It appears some of the issues can come from >>> >>> - inclusion of RSASSA-PSS alg in TLS 1.2 handshakes but >>> these can disabled at least >>> >>> -signature_algorithms_cert and supported_versions extensions >>> which seem to be hardcoded for TLS 1.2 (I was not able to >>> conclusively identify which of these caused my troubles) >>> >>> https://tools.ietf.org/html/rfc8446#section-1.3?does say >>> that TLS 1.2 clients are affected but in an optional >>> manner.Just today I've encountered another Java 11 interop >>> issue with TLS but this time with a physical device which >>> can have a long shelf life yet running a simple client >>> socket handshake abruptly terminates the connection upon >>> client hello (no server_hello at all), and downgrading the >>> JRE below 11 works fine. I'm including a trace for that as >>> well: javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.395 >>> AEDT|SSLCipher.java:437|jdk.tls.keyLimits: ?entry = >>> AES/GCM/NoPadding KeyUpdate 2^37. >>> AES/GCM/NOPADDING:KEYUPDATE = 137438953472 >>> >>> javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.433 >>> AEDT|ServerNameExtension.java:255|Unable to indicate server name >>> >>> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 >>> AEDT|SSLExtensions.java:235|Ignore, context unavailable >>> extension: server_name >>> >>> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 >>> AEDT|SSLExtensions.java:235|Ignore, context unavailable >>> extension: status_request >>> >>> javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.443 >>> AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, >>> is not supported by the underlying providers >>> >>> javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.444 >>> AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is >>> not supported by the underlying providers >>> >>> javax.net.ssl|INFO|01|main|2019-01-08 13:40:14.449 >>> AEDT|AlpnExtension.java:161|No available application protocols >>> >>> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.449 >>> AEDT|SSLExtensions.java:235|Ignore, context unavailable >>> extension: application_layer_protocol_negotiation >>> >>> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.450 >>> AEDT|SSLExtensions.java:235|Ignore, context unavailable >>> extension: status_request_v2 >>> >>> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.453 >>> AEDT|ClientHello.java:651|Produced ClientHello handshake >>> message ( >>> >>> "ClientHello": { >>> >>> ? "client version" ? ? ?: "TLSv1.2", >>> >>> ? "random" ? ? ? ? ? ? ?: "1A BA E8 FC 59 00 AB DF 9A 1A 07 >>> 94 24 7F 34 3D 0B D2 7D 10 72 52 54 CD 44 43 62 E8 8B 42 C6 68", >>> >>> ? "session id" ? ? ? ? ?: "", >>> >>> ? "cipher suites" ? ? ? : >>> "[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), >>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), >>> TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), >>> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), >>> TLS_RSA_WITH_AES_128_CBC_SHA(0x002F)]", >>> >>> ? "compression methods" : "00", >>> >>> ? "extensions" ? ? ? ? ?: [ >>> >>> ? ? "supported_groups (10)": { >>> >>> ? ? ? "versions": [secp256r1, secp384r1, secp521r1, secp160k1] >>> >>> ? ? }, >>> >>> ? ? "ec_point_formats (11)": { >>> >>> ? ? ? "formats": [uncompressed] >>> >>> ? ? }, >>> >>> ? ? "signature_algorithms (13)": { >>> >>> ? ? ? "signature schemes": [ecdsa_secp256r1_sha256, >>> ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, >>> rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, >>> rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, >>> rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, >>> rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, >>> dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5] >>> >>> ? ? }, >>> >>> ? ? "signature_algorithms_cert (50)": { >>> >>> ? ? ? "signature schemes": [ecdsa_secp256r1_sha256, >>> ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, >>> rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, >>> rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, >>> rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, >>> rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, >>> dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5] >>> >>> ? ? }, >>> >>> ? ? "extended_master_secret (23)": { >>> >>> ? ? ? >>> >>> ? ? }, >>> >>> ? ? "supported_versions (43)": { >>> >>> ? ? ? "versions": [TLSv1.2, TLSv1.1] >>> >>> ? ? }, >>> >>> ? ? "renegotiation_info (65,281)": { >>> >>> ? ? ? "renegotiated connection": [] >>> >>> ? ? } >>> >>> ? ] >>> >>> } >>> >>> ) >>> >>> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.455 >>> AEDT|Alert.java:232|Received alert message ( >>> >>> "Alert": { >>> >>> ? "level" ? ? ?: "fatal", >>> >>> ? "description": "handshake_failure" >>> >>> } >>> >>> ) >>> >>> javax.net.ssl|ERROR|01|main|2019-01-08 13:40:14.456 >>> AEDT|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE): >>> Received fatal alert: handshake_failure ( >>> >>> "throwable" : { >>> >>> ? javax.net.ssl.SSLHandshakeException: Received fatal alert: >>> handshake_failure >>> >>> ? ? at >>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >>> >>> ? ? at >>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >>> >>> ? ? at >>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >>> >>> ? ? at >>> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) >>> >>> ? ? at >>> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) >>> >>> ? ? at >>> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >>> >>> ? ? at >>> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) >>> >>> ? ? at >>> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) >>> >>> ? ? at >>> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) >>> >>> ? ? at SslSocketClient.main(SslSocketClient.kt:47)} >>> >>> >>> ) >>> >>> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 >>> AEDT|SSLSocketImpl.java:1361|close the underlying socket >>> >>> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 >>> AEDT|SSLSocketImpl.java:1380|close the SSL connection >>> (initiative) >>> >>> Exception in thread "main" >>> javax.net.ssl.SSLHandshakeException: Received fatal alert: >>> handshake_failure >>> >>> ? at >>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >>> >>> ? at >>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >>> >>> ? at >>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >>> >>> ? at >>> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) >>> >>> ? at >>> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) >>> >>> ? at >>> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >>> >>> ? at >>> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) >>> >>> ? at >>> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) >>> >>> ? at >>> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) >>> >>> ? at SslSocketClient.main(SslSocketClient.kt:47) >>> >>> >>> >>> >>> I've sent my reply earlier but neither got it posted nor >>> denied notification so trying again. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennis at gesker.com Tue Jan 22 02:13:22 2019 From: dennis at gesker.com (Dennis Gesker) Date: Mon, 21 Jan 2019 19:13:22 -0700 Subject: JDK-8215102 (Follow-up) In-Reply-To: References: <07e6daa4a6a83133acb80d8a065836e13637b866.camel@redhat.com> <367cf00106cd91678df4cd5f68f710647ac1515d.camel@redhat.com> Message-ID: Hi Severing: I'll post the generic error when I get to the office. It seems to throw the complaints when it closes a connection. Here is the thing... 1. I'm glad this found its way to you (being Red Hat guy) as we first noticed it in WildFly 15.0.1. (But, wasn't looking for it before as we only need it for a few XA migration transactions.) 2. It MIGHT be the driver as we use PostgreSQL driver mostly -- in the same container -- and no errors there on WildFly 15.0.1 and JDK 11. 3. I will also try to fall back to JDK 8 and see if it continues in WildFly 15.0.1. 4. The error occurs -- it would seem -- as the pool closes idle connections. 5. I'll post the pool/data source config in WildFly as well -- it seems correct and seems to work OK in my application. Oh, yeah... And, I found the form to be a contributor (not comitter) and will fill that out tomorrow as well and submit it to you directly. --drg On Mon, Jan 21, 2019, 09:23 Severin Gehwolf On Mon, 2019-01-21 at 07:57 -0700, Dennis Gesker wrote: > > > > Pasted: > > > > https://paste.fedoraproject.org/paste/vEvp9RwN2rVvIKGiC0IvEQ > > Is this the full trace? I don't see any exceptions happening in the > log. Am I missing something? > > Thanks, > Severin > > > On Mon, Jan 21, 2019 at 2:10 AM Severin Gehwolf > > wrote: > > > Hi Dennis, > > > > > > On Sat, 2019-01-19 at 12:08 -0700, Dennis Gesker wrote: > > > > Hi Severin: > > > > > > > > A link to the txt file via Google Drive his here. > > > > > > "Sorry, the file you have requested does not exist." > > > > > > Could you please upload it somewhere less restricted? Maybe > > > https://paste.fedoraproject.org/ or something similar? > > > > > > I guess if you include me directly, a file attachment would work > > > too... > > > It's the mailing lists which strip attachments. > > > > > > > I appreciate you and Alan taking a look. Especially, information > > > > submitted from someone who is not a part of openjdk project. > > > > I do hope the debug info helps. Let me know anything else you > > > need > > > > and I will do my best to provide it. > > > > > > Sure. I'll be mostly doing the intermediary work: getting the info > > > added to the bug, though. > > > > > > > And, should your team decide to open a new ticket or reopen this > > > > original ticket in the JIRA could you add me to the ticket? > > > > > > You'd have to become OpenJDK author for this[1]. It's not terribly > > > difficult, but it's somewhat of an entry barrier I understand. > > > > > > > BTW, (off topic), would your recommend submitting a contributor > > > > application to the openjdk project so bug reports can be > > > submitted > > > > directly? > > > > > > If you intend to submit the occasional bug report and fix it's > > > easier > > > for you long-term to attempt to become OpenJDK author (which > > > requires > > > signing the OCA[2]). > > > > > > > The dev group at my company is VERY small (and this message to > > > your > > > > group at the project is from my personal email) but I'd be glad > > > to > > > > submit bug reports as we come across them in our day to day use > > > of > > > > Java. > > > > > > If there are good reproducers for bugs this would be very welcome. > > > Thanks for investing some time in this! > > > > > > Cheers, > > > Severin > > > > > > [1] http://openjdk.java.net/bylaws#author > > > http://openjdk.java.net/projects/#project-author > > > [2] http://oss.oracle.com/oca.pdf > > > > > > > Cordially, > > > > Dennis > > > > dennis at gesker.com > > > > > > > > On Fri, Jan 18, 2019 at 10:07 AM Severin Gehwolf < > > > sgehwolf at redhat.com > > > > > wrote: > > > > > On Thu, 2019-01-17 at 10:00 -0700, Dennis Gesker wrote: > > > > > [...] > > > > > > Added the -Djavax.net.debug=all option to my Wildfly startup > > > and > > > > > > waited for the pool to close a connection to MySql at AWS. > > > > > > > > > > > > TXT file attached. > > > > > > > > > > > > javac 11.0.1 > > > > > > mysql jdbc driver 8.0.13 > > > > > > wildfly 15.0.1 > > > > > > > > > > > > --drg > > > > > > > > > > Unfortunately the txt file got stripped by the mailing list. > > > Would > > > > > you > > > > > be able to upload it somewhere and post a link? > > > > > > > > > > Thanks, > > > > > Severin > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennis at gesker.com Tue Jan 22 02:16:01 2019 From: dennis at gesker.com (Dennis Gesker) Date: Mon, 21 Jan 2019 19:16:01 -0700 Subject: JDK-8215102 (Follow-up) In-Reply-To: References: <07e6daa4a6a83133acb80d8a065836e13637b866.camel@redhat.com> <367cf00106cd91678df4cd5f68f710647ac1515d.camel@redhat.com> Message-ID: Severin: Also, sorry for the typos... Fat fingers on a little phone. --drg On Mon, Jan 21, 2019, 19:13 Dennis Gesker Hi Severing: > > I'll post the generic error when I get to the office. It seems to throw > the complaints when it closes a connection. > > Here is the thing... > > 1. I'm glad this found its way to you (being Red Hat guy) as we first > noticed it in WildFly 15.0.1. (But, wasn't looking for it before as we > only need it for a few XA migration transactions.) > > 2. It MIGHT be the driver as we use PostgreSQL driver mostly -- in the > same container -- and no errors there on WildFly 15.0.1 and JDK 11. > > 3. I will also try to fall back to JDK 8 and see if it continues in > WildFly 15.0.1. > > 4. The error occurs -- it would seem -- as the pool closes idle > connections. > > 5. I'll post the pool/data source config in WildFly as well -- it seems > correct and seems to work OK in my application. > > Oh, yeah... > > And, I found the form to be a contributor (not comitter) and will fill > that out tomorrow as well and submit it to you directly. > > --drg > > On Mon, Jan 21, 2019, 09:23 Severin Gehwolf >> On Mon, 2019-01-21 at 07:57 -0700, Dennis Gesker wrote: >> > >> > Pasted: >> > >> > https://paste.fedoraproject.org/paste/vEvp9RwN2rVvIKGiC0IvEQ >> >> Is this the full trace? I don't see any exceptions happening in the >> log. Am I missing something? >> >> Thanks, >> Severin >> >> > On Mon, Jan 21, 2019 at 2:10 AM Severin Gehwolf >> > wrote: >> > > Hi Dennis, >> > > >> > > On Sat, 2019-01-19 at 12:08 -0700, Dennis Gesker wrote: >> > > > Hi Severin: >> > > > >> > > > A link to the txt file via Google Drive his here. >> > > >> > > "Sorry, the file you have requested does not exist." >> > > >> > > Could you please upload it somewhere less restricted? Maybe >> > > https://paste.fedoraproject.org/ or something similar? >> > > >> > > I guess if you include me directly, a file attachment would work >> > > too... >> > > It's the mailing lists which strip attachments. >> > > >> > > > I appreciate you and Alan taking a look. Especially, information >> > > > submitted from someone who is not a part of openjdk project. >> > > > I do hope the debug info helps. Let me know anything else you >> > > need >> > > > and I will do my best to provide it. >> > > >> > > Sure. I'll be mostly doing the intermediary work: getting the info >> > > added to the bug, though. >> > > >> > > > And, should your team decide to open a new ticket or reopen this >> > > > original ticket in the JIRA could you add me to the ticket? >> > > >> > > You'd have to become OpenJDK author for this[1]. It's not terribly >> > > difficult, but it's somewhat of an entry barrier I understand. >> > > >> > > > BTW, (off topic), would your recommend submitting a contributor >> > > > application to the openjdk project so bug reports can be >> > > submitted >> > > > directly? >> > > >> > > If you intend to submit the occasional bug report and fix it's >> > > easier >> > > for you long-term to attempt to become OpenJDK author (which >> > > requires >> > > signing the OCA[2]). >> > > >> > > > The dev group at my company is VERY small (and this message to >> > > your >> > > > group at the project is from my personal email) but I'd be glad >> > > to >> > > > submit bug reports as we come across them in our day to day use >> > > of >> > > > Java. >> > > >> > > If there are good reproducers for bugs this would be very welcome. >> > > Thanks for investing some time in this! >> > > >> > > Cheers, >> > > Severin >> > > >> > > [1] http://openjdk.java.net/bylaws#author >> > > http://openjdk.java.net/projects/#project-author >> > > [2] http://oss.oracle.com/oca.pdf >> > > >> > > > Cordially, >> > > > Dennis >> > > > dennis at gesker.com >> > > > >> > > > On Fri, Jan 18, 2019 at 10:07 AM Severin Gehwolf < >> > > sgehwolf at redhat.com >> > > > > wrote: >> > > > > On Thu, 2019-01-17 at 10:00 -0700, Dennis Gesker wrote: >> > > > > [...] >> > > > > > Added the -Djavax.net.debug=all option to my Wildfly startup >> > > and >> > > > > > waited for the pool to close a connection to MySql at AWS. >> > > > > > >> > > > > > TXT file attached. >> > > > > > >> > > > > > javac 11.0.1 >> > > > > > mysql jdbc driver 8.0.13 >> > > > > > wildfly 15.0.1 >> > > > > > >> > > > > > --drg >> > > > > >> > > > > Unfortunately the txt file got stripped by the mailing list. >> > > Would >> > > > > you >> > > > > be able to upload it somewhere and post a link? >> > > > > >> > > > > Thanks, >> > > > > Severin >> > > > > >> > > > >> > > > >> > > >> > >> > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue Jan 22 02:33:01 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 21 Jan 2019 18:33:01 -0800 Subject: RFR 8215776: Keytool importkeystore may mix up certificate chain entries when DNs conflict In-Reply-To: <02A90389-495D-4D4D-81C3-41B93A0174CB@oracle.com> References: <87E0531E-F7CE-4F32-86B7-4A3F3C1B842F@oracle.com> <9e41b753-aeb7-a09c-f221-e464327e9e90@oracle.com> <8945E624-FE60-44C2-AADA-0D69B61244C7@oracle.com> <68dde8e9-3801-0b37-09ee-cfe489939ac0@oracle.com> <02A90389-495D-4D4D-81C3-41B93A0174CB@oracle.com> Message-ID: On 1/21/2019 4:38 PM, Weijun Wang wrote: > So what do you think of my original webrev? It only compares KID and subject/issuer, not caring about other extensions (like BC). The original webrev looks right to me except that I'm? not sure if a new AuthorityKeyIdentifierExtension was needed.? Is it sufficient to use the octet string of the DER value? It may need to selectors to use the X509CertSelector, for issuers w/o AKID. I will leave it to you for the final decision. Xuelei > Thanks, > Max > >> On Jan 22, 2019, at 1:39 AM, Xuelei Fan wrote: >> >>> but it seems it cannot deal with the case where a cert has the correct subject but no SKID extension. Or do you think this should never happen? >> It could happen, especially for self-signed cert. See also, the sun.security.provider.certpath.ForwardBuilder#PKIXCertComparator. >> Xuelei >> On 1/21/2019 2:05 AM, Weijun Wang wrote: >>> ; >>> >>> but it seems it cannot deal with the case where a cert has the correct subject but no SKID extension. Or do you think this should never happen? >>> >>> Thanks >>> Max >>> >>>> On Jan 17, 2019, at 11:41 AM, Weijun Wang wrote: >>>> >>>> I'll take a look. I thought java.security.cert.X509CertSelector is used by CertPath validators and builders internally and never thought it can be called directly. >>>> >>>> Thanks, >>>> Max >>>> >>>>> On Jan 17, 2019, at 1:49 AM, Xuelei Fan wrote: >>>>> >>>>> Hi Max, >>>>> >>>>> I did not look into the detailed implementation of findIssuer() yet. Have you considered to use java.security.cert.X509CertSelector? >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 1/9/2019 6:59 AM, Weijun Wang wrote: >>>>>> Please take a review at >>>>>> https://cr.openjdk.java.net/~weijun/8215776/webrev.00/ >>>>>> PKCS12KeyStore now can find certificate issuers more precisely using SubjectKeyIdentifier and AuthorityKeyIdentifier. I thought about using CertPath builder or checking signatures but those changes are too much. >>>>>> Thanks, >>>>>> Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Jan 22 02:52:59 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 22 Jan 2019 10:52:59 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20190117190436.GD27060@twosigma.com> References: <20181128175551.GA13826@twosigma.com> <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com> <20181204203436.GA22527@twosigma.com> <20181206184824.GB22527@twosigma.com> <32999A4A-F6AA-4D6C-A664-F55160744F59@oracle.com> <20181212004054.GG22527@twosigma.com> <20190117190436.GD27060@twosigma.com> Message-ID: Webrev updated again at https://cr.openjdk.java.net/~weijun/6722928/webrev.04/ This time I updated gssapi.h to make use of gss_const_xyz_t types. The types in NativeFunc.h and sspi.cpp are updated as well. (I wish there is an automatic tool to check the consistence). Several Windows API calls (QueryContextAttributes, MakeSignature, VerifySignature, EncryptMessage, DecryptMessage) need an explicit cast (from const *p to *p) because they don't announce the pointer to be const, but I think it's safe. No other change. Thanks, Max > On Jan 18, 2019, at 3:04 AM, Nico Williams wrote: > > On Thu, Jan 17, 2019 at 11:19:14PM +0800, Weijun Wang wrote: >> Webrev updated at >> >> https://cr.openjdk.java.net/~weijun/6722928/webrev.03 >> >> Changes since webrev.02: >> >> - gss_name_struct, gss_ctx_id_struct, and gss_cred_id_struct defined and >> gssapi.h is updated to use them to define pointer types gss_name_t, >> gss_cred_id_t, and gss_ctx_id_t. > > Excellent. > > And then you can actually define those structures and avoid casting these > pointers' types. > >> - No more translation between krb5 token and SPNEGO token. >> SEC_WINNT_AUTH_IDENTITY_EX.PackageList is now used to only enable kerberos >> in SPNEGO. Thus gss_cred_id_struct contains 2 CredHandles now. > > Nice! That's great. Thanks so much for doing that. > > I'll review this next week, > > Nico > -- From weijun.wang at oracle.com Tue Jan 22 03:06:02 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 22 Jan 2019 11:06:02 +0800 Subject: RFR 8215776: Keytool importkeystore may mix up certificate chain entries when DNs conflict In-Reply-To: References: <87E0531E-F7CE-4F32-86B7-4A3F3C1B842F@oracle.com> <9e41b753-aeb7-a09c-f221-e464327e9e90@oracle.com> <8945E624-FE60-44C2-AADA-0D69B61244C7@oracle.com> <68dde8e9-3801-0b37-09ee-cfe489939ac0@oracle.com> <02A90389-495D-4D4D-81C3-41B93A0174CB@oracle.com> Message-ID: <4C678867-E241-4887-843D-AA35769E34CE@oracle.com> > On Jan 22, 2019, at 10:33 AM, Xuelei Fan wrote: > > On 1/21/2019 4:38 PM, Weijun Wang wrote: >> So what do you think of my original webrev? It only compares KID and subject/issuer, not caring about other extensions (like BC). > The original webrev looks right to me except that I'm not sure if a new AuthorityKeyIdentifierExtension was needed. Is it sufficient to use the octet string of the DER value? The struct of AuthorityKeyIdentifier and SubjectKeyIdentifier is a little different. By using the AuthorityKeyIdentifierExtension class, I don't need to extract the field myself. AuthorityKeyIdentifier ::= SEQUENCE { keyIdentifier [0] KeyIdentifier OPTIONAL, authorityCertIssuer [1] GeneralNames OPTIONAL, authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } SubjectKeyIdentifier ::= KeyIdentifier and since getExtensionValue() returns the extension value encoded as an OCTET STRING, I will also need to extract the content inside. I also cannot call the X509CertImpl methods directly because it's only X509Certificate here. > It may need to selectors to use the X509CertSelector, for issuers w/o AKID. I will leave it to you for the final decision. I'll either need to go thru all certs twice or remember the fallback one like what I did in the current loop. It doesn't make much difference. Thanks, Max > Xuelei > >> Thanks, >> Max >> >> >>> On Jan 22, 2019, at 1:39 AM, Xuelei Fan >>> wrote: >>> >>> >>>> but it seems it cannot deal with the case where a cert has the correct subject but no SKID extension. Or do you think this should never happen? >>>> >>> It could happen, especially for self-signed cert. See also, the sun.security.provider.certpath.ForwardBuilder#PKIXCertComparator. >>> Xuelei >>> On 1/21/2019 2:05 AM, Weijun Wang wrote: >>> >>>> ; >>>> >>>> but it seems it cannot deal with the case where a cert has the correct subject but no SKID extension. Or do you think this should never happen? >>>> >>>> Thanks >>>> Max >>>> >>>> >>>>> On Jan 17, 2019, at 11:41 AM, Weijun Wang >>>>> wrote: >>>>> >>>>> I'll take a look. I thought java.security.cert.X509CertSelector is used by CertPath validators and builders internally and never thought it can be called directly. >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> >>>>>> On Jan 17, 2019, at 1:49 AM, Xuelei Fan >>>>>> wrote: >>>>>> >>>>>> Hi Max, >>>>>> >>>>>> I did not look into the detailed implementation of findIssuer() yet. Have you considered to use java.security.cert.X509CertSelector? >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> On 1/9/2019 6:59 AM, Weijun Wang wrote: >>>>>> >>>>>>> Please take a review at >>>>>>> >>>>>>> https://cr.openjdk.java.net/~weijun/8215776/webrev.00/ >>>>>>> >>>>>>> PKCS12KeyStore now can find certificate issuers more precisely using SubjectKeyIdentifier and AuthorityKeyIdentifier. I thought about using CertPath builder or checking signatures but those changes are too much. >>>>>>> Thanks, >>>>>>> Max >>>>>>> From amir.khassaia at gmail.com Tue Jan 22 03:20:55 2019 From: amir.khassaia at gmail.com (Amir Khassaia) Date: Tue, 22 Jan 2019 14:20:55 +1100 Subject: Not possible to disable new TLS extensions for TLS 1.2 connections In-Reply-To: <2b6f970c-38bd-9102-2e09-79212e13ac82@oracle.com> References: <1f4b323a-7a98-35c6-8501-f88c6cc2208b@oracle.com> <2b6f970c-38bd-9102-2e09-79212e13ac82@oracle.com> Message-ID: Thanks, I've created it through bugreport.java.com ( internal review ID : 9059057) Regards, Amir On Tue, Jan 22, 2019 at 12:53 PM Xuelei Fan wrote: > On 1/21/2019 1:29 PM, Amir Khassaia wrote: > > Thanks Xuelei, > Do you mean to create an RFE at openjdk https://bugs.openjdk.java.net/ ? > > Yes if you have an OpenJDK account. Otherwise, please use > bugreport.java.com > > Thanks, > > Xuelei > > > > On Tue, Jan 22, 2019 at 5:02 AM Xuelei Fan wrote: > >> Hi Amir, >> >> I can see the problem for incompatible impl. Would you mind submit an >> OpenJDK enhancement for a workaround? >> >> Thanks & Regards, >> >> Xuelei >> On 1/20/2019 4:10 PM, Amir Khassaia wrote: >> >> Xuelei, >> >> I have a sample socket client for the device TLS issue but its not very >> helpful as any socket client created on top of JDK will do, the last >> problem was apparent only when talking to a specific hardware device which >> refused to negotiate TLS session (I've seen several odd TLS implementations >> that were intolerant to Java changes in various ways over the years and >> compatibility could always be assured through config changes, this time >> around less so). >> >> Some of the hardware TLS stacks can range from small oddities to being >> completely broken by small changes as they can contain outdated and poorly >> implemented TLS stacks that are very sensitive so even a small change can >> break them and thats why its always important to have levers provided to >> control almost every aspect of the handshake. >> >> I have a sample in my gist ( >> https://gist.github.com/amir-khassaia/04347ca88526f4b958b3326968a905c0), >> apologies its in Kotlin. When ran with java 8, 9, 10 there were no issues. >> With java 11 this worked on most devices but I've had a device at a remote >> location that was not in my control that I've had to diagnose the handshake >> failure on using java 11 it was intolerant to TLS 1.2 client hello from >> Java 11 but fine with TLS 1.1 as the new extensions are not present. It >> would be fine with TLS 1.2 client hello from Java 10 and earlier as I >> mentioned. >> >> Javax.net.debug output >> ------------------------------- >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.395 >> AEDT|SSLCipher.java:437|jdk.tls.keyLimits: entry = AES/GCM/NoPadding >> KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472 >> javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.433 >> AEDT|ServerNameExtension.java:255|Unable to indicate server name >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 >> AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: >> server_name >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 >> AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: >> status_request >> javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.443 >> AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is not >> supported by the underlying providers >> javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.444 >> AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not supported >> by the underlying providers >> javax.net.ssl|INFO|01|main|2019-01-08 13:40:14.449 >> AEDT|AlpnExtension.java:161|No available application protocols >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.449 >> AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: >> application_layer_protocol_negotiation >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.450 >> AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: >> status_request_v2 >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.453 >> AEDT|ClientHello.java:651|Produced ClientHello handshake message ( >> "ClientHello": { >> "client version" : "TLSv1.2", >> "random" : "1A BA E8 FC 59 00 AB DF 9A 1A 07 94 24 7F 34 >> 3D 0B D2 7D 10 72 52 54 CD 44 43 62 E8 8B 42 C6 68", >> "session id" : "", >> "cipher suites" : >> "[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), >> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), >> TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), >> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), >> TLS_RSA_WITH_AES_128_CBC_SHA(0x002F)]", >> "compression methods" : "00", >> "extensions" : [ >> "supported_groups (10)": { >> "versions": [secp256r1, secp384r1, secp521r1, secp160k1] >> }, >> "ec_point_formats (11)": { >> "formats": [uncompressed] >> }, >> "signature_algorithms (13)": { >> "signature schemes": [ecdsa_secp256r1_sha256, >> ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, >> rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, >> rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, >> rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, >> ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5] >> }, >> "signature_algorithms_cert (50)": { >> "signature schemes": [ecdsa_secp256r1_sha256, >> ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, >> rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, >> rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, >> rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, >> ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5] >> }, >> "extended_master_secret (23)": { >> >> }, >> "supported_versions (43)": { >> "versions": [TLSv1.2, TLSv1.1] >> }, >> "renegotiation_info (65,281)": { >> "renegotiated connection": [] >> } >> ] >> } >> ) >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.455 >> AEDT|Alert.java:232|Received alert message ( >> "Alert": { >> "level" : "fatal", >> "description": "handshake_failure" >> } >> ) >> javax.net.ssl|ERROR|01|main|2019-01-08 13:40:14.456 >> AEDT|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE): Received fatal >> alert: handshake_failure ( >> "throwable" : { >> javax.net.ssl.SSLHandshakeException: Received fatal alert: >> handshake_failure >> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >> at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >> at >> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) >> at >> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) >> at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >> at >> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) >> at >> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) >> at >> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) >> at SslSocketClient.main(SslSocketClient.kt:47)} >> >> ) >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 >> AEDT|SSLSocketImpl.java:1361|close the underlying socket >> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 >> AEDT|SSLSocketImpl.java:1380|close the SSL connection (initiative) >> Exception in thread "main" javax.net.ssl.SSLHandshakeException: Received >> fatal alert: handshake_failure >> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >> at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >> at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) >> at >> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) >> at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >> at >> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) >> at >> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) >> at >> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) >> at SslSocketClient.main(SslSocketClient.kt:47) >> >> >> >> >> Wireshark TLS 1.2 Java 8 client hello >> ------------------------------------------------- >> Secure Sockets Layer >> TLSv1.2 Record Layer: Handshake Protocol: Client Hello >> Content Type: Handshake (22) >> Version: TLS 1.2 (0x0303) >> Length: 157 >> Handshake Protocol: Client Hello >> Handshake Type: Client Hello (1) >> Length: 153 >> Version: TLS 1.2 (0x0303) >> Random: 5c34044c709feae39585e4db8e41b0170fbf9fa428b38941... >> GMT Unix Time: Jan 8, 2019 13:00:44.000000000 AUS >> Eastern Daylight Time >> Random Bytes: >> 709feae39585e4db8e41b0170fbf9fa428b38941983ddb53... >> Session ID Length: 0 >> Cipher Suites Length: 44 >> Cipher Suites (22 suites) >> Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 >> (0xc023) >> Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 >> (0xc027) >> Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c) >> Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 >> (0xc025) >> Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 >> (0xc029) >> Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067) >> Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040) >> Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA >> (0xc009) >> Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) >> Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) >> Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004) >> Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e) >> Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) >> Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) >> Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 >> (0xc02b) >> Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 >> (0xc02f) >> Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c) >> Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 >> (0xc02d) >> Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 >> (0xc031) >> Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e) >> Cipher Suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (0x00a2) >> Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) >> Compression Methods Length: 1 >> Compression Methods (1 method) >> Compression Method: null (0) >> Extensions Length: 68 >> Extension: supported_groups (len=22) >> Type: supported_groups (10) >> Length: 22 >> Supported Groups List Length: 20 >> Supported Groups (10 groups) >> Supported Group: secp256r1 (0x0017) >> Supported Group: secp384r1 (0x0018) >> Supported Group: secp521r1 (0x0019) >> Supported Group: sect283k1 (0x0009) >> Supported Group: sect283r1 (0x000a) >> Supported Group: sect409k1 (0x000b) >> Supported Group: sect409r1 (0x000c) >> Supported Group: sect571k1 (0x000d) >> Supported Group: sect571r1 (0x000e) >> Supported Group: secp256k1 (0x0016) >> Extension: ec_point_formats (len=2) >> Type: ec_point_formats (11) >> Length: 2 >> EC point formats Length: 1 >> Elliptic curves point formats (1) >> EC point format: uncompressed (0) >> Extension: signature_algorithms (len=28) >> Type: signature_algorithms (13) >> Length: 28 >> Signature Hash Algorithms Length: 26 >> Signature Hash Algorithms (13 algorithms) >> Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603) >> Signature Hash Algorithm Hash: SHA512 (6) >> Signature Hash Algorithm Signature: ECDSA (3) >> Signature Algorithm: rsa_pkcs1_sha512 (0x0601) >> Signature Hash Algorithm Hash: SHA512 (6) >> Signature Hash Algorithm Signature: RSA (1) >> Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503) >> Signature Hash Algorithm Hash: SHA384 (5) >> Signature Hash Algorithm Signature: ECDSA (3) >> Signature Algorithm: rsa_pkcs1_sha384 (0x0501) >> Signature Hash Algorithm Hash: SHA384 (5) >> Signature Hash Algorithm Signature: RSA (1) >> Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) >> Signature Hash Algorithm Hash: SHA256 (4) >> Signature Hash Algorithm Signature: ECDSA (3) >> Signature Algorithm: rsa_pkcs1_sha256 (0x0401) >> Signature Hash Algorithm Hash: SHA256 (4) >> Signature Hash Algorithm Signature: RSA (1) >> Signature Algorithm: SHA256 DSA (0x0402) >> Signature Hash Algorithm Hash: SHA256 (4) >> Signature Hash Algorithm Signature: DSA (2) >> Signature Algorithm: SHA224 ECDSA (0x0303) >> Signature Hash Algorithm Hash: SHA224 (3) >> Signature Hash Algorithm Signature: ECDSA (3) >> Signature Algorithm: SHA224 RSA (0x0301) >> Signature Hash Algorithm Hash: SHA224 (3) >> Signature Hash Algorithm Signature: RSA (1) >> Signature Algorithm: SHA224 DSA (0x0302) >> Signature Hash Algorithm Hash: SHA224 (3) >> Signature Hash Algorithm Signature: DSA (2) >> Signature Algorithm: ecdsa_sha1 (0x0203) >> Signature Hash Algorithm Hash: SHA1 (2) >> Signature Hash Algorithm Signature: ECDSA (3) >> Signature Algorithm: rsa_pkcs1_sha1 (0x0201) >> Signature Hash Algorithm Hash: SHA1 (2) >> Signature Hash Algorithm Signature: RSA (1) >> Signature Algorithm: SHA1 DSA (0x0202) >> Signature Hash Algorithm Hash: SHA1 (2) >> Signature Hash Algorithm Signature: DSA (2) >> Extension: extended_master_secret (len=0) >> Type: extended_master_secret (23) >> Length: 0 >> >> >> >> Wireshark Java 11 TLS 1.2 Client hello >> ---------------------------------------------------- >> Secure Sockets Layer >> TLSv1.2 Record Layer: Handshake Protocol: Client Hello >> Content Type: Handshake (22) >> Version: TLS 1.2 (0x0303) >> Length: 185 >> Handshake Protocol: Client Hello >> Handshake Type: Client Hello (1) >> Length: 181 >> Version: TLS 1.2 (0x0303) >> Random: 37f32691301b6b9d45bb62c6268915819881b8ebd95f152c... >> GMT Unix Time: Sep 30, 1999 19:00:01.000000000 AUS >> Eastern Standard Time >> Random Bytes: >> 301b6b9d45bb62c6268915819881b8ebd95f152c41c7e483... >> Session ID Length: 0 >> Cipher Suites Length: 10 >> Cipher Suites (5 suites) >> Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 >> (0xc023) >> Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 >> (0xc027) >> Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c) >> Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 >> (0xc029) >> Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) >> Compression Methods Length: 1 >> Compression Methods (1 method) >> Compression Method: null (0) >> Extensions Length: 130 >> Extension: supported_groups (len=10) >> Type: supported_groups (10) >> Length: 10 >> Supported Groups List Length: 8 >> Supported Groups (4 groups) >> Supported Group: secp256r1 (0x0017) >> Supported Group: secp384r1 (0x0018) >> Supported Group: secp521r1 (0x0019) >> Supported Group: secp160k1 (0x000f) >> Extension: ec_point_formats (len=2) >> Type: ec_point_formats (11) >> Length: 2 >> EC point formats Length: 1 >> Elliptic curves point formats (1) >> EC point format: uncompressed (0) >> Extension: signature_algorithms (len=42) >> Type: signature_algorithms (13) >> Length: 42 >> Signature Hash Algorithms Length: 40 >> Signature Hash Algorithms (20 algorithms) >> Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) >> Signature Hash Algorithm Hash: SHA256 (4) >> Signature Hash Algorithm Signature: ECDSA (3) >> Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503) >> Signature Hash Algorithm Hash: SHA384 (5) >> Signature Hash Algorithm Signature: ECDSA (3) >> Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603) >> Signature Hash Algorithm Hash: SHA512 (6) >> Signature Hash Algorithm Signature: ECDSA (3) >> Signature Algorithm: rsa_pss_rsae_sha256 (0x0804) >> Signature Hash Algorithm Hash: Unknown (8) >> Signature Hash Algorithm Signature: Unknown (4) >> Signature Algorithm: rsa_pss_rsae_sha384 (0x0805) >> Signature Hash Algorithm Hash: Unknown (8) >> Signature Hash Algorithm Signature: Unknown (5) >> Signature Algorithm: rsa_pss_rsae_sha512 (0x0806) >> Signature Hash Algorithm Hash: Unknown (8) >> Signature Hash Algorithm Signature: Unknown (6) >> Signature Algorithm: rsa_pss_pss_sha256 (0x0809) >> Signature Hash Algorithm Hash: Unknown (8) >> Signature Hash Algorithm Signature: Unknown (9) >> Signature Algorithm: rsa_pss_pss_sha384 (0x080a) >> Signature Hash Algorithm Hash: Unknown (8) >> Signature Hash Algorithm Signature: Unknown (10) >> Signature Algorithm: rsa_pss_pss_sha512 (0x080b) >> Signature Hash Algorithm Hash: Unknown (8) >> Signature Hash Algorithm Signature: Unknown (11) >> Signature Algorithm: rsa_pkcs1_sha256 (0x0401) >> Signature Hash Algorithm Hash: SHA256 (4) >> Signature Hash Algorithm Signature: RSA (1) >> Signature Algorithm: rsa_pkcs1_sha384 (0x0501) >> Signature Hash Algorithm Hash: SHA384 (5) >> Signature Hash Algorithm Signature: RSA (1) >> Signature Algorithm: rsa_pkcs1_sha512 (0x0601) >> Signature Hash Algorithm Hash: SHA512 (6) >> Signature Hash Algorithm Signature: RSA (1) >> Signature Algorithm: SHA256 DSA (0x0402) >> Signature Hash Algorithm Hash: SHA256 (4) >> Signature Hash Algorithm Signature: DSA (2) >> Signature Algorithm: SHA224 ECDSA (0x0303) >> Signature Hash Algorithm Hash: SHA224 (3) >> Signature Hash Algorithm Signature: ECDSA (3) >> Signature Algorithm: SHA224 RSA (0x0301) >> Signature Hash Algorithm Hash: SHA224 (3) >> Signature Hash Algorithm Signature: RSA (1) >> Signature Algorithm: SHA224 DSA (0x0302) >> Signature Hash Algorithm Hash: SHA224 (3) >> Signature Hash Algorithm Signature: DSA (2) >> Signature Algorithm: ecdsa_sha1 (0x0203) >> Signature Hash Algorithm Hash: SHA1 (2) >> Signature Hash Algorithm Signature: ECDSA (3) >> Signature Algorithm: rsa_pkcs1_sha1 (0x0201) >> Signature Hash Algorithm Hash: SHA1 (2) >> Signature Hash Algorithm Signature: RSA (1) >> Signature Algorithm: SHA1 DSA (0x0202) >> Signature Hash Algorithm Hash: SHA1 (2) >> Signature Hash Algorithm Signature: DSA (2) >> Signature Algorithm: MD5 RSA (0x0101) >> Signature Hash Algorithm Hash: MD5 (1) >> Signature Hash Algorithm Signature: RSA (1) >> Extension: signature_algorithms_cert (len=42) >> Type: signature_algorithms_cert (50) >> Length: 42 >> Signature Hash Algorithms Length: 40 >> Signature Hash Algorithms (20 algorithms) >> Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) >> Signature Hash Algorithm Hash: SHA256 (4) >> Signature Hash Algorithm Signature: ECDSA (3) >> Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503) >> Signature Hash Algorithm Hash: SHA384 (5) >> Signature Hash Algorithm Signature: ECDSA (3) >> Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603) >> Signature Hash Algorithm Hash: SHA512 (6) >> Signature Hash Algorithm Signature: ECDSA (3) >> Signature Algorithm: rsa_pss_rsae_sha256 (0x0804) >> Signature Hash Algorithm Hash: Unknown (8) >> Signature Hash Algorithm Signature: Unknown (4) >> Signature Algorithm: rsa_pss_rsae_sha384 (0x0805) >> Signature Hash Algorithm Hash: Unknown (8) >> Signature Hash Algorithm Signature: Unknown (5) >> Signature Algorithm: rsa_pss_rsae_sha512 (0x0806) >> Signature Hash Algorithm Hash: Unknown (8) >> Signature Hash Algorithm Signature: Unknown (6) >> Signature Algorithm: rsa_pss_pss_sha256 (0x0809) >> Signature Hash Algorithm Hash: Unknown (8) >> Signature Hash Algorithm Signature: Unknown (9) >> Signature Algorithm: rsa_pss_pss_sha384 (0x080a) >> Signature Hash Algorithm Hash: Unknown (8) >> Signature Hash Algorithm Signature: Unknown (10) >> Signature Algorithm: rsa_pss_pss_sha512 (0x080b) >> Signature Hash Algorithm Hash: Unknown (8) >> Signature Hash Algorithm Signature: Unknown (11) >> Signature Algorithm: rsa_pkcs1_sha256 (0x0401) >> Signature Hash Algorithm Hash: SHA256 (4) >> Signature Hash Algorithm Signature: RSA (1) >> Signature Algorithm: rsa_pkcs1_sha384 (0x0501) >> Signature Hash Algorithm Hash: SHA384 (5) >> Signature Hash Algorithm Signature: RSA (1) >> Signature Algorithm: rsa_pkcs1_sha512 (0x0601) >> Signature Hash Algorithm Hash: SHA512 (6) >> Signature Hash Algorithm Signature: RSA (1) >> Signature Algorithm: SHA256 DSA (0x0402) >> Signature Hash Algorithm Hash: SHA256 (4) >> Signature Hash Algorithm Signature: DSA (2) >> Signature Algorithm: SHA224 ECDSA (0x0303) >> Signature Hash Algorithm Hash: SHA224 (3) >> Signature Hash Algorithm Signature: ECDSA (3) >> Signature Algorithm: SHA224 RSA (0x0301) >> Signature Hash Algorithm Hash: SHA224 (3) >> Signature Hash Algorithm Signature: RSA (1) >> Signature Algorithm: SHA224 DSA (0x0302) >> Signature Hash Algorithm Hash: SHA224 (3) >> Signature Hash Algorithm Signature: DSA (2) >> Signature Algorithm: ecdsa_sha1 (0x0203) >> Signature Hash Algorithm Hash: SHA1 (2) >> Signature Hash Algorithm Signature: ECDSA (3) >> Signature Algorithm: rsa_pkcs1_sha1 (0x0201) >> Signature Hash Algorithm Hash: SHA1 (2) >> Signature Hash Algorithm Signature: RSA (1) >> Signature Algorithm: SHA1 DSA (0x0202) >> Signature Hash Algorithm Hash: SHA1 (2) >> Signature Hash Algorithm Signature: DSA (2) >> Signature Algorithm: MD5 RSA (0x0101) >> Signature Hash Algorithm Hash: MD5 (1) >> Signature Hash Algorithm Signature: RSA (1) >> Extension: extended_master_secret (len=0) >> Type: extended_master_secret (23) >> Length: 0 >> Extension: supported_versions (len=5) >> Type: supported_versions (43) >> Length: 5 >> Supported Versions length: 4 >> Supported Version: TLS 1.2 (0x0303) >> Supported Version: TLS 1.1 (0x0302) >> Extension: renegotiation_info (len=1) >> Type: renegotiation_info (65281) >> Length: 1 >> Renegotiation Info extension >> Renegotiation info extension length: 0 >> >> >> >> >> >> >> On Mon, Jan 21, 2019 at 10:37 AM Xuelei Fan >> wrote: >> >>> Hi Amir, >>> >>> Normally, the extension should have no impact if it cannot be recognized >>> by the server. It's good to be able to disable extensions if not >>> needed. I need to evaluate the priority of it although. Did you have a >>> simple test code that I can reproduce the issue? >>> >>> Thanks, >>> >>> Xuelei >>> On 1/20/2019 3:03 PM, Amir Khassaia wrote: >>> >>> Greetings Xuelei, >>> To follow up on this, the certificate in the connection is a red herring >>> and not important. It's actually a very unusual behaviour by >>> talk.google.com endpoint to encapsulate an error message inside a >>> certificate. >>> >>> As per the output I included: >>> >>> *"certificate" : { >>> *>* "version" : "v3", >>> *>* "serial number" : "00 90 76 89 18 E9 33 93 A0", >>> *>* "signature algorithm": "SHA256withRSA", >>> *>* "issuer" : "CN=invalid2.invalid, OU="No SNI provided; >>> *>* please fix your client."", >>> *>* "not before" : "2015-01-01 11:00:00.000 AEDT", >>> *>* "not after" : "2030-01-01 11:00:00.000 AEDT", >>> *>* "subject" : "CN=invalid2.invalid, OU="No SNI provided; >>> *>* please fix your client."",* >>> >>> This certificate simply masks the TLS interoperability issue as an untrusted certificate issue. >>> >>> The fact is, some of the extensions sent by JSSE are changes to TLS 1.2 >>> to support TLS 1.3, this however affects some clients adversely in practice >>> and usually JDK provides properties to turn new enhancements off and work >>> around such behaviour, for the extensions I mentioned this is not provided >>> and hence they are always sent for client sockets unless TLSv1.2 is not in >>> use. >>> >>> The impact to us is that upgrading to JDK11 means for some endpoints or >>> devices that are not 100% compliant to the spec the security is reduced as >>> we have to now work around to drop connections to these to TLSv1.1 or >>> TLS1.0 or not to move to Java 11 at all. >>> >>> My request is simply to have all of the new extensions configurable on individual basis so that they can be turned off if needed for compatibility just like most other security enhancements that were delivered in the past. >>> >>> It appears some of the issues can come from >>> >>> - inclusion of RSASSA-PSS alg in TLS 1.2 handshakes but these can >>> disabled at least >>> >>> -signature_algorithms_cert and supported_versions extensions which seem >>> to be hardcoded for TLS 1.2 (I was not able to conclusively identify which >>> of these caused my troubles) >>> >>> https://tools.ietf.org/html/rfc8446#section-1.3 does say that TLS 1.2 >>> clients are affected but in an optional manner.Just today I've encountered >>> another Java 11 interop issue with TLS but this time with a physical device >>> which can have a long shelf life yet running a simple client socket >>> handshake abruptly terminates the connection upon client hello (no >>> server_hello at all), and downgrading the JRE below 11 works fine. I'm >>> including a trace for that as well: javax.net.ssl|DEBUG|01|main|2019-01-08 >>> 13:40:14.395 AEDT|SSLCipher.java:437|jdk.tls.keyLimits: entry = >>> AES/GCM/NoPadding KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472 >>> >>> javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.433 >>> AEDT|ServerNameExtension.java:255|Unable to indicate server name >>> >>> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 >>> AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: >>> server_name >>> >>> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 >>> AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: >>> status_request >>> >>> javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.443 >>> AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is not >>> supported by the underlying providers >>> >>> javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.444 >>> AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not supported >>> by the underlying providers >>> >>> javax.net.ssl|INFO|01|main|2019-01-08 13:40:14.449 >>> AEDT|AlpnExtension.java:161|No available application protocols >>> >>> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.449 >>> AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: >>> application_layer_protocol_negotiation >>> >>> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.450 >>> AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: >>> status_request_v2 >>> >>> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.453 >>> AEDT|ClientHello.java:651|Produced ClientHello handshake message ( >>> >>> "ClientHello": { >>> >>> "client version" : "TLSv1.2", >>> >>> "random" : "1A BA E8 FC 59 00 AB DF 9A 1A 07 94 24 7F 34 >>> 3D 0B D2 7D 10 72 52 54 CD 44 43 62 E8 8B 42 C6 68", >>> >>> "session id" : "", >>> >>> "cipher suites" : >>> "[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), >>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), >>> TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), >>> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), >>> TLS_RSA_WITH_AES_128_CBC_SHA(0x002F)]", >>> >>> "compression methods" : "00", >>> >>> "extensions" : [ >>> >>> "supported_groups (10)": { >>> >>> "versions": [secp256r1, secp384r1, secp521r1, secp160k1] >>> >>> }, >>> >>> "ec_point_formats (11)": { >>> >>> "formats": [uncompressed] >>> >>> }, >>> >>> "signature_algorithms (13)": { >>> >>> "signature schemes": [ecdsa_secp256r1_sha256, >>> ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, >>> rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, >>> rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, >>> rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, >>> ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5] >>> >>> }, >>> >>> "signature_algorithms_cert (50)": { >>> >>> "signature schemes": [ecdsa_secp256r1_sha256, >>> ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, >>> rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, >>> rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, >>> rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, >>> ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5] >>> >>> }, >>> >>> "extended_master_secret (23)": { >>> >>> >>> >>> }, >>> >>> "supported_versions (43)": { >>> >>> "versions": [TLSv1.2, TLSv1.1] >>> >>> }, >>> >>> "renegotiation_info (65,281)": { >>> >>> "renegotiated connection": [] >>> >>> } >>> >>> ] >>> >>> } >>> >>> ) >>> >>> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.455 >>> AEDT|Alert.java:232|Received alert message ( >>> >>> "Alert": { >>> >>> "level" : "fatal", >>> >>> "description": "handshake_failure" >>> >>> } >>> >>> ) >>> >>> javax.net.ssl|ERROR|01|main|2019-01-08 13:40:14.456 >>> AEDT|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE): Received fatal >>> alert: handshake_failure ( >>> >>> "throwable" : { >>> >>> javax.net.ssl.SSLHandshakeException: Received fatal alert: >>> handshake_failure >>> >>> at >>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >>> >>> at >>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >>> >>> at >>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >>> >>> at >>> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) >>> >>> at >>> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) >>> >>> at >>> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >>> >>> at >>> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) >>> >>> at >>> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) >>> >>> at >>> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) >>> >>> at SslSocketClient.main(SslSocketClient.kt:47)} >>> >>> >>> ) >>> >>> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 >>> AEDT|SSLSocketImpl.java:1361|close the underlying socket >>> >>> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 >>> AEDT|SSLSocketImpl.java:1380|close the SSL connection (initiative) >>> >>> Exception in thread "main" javax.net.ssl.SSLHandshakeException: Received >>> fatal alert: handshake_failure >>> >>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >>> >>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >>> >>> at >>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >>> >>> at >>> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) >>> >>> at >>> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) >>> >>> at >>> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >>> >>> at >>> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) >>> >>> at >>> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) >>> >>> at >>> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) >>> >>> at SslSocketClient.main(SslSocketClient.kt:47) >>> >>> >>> >>> >>> I've sent my reply earlier but neither got it posted nor denied >>> notification so trying again. >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue Jan 22 05:12:19 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 21 Jan 2019 21:12:19 -0800 Subject: RFR 8215776: Keytool importkeystore may mix up certificate chain entries when DNs conflict In-Reply-To: <4C678867-E241-4887-843D-AA35769E34CE@oracle.com> References: <87E0531E-F7CE-4F32-86B7-4A3F3C1B842F@oracle.com> <9e41b753-aeb7-a09c-f221-e464327e9e90@oracle.com> <8945E624-FE60-44C2-AADA-0D69B61244C7@oracle.com> <68dde8e9-3801-0b37-09ee-cfe489939ac0@oracle.com> <02A90389-495D-4D4D-81C3-41B93A0174CB@oracle.com> <4C678867-E241-4887-843D-AA35769E34CE@oracle.com> Message-ID: On 1/21/2019 7:06 PM, Weijun Wang wrote: > >> On Jan 22, 2019, at 10:33 AM, Xuelei Fan wrote: >> >> On 1/21/2019 4:38 PM, Weijun Wang wrote: >>> So what do you think of my original webrev? It only compares KID and subject/issuer, not caring about other extensions (like BC). >> The original webrev looks right to me except that I'm not sure if a new AuthorityKeyIdentifierExtension was needed. Is it sufficient to use the octet string of the DER value? > The struct of AuthorityKeyIdentifier and SubjectKeyIdentifier is a little different. By using the AuthorityKeyIdentifierExtension class, I don't need to extract the field myself. > > AuthorityKeyIdentifier ::= SEQUENCE { > keyIdentifier [0] KeyIdentifier OPTIONAL, > authorityCertIssuer [1] GeneralNames OPTIONAL, > authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } > > SubjectKeyIdentifier ::= KeyIdentifier > > and since getExtensionValue() returns the extension value encoded as an OCTET STRING, I will also need to extract the content inside. > > I also cannot call the X509CertImpl methods directly because it's only X509Certificate here. I see.? Thanks! > >> It may need to selectors to use the X509CertSelector, for issuers w/o AKID. I will leave it to you for the final decision. > I'll either need to go thru all certs twice or remember the fallback one like what I did in the current loop. It doesn't make much difference. I meant to use the certs one time. for (X509Certificate cert : allCerts) { ?? if (cert has SKID) { ???? // use the selector with SKID ? } else { ??? // use the selector without SKID ?} } The benefit is limited as you have to construct the AKID. I'm fine and have no more comments if you want to go with webrev.00. Xuelei > Thanks, > Max > >> Xuelei >> >>> Thanks, >>> Max >>> >>> >>>> On Jan 22, 2019, at 1:39 AM, Xuelei Fan >>>> wrote: >>>> >>>> >>>>> but it seems it cannot deal with the case where a cert has the correct subject but no SKID extension. Or do you think this should never happen? >>>>> >>>> It could happen, especially for self-signed cert. See also, the sun.security.provider.certpath.ForwardBuilder#PKIXCertComparator. >>>> Xuelei >>>> On 1/21/2019 2:05 AM, Weijun Wang wrote: >>>> >>>>> ; >>>>> >>>>> but it seems it cannot deal with the case where a cert has the correct subject but no SKID extension. Or do you think this should never happen? >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> >>>>>> On Jan 17, 2019, at 11:41 AM, Weijun Wang >>>>>> wrote: >>>>>> >>>>>> I'll take a look. I thought java.security.cert.X509CertSelector is used by CertPath validators and builders internally and never thought it can be called directly. >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> >>>>>>> On Jan 17, 2019, at 1:49 AM, Xuelei Fan >>>>>>> wrote: >>>>>>> >>>>>>> Hi Max, >>>>>>> >>>>>>> I did not look into the detailed implementation of findIssuer() yet. Have you considered to use java.security.cert.X509CertSelector? >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>>> On 1/9/2019 6:59 AM, Weijun Wang wrote: >>>>>>> >>>>>>>> Please take a review at >>>>>>>> >>>>>>>> https://cr.openjdk.java.net/~weijun/8215776/webrev.00/ >>>>>>>> >>>>>>>> PKCS12KeyStore now can find certificate issuers more precisely using SubjectKeyIdentifier and AuthorityKeyIdentifier. I thought about using CertPath builder or checking signatures but those changes are too much. >>>>>>>> Thanks, >>>>>>>> Max >>>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Jan 22 09:52:26 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 Jan 2019 09:52:26 +0000 Subject: High memory usage / leaks was: Best mailing list for JVM embedding In-Reply-To: References: <54df1401-857f-35c4-9973-ab0ac7818194@marcanoonline.com> Message-ID: <1f7b8dfb-176f-f53e-65ff-9cf0612d9456@oracle.com> On 22/01/2019 4:48 am, Robert Marcano wrote: >> : >> >> So the question now is, why signed jars could affect the memory usage >> of an application (we aren't doing JAR verification on our custom >> launcher, yet), just by being on the java.class.path? IIRC the >> initial application classpath JARs were never verified previously (by >> the java launcher alone, without JNLP around). >> >> Note: Tested with JARs signed with a self signed certificate and with >> one signed with a private CA. At most, signing the JARs could slow >> down the start up if it is now expected to these being verified by >> the java launcher (is it true?) but not higher memory usage and no >> reductions after a GC cycle but constants heap size increases. Signed JARs can be expensive to verify, esp. on first usage as the verification is likely to result in early loading of a lot of security classes and infrastructure. If you can narrow down the apparently memory leak to a small test case with analysis to suggest it's a JDK bug then it would be good to get a bug submitted. -Alan From jai.forums2013 at gmail.com Tue Jan 22 12:44:46 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 22 Jan 2019 18:14:46 +0530 Subject: JDK-8215102 (Follow-up) In-Reply-To: References: <07e6daa4a6a83133acb80d8a065836e13637b866.camel@redhat.com> <367cf00106cd91678df4cd5f68f710647ac1515d.camel@redhat.com> Message-ID: FWIW - I don't think this is related to WildFly server. So I decided to try and reproduce this in a trivial standalone program and I was able to reproduce this. Here's the code to reproduce this issue: import java.sql.*; public class ConnectionCloseTest { ??? public static void main(final String[] args) throws Exception { ??? ??? final String url = "jdbc:mysql://localhost/?requireSSL=true"; ??? ??? final String user = "youruser"; // set the right user ??? ??? final String pass = "yourpassword"; // set the right password ??? ??? Class.forName("com.mysql.jdbc.Driver"); ??? ??? final Connection conn = DriverManager.getConnection(url, user, pass); ??? ??? System.out.println("Got connection"); ??? ??? conn.close(); ??? ??? System.out.println("Closed connection"); ??? } } It's important to start the MySQL server with ssl enabled. For that I just had to set: [mysqld] ssl=1 in my MySQL server configuration. On the client side you will need the mysql JDBC driver jar in the classpath. The one I used for this test was mysql-connector-java-5.1.43.jar. Running this with Java 8 doesn't throw any exceptions or WARN logs. However, running it against Java 11 and even Java 12 latest EA build, throws an exception, which gets logged as a WARN by the driver (and things move on) on connection close: WARN: Caught while disconnecting... EXCEPTION STACK TRACE: ** BEGIN NESTED EXCEPTION ** javax.net.ssl.SSLException MESSAGE: closing inbound before receiving peer's close_notify STACKTRACE: javax.net.ssl.SSLException: closing inbound before receiving peer's close_notify ??? at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133) ??? at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) ??? at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:307) ??? at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263) ??? at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:254) ??? at java.base/sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:650) ??? at java.base/sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:629) ??? at com.mysql.jdbc.MysqlIO.quit(MysqlIO.java:2246) ??? at com.mysql.jdbc.ConnectionImpl.realClose(ConnectionImpl.java:4234) ??? at com.mysql.jdbc.ConnectionImpl.close(ConnectionImpl.java:1472) ??? at ConnectionCloseTest.main(ConnectionCloseTest.java:13) ??? at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ??? at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ??? at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ??? at java.base/java.lang.reflect.Method.invoke(Method.java:567) ??? at jdk.compiler/com.sun.tools.javac.launcher.Main.execute(Main.java:415) ??? at jdk.compiler/com.sun.tools.javac.launcher.Main.run(Main.java:192) ??? at jdk.compiler/com.sun.tools.javac.launcher.Main.main(Main.java:132) ** END NESTED EXCEPTION ** -Jaikiran On 22/01/19 7:43 AM, Dennis Gesker wrote: > Hi Severing: > > I'll post the generic error when I get to the office. It seems to > throw the complaints when it closes a connection. > > Here is the thing... > > 1. I'm glad this found its way to you (being Red Hat guy) as we first > noticed it in WildFly 15.0.1.? (But, wasn't looking for it before as > we only need it for a few XA migration transactions.) > > 2. It MIGHT be the driver as we use PostgreSQL driver mostly -- in the > same container -- and no errors there on WildFly 15.0.1 and JDK 11. > > 3. I will also try to fall back to JDK 8 and see if it continues in > WildFly 15.0.1. > > 4. The error occurs -- it would seem -- as the pool closes idle > connections. > > 5.? I'll post the pool/data source config in WildFly as well -- it > seems correct and seems to work OK in my application. > > Oh, yeah... > > And, I found the form to be a contributor (not comitter) and will fill > that out tomorrow as well and submit it to you directly. > > --drg > > On Mon, Jan 21, 2019, 09:23 Severin Gehwolf wrote: > > On Mon, 2019-01-21 at 07:57 -0700, Dennis Gesker wrote: > > > > Pasted: > > > > https://paste.fedoraproject.org/paste/vEvp9RwN2rVvIKGiC0IvEQ > > Is this the full trace? I don't see any exceptions happening in the > log. Am I missing something? > > Thanks, > Severin > > > On Mon, Jan 21, 2019 at 2:10 AM Severin Gehwolf > > > > wrote: > > > Hi Dennis, > > > > > > On Sat, 2019-01-19 at 12:08 -0700, Dennis Gesker wrote: > > > > Hi Severin: > > > > > > > > A link to the txt file via Google Drive his here. > > > > > > "Sorry, the file you have requested does not exist." > > > > > > Could you please upload it somewhere less restricted? Maybe > > > https://paste.fedoraproject.org/ or something similar? > > > > > > I guess if you include me directly, a file attachment would work > > > too... > > > It's the mailing lists which strip attachments. > > > > > > > I appreciate you and Alan taking a look. Especially, information > > > > submitted from someone who is not a part of openjdk project. > > > > I do hope the debug info helps. Let me know anything else you > > > need > > > > and I will do my best to provide it. > > > > > > Sure. I'll be mostly doing the intermediary work: getting the info > > > added to the bug, though. > > > > > > > And, should your team decide to open a new ticket or reopen this > > > > original ticket in the JIRA could you add me to the ticket? > > > > > > You'd have to become OpenJDK author for this[1]. It's not terribly > > > difficult, but it's somewhat of an entry barrier I understand. > > > > > > > BTW, (off topic), would your recommend submitting a contributor > > > > application to the openjdk project so bug reports can be > > > submitted > > > > directly? > > > > > > If you intend to submit the occasional bug report and fix it's > > > easier > > > for you long-term to attempt to become OpenJDK author (which > > > requires > > > signing the OCA[2]). > > > > > > > The dev group at my company is VERY small (and this message to > > > your > > > > group at the project is from my personal email) but I'd be glad > > > to > > > > submit bug reports as we come across them in our day to day use > > > of > > > > Java. > > > > > > If there are good reproducers for bugs this would be very welcome. > > > Thanks for investing some time in this! > > > > > > Cheers, > > > Severin > > > > > > [1] http://openjdk.java.net/bylaws#author > > >? ? ?http://openjdk.java.net/projects/#project-author > > > [2] http://oss.oracle.com/oca.pdf > > > > > > > Cordially, > > > > Dennis > > > > dennis at gesker.com > > > > > > > > On Fri, Jan 18, 2019 at 10:07 AM Severin Gehwolf < > > > sgehwolf at redhat.com > > > > > wrote: > > > > > On Thu, 2019-01-17 at 10:00 -0700, Dennis Gesker wrote: > > > > > [...] > > > > > > Added the? -Djavax.net.debug=all option to my Wildfly > startup > > > and > > > > > > waited for the pool to close a connection to MySql at AWS. > > > > > > > > > > > > TXT file attached. > > > > > > > > > > > > javac 11.0.1 > > > > > > mysql jdbc driver 8.0.13 > > > > > > wildfly 15.0.1 > > > > > > > > > > > > --drg > > > > > > > > > > Unfortunately the txt file got stripped by the mailing list. > > > Would > > > > > you > > > > > be able to upload it somewhere and post a link? > > > > > > > > > > Thanks, > > > > > Severin > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennis at gesker.com Tue Jan 22 14:22:52 2019 From: dennis at gesker.com (Dennis Gesker) Date: Tue, 22 Jan 2019 07:22:52 -0700 Subject: JDK-8215102 (Follow-up) In-Reply-To: References: <07e6daa4a6a83133acb80d8a065836e13637b866.camel@redhat.com> <367cf00106cd91678df4cd5f68f710647ac1515d.camel@redhat.com> Message-ID: Thank you for the test exception, Jaikiran! I just got to the office and was about to do the same thing. I didn't think It was a WildFly issue. WildFly was just where I first noticed the warning. Again, thank you, Sir. --drg On Tue, Jan 22, 2019 at 5:44 AM Jaikiran Pai wrote: > FWIW - I don't think this is related to WildFly server. So I decided to > try and reproduce this in a trivial standalone program and I was able to > reproduce this. Here's the code to reproduce this issue: > > > import java.sql.*; > > public class ConnectionCloseTest { > > public static void main(final String[] args) throws Exception { > final String url = "jdbc:mysql://localhost/?requireSSL=true"; > final String user = "youruser"; // set the right user > final String pass = "yourpassword"; // set the right password > Class.forName("com.mysql.jdbc.Driver"); > final Connection conn = DriverManager.getConnection(url, user, > pass); > System.out.println("Got connection"); > conn.close(); > System.out.println("Closed connection"); > } > > } > > It's important to start the MySQL server with ssl enabled. For that I just > had to set: > > [mysqld] > ssl=1 > > in my MySQL server configuration. On the client side you will need the > mysql JDBC driver jar in the classpath. The one I used for this test was > mysql-connector-java-5.1.43.jar. > > Running this with Java 8 doesn't throw any exceptions or WARN logs. > However, running it against Java 11 and even Java 12 latest EA build, > throws an exception, which gets logged as a WARN by the driver (and things > move on) on connection close: > > > WARN: Caught while disconnecting... > > EXCEPTION STACK TRACE: > > > > ** BEGIN NESTED EXCEPTION ** > > javax.net.ssl.SSLException > MESSAGE: closing inbound before receiving peer's close_notify > > STACKTRACE: > > javax.net.ssl.SSLException: closing inbound before receiving peer's > close_notify > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133) > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:307) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:254) > at > java.base/sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:650) > at > java.base/sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:629) > at com.mysql.jdbc.MysqlIO.quit(MysqlIO.java:2246) > at com.mysql.jdbc.ConnectionImpl.realClose(ConnectionImpl.java:4234) > at com.mysql.jdbc.ConnectionImpl.close(ConnectionImpl.java:1472) > at ConnectionCloseTest.main(ConnectionCloseTest.java:13) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:567) > at > jdk.compiler/com.sun.tools.javac.launcher.Main.execute(Main.java:415) > at jdk.compiler/com.sun.tools.javac.launcher.Main.run(Main.java:192) > at jdk.compiler/com.sun.tools.javac.launcher.Main.main(Main.java:132) > > > ** END NESTED EXCEPTION ** > > -Jaikiran > > > On 22/01/19 7:43 AM, Dennis Gesker wrote: > > Hi Severing: > > I'll post the generic error when I get to the office. It seems to throw > the complaints when it closes a connection. > > Here is the thing... > > 1. I'm glad this found its way to you (being Red Hat guy) as we first > noticed it in WildFly 15.0.1. (But, wasn't looking for it before as we > only need it for a few XA migration transactions.) > > 2. It MIGHT be the driver as we use PostgreSQL driver mostly -- in the > same container -- and no errors there on WildFly 15.0.1 and JDK 11. > > 3. I will also try to fall back to JDK 8 and see if it continues in > WildFly 15.0.1. > > 4. The error occurs -- it would seem -- as the pool closes idle > connections. > > 5. I'll post the pool/data source config in WildFly as well -- it seems > correct and seems to work OK in my application. > > Oh, yeah... > > And, I found the form to be a contributor (not comitter) and will fill > that out tomorrow as well and submit it to you directly. > > --drg > > On Mon, Jan 21, 2019, 09:23 Severin Gehwolf >> On Mon, 2019-01-21 at 07:57 -0700, Dennis Gesker wrote: >> > >> > Pasted: >> > >> > https://paste.fedoraproject.org/paste/vEvp9RwN2rVvIKGiC0IvEQ >> >> >> Is this the full trace? I don't see any exceptions happening in the >> log. Am I missing something? >> >> Thanks, >> Severin >> >> > On Mon, Jan 21, 2019 at 2:10 AM Severin Gehwolf >> > wrote: >> > > Hi Dennis, >> > > >> > > On Sat, 2019-01-19 at 12:08 -0700, Dennis Gesker wrote: >> > > > Hi Severin: >> > > > >> > > > A link to the txt file via Google Drive his here. >> > > >> > > "Sorry, the file you have requested does not exist." >> > > >> > > Could you please upload it somewhere less restricted? Maybe >> > > https://paste.fedoraproject.org/ >> >> or something similar? >> > > >> > > I guess if you include me directly, a file attachment would work >> > > too... >> > > It's the mailing lists which strip attachments. >> > > >> > > > I appreciate you and Alan taking a look. Especially, information >> > > > submitted from someone who is not a part of openjdk project. >> > > > I do hope the debug info helps. Let me know anything else you >> > > need >> > > > and I will do my best to provide it. >> > > >> > > Sure. I'll be mostly doing the intermediary work: getting the info >> > > added to the bug, though. >> > > >> > > > And, should your team decide to open a new ticket or reopen this >> > > > original ticket in the JIRA could you add me to the ticket? >> > > >> > > You'd have to become OpenJDK author for this[1]. It's not terribly >> > > difficult, but it's somewhat of an entry barrier I understand. >> > > >> > > > BTW, (off topic), would your recommend submitting a contributor >> > > > application to the openjdk project so bug reports can be >> > > submitted >> > > > directly? >> > > >> > > If you intend to submit the occasional bug report and fix it's >> > > easier >> > > for you long-term to attempt to become OpenJDK author (which >> > > requires >> > > signing the OCA[2]). >> > > >> > > > The dev group at my company is VERY small (and this message to >> > > your >> > > > group at the project is from my personal email) but I'd be glad >> > > to >> > > > submit bug reports as we come across them in our day to day use >> > > of >> > > > Java. >> > > >> > > If there are good reproducers for bugs this would be very welcome. >> > > Thanks for investing some time in this! >> > > >> > > Cheers, >> > > Severin >> > > >> > > [1] http://openjdk.java.net/bylaws#author >> >> > > http://openjdk.java.net/projects/#project-author >> >> > > [2] http://oss.oracle.com/oca.pdf >> >> > > >> > > > Cordially, >> > > > Dennis >> > > > dennis at gesker.com >> > > > >> > > > On Fri, Jan 18, 2019 at 10:07 AM Severin Gehwolf < >> > > sgehwolf at redhat.com >> > > > > wrote: >> > > > > On Thu, 2019-01-17 at 10:00 -0700, Dennis Gesker wrote: >> > > > > [...] >> > > > > > Added the -Djavax.net.debug=all option to my Wildfly startup >> > > and >> > > > > > waited for the pool to close a connection to MySql at AWS. >> > > > > > >> > > > > > TXT file attached. >> > > > > > >> > > > > > javac 11.0.1 >> > > > > > mysql jdbc driver 8.0.13 >> > > > > > wildfly 15.0.1 >> > > > > > >> > > > > > --drg >> > > > > >> > > > > Unfortunately the txt file got stripped by the mailing list. >> > > Would >> > > > > you >> > > > > be able to upload it somewhere and post a link? >> > > > > >> > > > > Thanks, >> > > > > Severin >> > > > > >> > > > >> > > > >> > > >> > >> > >> >> -- Dennis R. Gesker [image: LinkedIn] [image: WordPress] [image: Gesker] [image: GPG_PGP] [image: dennis at gesker.com] ?Be without fear in the face of your enemies. Be brave and upright that God may love thee. Speak the truth always, even if it leads to your death. Safeguard the helpless and do no wrong ? that is your oath.?* -The Knight?s Oath (Kingdom of Heaven)* -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.petcher at oracle.com Tue Jan 22 15:24:22 2019 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 22 Jan 2019 10:24:22 -0500 Subject: RFR 8217518: Crypto benchmarks not warming up in time Message-ID: <450d8096-cb78-407a-6bf3-10ffae68210d@oracle.com> Claes, Please review this very small change that adds the "+AlwaysPreTouch" option to the crypto benchmarks to allow them to warm up in time. This fix is in response to Eric's discovery (when reviewing the new benchmarks for KeyAgreement and Cipher) that the crypto benchmarks were not warming up very well. Sergey discovered that the cause is memory allocation overhead with large heaps and G1. Adding +AlwaysPreTouch does more of this memory allocation work up front so it doesn't interfere with the benchmark. Webrev: http://cr.openjdk.java.net/~apetcher/8217518/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8217518 From claes.redestad at oracle.com Tue Jan 22 15:35:23 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 22 Jan 2019 16:35:23 +0100 Subject: RFR 8217518: Crypto benchmarks not warming up in time In-Reply-To: <450d8096-cb78-407a-6bf3-10ffae68210d@oracle.com> References: <450d8096-cb78-407a-6bf3-10ffae68210d@oracle.com> Message-ID: <762d44d6-1d79-9410-7f0a-2439a4dc3828@oracle.com> Hi, looks OK as a point fix for now, although we should consider if there might be more robust ways that avoids hard-coding in flags. E.g, could +AlwaysPreTouch have unfortunate side-effects on machines with extreme amounts of RAM if you don't also limit maximum heap size (-Xmx)? /Claes On 2019-01-22 16:24, Adam Petcher wrote: > Claes, > > Please review this very small change that adds the "+AlwaysPreTouch" > option to the crypto benchmarks to allow them to warm up in time. This > fix is in response to Eric's discovery (when reviewing the new > benchmarks for KeyAgreement and Cipher) that the crypto benchmarks were > not warming up very well. Sergey discovered that the cause is memory > allocation overhead with large heaps and G1. Adding +AlwaysPreTouch does > more of this memory allocation work up front so it doesn't interfere > with the benchmark. > > Webrev: http://cr.openjdk.java.net/~apetcher/8217518/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8217518 > From christoph.langer at sap.com Tue Jan 22 19:57:55 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 22 Jan 2019 19:57:55 +0000 Subject: Shall TLS_EMPTY_RENEGOTIATION_INFO_SCSV really be disabled via jdk.tls.disabledAlgorithms=...,NULL or is it an unwanted side effect of JDK-8211883? Message-ID: <5934d2e2c55649c59261443f5e8b7165@sap.com> Hi security experts, one of our customers is running into an issue with a Tomcat application after JDK-8211883 [1]. It seems that because of adding NULL to jdk.tls.disabledAlgorithms, the pseudo cipher suite TLS_EMPTY_RENEGOTIATION_INFO_SCSV is disabled. Seems like, according to CipherSuite.java [2], it is considered a NULL cipher. The tracing/reproducer shows that it?s definitely disabled via jdk.tls.disabledAlgorithms=NULL. However, with my limited knowledge of TLS and ciphersuites and googling around, I understand that TLS_EMPTY_RENEGOTIATION_INFO_SCSV is part of the RFC 5746 specification [3], which is still considered secure and state of the art for renegotiation. Is that correct? The effect now in the customer application is that the client sends the SCSV and the Tomcat SSL Engine checks for the presence of the SCSV cipher in the cipher suites [4]. Since it is not present, the handshake is stopped by removing all ciphers [5]. I also understand the Oracle readme about the renegotiation topic, that TLS_EMPTY_RENEGOTIATION_INFO_SCSV is a thing to have but not to disable. Please let me know, if you agree with my analysis. If so, could you please file a bug or tell me to do so? Otherwise let me know what I?m missing. The workaround for the customer is to remove the NULL entry from jdk.tls.disabledAlgorithms for the time being. I guess that?s a bit more secure than setting ?sun.security.ssl.allowUnsafeRenegotiation? ?? Thanks Christoph [1] https://bugs.openjdk.java.net/browse/JDK-8211883 [2] http://hg.openjdk.java.net/jdk/jdk/file/1ae823617395/src/java.base/share/classes/sun/security/ssl/CipherSuite.java#l312 [3] http://www.ietf.org/rfc/rfc5746.txt [4] https://github.com/apache/tomcat70/blob/600d5c81aafee7e95fe07c3b9182f37741e2d0d8/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java#L145 [5] https://github.com/apache/tomcat70/blob/600d5c81aafee7e95fe07c3b9182f37741e2d0d8/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java#L293 [6] https://www.oracle.com/technetwork/java/javase/overview/tlsreadme2-176330.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Tue Jan 22 21:46:11 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 22 Jan 2019 16:46:11 -0500 Subject: Shall TLS_EMPTY_RENEGOTIATION_INFO_SCSV really be disabled via jdk.tls.disabledAlgorithms=...,NULL or is it an unwanted side effect of JDK-8211883? In-Reply-To: <5934d2e2c55649c59261443f5e8b7165@sap.com> References: <5934d2e2c55649c59261443f5e8b7165@sap.com> Message-ID: Hi Christoph, Yes, this indeed looks like a bug. The jdk.tls.disabledAlgorithms security property probably should not restrict suites that are not negotiable like TLS_EMPTY_RENEGOTIATION_INFO_SCSV. Please feel free to file a bug or else Sean Coffey or I can do that on your behalf tomorrow. The information below should be enough details to put in the bug. Thanks, Sean On 1/22/19 2:57 PM, Langer, Christoph wrote: > Hi security experts, > > one of our customers is running into an issue with a Tomcat application > after JDK-8211883 [1]. It seems that because of adding NULL to > jdk.tls.disabledAlgorithms, the pseudo cipher suite > TLS_EMPTY_RENEGOTIATION_INFO_SCSV is disabled. Seems like, according to > CipherSuite.java [2], it is considered a NULL cipher. The > tracing/reproducer shows that it?s definitely disabled via > jdk.tls.disabledAlgorithms=NULL. > > However, with my limited knowledge of TLS and ciphersuites and googling > around, I understand that TLS_EMPTY_RENEGOTIATION_INFO_SCSV is part of > the RFC 5746 specification [3], which is still considered secure and > state of the art for renegotiation. Is that correct? > > The effect now in the customer application is that the client sends the > SCSV and the Tomcat SSL Engine checks for the presence of the SCSV > cipher in the cipher suites [4]. Since it is not present, the handshake > is stopped by removing all ciphers [5]. > > I also understand the Oracle readme about the renegotiation topic, that > TLS_EMPTY_RENEGOTIATION_INFO_SCSV is a thing to have but not to disable. > > Please let me know, if you agree with my analysis. If so, could you > please file a bug or tell me to do so? Otherwise let me know what I?m > missing. The workaround for the customer is to remove the NULL entry > from jdk.tls.disabledAlgorithms for the time being. I guess that?s a bit > more secure than setting ?sun.security.ssl.allowUnsafeRenegotiation? ?? > > Thanks > > Christoph > > [1] https://bugs.openjdk.java.net/browse/JDK-8211883 > > [2] > http://hg.openjdk.java.net/jdk/jdk/file/1ae823617395/src/java.base/share/classes/sun/security/ssl/CipherSuite.java#l312 > > [3] http://www.ietf.org/rfc/rfc5746.txt > > [4] > https://github.com/apache/tomcat70/blob/600d5c81aafee7e95fe07c3b9182f37741e2d0d8/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java#L145 > > > [5] > https://github.com/apache/tomcat70/blob/600d5c81aafee7e95fe07c3b9182f37741e2d0d8/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java#L293 > > > [6] > https://www.oracle.com/technetwork/java/javase/overview/tlsreadme2-176330.html > > From sean.mullan at oracle.com Tue Jan 22 21:56:54 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 22 Jan 2019 16:56:54 -0500 Subject: Shall TLS_EMPTY_RENEGOTIATION_INFO_SCSV really be disabled via jdk.tls.disabledAlgorithms=...,NULL or is it an unwanted side effect of JDK-8211883? In-Reply-To: References: <5934d2e2c55649c59261443f5e8b7165@sap.com> Message-ID: Actually a bug for this has just been filed by SAP: https://bugs.openjdk.java.net/browse/JDK-8217579. Since it came in via webbugs, it has been initially marked Confidential. We can probably just use this bug. I'll copy in more details and open it up. --Sean On 1/22/19 4:46 PM, Sean Mullan wrote: > Hi Christoph, > > Yes, this indeed looks like a bug. The jdk.tls.disabledAlgorithms > security property probably should not restrict suites that are not > negotiable like TLS_EMPTY_RENEGOTIATION_INFO_SCSV. > > Please feel free to file a bug or else Sean Coffey or I can do that on > your behalf tomorrow. The information below should be enough details to > put in the bug. > > Thanks, > Sean > > On 1/22/19 2:57 PM, Langer, Christoph wrote: >> Hi security experts, >> >> one of our customers is running into an issue with a Tomcat >> application after JDK-8211883 [1]. It seems that because of adding >> NULL to jdk.tls.disabledAlgorithms, the pseudo cipher suite >> TLS_EMPTY_RENEGOTIATION_INFO_SCSV is disabled. Seems like, according >> to CipherSuite.java [2], it is considered a NULL cipher. The >> tracing/reproducer shows that it?s definitely disabled via >> jdk.tls.disabledAlgorithms=NULL. >> >> However, with my limited knowledge of TLS and ciphersuites and >> googling around, I understand that TLS_EMPTY_RENEGOTIATION_INFO_SCSV >> is part of the RFC 5746 specification [3], which is still considered >> secure and state of the art for renegotiation. Is that correct? >> >> The effect now in the customer application is that the client sends >> the SCSV and the Tomcat SSL Engine checks for the presence of the SCSV >> cipher in the cipher suites [4]. Since it is not present, the >> handshake is stopped by removing all ciphers [5]. >> >> I also understand the Oracle readme about the renegotiation topic, >> that TLS_EMPTY_RENEGOTIATION_INFO_SCSV is a thing to have but not to >> disable. >> >> Please let me know, if you agree with my analysis. If so, could you >> please file a bug or tell me to do so? Otherwise let me know what I?m >> missing. The workaround for the customer is to remove the NULL entry >> from jdk.tls.disabledAlgorithms for the time being. I guess that?s a >> bit more secure than setting >> ?sun.security.ssl.allowUnsafeRenegotiation? ?? >> >> Thanks >> >> Christoph >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8211883 >> >> [2] >> http://hg.openjdk.java.net/jdk/jdk/file/1ae823617395/src/java.base/share/classes/sun/security/ssl/CipherSuite.java#l312 >> >> >> [3] http://www.ietf.org/rfc/rfc5746.txt >> >> [4] >> https://github.com/apache/tomcat70/blob/600d5c81aafee7e95fe07c3b9182f37741e2d0d8/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java#L145 >> >> >> [5] >> https://github.com/apache/tomcat70/blob/600d5c81aafee7e95fe07c3b9182f37741e2d0d8/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java#L293 >> >> >> [6] >> https://www.oracle.com/technetwork/java/javase/overview/tlsreadme2-176330.html >> >> From matthias.baesken at sap.com Wed Jan 23 07:47:18 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 23 Jan 2019 07:47:18 +0000 Subject: Shall TLS_EMPTY_RENEGOTIATION_INFO_SCSV really be disabled via jdk.tls.disabledAlgorithms=...,NULL or is it an unwanted side effect of JDK-8211883? In-Reply-To: References: <5934d2e2c55649c59261443f5e8b7165@sap.com> Message-ID: Hi Sean, do you think it would be good to check in a jtreg test that TLS_EMPTY_RENEGOTIATION_INFO_SCSV Is always in the lists returned by ssf.getDefaultCipherSuites() and ssf.getSupportedCipherSuites() ? Best regards, Matthias > -----Original Message----- > From: Sean Mullan > Sent: Dienstag, 22. Januar 2019 22:57 > To: Langer, Christoph ; Se?n Coffey > ; OpenJDK Dev list dev at openjdk.java.net> > Cc: Baesken, Matthias > Subject: Re: Shall TLS_EMPTY_RENEGOTIATION_INFO_SCSV really be > disabled via jdk.tls.disabledAlgorithms=...,NULL or is it an unwanted side > effect of JDK-8211883? > > Actually a bug for this has just been filed by SAP: > https://bugs.openjdk.java.net/browse/JDK-8217579. Since it came in via > webbugs, it has been initially marked Confidential. We can probably just > use this bug. I'll copy in more details and open it up. > > --Sean > > On 1/22/19 4:46 PM, Sean Mullan wrote: > > Hi Christoph, > > > > Yes, this indeed looks like a bug. The jdk.tls.disabledAlgorithms > > security property probably should not restrict suites that are not > > negotiable like TLS_EMPTY_RENEGOTIATION_INFO_SCSV. > > > > Please feel free to file a bug or else Sean Coffey or I can do that on > > your behalf tomorrow. The information below should be enough details to > > put in the bug. > > > > Thanks, > > Sean > > > > On 1/22/19 2:57 PM, Langer, Christoph wrote: > >> Hi security experts, > >> > >> one of our customers is running into an issue with a Tomcat > >> application after JDK-8211883 [1]. It seems that because of adding > >> NULL to jdk.tls.disabledAlgorithms, the pseudo cipher suite > >> TLS_EMPTY_RENEGOTIATION_INFO_SCSV is disabled. Seems like, > according > >> to CipherSuite.java [2], it is considered a NULL cipher. The > >> tracing/reproducer shows that it?s definitely disabled via > >> jdk.tls.disabledAlgorithms=NULL. > >> > >> However, with my limited knowledge of TLS and ciphersuites and > >> googling around, I understand that > TLS_EMPTY_RENEGOTIATION_INFO_SCSV > >> is part of the RFC 5746 specification [3], which is still considered > >> secure and state of the art for renegotiation. Is that correct? > >> > >> The effect now in the customer application is that the client sends > >> the SCSV and the Tomcat SSL Engine checks for the presence of the SCSV > >> cipher in the cipher suites [4]. Since it is not present, the > >> handshake is stopped by removing all ciphers [5]. > >> > >> I also understand the Oracle readme about the renegotiation topic, > >> that TLS_EMPTY_RENEGOTIATION_INFO_SCSV is a thing to have but not > to > >> disable. > >> > >> Please let me know, if you agree with my analysis. If so, could you > >> please file a bug or tell me to do so? Otherwise let me know what I?m > >> missing. The workaround for the customer is to remove the NULL entry > >> from jdk.tls.disabledAlgorithms for the time being. I guess that?s a > >> bit more secure than setting > >> ?sun.security.ssl.allowUnsafeRenegotiation? ?? > >> > >> Thanks > >> > >> Christoph > >> > >> [1] https://bugs.openjdk.java.net/browse/JDK-8211883 > >> > >> [2] > >> > http://hg.openjdk.java.net/jdk/jdk/file/1ae823617395/src/java.base/share/ > classes/sun/security/ssl/CipherSuite.java#l312 > >> > >> > >> [3] http://www.ietf.org/rfc/rfc5746.txt > >> > >> [4] > >> > https://github.com/apache/tomcat70/blob/600d5c81aafee7e95fe07c3b9182f > 37741e2d0d8/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java > #L145 > >> > >> > >> [5] > >> > https://github.com/apache/tomcat70/blob/600d5c81aafee7e95fe07c3b9182f > 37741e2d0d8/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java > #L293 > >> > >> > >> [6] > >> > https://www.oracle.com/technetwork/java/javase/overview/tlsreadme2- > 176330.html > >> > >> From christoph.langer at sap.com Wed Jan 23 16:05:55 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 23 Jan 2019 16:05:55 +0000 Subject: RFR 8217657: Move the test for default value of jdk.includeInExceptions into own test Message-ID: <3f45b06bb6654a42b70f4184970878b9@sap.com> Hi, please review a small test update. Bug: https://bugs.openjdk.java.net/browse/JDK-8217657 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8217657.0/ I'd like to move the test for the correct default value of security property "jdk.includeInExceptions" into an own testcase in the jdk.security area. This seems a bit more natural than to hide this check in a java/net specific test and will help finding/maintaining tests when the (default-)value for that property changes. For instance new values get added or other OpenJDK builds have different defaults (e.g. SAPMachine). Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Thu Jan 24 07:47:46 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 24 Jan 2019 07:47:46 +0000 Subject: RFR 8217657: Move the test for default value of jdk.includeInExceptions into own test In-Reply-To: <3f45b06bb6654a42b70f4184970878b9@sap.com> References: <3f45b06bb6654a42b70f4184970878b9@sap.com> Message-ID: <076017e21cc0495a990e67e7b9bcf2e8@sap.com> Hi Christoph, it is a good idea to keep testing these two matters separately. Could you please document in the new test that in OpenJDK it is decided to keep this property empty? Something like: @comment In OpenJDK, this property is empty by default and on purpose. This test assures the default is not changed. Otherwise, looks good. Best regards, Goetz. From: net-dev On Behalf Of Langer, Christoph Sent: Mittwoch, 23. Januar 2019 17:06 To: OpenJDK Dev list ; OpenJDK Network Dev list Subject: [CAUTION] RFR 8217657: Move the test for default value of jdk.includeInExceptions into own test Hi, please review a small test update. Bug: https://bugs.openjdk.java.net/browse/JDK-8217657 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8217657.0/ I'd like to move the test for the correct default value of security property "jdk.includeInExceptions" into an own testcase in the jdk.security area. This seems a bit more natural than to hide this check in a java/net specific test and will help finding/maintaining tests when the (default-)value for that property changes. For instance new values get added or other OpenJDK builds have different defaults (e.g. SAPMachine). Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Jan 24 10:58:57 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 24 Jan 2019 10:58:57 +0000 Subject: RFR 8217657: Move the test for default value of jdk.includeInExceptions into own test In-Reply-To: <076017e21cc0495a990e67e7b9bcf2e8@sap.com> References: <3f45b06bb6654a42b70f4184970878b9@sap.com> <076017e21cc0495a990e67e7b9bcf2e8@sap.com> Message-ID: <61ce165f2159441e9fb8e95bacdccdbb@sap.com> Hi Goetz, thanks for the review. I've added the comment as you suggested: http://cr.openjdk.java.net/~clanger/webrevs/8217657.1/ Will run it through our nightly tests before submitting... /Christoph From: Lindenmaier, Goetz Sent: Donnerstag, 24. Januar 2019 08:48 To: Langer, Christoph ; OpenJDK Dev list ; OpenJDK Network Dev list Subject: RE: RFR 8217657: Move the test for default value of jdk.includeInExceptions into own test Hi Christoph, it is a good idea to keep testing these two matters separately. Could you please document in the new test that in OpenJDK it is decided to keep this property empty? Something like: @comment In OpenJDK, this property is empty by default and on purpose. This test assures the default is not changed. Otherwise, looks good. Best regards, Goetz. From: net-dev > On Behalf Of Langer, Christoph Sent: Mittwoch, 23. Januar 2019 17:06 To: OpenJDK Dev list >; OpenJDK Network Dev list > Subject: [CAUTION] RFR 8217657: Move the test for default value of jdk.includeInExceptions into own test Hi, please review a small test update. Bug: https://bugs.openjdk.java.net/browse/JDK-8217657 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8217657.0/ I'd like to move the test for the correct default value of security property "jdk.includeInExceptions" into an own testcase in the jdk.security area. This seems a bit more natural than to hide this check in a java/net specific test and will help finding/maintaining tests when the (default-)value for that property changes. For instance new values get added or other OpenJDK builds have different defaults (e.g. SAPMachine). Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Thu Jan 24 11:05:09 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 24 Jan 2019 11:05:09 +0000 Subject: RFR 8217657: Move the test for default value of jdk.includeInExceptions into own test In-Reply-To: <61ce165f2159441e9fb8e95bacdccdbb@sap.com> References: <3f45b06bb6654a42b70f4184970878b9@sap.com> <076017e21cc0495a990e67e7b9bcf2e8@sap.com> <61ce165f2159441e9fb8e95bacdccdbb@sap.com> Message-ID: <40756eaef100449fb9a6b9767a7e0e5e@sap.com> Thanks! I should have stated that I don't need a new webrev, thanks anyways. Best regards, Goetz. > -----Original Message----- > From: Langer, Christoph > Sent: Donnerstag, 24. Januar 2019 11:59 > To: Lindenmaier, Goetz ; OpenJDK Dev list > ; OpenJDK Network Dev list dev at openjdk.java.net> > Subject: RE: RFR 8217657: Move the test for default value of > jdk.includeInExceptions into own test > > Hi Goetz, > > > > thanks for the review. > > > > I've added the comment as you suggested: > http://cr.openjdk.java.net/~clanger/webrevs/8217657.1/ > > > > Will run it through our nightly tests before submitting... > > > > /Christoph > > > > > > From: Lindenmaier, Goetz > Sent: Donnerstag, 24. Januar 2019 08:48 > To: Langer, Christoph ; OpenJDK Dev list > ; OpenJDK Network Dev list dev at openjdk.java.net> > Subject: RE: RFR 8217657: Move the test for default value of > jdk.includeInExceptions into own test > > > > Hi Christoph, > > > > it is a good idea to keep testing these two matters separately. > > > > Could you please document in the new test that in OpenJDK > > it is decided to keep this property empty? > > Something like: > > @comment In OpenJDK, this property is empty by default and on purpose. This > test assures the default is not changed. > > > > Otherwise, looks good. > > > > Best regards, > > Goetz. > > > > From: net-dev bounces at openjdk.java.net> > On Behalf Of Langer, Christoph > Sent: Mittwoch, 23. Januar 2019 17:06 > To: OpenJDK Dev list dev at openjdk.java.net> >; OpenJDK Network Dev list dev at openjdk.java.net > > Subject: [CAUTION] RFR 8217657: Move the test for default value of > jdk.includeInExceptions into own test > > > > Hi, > > > > please review a small test update. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217657 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8217657.0/ > > > > I'd like to move the test for the correct default value of security property > "jdk.includeInExceptions" into an own testcase in the jdk.security area. This > seems a bit more natural than to hide this check in a java/net specific test and > will help finding/maintaining tests when the (default-)value for that property > changes. For instance new values get added or other OpenJDK builds have > different defaults (e.g. SAPMachine). > > > > Thanks > > Christoph > > From sean.mullan at oracle.com Thu Jan 24 16:42:35 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 24 Jan 2019 11:42:35 -0500 Subject: RFR 8217657: Move the test for default value of jdk.includeInExceptions into own test In-Reply-To: <3f45b06bb6654a42b70f4184970878b9@sap.com> References: <3f45b06bb6654a42b70f4184970878b9@sap.com> Message-ID: <24498b4b-ece1-180c-2598-e7fe709d5f4b@oracle.com> I don't think you really need to run the test with the othervm flag, unless you are concerned other tests may be setting this property and (incorrectly) not running in a separate VM, which would be a bug in my opinion. Well, then maybe you should run it in othervm just in case. Otherwise, looks ok to me. --Sean On 1/23/19 11:05 AM, Langer, Christoph wrote: > Hi, > > please review a small test update. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217657 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8217657.0/ > > I?d like to move the test for the correct default value of security > property ?jdk.includeInExceptions? into an own testcase in the > jdk.security area. This seems a bit more natural than to hide this check > in a java/net specific test and will help finding/maintaining tests when > the (default-)value for that property changes. For instance new values > get added or other OpenJDK builds have different defaults (e.g. SAPMachine). > > Thanks > > Christoph > From sgehwolf at redhat.com Thu Jan 24 17:01:16 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 24 Jan 2019 18:01:16 +0100 Subject: JDK-8215102 (Follow-up) In-Reply-To: References: <07e6daa4a6a83133acb80d8a065836e13637b866.camel@redhat.com> <367cf00106cd91678df4cd5f68f710647ac1515d.camel@redhat.com> Message-ID: <5095e6ec84cf05ef17568f66d929a6365f715120.camel@redhat.com> Hi, Thanks for your feedback! I've tried to reproduce this on my end too, but failed. At least with MariaDB 10.2.21 and their recent jdbc driver and JDK 11. This looks like a JDBC driver issue on newer JDKs. Hence, I've noted that in the bug and closed it: https://bugs.openjdk.java.net/browse/JDK-8215102 If somebody manages to reproduce this with recent JDBC drivers I'd be happy to re-open it. mysql-connector-java-5.1.43.jar seems rather old. Current is 8.0.14. Thanks, Severin On Tue, 2019-01-22 at 18:14 +0530, Jaikiran Pai wrote: > FWIW - I don't think this is related to WildFly server. So I decided > to try and reproduce this in a trivial standalone program and I was > able to reproduce this. Here's the code to reproduce this issue: > > import java.sql.*; > > public class ConnectionCloseTest { > > public static void main(final String[] args) throws Exception { > final String url = "jdbc:mysql://localhost/?requireSSL=true"; > final String user = "youruser"; // set the right user > final String pass = "yourpassword"; // set the right password > Class.forName("com.mysql.jdbc.Driver"); > final Connection conn = DriverManager.getConnection(url, > user, pass); > System.out.println("Got connection"); > conn.close(); > System.out.println("Closed connection"); > } > > } > It's important to start the MySQL server with ssl enabled. For that I > just had to set: > [mysqld] > ssl=1 > in my MySQL server configuration. On the client side you will need > the mysql JDBC driver jar in the classpath. The one I used for this > test was mysql-connector-java-5.1.43.jar. > Running this with Java 8 doesn't throw any exceptions or WARN logs. > However, running it against Java 11 and even Java 12 latest EA build, > throws an exception, which gets logged as a WARN by the driver (and > things move on) on connection close: > > WARN: Caught while disconnecting... > > EXCEPTION STACK TRACE: > > > > ** BEGIN NESTED EXCEPTION ** > > javax.net.ssl.SSLException > MESSAGE: closing inbound before receiving peer's close_notify > > STACKTRACE: > > javax.net.ssl.SSLException: closing inbound before receiving peer's > close_notify > at > java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133) > at > java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.ja > va:307) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.ja > va:263) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.ja > va:254) > at > java.base/sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl. > java:650) > at > java.base/sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl. > java:629) > at com.mysql.jdbc.MysqlIO.quit(MysqlIO.java:2246) > at > com.mysql.jdbc.ConnectionImpl.realClose(ConnectionImpl.java:4234) > at com.mysql.jdbc.ConnectionImpl.close(ConnectionImpl.java:1472) > at ConnectionCloseTest.main(ConnectionCloseTest.java:13) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Nativ > e Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Native > MethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(De > legatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:567) > at > jdk.compiler/com.sun.tools.javac.launcher.Main.execute(Main.java:415) > at > jdk.compiler/com.sun.tools.javac.launcher.Main.run(Main.java:192) > at > jdk.compiler/com.sun.tools.javac.launcher.Main.main(Main.java:132) > > > ** END NESTED EXCEPTION ** > -Jaikiran > > On 22/01/19 7:43 AM, Dennis Gesker wrote: > > Hi Severing: > > > > I'll post the generic error when I get to the office. It seems to > > throw the complaints when it closes a connection. > > > > Here is the thing... > > > > 1. I'm glad this found its way to you (being Red Hat guy) as we > > first noticed it in WildFly 15.0.1. (But, wasn't looking for it > > before as we only need it for a few XA migration transactions.) > > > > 2. It MIGHT be the driver as we use PostgreSQL driver mostly -- in > > the same container -- and no errors there on WildFly 15.0.1 and JDK > > 11. > > > > 3. I will also try to fall back to JDK 8 and see if it continues in > > WildFly 15.0.1. > > > > 4. The error occurs -- it would seem -- as the pool closes idle > > connections. > > > > 5. I'll post the pool/data source config in WildFly as well -- it > > seems correct and seems to work OK in my application. > > > > Oh, yeah... > > > > And, I found the form to be a contributor (not comitter) and will > > fill that out tomorrow as well and submit it to you directly. > > > > --drg > > > > On Mon, Jan 21, 2019, 09:23 Severin Gehwolf > wrote: > > > On Mon, 2019-01-21 at 07:57 -0700, Dennis Gesker wrote: > > > > > > > > Pasted: > > > > > > > > https://paste.fedoraproject.org/paste/vEvp9RwN2rVvIKGiC0IvEQ > > > > > > Is this the full trace? I don't see any exceptions happening in > > > the > > > log. Am I missing something? > > > > > > Thanks, > > > Severin > > > > > > > On Mon, Jan 21, 2019 at 2:10 AM Severin Gehwolf < > > > sgehwolf at redhat.com> > > > > wrote: > > > > > Hi Dennis, > > > > > > > > > > On Sat, 2019-01-19 at 12:08 -0700, Dennis Gesker wrote: > > > > > > Hi Severin: > > > > > > > > > > > > A link to the txt file via Google Drive his here. > > > > > > > > > > "Sorry, the file you have requested does not exist." > > > > > > > > > > Could you please upload it somewhere less restricted? Maybe > > > > > https://paste.fedoraproject.org/ or something similar? > > > > > > > > > > I guess if you include me directly, a file attachment would > > > work > > > > > too... > > > > > It's the mailing lists which strip attachments. > > > > > > > > > > > I appreciate you and Alan taking a look. Especially, > > > information > > > > > > submitted from someone who is not a part of openjdk > > > project. > > > > > > I do hope the debug info helps. Let me know anything else > > > you > > > > > need > > > > > > and I will do my best to provide it. > > > > > > > > > > Sure. I'll be mostly doing the intermediary work: getting the > > > info > > > > > added to the bug, though. > > > > > > > > > > > And, should your team decide to open a new ticket or reopen > > > this > > > > > > original ticket in the JIRA could you add me to the ticket? > > > > > > > > > > You'd have to become OpenJDK author for this[1]. It's not > > > terribly > > > > > difficult, but it's somewhat of an entry barrier I > > > understand. > > > > > > > > > > > BTW, (off topic), would your recommend submitting a > > > contributor > > > > > > application to the openjdk project so bug reports can be > > > > > submitted > > > > > > directly? > > > > > > > > > > If you intend to submit the occasional bug report and fix > > > it's > > > > > easier > > > > > for you long-term to attempt to become OpenJDK author (which > > > > > requires > > > > > signing the OCA[2]). > > > > > > > > > > > The dev group at my company is VERY small (and this message > > > to > > > > > your > > > > > > group at the project is from my personal email) but I'd be > > > glad > > > > > to > > > > > > submit bug reports as we come across them in our day to day > > > use > > > > > of > > > > > > Java. > > > > > > > > > > If there are good reproducers for bugs this would be very > > > welcome. > > > > > Thanks for investing some time in this! > > > > > > > > > > Cheers, > > > > > Severin > > > > > > > > > > [1] http://openjdk.java.net/bylaws#author > > > > > http://openjdk.java.net/projects/#project-author > > > > > [2] http://oss.oracle.com/oca.pdf > > > > > > > > > > > Cordially, > > > > > > Dennis > > > > > > dennis at gesker.com > > > > > > > > > > > > On Fri, Jan 18, 2019 at 10:07 AM Severin Gehwolf < > > > > > sgehwolf at redhat.com > > > > > > > wrote: > > > > > > > On Thu, 2019-01-17 at 10:00 -0700, Dennis Gesker wrote: > > > > > > > [...] > > > > > > > > Added the -Djavax.net.debug=all option to my Wildfly > > > startup > > > > > and > > > > > > > > waited for the pool to close a connection to MySql at > > > AWS. > > > > > > > > > > > > > > > > TXT file attached. > > > > > > > > > > > > > > > > javac 11.0.1 > > > > > > > > mysql jdbc driver 8.0.13 > > > > > > > > wildfly 15.0.1 > > > > > > > > > > > > > > > > --drg > > > > > > > > > > > > > > Unfortunately the txt file got stripped by the mailing > > > list. > > > > > Would > > > > > > > you > > > > > > > be able to upload it somewhere and post a link? > > > > > > > > > > > > > > Thanks, > > > > > > > Severin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From christoph.langer at sap.com Thu Jan 24 22:06:13 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 24 Jan 2019 22:06:13 +0000 Subject: RFR 8217657: Move the test for default value of jdk.includeInExceptions into own test In-Reply-To: <24498b4b-ece1-180c-2598-e7fe709d5f4b@oracle.com> References: <3f45b06bb6654a42b70f4184970878b9@sap.com> <24498b4b-ece1-180c-2598-e7fe709d5f4b@oracle.com> Message-ID: <7bc9884027b94df1b4c4722245d0b451@sap.com> Hi Sean, thanks for looking at this. I agree. Will remove othervm... Best regards Christoph > -----Original Message----- > From: Sean Mullan > Sent: Donnerstag, 24. Januar 2019 17:43 > To: Langer, Christoph ; OpenJDK Dev list > ; OpenJDK Network Dev list dev at openjdk.java.net> > Subject: Re: RFR 8217657: Move the test for default value of > jdk.includeInExceptions into own test > > I don't think you really need to run the test with the othervm flag, > unless you are concerned other tests may be setting this property and > (incorrectly) not running in a separate VM, which would be a bug in my > opinion. Well, then maybe you should run it in othervm just in case. > Otherwise, looks ok to me. > > --Sean > > On 1/23/19 11:05 AM, Langer, Christoph wrote: > > Hi, > > > > please review a small test update. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217657 > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8217657.0/ > > > > I'd like to move the test for the correct default value of security > > property "jdk.includeInExceptions" into an own testcase in the > > jdk.security area. This seems a bit more natural than to hide this check > > in a java/net specific test and will help finding/maintaining tests when > > the (default-)value for that property changes. For instance new values > > get added or other OpenJDK builds have different defaults (e.g. > SAPMachine). > > > > Thanks > > > > Christoph > > From jai.forums2013 at gmail.com Fri Jan 25 04:17:47 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 25 Jan 2019 09:47:47 +0530 Subject: JDK-8215102 (Follow-up) In-Reply-To: <5095e6ec84cf05ef17568f66d929a6365f715120.camel@redhat.com> References: <07e6daa4a6a83133acb80d8a065836e13637b866.camel@redhat.com> <367cf00106cd91678df4cd5f68f710647ac1515d.camel@redhat.com> <5095e6ec84cf05ef17568f66d929a6365f715120.camel@redhat.com> Message-ID: Hello Severin, Thank you for spending time on this. Although that JIRA was raised for in context of MySQL driver, having watched this discussion and looked a bit into the exception stacktrace, I think it's not really specific to MySQL. So I decided to reproduce this with just plain Java SSLSocket APIs and was able to reproduce this. I have attached a very simple jtreg test case which fails against the latest upstream jdk source repo. The test case has details about what it does, but in short, the test creates a SSLServerSocket (server) and a SSLSocket (client) and the client sends some random data to the server and then calls SSLSocket.shutdownInput(). That call triggers the exception that's being discussed here. Reading the javadoc of SSLSocket.shutdownInput() I don't think the usage of this API is incorrect (this is of course based on my limited knowledge of that API). -Jaikiran On 24/01/19 10:31 PM, Severin Gehwolf wrote: > Hi, > > Thanks for your feedback! > > I've tried to reproduce this on my end too, but failed. At least with > MariaDB 10.2.21 and their recent jdbc driver and JDK 11. > > This looks like a JDBC driver issue on newer JDKs. Hence, I've noted > that in the bug and closed it: > https://bugs.openjdk.java.net/browse/JDK-8215102 > > If somebody manages to reproduce this with recent JDBC drivers I'd be > happy to re-open it. mysql-connector-java-5.1.43.jar seems rather old. > Current is 8.0.14. > > Thanks, > Severin > > On Tue, 2019-01-22 at 18:14 +0530, Jaikiran Pai wrote: >> FWIW - I don't think this is related to WildFly server. So I decided >> to try and reproduce this in a trivial standalone program and I was >> able to reproduce this. Here's the code to reproduce this issue: >> >> import java.sql.*; >> >> public class ConnectionCloseTest { >> >> public static void main(final String[] args) throws Exception { >> final String url = "jdbc:mysql://localhost/?requireSSL=true"; >> final String user = "youruser"; // set the right user >> final String pass = "yourpassword"; // set the right password >> Class.forName("com.mysql.jdbc.Driver"); >> final Connection conn = DriverManager.getConnection(url, >> user, pass); >> System.out.println("Got connection"); >> conn.close(); >> System.out.println("Closed connection"); >> } >> >> } >> It's important to start the MySQL server with ssl enabled. For that I >> just had to set: >> [mysqld] >> ssl=1 >> in my MySQL server configuration. On the client side you will need >> the mysql JDBC driver jar in the classpath. The one I used for this >> test was mysql-connector-java-5.1.43.jar. >> Running this with Java 8 doesn't throw any exceptions or WARN logs. >> However, running it against Java 11 and even Java 12 latest EA build, >> throws an exception, which gets logged as a WARN by the driver (and >> things move on) on connection close: >> >> WARN: Caught while disconnecting... >> >> EXCEPTION STACK TRACE: >> >> >> >> ** BEGIN NESTED EXCEPTION ** >> >> javax.net.ssl.SSLException >> MESSAGE: closing inbound before receiving peer's close_notify >> >> STACKTRACE: >> >> javax.net.ssl.SSLException: closing inbound before receiving peer's >> close_notify >> at >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133) >> at >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >> at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.ja >> va:307) >> at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.ja >> va:263) >> at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.ja >> va:254) >> at >> java.base/sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl. >> java:650) >> at >> java.base/sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl. >> java:629) >> at com.mysql.jdbc.MysqlIO.quit(MysqlIO.java:2246) >> at >> com.mysql.jdbc.ConnectionImpl.realClose(ConnectionImpl.java:4234) >> at com.mysql.jdbc.ConnectionImpl.close(ConnectionImpl.java:1472) >> at ConnectionCloseTest.main(ConnectionCloseTest.java:13) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Nativ >> e Method) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Native >> MethodAccessorImpl.java:62) >> at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(De >> legatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:567) >> at >> jdk.compiler/com.sun.tools.javac.launcher.Main.execute(Main.java:415) >> at >> jdk.compiler/com.sun.tools.javac.launcher.Main.run(Main.java:192) >> at >> jdk.compiler/com.sun.tools.javac.launcher.Main.main(Main.java:132) >> >> >> ** END NESTED EXCEPTION ** >> -Jaikiran >> >> On 22/01/19 7:43 AM, Dennis Gesker wrote: >>> Hi Severing: >>> >>> I'll post the generic error when I get to the office. It seems to >>> throw the complaints when it closes a connection. >>> >>> Here is the thing... >>> >>> 1. I'm glad this found its way to you (being Red Hat guy) as we >>> first noticed it in WildFly 15.0.1. (But, wasn't looking for it >>> before as we only need it for a few XA migration transactions.) >>> >>> 2. It MIGHT be the driver as we use PostgreSQL driver mostly -- in >>> the same container -- and no errors there on WildFly 15.0.1 and JDK >>> 11. >>> >>> 3. I will also try to fall back to JDK 8 and see if it continues in >>> WildFly 15.0.1. >>> >>> 4. The error occurs -- it would seem -- as the pool closes idle >>> connections. >>> >>> 5. I'll post the pool/data source config in WildFly as well -- it >>> seems correct and seems to work OK in my application. >>> >>> Oh, yeah... >>> >>> And, I found the form to be a contributor (not comitter) and will >>> fill that out tomorrow as well and submit it to you directly. >>> >>> --drg >>> >>> On Mon, Jan 21, 2019, 09:23 Severin Gehwolf >> wrote: >>>> On Mon, 2019-01-21 at 07:57 -0700, Dennis Gesker wrote: >>>>> Pasted: >>>>> >>>>> https://paste.fedoraproject.org/paste/vEvp9RwN2rVvIKGiC0IvEQ >>>> Is this the full trace? I don't see any exceptions happening in >>>> the >>>> log. Am I missing something? >>>> >>>> Thanks, >>>> Severin >>>> >>>>> On Mon, Jan 21, 2019 at 2:10 AM Severin Gehwolf < >>>> sgehwolf at redhat.com> >>>>> wrote: >>>>>> Hi Dennis, >>>>>> >>>>>> On Sat, 2019-01-19 at 12:08 -0700, Dennis Gesker wrote: >>>>>>> Hi Severin: >>>>>>> >>>>>>> A link to the txt file via Google Drive his here. >>>>>> "Sorry, the file you have requested does not exist." >>>>>> >>>>>> Could you please upload it somewhere less restricted? Maybe >>>>>> https://paste.fedoraproject.org/ or something similar? >>>>>> >>>>>> I guess if you include me directly, a file attachment would >>>> work >>>>>> too... >>>>>> It's the mailing lists which strip attachments. >>>>>> >>>>>>> I appreciate you and Alan taking a look. Especially, >>>> information >>>>>>> submitted from someone who is not a part of openjdk >>>> project. >>>>>>> I do hope the debug info helps. Let me know anything else >>>> you >>>>>> need >>>>>>> and I will do my best to provide it. >>>>>> Sure. I'll be mostly doing the intermediary work: getting the >>>> info >>>>>> added to the bug, though. >>>>>> >>>>>>> And, should your team decide to open a new ticket or reopen >>>> this >>>>>>> original ticket in the JIRA could you add me to the ticket? >>>>>> You'd have to become OpenJDK author for this[1]. It's not >>>> terribly >>>>>> difficult, but it's somewhat of an entry barrier I >>>> understand. >>>>>>> BTW, (off topic), would your recommend submitting a >>>> contributor >>>>>>> application to the openjdk project so bug reports can be >>>>>> submitted >>>>>>> directly? >>>>>> If you intend to submit the occasional bug report and fix >>>> it's >>>>>> easier >>>>>> for you long-term to attempt to become OpenJDK author (which >>>>>> requires >>>>>> signing the OCA[2]). >>>>>> >>>>>>> The dev group at my company is VERY small (and this message >>>> to >>>>>> your >>>>>>> group at the project is from my personal email) but I'd be >>>> glad >>>>>> to >>>>>>> submit bug reports as we come across them in our day to day >>>> use >>>>>> of >>>>>>> Java. >>>>>> If there are good reproducers for bugs this would be very >>>> welcome. >>>>>> Thanks for investing some time in this! >>>>>> >>>>>> Cheers, >>>>>> Severin >>>>>> >>>>>> [1] http://openjdk.java.net/bylaws#author >>>>>> http://openjdk.java.net/projects/#project-author >>>>>> [2] http://oss.oracle.com/oca.pdf >>>>>> >>>>>>> Cordially, >>>>>>> Dennis >>>>>>> dennis at gesker.com >>>>>>> >>>>>>> On Fri, Jan 18, 2019 at 10:07 AM Severin Gehwolf < >>>>>> sgehwolf at redhat.com >>>>>>>> wrote: >>>>>>>> On Thu, 2019-01-17 at 10:00 -0700, Dennis Gesker wrote: >>>>>>>> [...] >>>>>>>>> Added the -Djavax.net.debug=all option to my Wildfly >>>> startup >>>>>> and >>>>>>>>> waited for the pool to close a connection to MySql at >>>> AWS. >>>>>>>>> TXT file attached. >>>>>>>>> >>>>>>>>> javac 11.0.1 >>>>>>>>> mysql jdbc driver 8.0.13 >>>>>>>>> wildfly 15.0.1 >>>>>>>>> >>>>>>>>> --drg >>>>>>>> Unfortunately the txt file got stripped by the mailing >>>> list. >>>>>> Would >>>>>>>> you >>>>>>>> be able to upload it somewhere and post a link? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Severin >>>>>>>> >>>>>>> >>>>> >>>> -------------- next part -------------- # HG changeset patch # User Jaikiran Pai # Date 1548389397 -19800 # Fri Jan 25 09:39:57 2019 +0530 # Node ID 8b421716e12337a1f669cbb5c06ad4737f715c6f # Parent d02f1f4ff3a637a99885563fcee0fee5d70b9b50 JDK-8215102 Testcase to reproduce the SSLSocket.shutdownInput exception diff --git a/test/jdk/javax/net/ssl/SSLSocket/SSLSocketShutdownInput.java b/test/jdk/javax/net/ssl/SSLSocket/SSLSocketShutdownInput.java new file mode 100644 --- /dev/null +++ b/test/jdk/javax/net/ssl/SSLSocket/SSLSocketShutdownInput.java @@ -0,0 +1,112 @@ +/* + * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 8215102 + * @summary Test that SSLSocket.shutdownInput() doesn't throw unexpected SSLException + * @library /javax/net/ssl/templates + */ + +import javax.net.ssl.SSLServerSocket; +import javax.net.ssl.SSLServerSocketFactory; +import javax.net.ssl.SSLSocket; +import java.io.BufferedReader; +import java.io.BufferedWriter; +import java.io.InputStreamReader; +import java.io.OutputStreamWriter; +import java.net.InetAddress; +import java.util.concurrent.Callable; +import java.util.concurrent.Executors; +import java.util.concurrent.Future; +import java.util.concurrent.TimeUnit; + +public class SSLSocketShutdownInput implements SSLContextTemplate { + + public static void main(String[] args) throws Exception { + new SSLSocketShutdownInput().test(); + } + + /** + * - Starts a server listening on a SSLServerSocket + * - Creates a (client) SSLSocket to communicate with that server + * - Client sends data to the server + * - Client then initiates a SSLSocket.shutdownInput() + * (Note: Server just receives data and doesn't write back or respond back + * to the client, so this is essentially a one-way communication) + * + * @throws Exception + */ + private void test() throws Exception { + final String data = "hello world"; + final Future serverTaskResult; + final SSLServerSocketFactory serversocketfactory = createServerSSLContext().getServerSocketFactory(); + try (final SSLServerSocket serverSocket = (SSLServerSocket) serversocketfactory.createServerSocket(0)) { + serverSocket.setNeedClientAuth(false); + serverSocket.setUseClientMode(false); + // start a thread which waits for client connection + serverTaskResult = Executors.newSingleThreadExecutor().submit(new Server(serverSocket)); + // create a client socket and communicate with the server + final String serverHost = InetAddress.getLocalHost().getHostName(); + final int serverPort = serverSocket.getLocalPort(); + try (final SSLSocket clientSocket = (SSLSocket) createClientSSLContext().getSocketFactory().createSocket( + serverHost, serverPort)) { + // send data to server + final BufferedWriter os = new BufferedWriter(new OutputStreamWriter(clientSocket.getOutputStream())); + os.write(data); + os.newLine(); + os.flush(); + + // shutdown the input + clientSocket.shutdownInput(); + + } + } + // verify that the server did receive the (right) data + final String dataReceivedByServer = serverTaskResult.get(1, TimeUnit.SECONDS); + if (!dataReceivedByServer.equals(data)) { + throw new Exception("Server did not receive the expected data"); + } + } + + private static final class Server implements Callable { + private final SSLServerSocket listenSocket; + + private Server(final SSLServerSocket listenSocket) { + this.listenSocket = listenSocket; + } + + @Override + public String call() throws Exception { + // wait for connection + try (final SSLSocket socket = (SSLSocket) listenSocket.accept()) { + // read any data from client + final BufferedReader reader = new BufferedReader(new InputStreamReader(socket.getInputStream())); + return reader.readLine(); + } + } + + } + +} + From sgehwolf at redhat.com Fri Jan 25 13:41:23 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 25 Jan 2019 14:41:23 +0100 Subject: JDK-8215102 (Follow-up) In-Reply-To: References: <07e6daa4a6a83133acb80d8a065836e13637b866.camel@redhat.com> <367cf00106cd91678df4cd5f68f710647ac1515d.camel@redhat.com> <5095e6ec84cf05ef17568f66d929a6365f715120.camel@redhat.com> Message-ID: <6ffc81f9c344bc272441cea91824540712cd4c9d.camel@redhat.com> Hi Jaikiran, On Fri, 2019-01-25 at 09:47 +0530, Jaikiran Pai wrote: > Hello Severin, > > Thank you for spending time on this. Although that JIRA was raised for > in context of MySQL driver, having watched this discussion and looked a > bit into the exception stacktrace, I think it's not really specific to > MySQL. > > So I decided to reproduce this with just plain Java SSLSocket APIs and > was able to reproduce this. I have attached a very simple jtreg test > case which fails against the latest upstream jdk source repo. The test > case has details about what it does, but in short, the test creates a > SSLServerSocket (server) and a SSLSocket (client) and the client sends > some random data to the server and then calls SSLSocket.shutdownInput(). > That call triggers the exception that's being discussed here. Reading > the javadoc of SSLSocket.shutdownInput() I don't think the usage of this > API is incorrect (this is of course based on my limited knowledge of > that API). > > -Jaikiran Thanks, I've added that info to the bug and re-opened it: https://bugs.openjdk.java.net/browse/JDK-8215102?focusedCommentId=14240050&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14240050 It's still not entirely clear to me whether this is wrong API usage or a JDK bug. Thanks, Severin From jai.forums2013 at gmail.com Fri Jan 25 13:53:02 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 25 Jan 2019 19:23:02 +0530 Subject: [PATCH] Typo in SSLSocket javadoc Message-ID: <47dd0641-5f7e-d06f-e43b-e06aa9d47f6c@gmail.com> Attached is a trivial patch which fixes a typo in the javadoc of SSLSocket. Could one of you please review and sponsor this patch? -Jaikiran -------------- next part -------------- # HG changeset patch # User Jaikiran Pai # Date 1548424232 -19800 # Fri Jan 25 19:20:32 2019 +0530 # Node ID fe149a371a1a961b53070e721a040c26d2e699c8 # Parent a692b606b4cd5ce41534e694f5a4330947b19cc8 Fix typo in SSLSocket javadoc diff --git a/src/java.base/share/classes/javax/net/ssl/SSLSocket.java b/src/java.base/share/classes/javax/net/ssl/SSLSocket.java --- a/src/java.base/share/classes/javax/net/ssl/SSLSocket.java +++ b/src/java.base/share/classes/javax/net/ssl/SSLSocket.java @@ -135,7 +135,7 @@ * applications should each close both sides of their respective connection. * For {@code SSLSocket} objects, for example, an application can call * {@link Socket#shutdownOutput()} or {@link java.io.OutputStream#close()} - * for output strean close and call {@link Socket#shutdownInput()} or + * for output stream close and call {@link Socket#shutdownInput()} or * {@link java.io.InputStream#close()} for input stream close. Note that * in some cases, closing the input stream may depend on the peer's output * stream being closed first. If the connection is not closed in an orderly From xuelei.fan at oracle.com Fri Jan 25 15:46:11 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 25 Jan 2019 07:46:11 -0800 Subject: [PATCH] Typo in SSLSocket javadoc In-Reply-To: <47dd0641-5f7e-d06f-e43b-e06aa9d47f6c@gmail.com> References: <47dd0641-5f7e-d06f-e43b-e06aa9d47f6c@gmail.com> Message-ID: <2b12d8cd-e179-3914-4450-90563febf80d@oracle.com> Hi Jaikiran, Thanks for the patch! It looks good to me, and I will sponsor for commit. Thanks, Xuelei On 1/25/2019 5:53 AM, Jaikiran Pai wrote: > Attached is a trivial patch which fixes a typo in the javadoc of > SSLSocket. Could one of you please review and sponsor this patch? > > -Jaikiran > From xuelei.fan at oracle.com Fri Jan 25 16:04:09 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 25 Jan 2019 08:04:09 -0800 Subject: [PATCH] Typo in SSLSocket javadoc In-Reply-To: <2b12d8cd-e179-3914-4450-90563febf80d@oracle.com> References: <47dd0641-5f7e-d06f-e43b-e06aa9d47f6c@gmail.com> <2b12d8cd-e179-3914-4450-90563febf80d@oracle.com> Message-ID: FYI. bug: https://bugs.openjdk.java.net/browse/JDK-8217795 changeset: http://hg.openjdk.java.net/jdk/jdk/rev/fffa4d0c0c14 Xuelei On 1/25/2019 7:46 AM, Xuelei Fan wrote: > Hi Jaikiran, > > Thanks for the patch!? It looks good to me, and I will sponsor for commit. > > Thanks, > Xuelei > > On 1/25/2019 5:53 AM, Jaikiran Pai wrote: >> Attached is a trivial patch which fixes a typo in the javadoc of >> SSLSocket. Could one of you please review and sponsor this patch? >> >> -Jaikiran >> From xuelei.fan at oracle.com Fri Jan 25 20:02:32 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 25 Jan 2019 12:02:32 -0800 Subject: Code Review Request, JDK-8217820 Useless cast in ECUtil.java Message-ID: <95ecdf01-d6a7-74c4-8274-f48ee2b3cfed@oracle.com> Hi, Can I have a code review for a trivial code cleanup? https://bugs.openjdk.java.net/browse/JDK-8217820 Thanks, Xuelei diff -r 1262a93634c2 src/java.base/share/classes/sun/security/util/ECUtil.java --- a/src/java.base/share/classes/sun/security/util/ECUtil.java Thu Jan 24 12:52:37 2019 -0500 +++ b/src/java.base/share/classes/sun/security/util/ECUtil.java Fri Jan 25 09:26:40 2019 -0800 @@ -31,7 +31,6 @@ import java.security.interfaces.*; import java.security.spec.*; import java.util.Arrays; -import sun.security.x509.X509Key; public class ECUtil { @@ -103,7 +102,7 @@ ECParameterSpec params) throws InvalidKeySpecException { KeyFactory keyFactory = getKeyFactory(); ECPublicKeySpec keySpec = new ECPublicKeySpec(w, params); - X509Key key = (X509Key)keyFactory.generatePublic(keySpec); + Key key = keyFactory.generatePublic(keySpec); return key.getEncoded(); } From jamil.j.nimeh at oracle.com Fri Jan 25 20:29:48 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 25 Jan 2019 12:29:48 -0800 Subject: Code Review Request, JDK-8217820 Useless cast in ECUtil.java In-Reply-To: <95ecdf01-d6a7-74c4-8274-f48ee2b3cfed@oracle.com> References: <95ecdf01-d6a7-74c4-8274-f48ee2b3cfed@oracle.com> Message-ID: <5ab32c53-07a9-0dc6-a063-77d498450a18@oracle.com> You sure can!? Looks good. --Jamil On 1/25/2019 12:02 PM, Xuelei Fan wrote: > Hi, > > Can I have a code review for a trivial code cleanup? > > ? https://bugs.openjdk.java.net/browse/JDK-8217820 > > Thanks, > Xuelei > > diff -r 1262a93634c2 > src/java.base/share/classes/sun/security/util/ECUtil.java > --- a/src/java.base/share/classes/sun/security/util/ECUtil.java Thu > Jan 24 12:52:37 2019 -0500 > +++ b/src/java.base/share/classes/sun/security/util/ECUtil.java Fri > Jan 25 09:26:40 2019 -0800 > @@ -31,7 +31,6 @@ > ?import java.security.interfaces.*; > ?import java.security.spec.*; > ?import java.util.Arrays; > -import sun.security.x509.X509Key; > > ?public class ECUtil { > > @@ -103,7 +102,7 @@ > ???????????? ECParameterSpec params) throws InvalidKeySpecException { > ???????? KeyFactory keyFactory = getKeyFactory(); > ???????? ECPublicKeySpec keySpec = new ECPublicKeySpec(w, params); > -??????? X509Key key = (X509Key)keyFactory.generatePublic(keySpec); > +??????? Key key = keyFactory.generatePublic(keySpec); > > ???????? return key.getEncoded(); > ???? } From jai.forums2013 at gmail.com Sat Jan 26 02:21:43 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 26 Jan 2019 07:51:43 +0530 Subject: [PATCH] Typo in SSLSocket javadoc In-Reply-To: References: <47dd0641-5f7e-d06f-e43b-e06aa9d47f6c@gmail.com> <2b12d8cd-e179-3914-4450-90563febf80d@oracle.com> Message-ID: Thank you Xuelei. -Jaikiran On 25/01/19 9:34 PM, Xuelei Fan wrote: > FYI. > > bug: https://bugs.openjdk.java.net/browse/JDK-8217795 > changeset: http://hg.openjdk.java.net/jdk/jdk/rev/fffa4d0c0c14 > > Xuelei > > On 1/25/2019 7:46 AM, Xuelei Fan wrote: >> Hi Jaikiran, >> >> Thanks for the patch!? It looks good to me, and I will sponsor for >> commit. >> >> Thanks, >> Xuelei >> >> On 1/25/2019 5:53 AM, Jaikiran Pai wrote: >>> Attached is a trivial patch which fixes a typo in the javadoc of >>> SSLSocket. Could one of you please review and sponsor this patch? >>> >>> -Jaikiran >>> From sean.mullan at oracle.com Mon Jan 28 18:26:36 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 28 Jan 2019 13:26:36 -0500 Subject: RFR: 8217579: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is gone after 8211883 Message-ID: <6f83fe24-7d70-2633-be5b-22ab0b55cd42@oracle.com> This fixes a regression introduced by the recent change to disable the TLS NULL cipher suites [1]. This accidentally also disabled the TLS_EMPTY_RENEGOTIATION_INFO_SCSV cipher suite because when the name is decomposed by the algorithm constraints checking code it has NULL for its different parts (key exchange, etc). But this cipher suite is not negotiable and is only used for renegotiation purposes as defined in RFC 5746. It should not have been disabled. I also resurrected the CheckCipherSuites test which had an @ignore label on it. This is a good test because it checks what the expected enabled/supported suites should be, and will help catch issues like this in the future. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8217579/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8217579 Thanks, Sean [1] https://bugs.openjdk.java.net/browse/JDK-8211883 From xuelei.fan at oracle.com Mon Jan 28 18:46:05 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 28 Jan 2019 10:46:05 -0800 Subject: CSR Review Request, JDK-8217835, Remove the experimental SunJSSE FIPS compliant mode. Message-ID: <69e31dc5-647f-a19f-f9de-ae51f8110a60@oracle.com> Hi, Could I get the CSR reviewed: CSR: https://bugs.openjdk.java.net/browse/JDK-8217907 and here is the proposed release note: https://bugs.openjdk.java.net/browse/JDK-8217911 If you are using this experimental feature, please let me know the compatibility impact by the end of Jan 31, 2019. Thanks, Xuelei From jamil.j.nimeh at oracle.com Mon Jan 28 19:25:06 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 28 Jan 2019 11:25:06 -0800 Subject: RFR: 8217579: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is gone after 8211883 In-Reply-To: <6f83fe24-7d70-2633-be5b-22ab0b55cd42@oracle.com> References: <6f83fe24-7d70-2633-be5b-22ab0b55cd42@oracle.com> Message-ID: The change looks straightforward to me.? One thing in the test code: if this were to ever be backported to 11 the ChaCha20-Poly1305 suites need to be removed from the ENABLED_UNLIMITED array.? But is fine for jdk/jdk and jdk12. --Jamil On 1/28/2019 10:26 AM, Sean Mullan wrote: > This fixes a regression introduced by the recent change to disable the > TLS NULL cipher suites [1]. This accidentally also disabled the > TLS_EMPTY_RENEGOTIATION_INFO_SCSV cipher suite because when the name > is decomposed by the algorithm constraints checking code it has NULL > for its different parts (key exchange, etc). But this cipher suite is > not negotiable and is only used for renegotiation purposes as defined > in RFC > 5746. It should not have been disabled. > > I also resurrected the CheckCipherSuites test which had an @ignore > label on it. This is a good test because it checks what the expected > enabled/supported suites should be, and will help catch issues like > this in the future. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8217579/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8217579 > > Thanks, > Sean > > [1] https://bugs.openjdk.java.net/browse/JDK-8211883 From sean.mullan at oracle.com Mon Jan 28 19:48:20 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 28 Jan 2019 14:48:20 -0500 Subject: RFR: 8217579: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is gone after 8211883 In-Reply-To: References: <6f83fe24-7d70-2633-be5b-22ab0b55cd42@oracle.com> Message-ID: <91321a12-ee5b-09a9-9992-510c989b7828@oracle.com> On 1/28/19 2:25 PM, Jamil Nimeh wrote: > The change looks straightforward to me.? One thing in the test code: if > this were to ever be backported to 11 the ChaCha20-Poly1305 suites need > to be removed from the ENABLED_UNLIMITED array. Yes. > But is fine for jdk/jdk > and jdk12. Great, thanks for the review. --Sean > > --Jamil > > On 1/28/2019 10:26 AM, Sean Mullan wrote: >> This fixes a regression introduced by the recent change to disable the >> TLS NULL cipher suites [1]. This accidentally also disabled the >> TLS_EMPTY_RENEGOTIATION_INFO_SCSV cipher suite because when the name >> is decomposed by the algorithm constraints checking code it has NULL >> for its different parts (key exchange, etc). But this cipher suite is >> not negotiable and is only used for renegotiation purposes as defined >> in RFC >> 5746. It should not have been disabled. >> >> I also resurrected the CheckCipherSuites test which had an @ignore >> label on it. This is a good test because it checks what the expected >> enabled/supported suites should be, and will help catch issues like >> this in the future. >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8217579/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8217579 >> >> Thanks, >> Sean >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8211883 > From ecki at zusammenkunft.net Mon Jan 28 19:54:31 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 28 Jan 2019 20:54:31 +0100 Subject: 8217579: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is gone after 8211883 In-Reply-To: <6f83fe24-7d70-2633-be5b-22ab0b55cd42@oracle.com> References: <6f83fe24-7d70-2633-be5b-22ab0b55cd42@oracle.com> Message-ID: <5c4f5df7.1c69fb81.72caa.5bd9@mx.google.com> Hello Sean, Maybe you also want to change comment and name of the SUPPORTE_DDEFAULT Array to ?SUPPORTED_LIMITED? since Unlimited is now Default? private final static String[] ENABLED_DEFAULT ?. // supported ciphersuites using default JCE policy jurisdiction files // AES/256 unavailable private final static String[] SUPPORTED_DEFAULT = { 230 ? remove ?Default Is the test already run with all available policies? With the new System property it should be easy to run it with other/vm twice? Is Oracle considering pushing a emergency public update for this? The change Looks otherwise fine (I was first wondering if checking for a _SVCS Family makes more sense but I guess that can be done once we have more of those ciphers. Gruss Bernd -- http://bernd.eckenfels.net Von: Sean Mullan Gesendet: Montag, 28. Januar 2019 20:26 An: security Dev OpenJDK Betreff: RFR: 8217579: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is gone after 8211883 This fixes a regression introduced by the recent change to disable the TLS NULL cipher suites [1]. This accidentally also disabled the TLS_EMPTY_RENEGOTIATION_INFO_SCSV cipher suite because when the name is decomposed by the algorithm constraints checking code it has NULL for its different parts (key exchange, etc). But this cipher suite is not negotiable and is only used for renegotiation purposes as defined in RFC 5746. It should not have been disabled. I also resurrected the CheckCipherSuites test which had an @ignore label on it. This is a good test because it checks what the expected enabled/supported suites should be, and will help catch issues like this in the future. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8217579/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8217579 Thanks, Sean [1] https://bugs.openjdk.java.net/browse/JDK-8211883 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Jan 28 21:24:59 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 28 Jan 2019 16:24:59 -0500 Subject: 8217579: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is gone after 8211883 In-Reply-To: <5c4f5df7.1c69fb81.72caa.5bd9@mx.google.com> References: <6f83fe24-7d70-2633-be5b-22ab0b55cd42@oracle.com> <5c4f5df7.1c69fb81.72caa.5bd9@mx.google.com> Message-ID: <60277c5c-84c8-3d4c-ada5-8faaaabbcce2@oracle.com> Updated webrev: http://cr.openjdk.java.net/~mullan/webrevs/8217579/webrev.01/ Comments inline ... On 1/28/19 2:54 PM, Bernd Eckenfels wrote: > Hello Sean, > > Maybe you also want to change comment and name of the SUPPORTE_DDEFAULT > Array to ?SUPPORTED_LIMITED? since Unlimited is now Default? > > ??? private final static String[] ENABLED_DEFAULT > > ?. > > ???? // supported ciphersuites using default JCE policy jurisdiction files > > ???? // AES/256 unavailable > > ???? private final static String[] SUPPORTED_DEFAULT = { > > 230 ? remove ?Default Good point. I have renamed the *_UNLIMITED constants to *_DEFAULT and renamed the *_DEFAULT constants to *_LIMITED. > Is the test already run with all available policies? With the new System > property it should be easy to run it with other/vm twice? Good point. I have changed the test to use the crypto.policy security property to test the suites with the default and limited policies. > Is Oracle considering pushing a emergency public update for this? We are planning to backport it to all affected releases. > The change Looks otherwise fine (I was first wondering if checking for a > _SVCS Family makes more sense but I guess that can be done once we have > more of those ciphers. Ok, thanks for the review. --Sean > > Gruss > > Bernd > > -- > http://bernd.eckenfels.net > > *Von: *Sean Mullan > *Gesendet: *Montag, 28. Januar 2019 20:26 > *An: *security Dev OpenJDK > *Betreff: *RFR: 8217579: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is gone after > 8211883 > > This fixes a regression introduced by the recent change to disable the > > TLS NULL cipher suites [1]. This accidentally also disabled the > > TLS_EMPTY_RENEGOTIATION_INFO_SCSV cipher suite because when the name is > > decomposed by the algorithm constraints checking code it has NULL for > > its different parts (key exchange, etc). But this cipher suite is not > > negotiable and is only used for renegotiation purposes as defined in RFC > > 5746. It should not have been disabled. > > I also resurrected the CheckCipherSuites test which had an @ignore label > > on it. This is a good test because it checks what the expected > > enabled/supported suites should be, and will help catch issues like this > > in the future. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8217579/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8217579 > > Thanks, > > Sean > > [1] https://bugs.openjdk.java.net/browse/JDK-8211883 > From christoph.langer at sap.com Mon Jan 28 22:45:58 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 28 Jan 2019 22:45:58 +0000 Subject: 8217579: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is gone after 8211883 In-Reply-To: <60277c5c-84c8-3d4c-ada5-8faaaabbcce2@oracle.com> References: <6f83fe24-7d70-2633-be5b-22ab0b55cd42@oracle.com> <5c4f5df7.1c69fb81.72caa.5bd9@mx.google.com> <60277c5c-84c8-3d4c-ada5-8faaaabbcce2@oracle.com> Message-ID: Hi Sean, to me this looks fine. +1 The test should be really valuable in the future. Thanks & Best regards Christoph > -----Original Message----- > From: security-dev On Behalf Of > Sean Mullan > Sent: Montag, 28. Januar 2019 22:25 > To: security-dev at openjdk.java.net > Subject: Re: 8217579: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is gone after > 8211883 > > Updated webrev: > http://cr.openjdk.java.net/~mullan/webrevs/8217579/webrev.01/ > > Comments inline ... > > On 1/28/19 2:54 PM, Bernd Eckenfels wrote: > > Hello Sean, > > > > Maybe you also want to change comment and name of the > SUPPORTE_DDEFAULT > > Array to ?SUPPORTED_LIMITED? since Unlimited is now Default? > > > > ??? private final static String[] ENABLED_DEFAULT > > > > ?. > > > > ???? // supported ciphersuites using default JCE policy jurisdiction files > > > > ???? // AES/256 unavailable > > > > ???? private final static String[] SUPPORTED_DEFAULT = { > > > > 230 ? remove ?Default > > Good point. I have renamed the *_UNLIMITED constants to *_DEFAULT and > renamed the *_DEFAULT constants to *_LIMITED. > > > Is the test already run with all available policies? With the new System > > property it should be easy to run it with other/vm twice? > > Good point. I have changed the test to use the crypto.policy security > property to test the suites with the default and limited policies. > > > Is Oracle considering pushing a emergency public update for this? > > We are planning to backport it to all affected releases. > > > The change Looks otherwise fine (I was first wondering if checking for a > > _SVCS Family makes more sense but I guess that can be done once we > have > > more of those ciphers. > > Ok, thanks for the review. > > --Sean > > > > > Gruss > > > > Bernd > > > > -- > > http://bernd.eckenfels.net > > > > *Von: *Sean Mullan > > *Gesendet: *Montag, 28. Januar 2019 20:26 > > *An: *security Dev OpenJDK > > *Betreff: *RFR: 8217579: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is gone > after > > 8211883 > > > > This fixes a regression introduced by the recent change to disable the > > > > TLS NULL cipher suites [1]. This accidentally also disabled the > > > > TLS_EMPTY_RENEGOTIATION_INFO_SCSV cipher suite because when the > name is > > > > decomposed by the algorithm constraints checking code it has NULL for > > > > its different parts (key exchange, etc). But this cipher suite is not > > > > negotiable and is only used for renegotiation purposes as defined in RFC > > > > 5746. It should not have been disabled. > > > > I also resurrected the CheckCipherSuites test which had an @ignore label > > > > on it. This is a good test because it checks what the expected > > > > enabled/supported suites should be, and will help catch issues like this > > > > in the future. > > > > webrev: > http://cr.openjdk.java.net/~mullan/webrevs/8217579/webrev.00/ > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8217579 > > > > Thanks, > > > > Sean > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8211883 > > From weijun.wang at oracle.com Tue Jan 29 01:02:46 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 29 Jan 2019 09:02:46 +0800 Subject: [12] RFR 8217690: Update public suffix version Message-ID: <2E42DF68-B0AC-4067-8C97-639C1D60DF62@oracle.com> Please review the change at https://cr.openjdk.java.net/~weijun/8217690/webrev.00/ Thanks, Max From sean.mullan at oracle.com Tue Jan 29 14:44:26 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 29 Jan 2019 09:44:26 -0500 Subject: [12] RFR 8217690: Update public suffix version In-Reply-To: <2E42DF68-B0AC-4067-8C97-639C1D60DF62@oracle.com> References: <2E42DF68-B0AC-4067-8C97-639C1D60DF62@oracle.com> Message-ID: You should also update the date in the VERSION file. --Sean On 1/28/19 8:02 PM, Weijun Wang wrote: > Please review the change at > > https://cr.openjdk.java.net/~weijun/8217690/webrev.00/ > > Thanks, > Max > From weijun.wang at oracle.com Tue Jan 29 15:05:27 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 29 Jan 2019 23:05:27 +0800 Subject: [12] RFR 8217690: Update public suffix version In-Reply-To: References: <2E42DF68-B0AC-4067-8C97-639C1D60DF62@oracle.com> Message-ID: <5CE529F7-7FD1-4E8A-B7A1-3BA3E6C21D68@oracle.com> -Date: 2018-05-24 +Date: 2019-01-28 Thanks, Max > On Jan 29, 2019, at 10:44 PM, Sean Mullan wrote: > > You should also update the date in the VERSION file. > > --Sean > > On 1/28/19 8:02 PM, Weijun Wang wrote: >> Please review the change at >> https://cr.openjdk.java.net/~weijun/8217690/webrev.00/ >> Thanks, >> Max From yozons at gmail.com Wed Jan 30 20:59:07 2019 From: yozons at gmail.com (Open eSignForms) Date: Wed, 30 Jan 2019 12:59:07 -0800 Subject: XML Digital Signature throws NAMESPACE_ERR exception under OpenJDK 11 that works under Java SE 8 Message-ID: My XML Digital Signature code runs fine under Java 8 (1.8.0_161), but on upgrading to OpenJDK 11 (11.0.2, ), it now traps with an NAMESPACE_ERR exception: org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces. at java.xml/com.sun.org.apache.xerces.internal.dom.ElementNSImpl.setName(ElementNSImpl.java:109) at java.xml/com.sun.org.apache.xerces.internal.dom.ElementNSImpl.(ElementNSImpl.java:84) at java.xml/com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.createElementNS(CoreDocumentImpl.java:2089) at java.xml.crypto/org.jcp.xml.dsig.internal.dom.XmlWriterToTree.writeStartElement(XmlWriterToTree.java:99) at java.xml.crypto/org.jcp.xml.dsig.internal.dom.Marshaller.marshalGenericNode(Marshaller.java:303) at java.xml.crypto/org.jcp.xml.dsig.internal.dom.Marshaller.marshalGenericNode(Marshaller.java:286) at java.xml.crypto/org.jcp.xml.dsig.internal.dom.Marshaller$14.marshalObject(Marshaller.java:251) at java.xml.crypto/org.jcp.xml.dsig.internal.dom.Marshaller$14.marshalObject(Marshaller.java:247) at java.xml.crypto/org.jcp.xml.dsig.internal.dom.XmlWriterToTree.marshalStructure(XmlWriterToTree.java:200) at java.xml.crypto/org.jcp.xml.dsig.internal.dom.DOMXMLObject.marshal(DOMXMLObject.java:180) at java.xml.crypto/org.jcp.xml.dsig.internal.dom.DOMXMLSignature.marshal(DOMXMLSignature.java:233) at java.xml.crypto/org.jcp.xml.dsig.internal.dom.DOMXMLSignature.sign(DOMXMLSignature.java:325) at com.esignforms.open.crypto.XmlDigitalSignature.sign(XmlDigitalSignature.java:208) If I revert back to Java 8, it works again. I noted that our XML digital signature code makes no direct references to namespaces. Basic code does set the DocumentBuildFactory to be namespace aware: DocumentBuilderFactory dbf = DocumentBuilderFactory.*newInstance*(); dbf.setNamespaceAware(*true*); When we sign under Java 8, this is the resulting digitally signed output for our XML element, which does have a namespace of our own: Date Doc 1

* * * T E S T T R A N S A C T I O N * * *

January 30, 2019

]]> 82PhK9E99GBG/pq5PSLRIGqpz0QbwwN8wlYQJsR3e4r5g1M8yhD3J0XhxNcMHmJIyyyb7yzo947O y2T9M/EHQw== zqVVsv0tdx1Fp/c1rrj5b7aKdVtwtq2u0R0RsUnwCja3aMXGjsfqA68lZawt5wCtZqLWsKllPUom Z5quVeBVBg== AKs1UqheswdoyC7xfofmnZoCOF8dmFISw0Cnqfp9n294EgvP5dnZAWWXH+yspvhnNr3qOJmcaP3N ZYoN6rG5XA== PzDq2Q3GpkgsnMmD//3bp5q+IksCxpR106yL1hx+WdxNvZWeAdT3SFAoHgLZtx4KL814iqLbiL5U kwwmI2q8DA== ID9zJVDWmIjJzv2TWdq3RjZ4MdF3+gX2LX2du7uRw0A2BJ7u8DAg33Wzlg0EnGNyOFC/P8obaegE xCaomRhZXqrLdCoyobe5zWxAFZ+cEHvUY4IwZKdf06i8UEgWiREdHTLfmqqbrhWrnXSnyFoSzAR3 pn4WssvP4LlJqoMPVQfHtO2aPJQpBBbnQe9wa8K0DgEpAy3ge6OwTtOZ48F27AweZPnFQOBhcmw4 Rfsri9CmZKUWI46RmLuSBv5uyxSwaZIX88uGPd4bG2zXcHd2VBxDyKblpGgIU+xcG+nxuSYNN8Y6 rs5o9/XoMM6T8x8LTdNWIgMRf11VhJ1bCh6uF8nEi/QYnV5GcRys/14a8J1oq7l/RNwEk1rMU1m/ VWDWhQT591S8hD4ZCVx7tokHdqtPg7hGHBbNdpcDYDKAhwRm3PJJBJ9XBHTgByrxnCqVk1W7D50f bSiITGvsOIp3ooX3wsq44zv/GVl6BamUPMLhgDq30YZmMNDobJsZxY+CoxQPINfv325R4solQ6s0 WXqg5RzHHjRTfTK6uNNX931iCb9o3HzKZhtyfZcLygUY69og0etvVpUXjMc2m590eUFUs14ekKwU hvB8rN0Qz+FVFH/jwR7AsNgDwE2KGaHEgypEOG5m3vLfLlJXP9ocGuCTp8IpOetx3GAndDFmizU= 021eddcd-ebd0-4603-8b26-24b3f7fee682 iSEKAXeyDOq1RKCwypjN5iuU2uR//YM4ssMBGBCtfpq7eF6pXm0rU5Zz4LnmoptUyu4IcnrStgRr JP3NPOeHgibR8i/Ef9frzd4rCwX2JpY3tztCGYByzk93ln7tzRYnMug9q0IVk6Far7JxBIuMy/eg LOyptCZGnRU8wV6D+gydsdoFsaR+zghMtBmoZ8sArGd81rzq28B3NDdqrd4camU7viI+5mMTRGJn UtBzU/4p7kxv2gePzUc2vJ76+8I1eUGbqc7Co12q8vS+wGpQ4a0lUiWJwj7BRXR21oPz+Qo5fiqb a/mSo0gv11s3T2oHTTzWSyvTPb2wbwyBSFAVVaoqJ0g01UEjU2Lv2RkTi/YZpyyPPUDh4OA1KMfX f3M7wxzS0+tJFfE4O4ELsaYlcRElVIor1y98LPKmqWgTg0olfU8H00igjbJdU37SzyqygqNadZlC ocTtaMvveNIkDURAPPZS/Llp1KUm4YY29m+Of0JK0ZoEBLIj5R0uEIpOBe0MWhH4d8l5mxn8IKpR chGgxgJ4P7bNpPQmPUH2rpFukV0NIPe946X7oJE/NubjePyQxpQwwE6zzavz0rf9s4OQpW7tdG/+ fyubGHXq4H/DH4ZZt0KBuIhLfqjEd3mgyzp4waihnkn4bhcRFm8s5UJEuszp6BkD0EHcPfN76Uk= AQAB MIIKkDCCCHigAwIBAgIIXjPAnc0XFeIwDQYJKoZIhvcNAQENBQAwgcIxOTA3BgNVBAMMME9wZW5f ZVNpZ25Gb3Jtc19odHRwczovL29wZW4uZXNpZ25mb3Jtcy5jb20vZGVtbzE6MDgGA1UECgwxRGVw bG95bWVudElEL2JiZmU5YmVkLTkxOGQtNDQ2Yi05NTE4LThlYzMwM2JhZmI4MzE8MDoGA1UECwwz U2lnbmF0dXJlS2V5SUQvMDIxZWRkY2QtZWJkMC00NjAzLThiMjYtMjRiM2Y3ZmVlNjgyMQswCQYD VQQGEwJVUzAeFw0xMTA0MTYwMzIxMzhaFw0yMTA0MTYwMzIxMzhaMIHCMTkwNwYDVQQDDDBPcGVu X2VTaWduRm9ybXNfaHR0cHM6Ly9vcGVuLmVzaWduZm9ybXMuY29tL2RlbW8xOjA4BgNVBAoMMURl cGxveW1lbnRJRC9iYmZlOWJlZC05MThkLTQ0NmItOTUxOC04ZWMzMDNiYWZiODMxPDA6BgNVBAsM M1NpZ25hdHVyZUtleUlELzAyMWVkZGNkLWViZDAtNDYwMy04YjI2LTI0YjNmN2ZlZTY4MjELMAkG A1UEBhMCVVMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCJIQoBd7IM6rVEoLDKmM3m K5Ta5H/9gziywwEYEK1+mrt4XqlebStTlnPgueaim1TK7ghyetK2BGsk/c0854eCJtHyL8R/1+vN 3isLBfYmlje3O0IZgHLOT3eWfu3NFicy6D2rQhWToVqvsnEEi4zL96As7Km0JkadFTzBXoP6DJ2x 2gWxpH7OCEy0GahnywCsZ3zWvOrbwHc0N2qt3hxqZTu+Ij7mYxNEYmdS0HNT/inuTG/aB4/NRza8 nvr7wjV5QZupzsKjXary9L7AalDhrSVSJYnCPsFFdHbWg/P5Cjl+Kptr+ZKjSC/XWzdPagdNPNZL K9M9vbBvDIFIUBVVqionSDTVQSNTYu/ZGROL9hmnLI89QOHg4DUox9d/czvDHNLT60kV8Tg7gQux piVxESVUiivXL3ws8qapaBODSiV9TwfTSKCNsl1TftLPKrKCo1p1mUKhxO1oy+940iQNREA89lL8 uWnUpSbhhjb2b45/QkrRmgQEsiPlHS4Qik4F7QxaEfh3yXmbGfwgqlFyEaDGAng/ts2k9CY9Qfau kW6RXQ0g973jpfugkT825uN4/JDGlDDATrPNq/PSt/2zg5Clbu10b/5/K5sYdergf8Mfhlm3QoG4 iEt+qMR3eaDLOnjBqKGeSfhuFxEWbyzlQkS6zOnoGQPQQdw983vpSQIDAQABo4IEhjCCBIIwggIz BgNVHQ4EggIqBIICJjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAIkhCgF3sgzqtUSg sMqYzeYrlNrkf/2DOLLDARgQrX6au3heqV5tK1OWc+C55qKbVMruCHJ60rYEayT9zTznh4Im0fIv xH/X683eKwsF9iaWN7c7QhmAcs5Pd5Z+7c0WJzLoPatCFZOhWq+ycQSLjMv3oCzsqbQmRp0VPMFe g/oMnbHaBbGkfs4ITLQZqGfLAKxnfNa86tvAdzQ3aq3eHGplO74iPuZjE0RiZ1LQc1P+Ke5Mb9oH j81HNrye+vvCNXlBm6nOwqNdqvL0vsBqUOGtJVIlicI+wUV0dtaD8/kKOX4qm2v5kqNIL9dbN09q B0081ksr0z29sG8MgUhQFVWqKidINNVBI1Ni79kZE4v2Gacsjz1A4eDgNSjH139zO8Mc0tPrSRXx ODuBC7GmJXERJVSKK9cvfCzypqloE4NKJX1PB9NIoI2yXVN+0s8qsoKjWnWZQqHE7WjL73jSJA1E QDz2Uvy5adSlJuGGNvZvjn9CStGaBASyI+UdLhCKTgXtDFoR+HfJeZsZ/CCqUXIRoMYCeD+2zaT0 Jj1B9q6RbpFdDSD3veOl+6CRPzbm43j8kMaUMMBOs82r89K3/bODkKVu7XRv/n8rmxh16uB/wx+G WbdCgbiIS36oxHd5oMs6eMGooZ5J+G4XERZvLOVCRLrM6egZA9BB3D3ze+lJAgMBAAEwggI3BgNV HSMEggIuMIICKoCCAiYwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCJIQoBd7IM6rVE oLDKmM3mK5Ta5H/9gziywwEYEK1+mrt4XqlebStTlnPgueaim1TK7ghyetK2BGsk/c0854eCJtHy L8R/1+vN3isLBfYmlje3O0IZgHLOT3eWfu3NFicy6D2rQhWToVqvsnEEi4zL96As7Km0JkadFTzB XoP6DJ2x2gWxpH7OCEy0GahnywCsZ3zWvOrbwHc0N2qt3hxqZTu+Ij7mYxNEYmdS0HNT/inuTG/a B4/NRza8nvr7wjV5QZupzsKjXary9L7AalDhrSVSJYnCPsFFdHbWg/P5Cjl+Kptr+ZKjSC/XWzdP agdNPNZLK9M9vbBvDIFIUBVVqionSDTVQSNTYu/ZGROL9hmnLI89QOHg4DUox9d/czvDHNLT60kV 8Tg7gQuxpiVxESVUiivXL3ws8qapaBODSiV9TwfTSKCNsl1TftLPKrKCo1p1mUKhxO1oy+940iQN REA89lL8uWnUpSbhhjb2b45/QkrRmgQEsiPlHS4Qik4F7QxaEfh3yXmbGfwgqlFyEaDGAng/ts2k 9CY9QfaukW6RXQ0g973jpfugkT825uN4/JDGlDDATrPNq/PSt/2zg5Clbu10b/5/K5sYdergf8Mf hlm3QoG4iEt+qMR3eaDLOnjBqKGeSfhuFxEWbyzlQkS6zOnoGQPQQdw983vpSQIDAQABMA4GA1Ud DwEB/wQEAwIGwDANBgkqhkiG9w0BAQ0FAAOCAgEAaGn/Q+1fjL7N675UYMGuC5EfloDQ3Y+zuYyx FtMrwO3GuvABTf+oKsQc5n7XDgpQVBWlgIHH+LldDhRPQ1a0MPvMzPDL3Ps1K+hJewNhcec6fqXS t+lszt+mnuK6gGKTioTbO6Li1E41WtJ1UhK4br1lsoNkM0E4rB5KUyj0ZmTCSlYlchAzMYLr1Ymc Q5wgAu0lFIpluhd12un9mUWWXouSC+8pI+ZKfPz2lm+PGBDTTp0TsLLWldvLcnEAgbLG4wZvb1za 3EccZWtCX0b5lGjMCajhADiz76GgYZt1fTus1fhoTe6GsJV9lM11NZTEeTPAUE9VvtNGYOaNUl2e S9pE1myNfiBgXNNJ3L4J6d6fGPlHV9rNPzjclfAOn4a1c+7ZBIsvW1znaeaAoeNyCcRPUr9rgKBS L+izvr6w3eYiqjQWozCi2Nw/oTKk1dC32uzD9KRrQ8pAlSDsspic7FJpFqPVuxrvs8z7tXpc6uyB cmaNZN91xowONrPljlbW2jm5AkebDyTMPfxIRcrTybOr/K3nOYEMkV8G/tRli4SRleGr3cUusHd5 47BlUSoncDYywh+4drtCycli2mfph3hjB34qkwbzI8j8iX6PSROH+AGcC0L1MEgRq2Um9+K3iTBA 9zGxY4cvR4vn4VtWcebg9AVMJCwhV85c7l0P0uU= 2019-01-30T12:40:46-08:00 document.html text/html -------------- next part -------------- An HTML attachment was scrubbed... URL: From yozons at gmail.com Wed Jan 30 21:37:53 2019 From: yozons at gmail.com (Yozons) Date: Wed, 30 Jan 2019 14:37:53 -0700 (MST) Subject: XML Digital Signature throws NAMESPACE_ERR exception under OpenJDK 11 that works under Java SE 8 In-Reply-To: References: Message-ID: <1548884273920-0.post@n7.nabble.com> A quick update if it helps. We were able to test under Java 10, and it also works fine. So the issue starts with OpenJDK 11. Works Java 8: java version "1.8.0_161" Java(TM) SE Runtime Environment (build 1.8.0_161-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode) Works Java 10: java version "10.0.2" 2018-07-17 Java(TM) SE Runtime Environment 18.3 (build 10.0.2+13) Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode) Broken on Java 11: openjdk version "11.0.2" 2019-01-15 OpenJDK Runtime Environment 18.9 (build 11.0.2+9) OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) -- Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-Security-Development-f69724.html From sean.mullan at oracle.com Wed Jan 30 21:54:45 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 30 Jan 2019 16:54:45 -0500 Subject: XML Digital Signature throws NAMESPACE_ERR exception under OpenJDK 11 that works under Java SE 8 In-Reply-To: References: Message-ID: Hi, Thanks for reporting the issue. Can you please file a bug at https://bugreport.java.com/bugreport/ so that it can be tracked and further evaluated? --Sean On 1/30/19 3:59 PM, Open eSignForms wrote: > > My XML Digital Signature code runs fine under Java 8 (1.8.0_161), but > on upgrading to OpenJDK 11 (11.0.2, ), it now traps with an > NAMESPACE_ERR exception: > > org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create > or change an object in a way which is incorrect with regard to namespaces. > > at > java.xml/com.sun.org.apache.xerces.internal.dom.ElementNSImpl.setName(ElementNSImpl.java:109) > > at > java.xml/com.sun.org.apache.xerces.internal.dom.ElementNSImpl.(ElementNSImpl.java:84) > > at > java.xml/com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.createElementNS(CoreDocumentImpl.java:2089) > > at > java.xml.crypto/org.jcp.xml.dsig.internal.dom.XmlWriterToTree.writeStartElement(XmlWriterToTree.java:99) > > at > java.xml.crypto/org.jcp.xml.dsig.internal.dom.Marshaller.marshalGenericNode(Marshaller.java:303) > > at > java.xml.crypto/org.jcp.xml.dsig.internal.dom.Marshaller.marshalGenericNode(Marshaller.java:286) > > at > java.xml.crypto/org.jcp.xml.dsig.internal.dom.Marshaller$14.marshalObject(Marshaller.java:251) > > at > java.xml.crypto/org.jcp.xml.dsig.internal.dom.Marshaller$14.marshalObject(Marshaller.java:247) > > at > java.xml.crypto/org.jcp.xml.dsig.internal.dom.XmlWriterToTree.marshalStructure(XmlWriterToTree.java:200) > > at > java.xml.crypto/org.jcp.xml.dsig.internal.dom.DOMXMLObject.marshal(DOMXMLObject.java:180) > > at > java.xml.crypto/org.jcp.xml.dsig.internal.dom.DOMXMLSignature.marshal(DOMXMLSignature.java:233) > > at > java.xml.crypto/org.jcp.xml.dsig.internal.dom.DOMXMLSignature.sign(DOMXMLSignature.java:325) > > at > com.esignforms.open.crypto.XmlDigitalSignature.sign(XmlDigitalSignature.java:208) > > If I revert back to Java 8, it works again. > > I noted that our XML digital signature code makes no direct references > to namespaces.? Basic code does set the DocumentBuildFactory to be > namespace aware: > > ? DocumentBuilderFactorydbf= DocumentBuilderFactory./newInstance/(); > > dbf.setNamespaceAware(*true*); > > When we sign under Java 8, this is the resulting digitally signed > output for our XML element, which does have a namespace of > our own: > > html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > > > > > > > > Date Doc 1 > > > > > > > > > > content="bbfe9bed-918d-446b-9518-8ec303bafb83" /> > > content="5163276c-d8aa-436f-8a96-5bc0c9eca931" /> > > content="d15a91a3-87b8-457e-84bc-0b56ac7ebb10" /> > > > > > > content="61afd6f3-b79e-4d14-844d-3a38541020ea" /> > > > > > > > > content="52248c28-187e-43f0-8de8-98357fa63654" /> > > content="62edfd59-be00-435a-9bd5-583cc84d220a" /> > > > > > > > > content="50-46-115-249.evrt.wa.frontiernet.net > (50.46.115.249)" /> > > > > > > > > > > > > > >
class="X86f339d5_81e2_4117_95c2_8f747f5a6fe3 pagediv"> > >
* * * ? T E S T ? T R A N S A C T I > O N ? * * *
> >
> >

class="labelAreaStacked"> >January 30, 2019

> >
> >
> > > > > > ]]>82PhK9E99GBG/pq5PSLRIGqpz0QbwwN8wlYQJsR3e4r5g1M8yhD3J0XhxNcMHmJIyyyb7yzo947O > > y2T9M/EHQw==zqVVsv0tdx1Fp/c1rrj5b7aKdVtwtq2u0R0RsUnwCja3aMXGjsfqA68lZawt5wCtZqLWsKllPUom > > Z5quVeBVBg==AKs1UqheswdoyC7xfofmnZoCOF8dmFISw0Cnqfp9n294EgvP5dnZAWWXH+yspvhnNr3qOJmcaP3N > > ZYoN6rG5XA==PzDq2Q3GpkgsnMmD//3bp5q+IksCxpR106yL1hx+WdxNvZWeAdT3SFAoHgLZtx4KL814iqLbiL5U > > kwwmI2q8DA==ID9zJVDWmIjJzv2TWdq3RjZ4MdF3+gX2LX2du7uRw0A2BJ7u8DAg33Wzlg0EnGNyOFC/P8obaegE > > xCaomRhZXqrLdCoyobe5zWxAFZ+cEHvUY4IwZKdf06i8UEgWiREdHTLfmqqbrhWrnXSnyFoSzAR3 > > pn4WssvP4LlJqoMPVQfHtO2aPJQpBBbnQe9wa8K0DgEpAy3ge6OwTtOZ48F27AweZPnFQOBhcmw4 > > Rfsri9CmZKUWI46RmLuSBv5uyxSwaZIX88uGPd4bG2zXcHd2VBxDyKblpGgIU+xcG+nxuSYNN8Y6 > > rs5o9/XoMM6T8x8LTdNWIgMRf11VhJ1bCh6uF8nEi/QYnV5GcRys/14a8J1oq7l/RNwEk1rMU1m/ > > VWDWhQT591S8hD4ZCVx7tokHdqtPg7hGHBbNdpcDYDKAhwRm3PJJBJ9XBHTgByrxnCqVk1W7D50f > > bSiITGvsOIp3ooX3wsq44zv/GVl6BamUPMLhgDq30YZmMNDobJsZxY+CoxQPINfv325R4solQ6s0 > > WXqg5RzHHjRTfTK6uNNX931iCb9o3HzKZhtyfZcLygUY69og0etvVpUXjMc2m590eUFUs14ekKwU > > hvB8rN0Qz+FVFH/jwR7AsNgDwE2KGaHEgypEOG5m3vLfLlJXP9ocGuCTp8IpOetx3GAndDFmizU=021eddcd-ebd0-4603-8b26-24b3f7fee682iSEKAXeyDOq1RKCwypjN5iuU2uR//YM4ssMBGBCtfpq7eF6pXm0rU5Zz4LnmoptUyu4IcnrStgRr > > JP3NPOeHgibR8i/Ef9frzd4rCwX2JpY3tztCGYByzk93ln7tzRYnMug9q0IVk6Far7JxBIuMy/eg > > LOyptCZGnRU8wV6D+gydsdoFsaR+zghMtBmoZ8sArGd81rzq28B3NDdqrd4camU7viI+5mMTRGJn > > UtBzU/4p7kxv2gePzUc2vJ76+8I1eUGbqc7Co12q8vS+wGpQ4a0lUiWJwj7BRXR21oPz+Qo5fiqb > > a/mSo0gv11s3T2oHTTzWSyvTPb2wbwyBSFAVVaoqJ0g01UEjU2Lv2RkTi/YZpyyPPUDh4OA1KMfX > > f3M7wxzS0+tJFfE4O4ELsaYlcRElVIor1y98LPKmqWgTg0olfU8H00igjbJdU37SzyqygqNadZlC > > ocTtaMvveNIkDURAPPZS/Llp1KUm4YY29m+Of0JK0ZoEBLIj5R0uEIpOBe0MWhH4d8l5mxn8IKpR > > chGgxgJ4P7bNpPQmPUH2rpFukV0NIPe946X7oJE/NubjePyQxpQwwE6zzavz0rf9s4OQpW7tdG/+ > > fyubGHXq4H/DH4ZZt0KBuIhLfqjEd3mgyzp4waihnkn4bhcRFm8s5UJEuszp6BkD0EHcPfN76Uk=AQABMIIKkDCCCHigAwIBAgIIXjPAnc0XFeIwDQYJKoZIhvcNAQENBQAwgcIxOTA3BgNVBAMMME9wZW5f > > ZVNpZ25Gb3Jtc19odHRwczovL29wZW4uZXNpZ25mb3Jtcy5jb20vZGVtbzE6MDgGA1UECgwxRGVw > > bG95bWVudElEL2JiZmU5YmVkLTkxOGQtNDQ2Yi05NTE4LThlYzMwM2JhZmI4MzE8MDoGA1UECwwz > > U2lnbmF0dXJlS2V5SUQvMDIxZWRkY2QtZWJkMC00NjAzLThiMjYtMjRiM2Y3ZmVlNjgyMQswCQYD > > VQQGEwJVUzAeFw0xMTA0MTYwMzIxMzhaFw0yMTA0MTYwMzIxMzhaMIHCMTkwNwYDVQQDDDBPcGVu > > X2VTaWduRm9ybXNfaHR0cHM6Ly9vcGVuLmVzaWduZm9ybXMuY29tL2RlbW8xOjA4BgNVBAoMMURl > > cGxveW1lbnRJRC9iYmZlOWJlZC05MThkLTQ0NmItOTUxOC04ZWMzMDNiYWZiODMxPDA6BgNVBAsM > > M1NpZ25hdHVyZUtleUlELzAyMWVkZGNkLWViZDAtNDYwMy04YjI2LTI0YjNmN2ZlZTY4MjELMAkG > > A1UEBhMCVVMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCJIQoBd7IM6rVEoLDKmM3m > > K5Ta5H/9gziywwEYEK1+mrt4XqlebStTlnPgueaim1TK7ghyetK2BGsk/c0854eCJtHyL8R/1+vN > > 3isLBfYmlje3O0IZgHLOT3eWfu3NFicy6D2rQhWToVqvsnEEi4zL96As7Km0JkadFTzBXoP6DJ2x > > 2gWxpH7OCEy0GahnywCsZ3zWvOrbwHc0N2qt3hxqZTu+Ij7mYxNEYmdS0HNT/inuTG/aB4/NRza8 > > nvr7wjV5QZupzsKjXary9L7AalDhrSVSJYnCPsFFdHbWg/P5Cjl+Kptr+ZKjSC/XWzdPagdNPNZL > > K9M9vbBvDIFIUBVVqionSDTVQSNTYu/ZGROL9hmnLI89QOHg4DUox9d/czvDHNLT60kV8Tg7gQux > > piVxESVUiivXL3ws8qapaBODSiV9TwfTSKCNsl1TftLPKrKCo1p1mUKhxO1oy+940iQNREA89lL8 > > uWnUpSbhhjb2b45/QkrRmgQEsiPlHS4Qik4F7QxaEfh3yXmbGfwgqlFyEaDGAng/ts2k9CY9Qfau > > kW6RXQ0g973jpfugkT825uN4/JDGlDDATrPNq/PSt/2zg5Clbu10b/5/K5sYdergf8Mfhlm3QoG4 > > iEt+qMR3eaDLOnjBqKGeSfhuFxEWbyzlQkS6zOnoGQPQQdw983vpSQIDAQABo4IEhjCCBIIwggIz > > BgNVHQ4EggIqBIICJjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAIkhCgF3sgzqtUSg > > sMqYzeYrlNrkf/2DOLLDARgQrX6au3heqV5tK1OWc+C55qKbVMruCHJ60rYEayT9zTznh4Im0fIv > > xH/X683eKwsF9iaWN7c7QhmAcs5Pd5Z+7c0WJzLoPatCFZOhWq+ycQSLjMv3oCzsqbQmRp0VPMFe > > g/oMnbHaBbGkfs4ITLQZqGfLAKxnfNa86tvAdzQ3aq3eHGplO74iPuZjE0RiZ1LQc1P+Ke5Mb9oH > > j81HNrye+vvCNXlBm6nOwqNdqvL0vsBqUOGtJVIlicI+wUV0dtaD8/kKOX4qm2v5kqNIL9dbN09q > > B0081ksr0z29sG8MgUhQFVWqKidINNVBI1Ni79kZE4v2Gacsjz1A4eDgNSjH139zO8Mc0tPrSRXx > > ODuBC7GmJXERJVSKK9cvfCzypqloE4NKJX1PB9NIoI2yXVN+0s8qsoKjWnWZQqHE7WjL73jSJA1E > > QDz2Uvy5adSlJuGGNvZvjn9CStGaBASyI+UdLhCKTgXtDFoR+HfJeZsZ/CCqUXIRoMYCeD+2zaT0 > > Jj1B9q6RbpFdDSD3veOl+6CRPzbm43j8kMaUMMBOs82r89K3/bODkKVu7XRv/n8rmxh16uB/wx+G > > WbdCgbiIS36oxHd5oMs6eMGooZ5J+G4XERZvLOVCRLrM6egZA9BB3D3ze+lJAgMBAAEwggI3BgNV > > HSMEggIuMIICKoCCAiYwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCJIQoBd7IM6rVE > > oLDKmM3mK5Ta5H/9gziywwEYEK1+mrt4XqlebStTlnPgueaim1TK7ghyetK2BGsk/c0854eCJtHy > > L8R/1+vN3isLBfYmlje3O0IZgHLOT3eWfu3NFicy6D2rQhWToVqvsnEEi4zL96As7Km0JkadFTzB > > XoP6DJ2x2gWxpH7OCEy0GahnywCsZ3zWvOrbwHc0N2qt3hxqZTu+Ij7mYxNEYmdS0HNT/inuTG/a > > B4/NRza8nvr7wjV5QZupzsKjXary9L7AalDhrSVSJYnCPsFFdHbWg/P5Cjl+Kptr+ZKjSC/XWzdP > > agdNPNZLK9M9vbBvDIFIUBVVqionSDTVQSNTYu/ZGROL9hmnLI89QOHg4DUox9d/czvDHNLT60kV > > 8Tg7gQuxpiVxESVUiivXL3ws8qapaBODSiV9TwfTSKCNsl1TftLPKrKCo1p1mUKhxO1oy+940iQN > > REA89lL8uWnUpSbhhjb2b45/QkrRmgQEsiPlHS4Qik4F7QxaEfh3yXmbGfwgqlFyEaDGAng/ts2k > > 9CY9QfaukW6RXQ0g973jpfugkT825uN4/JDGlDDATrPNq/PSt/2zg5Clbu10b/5/K5sYdergf8Mf > > hlm3QoG4iEt+qMR3eaDLOnjBqKGeSfhuFxEWbyzlQkS6zOnoGQPQQdw983vpSQIDAQABMA4GA1Ud > > DwEB/wQEAwIGwDANBgkqhkiG9w0BAQ0FAAOCAgEAaGn/Q+1fjL7N675UYMGuC5EfloDQ3Y+zuYyx > > FtMrwO3GuvABTf+oKsQc5n7XDgpQVBWlgIHH+LldDhRPQ1a0MPvMzPDL3Ps1K+hJewNhcec6fqXS > > t+lszt+mnuK6gGKTioTbO6Li1E41WtJ1UhK4br1lsoNkM0E4rB5KUyj0ZmTCSlYlchAzMYLr1Ymc > > Q5wgAu0lFIpluhd12un9mUWWXouSC+8pI+ZKfPz2lm+PGBDTTp0TsLLWldvLcnEAgbLG4wZvb1za > > 3EccZWtCX0b5lGjMCajhADiz76GgYZt1fTus1fhoTe6GsJV9lM11NZTEeTPAUE9VvtNGYOaNUl2e > > S9pE1myNfiBgXNNJ3L4J6d6fGPlHV9rNPzjclfAOn4a1c+7ZBIsvW1znaeaAoeNyCcRPUr9rgKBS > > L+izvr6w3eYiqjQWozCi2Nw/oTKk1dC32uzD9KRrQ8pAlSDsspic7FJpFqPVuxrvs8z7tXpc6uyB > > cmaNZN91xowONrPljlbW2jm5AkebDyTMPfxIRcrTybOr/K3nOYEMkV8G/tRli4SRleGr3cUusHd5 > > 47BlUSoncDYywh+4drtCycli2mfph3hjB34qkwbzI8j8iX6PSROH+AGcC0L1MEgRq2Um9+K3iTBA > > 9zGxY4cvR4vn4VtWcebg9AVMJCwhV85c7l0P0uU=2019-01-30T12:40:46-08:00document.htmltext/html "DeploymentId="bbfe9bed-918d-446b-9518-8ec303bafb83"SignerAddress="50-46-115-249.evrt.wa.frontiernet.net > > (50.46.115.249)"SignerAgent="Mozilla/5.0 (Macintosh; Intel Mac OS X > 10_14_3) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.3 > Safari/605.1.15"Timestamp="2019-01-30T12:40:46-08:00"Version="19.1.19_p0129_1657"/> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yozons at gmail.com Wed Jan 30 22:03:50 2019 From: yozons at gmail.com (Open eSignForms) Date: Wed, 30 Jan 2019 14:03:50 -0800 Subject: XML Digital Signature throws NAMESPACE_ERR exception under OpenJDK 11 that works under Java SE 8 In-Reply-To: References: Message-ID: Created internal review id: 9059185 I have our source code, but it's part of a large suite of code (all can be accessed under the AGPL), so it's not clear what all would help in the report. If you need anything more, I'd be happy to share that so it can be part of the bug report. On Wed, Jan 30, 2019 at 1:54 PM Sean Mullan wrote: > Hi, > > Thanks for reporting the issue. Can you please file a bug at > https://bugreport.java.com/bugreport/ so that it can be tracked and > further evaluated? > > --Sean > > On 1/30/19 3:59 PM, Open eSignForms wrote: > > My XML Digital Signature code runs fine under Java 8 (1.8.0_161), but on > upgrading to OpenJDK 11 (11.0.2, ), it now traps with an NAMESPACE_ERR > exception: > > > > org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or > change an object in a way which is incorrect with regard to namespaces. > > at > java.xml/com.sun.org.apache.xerces.internal.dom.ElementNSImpl.setName(ElementNSImpl.java:109) > > at > java.xml/com.sun.org.apache.xerces.internal.dom.ElementNSImpl.(ElementNSImpl.java:84) > > at > java.xml/com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.createElementNS(CoreDocumentImpl.java:2089) > > at > java.xml.crypto/org.jcp.xml.dsig.internal.dom.XmlWriterToTree.writeStartElement(XmlWriterToTree.java:99) > > at > java.xml.crypto/org.jcp.xml.dsig.internal.dom.Marshaller.marshalGenericNode(Marshaller.java:303) > > at > java.xml.crypto/org.jcp.xml.dsig.internal.dom.Marshaller.marshalGenericNode(Marshaller.java:286) > > at > java.xml.crypto/org.jcp.xml.dsig.internal.dom.Marshaller$14.marshalObject(Marshaller.java:251) > > at > java.xml.crypto/org.jcp.xml.dsig.internal.dom.Marshaller$14.marshalObject(Marshaller.java:247) > > at > java.xml.crypto/org.jcp.xml.dsig.internal.dom.XmlWriterToTree.marshalStructure(XmlWriterToTree.java:200) > > at > java.xml.crypto/org.jcp.xml.dsig.internal.dom.DOMXMLObject.marshal(DOMXMLObject.java:180) > > at > java.xml.crypto/org.jcp.xml.dsig.internal.dom.DOMXMLSignature.marshal(DOMXMLSignature.java:233) > > at > java.xml.crypto/org.jcp.xml.dsig.internal.dom.DOMXMLSignature.sign(DOMXMLSignature.java:325) > > at > com.esignforms.open.crypto.XmlDigitalSignature.sign(XmlDigitalSignature.java:208) > > > > If I revert back to Java 8, it works again. > > I noted that our XML digital signature code makes no direct references to > namespaces. Basic code does set the DocumentBuildFactory to be namespace > aware: > > > > DocumentBuilderFactory dbf = DocumentBuilderFactory.*newInstance*(); > > dbf.setNamespaceAware(*true*); > > > > When we sign under Java 8, this is the resulting digitally signed output > for our XML element, which does have a namespace of our own: > > > > "2019-01-30T12:40:46-08:00" type="document"> PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " > http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > > > > > > > > Date Doc 1 > > > > > > > > > > > > /> > > content="d15a91a3-87b8-457e-84bc-0b56ac7ebb10" /> > > > > > > content="61afd6f3-b79e-4d14-844d-3a38541020ea" /> > > > > > > > > content="52248c28-187e-43f0-8de8-98357fa63654" /> > > content="62edfd59-be00-435a-9bd5-583cc84d220a" /> > > > > > > > > > > > > > > > > > > > > > >
class="X86f339d5_81e2_4117_95c2_8f747f5a6fe3 pagediv"> > >
* * * T E S T T R A N S A C T I O N > * * *
> > > > > > > >
> > > >

class="labelAreaStacked">January > 30, 2019

> > > >
> > > > > > > >
> > > > > > ]]> "OpenESignForms_Seal"> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/> Id="Payload_Reference_ID" URI=""> /> > 82PhK9E99GBG/pq5PSLRIGqpz0QbwwN8wlYQJsR3e4r5g1M8yhD3J0XhxNcMHmJIyyyb7yzo947O > > y2T9M/EHQw== > /> > zqVVsv0tdx1Fp/c1rrj5b7aKdVtwtq2u0R0RsUnwCja3aMXGjsfqA68lZawt5wCtZqLWsKllPUom > > Z5quVeBVBg== "#QualifyingProperties_ID"> > AKs1UqheswdoyC7xfofmnZoCOF8dmFISw0Cnqfp9n294EgvP5dnZAWWXH+yspvhnNr3qOJmcaP3N > > ZYoN6rG5XA== "#OpenESignForms_Seal_ID"> > PzDq2Q3GpkgsnMmD//3bp5q+IksCxpR106yL1hx+WdxNvZWeAdT3SFAoHgLZtx4KL814iqLbiL5U > > kwwmI2q8DA== > ID9zJVDWmIjJzv2TWdq3RjZ4MdF3+gX2LX2du7uRw0A2BJ7u8DAg33Wzlg0EnGNyOFC/P8obaegE > > > xCaomRhZXqrLdCoyobe5zWxAFZ+cEHvUY4IwZKdf06i8UEgWiREdHTLfmqqbrhWrnXSnyFoSzAR3 > > > pn4WssvP4LlJqoMPVQfHtO2aPJQpBBbnQe9wa8K0DgEpAy3ge6OwTtOZ48F27AweZPnFQOBhcmw4 > > > Rfsri9CmZKUWI46RmLuSBv5uyxSwaZIX88uGPd4bG2zXcHd2VBxDyKblpGgIU+xcG+nxuSYNN8Y6 > > > rs5o9/XoMM6T8x8LTdNWIgMRf11VhJ1bCh6uF8nEi/QYnV5GcRys/14a8J1oq7l/RNwEk1rMU1m/ > > > VWDWhQT591S8hD4ZCVx7tokHdqtPg7hGHBbNdpcDYDKAhwRm3PJJBJ9XBHTgByrxnCqVk1W7D50f > > > bSiITGvsOIp3ooX3wsq44zv/GVl6BamUPMLhgDq30YZmMNDobJsZxY+CoxQPINfv325R4solQ6s0 > > > WXqg5RzHHjRTfTK6uNNX931iCb9o3HzKZhtyfZcLygUY69og0etvVpUXjMc2m590eUFUs14ekKwU > > > hvB8rN0Qz+FVFH/jwR7AsNgDwE2KGaHEgypEOG5m3vLfLlJXP9ocGuCTp8IpOetx3GAndDFmizU= > > 021eddcd-ebd0-4603-8b26-24b3f7fee682 > > iSEKAXeyDOq1RKCwypjN5iuU2uR//YM4ssMBGBCtfpq7eF6pXm0rU5Zz4LnmoptUyu4IcnrStgRr > > > JP3NPOeHgibR8i/Ef9frzd4rCwX2JpY3tztCGYByzk93ln7tzRYnMug9q0IVk6Far7JxBIuMy/eg > > > LOyptCZGnRU8wV6D+gydsdoFsaR+zghMtBmoZ8sArGd81rzq28B3NDdqrd4camU7viI+5mMTRGJn > > > UtBzU/4p7kxv2gePzUc2vJ76+8I1eUGbqc7Co12q8vS+wGpQ4a0lUiWJwj7BRXR21oPz+Qo5fiqb > > > a/mSo0gv11s3T2oHTTzWSyvTPb2wbwyBSFAVVaoqJ0g01UEjU2Lv2RkTi/YZpyyPPUDh4OA1KMfX > > > f3M7wxzS0+tJFfE4O4ELsaYlcRElVIor1y98LPKmqWgTg0olfU8H00igjbJdU37SzyqygqNadZlC > > > ocTtaMvveNIkDURAPPZS/Llp1KUm4YY29m+Of0JK0ZoEBLIj5R0uEIpOBe0MWhH4d8l5mxn8IKpR > > > chGgxgJ4P7bNpPQmPUH2rpFukV0NIPe946X7oJE/NubjePyQxpQwwE6zzavz0rf9s4OQpW7tdG/+ > > > fyubGHXq4H/DH4ZZt0KBuIhLfqjEd3mgyzp4waihnkn4bhcRFm8s5UJEuszp6BkD0EHcPfN76Uk= > AQAB > > MIIKkDCCCHigAwIBAgIIXjPAnc0XFeIwDQYJKoZIhvcNAQENBQAwgcIxOTA3BgNVBAMMME9wZW5f > > > ZVNpZ25Gb3Jtc19odHRwczovL29wZW4uZXNpZ25mb3Jtcy5jb20vZGVtbzE6MDgGA1UECgwxRGVw > > > bG95bWVudElEL2JiZmU5YmVkLTkxOGQtNDQ2Yi05NTE4LThlYzMwM2JhZmI4MzE8MDoGA1UECwwz > > > U2lnbmF0dXJlS2V5SUQvMDIxZWRkY2QtZWJkMC00NjAzLThiMjYtMjRiM2Y3ZmVlNjgyMQswCQYD > > > VQQGEwJVUzAeFw0xMTA0MTYwMzIxMzhaFw0yMTA0MTYwMzIxMzhaMIHCMTkwNwYDVQQDDDBPcGVu > > > X2VTaWduRm9ybXNfaHR0cHM6Ly9vcGVuLmVzaWduZm9ybXMuY29tL2RlbW8xOjA4BgNVBAoMMURl > > > cGxveW1lbnRJRC9iYmZlOWJlZC05MThkLTQ0NmItOTUxOC04ZWMzMDNiYWZiODMxPDA6BgNVBAsM > > > M1NpZ25hdHVyZUtleUlELzAyMWVkZGNkLWViZDAtNDYwMy04YjI2LTI0YjNmN2ZlZTY4MjELMAkG > > > A1UEBhMCVVMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCJIQoBd7IM6rVEoLDKmM3m > > > K5Ta5H/9gziywwEYEK1+mrt4XqlebStTlnPgueaim1TK7ghyetK2BGsk/c0854eCJtHyL8R/1+vN > > > 3isLBfYmlje3O0IZgHLOT3eWfu3NFicy6D2rQhWToVqvsnEEi4zL96As7Km0JkadFTzBXoP6DJ2x > > > 2gWxpH7OCEy0GahnywCsZ3zWvOrbwHc0N2qt3hxqZTu+Ij7mYxNEYmdS0HNT/inuTG/aB4/NRza8 > > > nvr7wjV5QZupzsKjXary9L7AalDhrSVSJYnCPsFFdHbWg/P5Cjl+Kptr+ZKjSC/XWzdPagdNPNZL > > > K9M9vbBvDIFIUBVVqionSDTVQSNTYu/ZGROL9hmnLI89QOHg4DUox9d/czvDHNLT60kV8Tg7gQux > > > piVxESVUiivXL3ws8qapaBODSiV9TwfTSKCNsl1TftLPKrKCo1p1mUKhxO1oy+940iQNREA89lL8 > > > uWnUpSbhhjb2b45/QkrRmgQEsiPlHS4Qik4F7QxaEfh3yXmbGfwgqlFyEaDGAng/ts2k9CY9Qfau > > > kW6RXQ0g973jpfugkT825uN4/JDGlDDATrPNq/PSt/2zg5Clbu10b/5/K5sYdergf8Mfhlm3QoG4 > > > iEt+qMR3eaDLOnjBqKGeSfhuFxEWbyzlQkS6zOnoGQPQQdw983vpSQIDAQABo4IEhjCCBIIwggIz > > > BgNVHQ4EggIqBIICJjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAIkhCgF3sgzqtUSg > > > sMqYzeYrlNrkf/2DOLLDARgQrX6au3heqV5tK1OWc+C55qKbVMruCHJ60rYEayT9zTznh4Im0fIv > > > xH/X683eKwsF9iaWN7c7QhmAcs5Pd5Z+7c0WJzLoPatCFZOhWq+ycQSLjMv3oCzsqbQmRp0VPMFe > > > g/oMnbHaBbGkfs4ITLQZqGfLAKxnfNa86tvAdzQ3aq3eHGplO74iPuZjE0RiZ1LQc1P+Ke5Mb9oH > > > j81HNrye+vvCNXlBm6nOwqNdqvL0vsBqUOGtJVIlicI+wUV0dtaD8/kKOX4qm2v5kqNIL9dbN09q > > > B0081ksr0z29sG8MgUhQFVWqKidINNVBI1Ni79kZE4v2Gacsjz1A4eDgNSjH139zO8Mc0tPrSRXx > > > ODuBC7GmJXERJVSKK9cvfCzypqloE4NKJX1PB9NIoI2yXVN+0s8qsoKjWnWZQqHE7WjL73jSJA1E > > > QDz2Uvy5adSlJuGGNvZvjn9CStGaBASyI+UdLhCKTgXtDFoR+HfJeZsZ/CCqUXIRoMYCeD+2zaT0 > > > Jj1B9q6RbpFdDSD3veOl+6CRPzbm43j8kMaUMMBOs82r89K3/bODkKVu7XRv/n8rmxh16uB/wx+G > > > WbdCgbiIS36oxHd5oMs6eMGooZ5J+G4XERZvLOVCRLrM6egZA9BB3D3ze+lJAgMBAAEwggI3BgNV > > > HSMEggIuMIICKoCCAiYwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCJIQoBd7IM6rVE > > > oLDKmM3mK5Ta5H/9gziywwEYEK1+mrt4XqlebStTlnPgueaim1TK7ghyetK2BGsk/c0854eCJtHy > > > L8R/1+vN3isLBfYmlje3O0IZgHLOT3eWfu3NFicy6D2rQhWToVqvsnEEi4zL96As7Km0JkadFTzB > > > XoP6DJ2x2gWxpH7OCEy0GahnywCsZ3zWvOrbwHc0N2qt3hxqZTu+Ij7mYxNEYmdS0HNT/inuTG/a > > > B4/NRza8nvr7wjV5QZupzsKjXary9L7AalDhrSVSJYnCPsFFdHbWg/P5Cjl+Kptr+ZKjSC/XWzdP > > > agdNPNZLK9M9vbBvDIFIUBVVqionSDTVQSNTYu/ZGROL9hmnLI89QOHg4DUox9d/czvDHNLT60kV > > > 8Tg7gQuxpiVxESVUiivXL3ws8qapaBODSiV9TwfTSKCNsl1TftLPKrKCo1p1mUKhxO1oy+940iQN > > > REA89lL8uWnUpSbhhjb2b45/QkrRmgQEsiPlHS4Qik4F7QxaEfh3yXmbGfwgqlFyEaDGAng/ts2k > > > 9CY9QfaukW6RXQ0g973jpfugkT825uN4/JDGlDDATrPNq/PSt/2zg5Clbu10b/5/K5sYdergf8Mf > > > hlm3QoG4iEt+qMR3eaDLOnjBqKGeSfhuFxEWbyzlQkS6zOnoGQPQQdw983vpSQIDAQABMA4GA1Ud > > > DwEB/wQEAwIGwDANBgkqhkiG9w0BAQ0FAAOCAgEAaGn/Q+1fjL7N675UYMGuC5EfloDQ3Y+zuYyx > > > FtMrwO3GuvABTf+oKsQc5n7XDgpQVBWlgIHH+LldDhRPQ1a0MPvMzPDL3Ps1K+hJewNhcec6fqXS > > > t+lszt+mnuK6gGKTioTbO6Li1E41WtJ1UhK4br1lsoNkM0E4rB5KUyj0ZmTCSlYlchAzMYLr1Ymc > > > Q5wgAu0lFIpluhd12un9mUWWXouSC+8pI+ZKfPz2lm+PGBDTTp0TsLLWldvLcnEAgbLG4wZvb1za > > > 3EccZWtCX0b5lGjMCajhADiz76GgYZt1fTus1fhoTe6GsJV9lM11NZTEeTPAUE9VvtNGYOaNUl2e > > > S9pE1myNfiBgXNNJ3L4J6d6fGPlHV9rNPzjclfAOn4a1c+7ZBIsvW1znaeaAoeNyCcRPUr9rgKBS > > > L+izvr6w3eYiqjQWozCi2Nw/oTKk1dC32uzD9KRrQ8pAlSDsspic7FJpFqPVuxrvs8z7tXpc6uyB > > > cmaNZN91xowONrPljlbW2jm5AkebDyTMPfxIRcrTybOr/K3nOYEMkV8G/tRli4SRleGr3cUusHd5 > > > 47BlUSoncDYywh+4drtCycli2mfph3hjB34qkwbzI8j8iX6PSROH+AGcC0L1MEgRq2Um9+K3iTBA > > 9zGxY4cvR4vn4VtWcebg9AVMJCwhV85c7l0P0uU= > "QualifyingProperties_ID" > > > 2019-01-30T12:40:46-08:00 > ObjectReference="#Payload_Reference_ID">document.html > text/html > Id="OpenESignForms_Seal_ID" Target="#OpenESignForms_Seal" > > "104.239.136.116"DeploymentHostName="open.esignforms.com" DeploymentId= > "bbfe9bed-918d-446b-9518-8ec303bafb83" SignerAddress=" > 50-46-115-249.evrt.wa.frontiernet.net (50.46.115.249)" SignerAgent="Mozilla/5.0 > (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/605.1.15 (KHTML, like > Gecko) Version/12.0.3 Safari/605.1.15" Timestamp= > "2019-01-30T12:40:46-08:00" Version="19.1.19_p0129_1657" > /> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yozons at gmail.com Thu Jan 31 00:18:56 2019 From: yozons at gmail.com (Open eSignForms) Date: Wed, 30 Jan 2019 16:18:56 -0800 Subject: XML Digital Signature throws NAMESPACE_ERR exception under OpenJDK 11 that works under Java SE 8 In-Reply-To: References: Message-ID: The last bit we've discovered is that under OpenJDK 11, it appears that the XML digitally signed documents are verified fine; it's just creating new digitally signed that throws the NAMESPACE_ERR issue. When we retrieve XML digitally signed documents, we verify that the signature is valid, and that code appears to work and find the prior signature to be valid. On Wed, Jan 30, 2019 at 2:03 PM Open eSignForms wrote: > Created internal review id: 9059185 > I have our source code, but it's part of a large suite of code (all can be > accessed under the AGPL), so it's not clear what all would help in the > report. If you need anything more, I'd be happy to share that so it can be > part of the bug report. > > On Wed, Jan 30, 2019 at 1:54 PM Sean Mullan > wrote: > >> Hi, >> >> Thanks for reporting the issue. Can you please file a bug at >> https://bugreport.java.com/bugreport/ so that it can be tracked and >> further evaluated? >> >> --Sean >> >> On 1/30/19 3:59 PM, Open eSignForms wrote: >> >> My XML Digital Signature code runs fine under Java 8 (1.8.0_161), but on >> upgrading to OpenJDK 11 (11.0.2, ), it now traps with an NAMESPACE_ERR >> exception: >> >> >> >> org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or >> change an object in a way which is incorrect with regard to namespaces. >> >> at >> java.xml/com.sun.org.apache.xerces.internal.dom.ElementNSImpl.setName(ElementNSImpl.java:109) >> >> at >> java.xml/com.sun.org.apache.xerces.internal.dom.ElementNSImpl.(ElementNSImpl.java:84) >> >> at >> java.xml/com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.createElementNS(CoreDocumentImpl.java:2089) >> >> at >> java.xml.crypto/org.jcp.xml.dsig.internal.dom.XmlWriterToTree.writeStartElement(XmlWriterToTree.java:99) >> >> at >> java.xml.crypto/org.jcp.xml.dsig.internal.dom.Marshaller.marshalGenericNode(Marshaller.java:303) >> >> at >> java.xml.crypto/org.jcp.xml.dsig.internal.dom.Marshaller.marshalGenericNode(Marshaller.java:286) >> >> at >> java.xml.crypto/org.jcp.xml.dsig.internal.dom.Marshaller$14.marshalObject(Marshaller.java:251) >> >> at >> java.xml.crypto/org.jcp.xml.dsig.internal.dom.Marshaller$14.marshalObject(Marshaller.java:247) >> >> at >> java.xml.crypto/org.jcp.xml.dsig.internal.dom.XmlWriterToTree.marshalStructure(XmlWriterToTree.java:200) >> >> at >> java.xml.crypto/org.jcp.xml.dsig.internal.dom.DOMXMLObject.marshal(DOMXMLObject.java:180) >> >> at >> java.xml.crypto/org.jcp.xml.dsig.internal.dom.DOMXMLSignature.marshal(DOMXMLSignature.java:233) >> >> at >> java.xml.crypto/org.jcp.xml.dsig.internal.dom.DOMXMLSignature.sign(DOMXMLSignature.java:325) >> >> at >> com.esignforms.open.crypto.XmlDigitalSignature.sign(XmlDigitalSignature.java:208) >> >> >> >> If I revert back to Java 8, it works again. >> >> I noted that our XML digital signature code makes no direct references to >> namespaces. Basic code does set the DocumentBuildFactory to be namespace >> aware: >> >> >> >> DocumentBuilderFactory dbf = DocumentBuilderFactory.*newInstance*(); >> >> dbf.setNamespaceAware(*true*); >> >> >> >> When we sign under Java 8, this is the resulting digitally signed output >> for our XML element, which does have a namespace of our own: >> >> >> >> > "2019-01-30T12:40:46-08:00" type="document">> PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " >> http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> >> >> >> >> >> >> >> >> Date Doc 1 >> >> >> >> >> >> >> >> >> >> > /> >> >> > /> >> >> > content="d15a91a3-87b8-457e-84bc-0b56ac7ebb10" /> >> >> >> >> >> >> > content="61afd6f3-b79e-4d14-844d-3a38541020ea" /> >> >> >> >> >> >> >> >> > content="52248c28-187e-43f0-8de8-98357fa63654" /> >> >> > content="62edfd59-be00-435a-9bd5-583cc84d220a" /> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>
> class="X86f339d5_81e2_4117_95c2_8f747f5a6fe3 pagediv"> >> >>
* * * T E S T T R A N S A C T I O N >> * * *
>> >> >> >> >> >> >> >>
>> >> >> >>

> class="labelAreaStacked">January >> 30, 2019

>> >> >> >>
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> ]]>> "OpenESignForms_Seal">> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/>> Id="Payload_Reference_ID" URI="">> /> >> 82PhK9E99GBG/pq5PSLRIGqpz0QbwwN8wlYQJsR3e4r5g1M8yhD3J0XhxNcMHmJIyyyb7yzo947O >> >> y2T9M/EHQw==> >> /> >> zqVVsv0tdx1Fp/c1rrj5b7aKdVtwtq2u0R0RsUnwCja3aMXGjsfqA68lZawt5wCtZqLWsKllPUom >> >> Z5quVeBVBg==> "#QualifyingProperties_ID"> >> AKs1UqheswdoyC7xfofmnZoCOF8dmFISw0Cnqfp9n294EgvP5dnZAWWXH+yspvhnNr3qOJmcaP3N >> >> ZYoN6rG5XA==> "#OpenESignForms_Seal_ID"> >> PzDq2Q3GpkgsnMmD//3bp5q+IksCxpR106yL1hx+WdxNvZWeAdT3SFAoHgLZtx4KL814iqLbiL5U >> >> kwwmI2q8DA== >> ID9zJVDWmIjJzv2TWdq3RjZ4MdF3+gX2LX2du7uRw0A2BJ7u8DAg33Wzlg0EnGNyOFC/P8obaegE >> >> >> xCaomRhZXqrLdCoyobe5zWxAFZ+cEHvUY4IwZKdf06i8UEgWiREdHTLfmqqbrhWrnXSnyFoSzAR3 >> >> >> pn4WssvP4LlJqoMPVQfHtO2aPJQpBBbnQe9wa8K0DgEpAy3ge6OwTtOZ48F27AweZPnFQOBhcmw4 >> >> >> Rfsri9CmZKUWI46RmLuSBv5uyxSwaZIX88uGPd4bG2zXcHd2VBxDyKblpGgIU+xcG+nxuSYNN8Y6 >> >> >> rs5o9/XoMM6T8x8LTdNWIgMRf11VhJ1bCh6uF8nEi/QYnV5GcRys/14a8J1oq7l/RNwEk1rMU1m/ >> >> >> VWDWhQT591S8hD4ZCVx7tokHdqtPg7hGHBbNdpcDYDKAhwRm3PJJBJ9XBHTgByrxnCqVk1W7D50f >> >> >> bSiITGvsOIp3ooX3wsq44zv/GVl6BamUPMLhgDq30YZmMNDobJsZxY+CoxQPINfv325R4solQ6s0 >> >> >> WXqg5RzHHjRTfTK6uNNX931iCb9o3HzKZhtyfZcLygUY69og0etvVpUXjMc2m590eUFUs14ekKwU >> >> >> hvB8rN0Qz+FVFH/jwR7AsNgDwE2KGaHEgypEOG5m3vLfLlJXP9ocGuCTp8IpOetx3GAndDFmizU= >> >> 021eddcd-ebd0-4603-8b26-24b3f7fee682 >> >> iSEKAXeyDOq1RKCwypjN5iuU2uR//YM4ssMBGBCtfpq7eF6pXm0rU5Zz4LnmoptUyu4IcnrStgRr >> >> >> JP3NPOeHgibR8i/Ef9frzd4rCwX2JpY3tztCGYByzk93ln7tzRYnMug9q0IVk6Far7JxBIuMy/eg >> >> >> LOyptCZGnRU8wV6D+gydsdoFsaR+zghMtBmoZ8sArGd81rzq28B3NDdqrd4camU7viI+5mMTRGJn >> >> >> UtBzU/4p7kxv2gePzUc2vJ76+8I1eUGbqc7Co12q8vS+wGpQ4a0lUiWJwj7BRXR21oPz+Qo5fiqb >> >> >> a/mSo0gv11s3T2oHTTzWSyvTPb2wbwyBSFAVVaoqJ0g01UEjU2Lv2RkTi/YZpyyPPUDh4OA1KMfX >> >> >> f3M7wxzS0+tJFfE4O4ELsaYlcRElVIor1y98LPKmqWgTg0olfU8H00igjbJdU37SzyqygqNadZlC >> >> >> ocTtaMvveNIkDURAPPZS/Llp1KUm4YY29m+Of0JK0ZoEBLIj5R0uEIpOBe0MWhH4d8l5mxn8IKpR >> >> >> chGgxgJ4P7bNpPQmPUH2rpFukV0NIPe946X7oJE/NubjePyQxpQwwE6zzavz0rf9s4OQpW7tdG/+ >> >> >> fyubGHXq4H/DH4ZZt0KBuIhLfqjEd3mgyzp4waihnkn4bhcRFm8s5UJEuszp6BkD0EHcPfN76Uk= >> AQAB >> >> MIIKkDCCCHigAwIBAgIIXjPAnc0XFeIwDQYJKoZIhvcNAQENBQAwgcIxOTA3BgNVBAMMME9wZW5f >> >> >> ZVNpZ25Gb3Jtc19odHRwczovL29wZW4uZXNpZ25mb3Jtcy5jb20vZGVtbzE6MDgGA1UECgwxRGVw >> >> >> bG95bWVudElEL2JiZmU5YmVkLTkxOGQtNDQ2Yi05NTE4LThlYzMwM2JhZmI4MzE8MDoGA1UECwwz >> >> >> U2lnbmF0dXJlS2V5SUQvMDIxZWRkY2QtZWJkMC00NjAzLThiMjYtMjRiM2Y3ZmVlNjgyMQswCQYD >> >> >> VQQGEwJVUzAeFw0xMTA0MTYwMzIxMzhaFw0yMTA0MTYwMzIxMzhaMIHCMTkwNwYDVQQDDDBPcGVu >> >> >> X2VTaWduRm9ybXNfaHR0cHM6Ly9vcGVuLmVzaWduZm9ybXMuY29tL2RlbW8xOjA4BgNVBAoMMURl >> >> >> cGxveW1lbnRJRC9iYmZlOWJlZC05MThkLTQ0NmItOTUxOC04ZWMzMDNiYWZiODMxPDA6BgNVBAsM >> >> >> M1NpZ25hdHVyZUtleUlELzAyMWVkZGNkLWViZDAtNDYwMy04YjI2LTI0YjNmN2ZlZTY4MjELMAkG >> >> >> A1UEBhMCVVMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCJIQoBd7IM6rVEoLDKmM3m >> >> >> K5Ta5H/9gziywwEYEK1+mrt4XqlebStTlnPgueaim1TK7ghyetK2BGsk/c0854eCJtHyL8R/1+vN >> >> >> 3isLBfYmlje3O0IZgHLOT3eWfu3NFicy6D2rQhWToVqvsnEEi4zL96As7Km0JkadFTzBXoP6DJ2x >> >> >> 2gWxpH7OCEy0GahnywCsZ3zWvOrbwHc0N2qt3hxqZTu+Ij7mYxNEYmdS0HNT/inuTG/aB4/NRza8 >> >> >> nvr7wjV5QZupzsKjXary9L7AalDhrSVSJYnCPsFFdHbWg/P5Cjl+Kptr+ZKjSC/XWzdPagdNPNZL >> >> >> K9M9vbBvDIFIUBVVqionSDTVQSNTYu/ZGROL9hmnLI89QOHg4DUox9d/czvDHNLT60kV8Tg7gQux >> >> >> piVxESVUiivXL3ws8qapaBODSiV9TwfTSKCNsl1TftLPKrKCo1p1mUKhxO1oy+940iQNREA89lL8 >> >> >> uWnUpSbhhjb2b45/QkrRmgQEsiPlHS4Qik4F7QxaEfh3yXmbGfwgqlFyEaDGAng/ts2k9CY9Qfau >> >> >> kW6RXQ0g973jpfugkT825uN4/JDGlDDATrPNq/PSt/2zg5Clbu10b/5/K5sYdergf8Mfhlm3QoG4 >> >> >> iEt+qMR3eaDLOnjBqKGeSfhuFxEWbyzlQkS6zOnoGQPQQdw983vpSQIDAQABo4IEhjCCBIIwggIz >> >> >> BgNVHQ4EggIqBIICJjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAIkhCgF3sgzqtUSg >> >> >> sMqYzeYrlNrkf/2DOLLDARgQrX6au3heqV5tK1OWc+C55qKbVMruCHJ60rYEayT9zTznh4Im0fIv >> >> >> xH/X683eKwsF9iaWN7c7QhmAcs5Pd5Z+7c0WJzLoPatCFZOhWq+ycQSLjMv3oCzsqbQmRp0VPMFe >> >> >> g/oMnbHaBbGkfs4ITLQZqGfLAKxnfNa86tvAdzQ3aq3eHGplO74iPuZjE0RiZ1LQc1P+Ke5Mb9oH >> >> >> j81HNrye+vvCNXlBm6nOwqNdqvL0vsBqUOGtJVIlicI+wUV0dtaD8/kKOX4qm2v5kqNIL9dbN09q >> >> >> B0081ksr0z29sG8MgUhQFVWqKidINNVBI1Ni79kZE4v2Gacsjz1A4eDgNSjH139zO8Mc0tPrSRXx >> >> >> ODuBC7GmJXERJVSKK9cvfCzypqloE4NKJX1PB9NIoI2yXVN+0s8qsoKjWnWZQqHE7WjL73jSJA1E >> >> >> QDz2Uvy5adSlJuGGNvZvjn9CStGaBASyI+UdLhCKTgXtDFoR+HfJeZsZ/CCqUXIRoMYCeD+2zaT0 >> >> >> Jj1B9q6RbpFdDSD3veOl+6CRPzbm43j8kMaUMMBOs82r89K3/bODkKVu7XRv/n8rmxh16uB/wx+G >> >> >> WbdCgbiIS36oxHd5oMs6eMGooZ5J+G4XERZvLOVCRLrM6egZA9BB3D3ze+lJAgMBAAEwggI3BgNV >> >> >> HSMEggIuMIICKoCCAiYwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCJIQoBd7IM6rVE >> >> >> oLDKmM3mK5Ta5H/9gziywwEYEK1+mrt4XqlebStTlnPgueaim1TK7ghyetK2BGsk/c0854eCJtHy >> >> >> L8R/1+vN3isLBfYmlje3O0IZgHLOT3eWfu3NFicy6D2rQhWToVqvsnEEi4zL96As7Km0JkadFTzB >> >> >> XoP6DJ2x2gWxpH7OCEy0GahnywCsZ3zWvOrbwHc0N2qt3hxqZTu+Ij7mYxNEYmdS0HNT/inuTG/a >> >> >> B4/NRza8nvr7wjV5QZupzsKjXary9L7AalDhrSVSJYnCPsFFdHbWg/P5Cjl+Kptr+ZKjSC/XWzdP >> >> >> agdNPNZLK9M9vbBvDIFIUBVVqionSDTVQSNTYu/ZGROL9hmnLI89QOHg4DUox9d/czvDHNLT60kV >> >> >> 8Tg7gQuxpiVxESVUiivXL3ws8qapaBODSiV9TwfTSKCNsl1TftLPKrKCo1p1mUKhxO1oy+940iQN >> >> >> REA89lL8uWnUpSbhhjb2b45/QkrRmgQEsiPlHS4Qik4F7QxaEfh3yXmbGfwgqlFyEaDGAng/ts2k >> >> >> 9CY9QfaukW6RXQ0g973jpfugkT825uN4/JDGlDDATrPNq/PSt/2zg5Clbu10b/5/K5sYdergf8Mf >> >> >> hlm3QoG4iEt+qMR3eaDLOnjBqKGeSfhuFxEWbyzlQkS6zOnoGQPQQdw983vpSQIDAQABMA4GA1Ud >> >> >> DwEB/wQEAwIGwDANBgkqhkiG9w0BAQ0FAAOCAgEAaGn/Q+1fjL7N675UYMGuC5EfloDQ3Y+zuYyx >> >> >> FtMrwO3GuvABTf+oKsQc5n7XDgpQVBWlgIHH+LldDhRPQ1a0MPvMzPDL3Ps1K+hJewNhcec6fqXS >> >> >> t+lszt+mnuK6gGKTioTbO6Li1E41WtJ1UhK4br1lsoNkM0E4rB5KUyj0ZmTCSlYlchAzMYLr1Ymc >> >> >> Q5wgAu0lFIpluhd12un9mUWWXouSC+8pI+ZKfPz2lm+PGBDTTp0TsLLWldvLcnEAgbLG4wZvb1za >> >> >> 3EccZWtCX0b5lGjMCajhADiz76GgYZt1fTus1fhoTe6GsJV9lM11NZTEeTPAUE9VvtNGYOaNUl2e >> >> >> S9pE1myNfiBgXNNJ3L4J6d6fGPlHV9rNPzjclfAOn4a1c+7ZBIsvW1znaeaAoeNyCcRPUr9rgKBS >> >> >> L+izvr6w3eYiqjQWozCi2Nw/oTKk1dC32uzD9KRrQ8pAlSDsspic7FJpFqPVuxrvs8z7tXpc6uyB >> >> >> cmaNZN91xowONrPljlbW2jm5AkebDyTMPfxIRcrTybOr/K3nOYEMkV8G/tRli4SRleGr3cUusHd5 >> >> >> 47BlUSoncDYywh+4drtCycli2mfph3hjB34qkwbzI8j8iX6PSROH+AGcC0L1MEgRq2Um9+K3iTBA >> >> 9zGxY4cvR4vn4VtWcebg9AVMJCwhV85c7l0P0uU= >> > "QualifyingProperties_ID" >> > >> 2019-01-30T12:40:46-08:00 >> > ObjectReference="#Payload_Reference_ID">document.html >> text/html >> > Id="OpenESignForms_Seal_ID" Target="#OpenESignForms_Seal" >> >> "104.239.136.116"DeploymentHostName="open.esignforms.com" DeploymentId= >> "bbfe9bed-918d-446b-9518-8ec303bafb83" SignerAddress=" >> 50-46-115-249.evrt.wa.frontiernet.net (50.46.115.249)" SignerAgent="Mozilla/5.0 >> (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/605.1.15 (KHTML, like >> Gecko) Version/12.0.3 Safari/605.1.15" Timestamp= >> "2019-01-30T12:40:46-08:00" Version="19.1.19_p0129_1657" >> /> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Jan 31 13:36:43 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 31 Jan 2019 13:36:43 +0000 Subject: RFR [11u backport]: 8217579: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is disabled after 8211883 Message-ID: <3aacce99786c4295ae877bc3adebffe1@sap.com> Hi, please review the backport of the fix for 8217579 to jdk11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8217579 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8217579.11u/ Original review thread: https://mail.openjdk.java.net/pipermail/security-dev/2019-January/019256.html The patch did apply cleanly but I had to remove the ChaCha ciphers to make the test work with JDK 11. Thanks and Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Jan 31 20:02:52 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 31 Jan 2019 15:02:52 -0500 Subject: RFR [11u backport]: 8217579: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is disabled after 8211883 In-Reply-To: <3aacce99786c4295ae877bc3adebffe1@sap.com> References: <3aacce99786c4295ae877bc3adebffe1@sap.com> Message-ID: <126f9dda-e20b-6971-4bcd-f12c26f1e8a6@oracle.com> CheckCipherSuites.java 116 // List of enabled cipher suites when the "crypto.policy" security typo: s/enabled/supported/ (I realized that typo after I had already pushed the fix to JDK 13, but better to just fix it here now). Otherwise looks good. --Sean On 1/31/19 8:36 AM, Langer, Christoph wrote: > Hi, > > please review the backport of the fix for 8217579 to jdk11u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217579 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8217579.11u/ > > Original review thread: > https://mail.openjdk.java.net/pipermail/security-dev/2019-January/019256.html > > The patch did apply cleanly but I had to remove the ChaCha ciphers to > make the test work with JDK 11. > > Thanks and Best regards > > Christoph > From amir.khassaia at gmail.com Tue Jan 8 05:28:03 2019 From: amir.khassaia at gmail.com (Amir Khassaia) Date: Tue, 08 Jan 2019 05:28:03 -0000 Subject: Not possible to disable new TLS extensions for TLS 1.2 connections Message-ID: Xuelei, The certificate in the connection is a red herring and not important. It's actually a very unusual behaviour by talk.google.com endpoint to encapsulate an error message inside a certificate. As per the output I included: *"certificate" : { *>* "version" : "v3", *>* "serial number" : "00 90 76 89 18 E9 33 93 A0", *>* "signature algorithm": "SHA256withRSA", *>* "issuer" : "CN=invalid2.invalid, OU="No SNI provided; *>* please fix your client."", *>* "not before" : "2015-01-01 11:00:00.000 AEDT", *>* "not after" : "2030-01-01 11:00:00.000 AEDT", *>* "subject" : "CN=invalid2.invalid, OU="No SNI provided; *>* please fix your client."",* This certificate simply masks the TLS interoperability issue as an untrusted certificate issue. The fact is, some of the extensions sent by JSSE are changes to TLS 1.2 to support TLS 1.3, this however affects some clients adversely in practice and usually JDK provides properties to turn new enhancements off and work around such behaviour, for the extensions I mentioned this is not provided and hence they are always sent for client sockets unless TLSv1.2 is not in use. The impact to us is that upgrading to JDK11 means for some endpoints or devices that are not 100% compliant to the spec the security is reduced as we have to now work around to drop connections to these to TLSv1.1 or TLS1.0 or not to move to Java 11 at all. My request is simply to have all of the new extensions configurable on individual basis so that they can be turned off if needed for compatibility just like most other security enhancements that were delivered in the past. It appears some of the issues can come from - inclusion of RSASSA-PSS alg in TLS 1.2 handshakes but these can disabled at least -signature_algorithms_cert and supported_versions extensions which seem to be hardcoded for TLS 1.2 (I was not able to conclusively identify which of these caused my troubles) https://tools.ietf.org/html/rfc8446#section-1.3 does say that TLS 1.2 clients are affected but in an optional manner.Just today I've encountered another Java 11 interop issue with TLS but this time with a physical device which can have a long shelf life yet running a simple client socket handshake abruptly terminates the connection upon client hello (no server_hello at all), and downgrading the JRE below 11 works fine. I'm including a trace for that as well: javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.395 AEDT|SSLCipher.java:437|jdk.tls.keyLimits: entry = AES/GCM/NoPadding KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472 javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.433 AEDT|ServerNameExtension.java:255|Unable to indicate server name javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: server_name javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: status_request javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.443 AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is not supported by the underlying providers javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.444 AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not supported by the underlying providers javax.net.ssl|INFO|01|main|2019-01-08 13:40:14.449 AEDT|AlpnExtension.java:161|No available application protocols javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.449 AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: application_layer_protocol_negotiation javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.450 AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: status_request_v2 javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.453 AEDT|ClientHello.java:651|Produced ClientHello handshake message ( "ClientHello": { "client version" : "TLSv1.2", "random" : "1A BA E8 FC 59 00 AB DF 9A 1A 07 94 24 7F 34 3D 0B D2 7D 10 72 52 54 CD 44 43 62 E8 8B 42 C6 68", "session id" : "", "cipher suites" : "[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), TLS_RSA_WITH_AES_128_CBC_SHA(0x002F)]", "compression methods" : "00", "extensions" : [ "supported_groups (10)": { "versions": [secp256r1, secp384r1, secp521r1, secp160k1] }, "ec_point_formats (11)": { "formats": [uncompressed] }, "signature_algorithms (13)": { "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5] }, "signature_algorithms_cert (50)": { "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5] }, "extended_master_secret (23)": { }, "supported_versions (43)": { "versions": [TLSv1.2, TLSv1.1] }, "renegotiation_info (65,281)": { "renegotiated connection": [] } ] } ) javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.455 AEDT|Alert.java:232|Received alert message ( "Alert": { "level" : "fatal", "description": "handshake_failure" } ) javax.net.ssl|ERROR|01|main|2019-01-08 13:40:14.456 AEDT|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE): Received fatal alert: handshake_failure ( "throwable" : { javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) at SslSocketClient.main(SslSocketClient.kt:47)} ) javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 AEDT|SSLSocketImpl.java:1361|close the underlying socket javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 AEDT|SSLSocketImpl.java:1380|close the SSL connection (initiative) Exception in thread "main" javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) at SslSocketClient.main(SslSocketClient.kt:47) -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at marcanoonline.com Tue Jan 22 10:01:16 2019 From: robert at marcanoonline.com (Robert Marcano) Date: Tue, 22 Jan 2019 10:01:16 -0000 Subject: High memory usage / leaks was: Best mailing list for JVM embedding In-Reply-To: <1f7b8dfb-176f-f53e-65ff-9cf0612d9456@oracle.com> References: <54df1401-857f-35c4-9973-ab0ac7818194@marcanoonline.com> <1f7b8dfb-176f-f53e-65ff-9cf0612d9456@oracle.com> Message-ID: On Tue, Jan 22, 2019, 5:53 AM Alan Bateman On 22/01/2019 4:48 am, Robert Marcano wrote: > >> : > >> > >> So the question now is, why signed jars could affect the memory usage > >> of an application (we aren't doing JAR verification on our custom > >> launcher, yet), just by being on the java.class.path? IIRC the > >> initial application classpath JARs were never verified previously (by > >> the java launcher alone, without JNLP around). > >> > >> Note: Tested with JARs signed with a self signed certificate and with > >> one signed with a private CA. At most, signing the JARs could slow > >> down the start up if it is now expected to these being verified by > >> the java launcher (is it true?) but not higher memory usage and no > >> reductions after a GC cycle but constants heap size increases. > Signed JARs can be expensive to verify, esp. on first usage as the > verification is likely to result in early loading of a lot of security > classes and infrastructure. If you can narrow down the apparently memory > leak to a small test case with analysis to suggest it's a JDK bug then > it would be good to get a bug submitted. > > -Alan Greeting. Sure, I will work on a distributable reproduction of the problem today but it is new to me that the java launcher do JARs verification now. If it is doing it I doesn't make sense to me, because a self signed or unrecognized CA doesn't trigger a validation error. > -------------- next part -------------- An HTML attachment was scrubbed... URL: