From leventov.ru at gmail.com Wed Jan 1 18:25:36 2020 From: leventov.ru at gmail.com (Roman Leventov) Date: Wed, 1 Jan 2020 21:25:36 +0300 Subject: Subject.getPrincipals(), getPublicCredentials(), getPrivateCredentials() are inherently unsafe Message-ID: If somebody tries to iterate these collections concurrently with modification in another thread, the consequences are undefined. A possible fix is to use CopyOnWriteArrayList as SecureSet.elements field instead of LinkedList. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Jan 2 15:01:35 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 2 Jan 2020 10:01:35 -0500 Subject: Subject.getPrincipals(), getPublicCredentials(), getPrivateCredentials() are inherently unsafe In-Reply-To: References: Message-ID: <982837e7-04ab-7e3d-bdb7-e9a822005bcf@oracle.com> On 1/1/20 1:25 PM, Roman Leventov wrote: > If somebody tries to iterate these collections concurrently with > modification in another thread, the consequences are undefined. Right, the javadoc is not clear on that. > A possible fix is to use CopyOnWriteArrayList as SecureSet.elements > field instead of LinkedList. A workaround is to synchronize on the returned collections when iterating. Would you please consider filing a bug [1]? If you have a test case, please also attach it to the bug report. Thanks, Sean [1] https://bugreport.java.com/bugreport/ From sean.mullan at oracle.com Thu Jan 2 15:12:45 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 2 Jan 2020 10:12:45 -0500 Subject: Reading from a closed socket: different behavior between Linux and other operating systems In-Reply-To: References: Message-ID: <3a035a1c-53ed-18c2-e8d9-bd42ed263366@oracle.com> Cross-posting to security-dev as SSL is involved. --Sean On 12/29/19 4:01 PM, Dawid Weiss wrote: > Hello, > > I am a committer to the Apache Lucene project. We have been looking > into a problem in which SSL connections were handled differently in > tests on different operating systems and narrowed it down to > essentially the following scenario (full repro code at [1]): > > Server side: > > try (ServerSocketChannel serverChannel = ServerSocketChannel.open()) { > SocketChannel clientChannel = serverChannel.accept(); > clientChannel.close(); > } > > Client side: > > Socket socket = new Socket(); > socket.connect(target); > // ... server closes the socket here. > // Queue some data for writing to the closed socket. This succeeds. > socket.getOutputStream().write("will succeed?!".getBytes("UTF-8")); > // Try to read something from the closed socket. > socket.getInputStream().read(new byte[100]); > > The last line of the client results in different behavior between > operating systems. > > 1) Linux, JDK 11, 13, 14: succeeds with -1 (EOF). > 2) Windows, JDK 11: SocketException ("recv failed") is thrown > 3) Windows, JDK 13, 14: SocketException (localized message) is thrown > 4) FreeBSD: SocketException (connection reset) is thrown > 5) Mac OS X: SocketException (connection reset) is thrown > > I admit my original thinking on the Lucene issue (see full discussion > at [2]) was that it was Windows that was off here (due to > WSAECONNRESET not being handled at all in SocketInputStream.c [3]. > Since then (JDK11) the underlying socket implementation has changed > due to JEP 353 [4] (which Alan Bateman kindly pointed out to me). > > But the difference in runtime behavior between Linux and other > operating systems still exists on both the old and the new > implementation. I don't know whether it's something that should be > qualified as platform-specific but it causes additional problems when > it triggers somewhere deep inside the SSL handling layer -- then the > application-level code receives a different exception depending on > where it's run (an SSLException with a suppressed SocketException or a > SocketException directly). > > I don't have any ideas about what a "good" fix for this is but I'm > curious what others think. > > Dawid > > [1] https://issues.apache.org/jira/secure/attachment/12989538/RecvRepro.java > [2] https://issues.apache.org/jira/browse/SOLR-13778 > [3] https://github.com/openjdk/jdk14/blob/f58a8cbed2ba984ceeb9a1ea59f917e3f9530f1e/src/java.base/windows/native/libnet/SocketInputStream.c#L120-L154 > [4] https://openjdk.java.net/jeps/353 > From leventov.ru at gmail.com Thu Jan 2 15:47:26 2020 From: leventov.ru at gmail.com (Roman Leventov) Date: Thu, 2 Jan 2020 18:47:26 +0300 Subject: Subject.getPrincipals(), getPublicCredentials(), getPrivateCredentials() are inherently unsafe In-Reply-To: <982837e7-04ab-7e3d-bdb7-e9a822005bcf@oracle.com> References: <982837e7-04ab-7e3d-bdb7-e9a822005bcf@oracle.com> Message-ID: I already filed a bug (ID 9063182), but was advised to write to this list instead. I don't have an artificial test case, but it should be straightforward to write one. On Thu, 2 Jan 2020 at 18:01, Sean Mullan wrote: > On 1/1/20 1:25 PM, Roman Leventov wrote: > > If somebody tries to iterate these collections concurrently with > > modification in another thread, the consequences are undefined. > > Right, the javadoc is not clear on that. > > > A possible fix is to use CopyOnWriteArrayList as SecureSet.elements > > field instead of LinkedList. > > A workaround is to synchronize on the returned collections when iterating. > > Would you please consider filing a bug [1]? If you have a test case, > please also attach it to the bug report. > > Thanks, > Sean > > [1] https://bugreport.java.com/bugreport/ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Jan 2 19:11:42 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 2 Jan 2020 14:11:42 -0500 Subject: Stateless session resumption for TLS 1.3 with enableSessionTicketExtension? In-Reply-To: References: <9f0ed8a0-a2dd-d73a-2c32-57585f8b0a64@oracle.com> Message-ID: <66f86a8a-ebc7-f970-62e8-844a8eb95ea4@oracle.com> Thanks for spotting this. I filed https://bugs.openjdk.java.net/browse/JDK-8236624 to update the docs. --Sean On 12/17/19 7:53 AM, raell at web.de wrote: > Hi Tony, > > thank you for the clarification. > > Btw: If I'm not mistaken, the new System properties for stateless session resumption are not included in the documentation https://docs.oracle.com/en/java/javase/13/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-93DEEE16-0B70-40E5-BBE7-55C3FD432345 (Table 8-3) so far. If they should be added there at a later time, maybe, your clarification for TLS 1.3 could be incorporated there? > > Regards, > > Ralph > > > > On 12/16/2019 3:20 PM, Anthony Scarpino wrote: >>> Dear all, >>> >>> >>> in Java 13 the new System properties jdk.tls.client.enableSessionTicketExtension and?jdk.tls.server.enableSessionTicketExtension were introduced. In TLS 1.2?and prior these properties support stateful session resumption?according to RFC 5077. >>> >>> In TLS 1.3, however, there is no?SessionTicketExtension and it isn't clear from the description [1] what?impact jdk.tls.server.enableSessionTicketExtension has in case of a?TLS 1.3 connection. >>> >>> Question 1: Does a Java server perform on a TLS 1.3 connection?a?stateless resp. stateful session resumption, if >>> jdk.tls.server.enableSessionTicketExtension is set to true resp. false? > >> Yes > >>> >>> Question 2: Does the content of the NewSessionTicket message in TLS 1.3?depend?on the value of jdk.tls.server.enableSessionTicketExtension? > >> Yes > > >> Tony From david.lloyd at redhat.com Fri Jan 3 13:53:25 2020 From: david.lloyd at redhat.com (David Lloyd) Date: Fri, 3 Jan 2020 07:53:25 -0600 Subject: Reading from a closed socket: different behavior between Linux and other operating systems In-Reply-To: <3a035a1c-53ed-18c2-e8d9-bd42ed263366@oracle.com> References: <3a035a1c-53ed-18c2-e8d9-bd42ed263366@oracle.com> Message-ID: This is, AFAICT, expected based on the differences between the socket layers of the various operating systems involved and their handling of closed sockets. If you write a similar test program in C using OS specific APIs, I believe you will see similar results. I don't think this is a problem with the JDK, nor is it likely to be something that can be fixed in the JDK (since the error reported by the OS is, as far as I know, unlikely to be universally sufficient to extrapolate the exact cause of failure). On Thu, Jan 2, 2020 at 9:14 AM Sean Mullan wrote: > Cross-posting to security-dev as SSL is involved. > > --Sean > > On 12/29/19 4:01 PM, Dawid Weiss wrote: > > Hello, > > > > I am a committer to the Apache Lucene project. We have been looking > > into a problem in which SSL connections were handled differently in > > tests on different operating systems and narrowed it down to > > essentially the following scenario (full repro code at [1]): > > > > Server side: > > > > try (ServerSocketChannel serverChannel = ServerSocketChannel.open()) { > > SocketChannel clientChannel = serverChannel.accept(); > > clientChannel.close(); > > } > > > > Client side: > > > > Socket socket = new Socket(); > > socket.connect(target); > > // ... server closes the socket here. > > // Queue some data for writing to the closed socket. This succeeds. > > socket.getOutputStream().write("will succeed?!".getBytes("UTF-8")); > > // Try to read something from the closed socket. > > socket.getInputStream().read(new byte[100]); > > > > The last line of the client results in different behavior between > > operating systems. > > > > 1) Linux, JDK 11, 13, 14: succeeds with -1 (EOF). > > 2) Windows, JDK 11: SocketException ("recv failed") is thrown > > 3) Windows, JDK 13, 14: SocketException (localized message) is thrown > > 4) FreeBSD: SocketException (connection reset) is thrown > > 5) Mac OS X: SocketException (connection reset) is thrown > > > > I admit my original thinking on the Lucene issue (see full discussion > > at [2]) was that it was Windows that was off here (due to > > WSAECONNRESET not being handled at all in SocketInputStream.c [3]. > > Since then (JDK11) the underlying socket implementation has changed > > due to JEP 353 [4] (which Alan Bateman kindly pointed out to me). > > > > But the difference in runtime behavior between Linux and other > > operating systems still exists on both the old and the new > > implementation. I don't know whether it's something that should be > > qualified as platform-specific but it causes additional problems when > > it triggers somewhere deep inside the SSL handling layer -- then the > > application-level code receives a different exception depending on > > where it's run (an SSLException with a suppressed SocketException or a > > SocketException directly). > > > > I don't have any ideas about what a "good" fix for this is but I'm > > curious what others think. > > > > Dawid > > > > [1] > https://issues.apache.org/jira/secure/attachment/12989538/RecvRepro.java > > [2] https://issues.apache.org/jira/browse/SOLR-13778 > > [3] > https://github.com/openjdk/jdk14/blob/f58a8cbed2ba984ceeb9a1ea59f917e3f9530f1e/src/java.base/windows/native/libnet/SocketInputStream.c#L120-L154 > > [4] https://openjdk.java.net/jeps/353 > > > > -- - DML -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Fri Jan 3 18:06:19 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 3 Jan 2020 10:06:19 -0800 Subject: RFR JDK-8236039: JSSE Client does not accept status_request extension in CertificateRequest messages for TLS 1.3 Message-ID: <739aa89f-c4dc-898d-4459-0d1efe2359aa@oracle.com> Hi All, the golang folks have been running into an issue where our JSSE client treats the status_request extension in a CertificateRequest message from a golang server as an unknown extension and alerts.? This quick fix will allow the client to read and accept the extension and proceed.? I believe you need golang 1.13.x to see this take place. This fix does not implement client-side OCSP stapling.? That will be an RFE for another day. Bug: https://bugs.openjdk.java.net/browse/JDK-8236039 Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8236039/webrev.01/ --Jamil From xuelei.fan at oracle.com Sat Jan 4 17:27:57 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 4 Jan 2020 09:27:57 -0800 Subject: RFR JDK-8236039: JSSE Client does not accept status_request extension in CertificateRequest messages for TLS 1.3 In-Reply-To: <739aa89f-c4dc-898d-4459-0d1efe2359aa@oracle.com> References: <739aa89f-c4dc-898d-4459-0d1efe2359aa@oracle.com> Message-ID: CertStatusExtension.java ------------------------ 1239 // The consuming happens in server side only. typo? server -> client It wold be nice to add a debug log that this extension get ignored. But may not need to define this consumer as it is not supported. SSLExtension.java ----------------- As this fix does not implement this feature yet, is it possible to just define it without the on-load consumer? Otherwise, it looks fine to me. BTW, this issue reminders me a common problem: if an extension is supported in a handshake message, we need to know all other handshake messages that could use the extension, and define an SSLExtension enum for them. Otherwise, a similar issue could happen. I think it would be challenge to know that in practice. So I was just wondering, could we just release the check in the SSLExtensions.java implementation (from line 71 to 95)? If the extension for the specific handshake type is not defined, just ignore it, except for ServerHello? I think the behavior complies to the TLS 1.3 protocol. if (SSLExtension.isConsumable(extId) && SSLExtension.valueOf(handshakeType, extId) == null) { ... - } else { + } else if (handshakeType == SSLHandshake.SERVER_HELLO) { throw hm.handshakeContext.conContext.fatal( Alert.UNSUPPORTED_EXTENSION, "extension (" + extId + ") should not be presented in " + handshakeType.name); + } else { + isSupported = false; + // debug log to ignore unknown extension for handshakeType } } Xuelei On 1/3/2020 10:06 AM, Jamil Nimeh wrote: > Hi All, the golang folks have been running into an issue where our JSSE > client treats the status_request extension in a CertificateRequest > message from a golang server as an unknown extension and alerts.? This > quick fix will allow the client to read and accept the extension and > proceed.? I believe you need golang 1.13.x to see this take place. > > This fix does not implement client-side OCSP stapling.? That will be an > RFE for another day. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8236039 > > Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8236039/webrev.01/ > > --Jamil > From jamil.j.nimeh at oracle.com Sat Jan 4 18:03:02 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Sat, 4 Jan 2020 10:03:02 -0800 Subject: RFR JDK-8236039: JSSE Client does not accept status_request extension in CertificateRequest messages for TLS 1.3 In-Reply-To: <95593577-27f2-bd6e-6fae-2a7d74c0fc2c@oracle.com> References: <739aa89f-c4dc-898d-4459-0d1efe2359aa@oracle.com> <95593577-27f2-bd6e-6fae-2a7d74c0fc2c@oracle.com> Message-ID: Whoops...forgot to reply-all. On 1/4/2020 10:02 AM, Jamil Nimeh wrote: > Thanks for catching the comment typo.? I'll fix that. > > My original fix was just the definition in SSLExtension with all null > consumer/producers.? That will work, but you get a warning when debug > tracing is turned on that is spurrious: > > SSLExtensions.java:132|Ignore unknown or unsupported extension ( > "unknown extension (5)": { > > } > > I didn't really like that "unknown extension" log message when we > clearly know what status_request is in general.? When I went through > and traced it, it basically falls into that code path because there's > no onLoadConsumer.? So I just made a very simple onLoad that would > parse the extension and nothing else.? I figured it would serve as the > springboard for client-side OCSP stapling if we ever decide to do it. > > Regarding your comment about defining extensions for all messages or > none at all, I noticed the same thing and came to a similar conclusion > when I was debugging that spurious debug message above.? The golang > server asserts signed_certificate_timestamp which it was happy to > treat as an unknown extension while SCT caused the client to alert. > > I'll try adding your check and commenting out my consumer to see if a) > it allows the extension, b) it doesn't throw a bogus debug message. > > --Jamil > > On 1/4/2020 9:27 AM, Xuelei Fan wrote: >> CertStatusExtension.java >> ------------------------ >> 1239???????????? // The consuming happens in server side only. >> typo? server -> client >> >> It wold be nice to add a debug log that this extension get ignored.? >> But may not need to define this consumer as it is not supported. >> >> SSLExtension.java >> ----------------- >> As this fix does not implement this feature yet, is it possible to >> just define it without the on-load consumer? >> >> Otherwise, it looks fine to me. >> >> BTW, this issue reminders me a common problem: if an extension is >> supported in a handshake message, we need to know all other handshake >> messages that could use the extension, and define an SSLExtension >> enum for them.? Otherwise, a similar issue could happen.? I think it >> would be challenge to know that in practice. >> >> So I was just wondering, could we just release the check in the >> SSLExtensions.java implementation (from line 71 to 95)?? If the >> extension for the specific handshake type is not defined, just ignore >> it, except for ServerHello?? I think the behavior complies to the TLS >> 1.3 protocol. >> >> if (SSLExtension.isConsumable(extId) && >> ??? SSLExtension.valueOf(handshakeType, extId) == null) { >> ??? ... >> -?? } else { >> +?? } else if (handshakeType == SSLHandshake.SERVER_HELLO) { >> ??????? throw hm.handshakeContext.conContext.fatal( >> ????????????? Alert.UNSUPPORTED_EXTENSION, >> ????????????? "extension (" + extId + >> ????????????? ") should not be presented in " + handshakeType.name); >> +?? } else { >> +?????? isSupported = false; >> +?????? // debug log to ignore unknown extension for handshakeType >> ??? } >> } >> >> Xuelei >> >> On 1/3/2020 10:06 AM, Jamil Nimeh wrote: >>> Hi All, the golang folks have been running into an issue where our >>> JSSE client treats the status_request extension in a >>> CertificateRequest message from a golang server as an unknown >>> extension and alerts.? This quick fix will allow the client to read >>> and accept the extension and proceed.? I believe you need golang >>> 1.13.x to see this take place. >>> >>> This fix does not implement client-side OCSP stapling.? That will be >>> an RFE for another day. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236039 >>> >>> Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8236039/webrev.01/ >>> >>> --Jamil >>> From jamil.j.nimeh at oracle.com Sat Jan 4 23:19:14 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Sat, 4 Jan 2020 15:19:14 -0800 Subject: RFR JDK-8236039: JSSE Client does not accept status_request extension in CertificateRequest messages for TLS 1.3 In-Reply-To: References: <739aa89f-c4dc-898d-4459-0d1efe2359aa@oracle.com> Message-ID: <2004fc2d-0ea5-a3c2-cd1c-4ccdb66a7cfc@oracle.com> Hi Xuelei, I backed out my change and went solely with the approach you suggested below.? It works in that it allows the handshake to proceed.? I notice these debug log messages though during consumption of the CR message from the server: javax.net.ssl|DEBUG|01|main|2020-01-04 15:02:26.636 PST|SSLExtensions.java:135|Ignore unknown or unsupported extension ( "unknown extension (5)": { } ... javax.net.ssl|DEBUG|01|main|2020-01-04 15:02:26.656 PST|CertificateRequest.java:926|Consuming CertificateRequest handshake message ( "CertificateRequest": { ? "certificate_request_context": "", ? "extensions": [ ??? "unknown extension (5)": { ??? }, ??? "unknown extension (18)": { ??? }, ??? "signature_algorithms (13)": { ????? "signature schemes": [rsa_pss_rsae_sha256, ecdsa_secp256r1_sha256, ed25519, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pkcs1_sha1, ecdsa_sha1] ??? }, ??? "unknown extension (47)": { ????? 0000: 00 29 00 27 30 25 31 10?? 30 0E 06 03 55 04 0A 0C? .).'0%1.0...U... ????? 0010: 07 54 65 73 74 50 4B 49?? 31 11 30 0F 06 03 55 04? .TestPKI1.0...U. ????? 0020: 03 0C 08 54 65 73 74 52?? 6F 6F 74???????????????? ...TestRoot ??? } ? ] } ) In the debug logs, it seems like we shouldn't call a status_request extension an "unknown extension" because we know what it is and can parse it.? Having the entry in SSLExtension for CR_STATUS_REQUEST and a simple do-nothing consumer gets rid of the status_request/unknown messages and has it render in the printing of the CR message properly. While we're talking about the debug logs we have other extensions that we know about and have entries in SSLExtension, but they have no per-message registration.? You can see in the CR above that 18 (signed_certificate_timestamp) and 47 (certificate_authorities) are extensions that we were aware of enough to put basic entries in SSLExtension for, but just didn't put full consumer/producer support in there. It might be nice to use the display approach that we have for an unsupported extension for those extensions we at least know about, but rather than say "unknown extension" at the start of the printing at least give the name.? Let me see if I can make that work without it being too invasive. --Jamil On 1/4/20 9:27 AM, Xuelei Fan wrote: > CertStatusExtension.java > ------------------------ > 1239???????????? // The consuming happens in server side only. > typo? server -> client > > It wold be nice to add a debug log that this extension get ignored.? > But may not need to define this consumer as it is not supported. > > SSLExtension.java > ----------------- > As this fix does not implement this feature yet, is it possible to > just define it without the on-load consumer? > > Otherwise, it looks fine to me. > > BTW, this issue reminders me a common problem: if an extension is > supported in a handshake message, we need to know all other handshake > messages that could use the extension, and define an SSLExtension enum > for them.? Otherwise, a similar issue could happen.? I think it would > be challenge to know that in practice. > > So I was just wondering, could we just release the check in the > SSLExtensions.java implementation (from line 71 to 95)?? If the > extension for the specific handshake type is not defined, just ignore > it, except for ServerHello?? I think the behavior complies to the TLS > 1.3 protocol. > > if (SSLExtension.isConsumable(extId) && > ??? SSLExtension.valueOf(handshakeType, extId) == null) { > ??? ... > -?? } else { > +?? } else if (handshakeType == SSLHandshake.SERVER_HELLO) { > ??????? throw hm.handshakeContext.conContext.fatal( > ????????????? Alert.UNSUPPORTED_EXTENSION, > ????????????? "extension (" + extId + > ????????????? ") should not be presented in " + handshakeType.name); > +?? } else { > +?????? isSupported = false; > +?????? // debug log to ignore unknown extension for handshakeType > ??? } > } > > Xuelei > > On 1/3/2020 10:06 AM, Jamil Nimeh wrote: >> Hi All, the golang folks have been running into an issue where our >> JSSE client treats the status_request extension in a >> CertificateRequest message from a golang server as an unknown >> extension and alerts.? This quick fix will allow the client to read >> and accept the extension and proceed.? I believe you need golang >> 1.13.x to see this take place. >> >> This fix does not implement client-side OCSP stapling.? That will be >> an RFE for another day. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8236039 >> >> Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8236039/webrev.01/ >> >> --Jamil >> From Xuelei.Fan at Oracle.Com Sat Jan 4 23:35:07 2020 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Sat, 4 Jan 2020 15:35:07 -0800 Subject: RFR JDK-8236039: JSSE Client does not accept status_request extension in CertificateRequest messages for TLS 1.3 In-Reply-To: <2004fc2d-0ea5-a3c2-cd1c-4ccdb66a7cfc@oracle.com> References: <739aa89f-c4dc-898d-4459-0d1efe2359aa@oracle.com> <2004fc2d-0ea5-a3c2-cd1c-4ccdb66a7cfc@oracle.com> Message-ID: We may not want to parse the extension if the debug is not enabled. It may not worthy to define consume for debug only. How about replace ?unknown? with ?unsupported?? And parse the extension id to literal name if the name is known? Xuelei > On Jan 4, 2020, at 3:19 PM, Jamil Nimeh wrote: > > Hi Xuelei, I backed out my change and went solely with the approach you suggested below. It works in that it allows the handshake to proceed. I notice these debug log messages though during consumption of the CR message from the server: > > javax.net.ssl|DEBUG|01|main|2020-01-04 15:02:26.636 PST|SSLExtensions.java:135|Ignore unknown or unsupported extension ( > "unknown extension (5)": { > > } > ... > javax.net.ssl|DEBUG|01|main|2020-01-04 15:02:26.656 PST|CertificateRequest.java:926|Consuming CertificateRequest handshake message ( > "CertificateRequest": { > "certificate_request_context": "", > "extensions": [ > "unknown extension (5)": { > > }, > "unknown extension (18)": { > > }, > "signature_algorithms (13)": { > "signature schemes": [rsa_pss_rsae_sha256, ecdsa_secp256r1_sha256, ed25519, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pkcs1_sha1, ecdsa_sha1] > }, > "unknown extension (47)": { > 0000: 00 29 00 27 30 25 31 10 30 0E 06 03 55 04 0A 0C .).'0%1.0...U... > 0010: 07 54 65 73 74 50 4B 49 31 11 30 0F 06 03 55 04 .TestPKI1.0...U. > 0020: 03 0C 08 54 65 73 74 52 6F 6F 74 ...TestRoot > } > ] > } > ) > > In the debug logs, it seems like we shouldn't call a status_request extension an "unknown extension" because we know what it is and can parse it. Having the entry in SSLExtension for CR_STATUS_REQUEST and a simple do-nothing consumer gets rid of the status_request/unknown messages and has it render in the printing of the CR message properly. > > While we're talking about the debug logs we have other extensions that we know about and have entries in SSLExtension, but they have no per-message registration. You can see in the CR above that 18 (signed_certificate_timestamp) and 47 (certificate_authorities) are extensions that we were aware of enough to put basic entries in SSLExtension for, but just didn't put full consumer/producer support in there. > > It might be nice to use the display approach that we have for an unsupported extension for those extensions we at least know about, but rather than say "unknown extension" at the start of the printing at least give the name. Let me see if I can make that work without it being too invasive. > > --Jamil > >> On 1/4/20 9:27 AM, Xuelei Fan wrote: >> CertStatusExtension.java >> ------------------------ >> 1239 // The consuming happens in server side only. >> typo? server -> client >> >> It wold be nice to add a debug log that this extension get ignored. But may not need to define this consumer as it is not supported. >> >> SSLExtension.java >> ----------------- >> As this fix does not implement this feature yet, is it possible to just define it without the on-load consumer? >> >> Otherwise, it looks fine to me. >> >> BTW, this issue reminders me a common problem: if an extension is supported in a handshake message, we need to know all other handshake messages that could use the extension, and define an SSLExtension enum for them. Otherwise, a similar issue could happen. I think it would be challenge to know that in practice. >> >> So I was just wondering, could we just release the check in the SSLExtensions.java implementation (from line 71 to 95)? If the extension for the specific handshake type is not defined, just ignore it, except for ServerHello? I think the behavior complies to the TLS 1.3 protocol. >> >> if (SSLExtension.isConsumable(extId) && >> SSLExtension.valueOf(handshakeType, extId) == null) { >> ... >> - } else { >> + } else if (handshakeType == SSLHandshake.SERVER_HELLO) { >> throw hm.handshakeContext.conContext.fatal( >> Alert.UNSUPPORTED_EXTENSION, >> "extension (" + extId + >> ") should not be presented in " + handshakeType.name); >> + } else { >> + isSupported = false; >> + // debug log to ignore unknown extension for handshakeType >> } >> } >> >> Xuelei >> >>> On 1/3/2020 10:06 AM, Jamil Nimeh wrote: >>> Hi All, the golang folks have been running into an issue where our JSSE client treats the status_request extension in a CertificateRequest message from a golang server as an unknown extension and alerts. This quick fix will allow the client to read and accept the extension and proceed. I believe you need golang 1.13.x to see this take place. >>> >>> This fix does not implement client-side OCSP stapling. That will be an RFE for another day. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236039 >>> >>> Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8236039/webrev.01/ >>> >>> --Jamil >>> From jamil.j.nimeh at oracle.com Sat Jan 4 23:53:02 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Sat, 4 Jan 2020 15:53:02 -0800 Subject: RFR JDK-8236039: JSSE Client does not accept status_request extension in CertificateRequest messages for TLS 1.3 In-Reply-To: References: <739aa89f-c4dc-898d-4459-0d1efe2359aa@oracle.com> <2004fc2d-0ea5-a3c2-cd1c-4ccdb66a7cfc@oracle.com> Message-ID: Let me throw out another idea.? I think the actual parsing only happens in the consumer if you call the spec constructor.? You could have a consumer registered that simply returns null.? That avoids the extra unknown/unsupported log message that we don't need and you don't have the cost of actually parsing the extension.? It should just skip over it.? The only performance hit you take is the actual call into one additional method.? That shouldn't have a major performance impact. Just to see how it would work, I created SSLExtension.nameOf(int) which takes the extension ID and returns a name or "unknown extension".? I did that because I didn't want to mess with valueOf(SSLHandshake, int) since there's other logic depending on that returning null for extensions we don't support. The result was that the unsupported-but-known extensions have their names presented, which is a nice thing for those looking at the log. --Jamil On 1/4/20 3:35 PM, Xuelei Fan wrote: > We may not want to parse the extension if the debug is not enabled. It may not worthy to define consume for debug only. How about replace ?unknown? with ?unsupported?? And parse the extension id to literal name if the name is known? > > Xuelei > >> On Jan 4, 2020, at 3:19 PM, Jamil Nimeh wrote: >> >> Hi Xuelei, I backed out my change and went solely with the approach you suggested below. It works in that it allows the handshake to proceed. I notice these debug log messages though during consumption of the CR message from the server: >> >> javax.net.ssl|DEBUG|01|main|2020-01-04 15:02:26.636 PST|SSLExtensions.java:135|Ignore unknown or unsupported extension ( >> "unknown extension (5)": { >> >> } >> ... >> javax.net.ssl|DEBUG|01|main|2020-01-04 15:02:26.656 PST|CertificateRequest.java:926|Consuming CertificateRequest handshake message ( >> "CertificateRequest": { >> "certificate_request_context": "", >> "extensions": [ >> "unknown extension (5)": { >> >> }, >> "unknown extension (18)": { >> >> }, >> "signature_algorithms (13)": { >> "signature schemes": [rsa_pss_rsae_sha256, ecdsa_secp256r1_sha256, ed25519, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pkcs1_sha1, ecdsa_sha1] >> }, >> "unknown extension (47)": { >> 0000: 00 29 00 27 30 25 31 10 30 0E 06 03 55 04 0A 0C .).'0%1.0...U... >> 0010: 07 54 65 73 74 50 4B 49 31 11 30 0F 06 03 55 04 .TestPKI1.0...U. >> 0020: 03 0C 08 54 65 73 74 52 6F 6F 74 ...TestRoot >> } >> ] >> } >> ) >> >> In the debug logs, it seems like we shouldn't call a status_request extension an "unknown extension" because we know what it is and can parse it. Having the entry in SSLExtension for CR_STATUS_REQUEST and a simple do-nothing consumer gets rid of the status_request/unknown messages and has it render in the printing of the CR message properly. >> >> While we're talking about the debug logs we have other extensions that we know about and have entries in SSLExtension, but they have no per-message registration. You can see in the CR above that 18 (signed_certificate_timestamp) and 47 (certificate_authorities) are extensions that we were aware of enough to put basic entries in SSLExtension for, but just didn't put full consumer/producer support in there. >> >> It might be nice to use the display approach that we have for an unsupported extension for those extensions we at least know about, but rather than say "unknown extension" at the start of the printing at least give the name. Let me see if I can make that work without it being too invasive. >> >> --Jamil >> >>> On 1/4/20 9:27 AM, Xuelei Fan wrote: >>> CertStatusExtension.java >>> ------------------------ >>> 1239 // The consuming happens in server side only. >>> typo? server -> client >>> >>> It wold be nice to add a debug log that this extension get ignored. But may not need to define this consumer as it is not supported. >>> >>> SSLExtension.java >>> ----------------- >>> As this fix does not implement this feature yet, is it possible to just define it without the on-load consumer? >>> >>> Otherwise, it looks fine to me. >>> >>> BTW, this issue reminders me a common problem: if an extension is supported in a handshake message, we need to know all other handshake messages that could use the extension, and define an SSLExtension enum for them. Otherwise, a similar issue could happen. I think it would be challenge to know that in practice. >>> >>> So I was just wondering, could we just release the check in the SSLExtensions.java implementation (from line 71 to 95)? If the extension for the specific handshake type is not defined, just ignore it, except for ServerHello? I think the behavior complies to the TLS 1.3 protocol. >>> >>> if (SSLExtension.isConsumable(extId) && >>> SSLExtension.valueOf(handshakeType, extId) == null) { >>> ... >>> - } else { >>> + } else if (handshakeType == SSLHandshake.SERVER_HELLO) { >>> throw hm.handshakeContext.conContext.fatal( >>> Alert.UNSUPPORTED_EXTENSION, >>> "extension (" + extId + >>> ") should not be presented in " + handshakeType.name); >>> + } else { >>> + isSupported = false; >>> + // debug log to ignore unknown extension for handshakeType >>> } >>> } >>> >>> Xuelei >>> >>>> On 1/3/2020 10:06 AM, Jamil Nimeh wrote: >>>> Hi All, the golang folks have been running into an issue where our JSSE client treats the status_request extension in a CertificateRequest message from a golang server as an unknown extension and alerts. This quick fix will allow the client to read and accept the extension and proceed. I believe you need golang 1.13.x to see this take place. >>>> >>>> This fix does not implement client-side OCSP stapling. That will be an RFE for another day. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236039 >>>> >>>> Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8236039/webrev.01/ >>>> >>>> --Jamil >>>> From xuelei.fan at oracle.com Sun Jan 5 02:41:42 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 4 Jan 2020 18:41:42 -0800 Subject: RFR JDK-8236039: JSSE Client does not accept status_request extension in CertificateRequest messages for TLS 1.3 In-Reply-To: References: <739aa89f-c4dc-898d-4459-0d1efe2359aa@oracle.com> <2004fc2d-0ea5-a3c2-cd1c-4ccdb66a7cfc@oracle.com> Message-ID: It's a good idea to me to have a SSLExtension.nameOf(int) method. Thanks, Xuelei On 1/4/2020 3:53 PM, Jamil Nimeh wrote: > Let me throw out another idea.? I think the actual parsing only happens > in the consumer if you call the spec constructor.? You could have a > consumer registered that simply returns null.? That avoids the extra > unknown/unsupported log message that we don't need and you don't have > the cost of actually parsing the extension.? It should just skip over > it.? The only performance hit you take is the actual call into one > additional method.? That shouldn't have a major performance impact. > > Just to see how it would work, I created SSLExtension.nameOf(int) which > takes the extension ID and returns a name or "unknown extension".? I did > that because I didn't want to mess with valueOf(SSLHandshake, int) since > there's other logic depending on that returning null for extensions we > don't support. > > The result was that the unsupported-but-known extensions have their > names presented, which is a nice thing for those looking at the log. > > --Jamil > > On 1/4/20 3:35 PM, Xuelei Fan wrote: >> We may not want to parse the extension if the debug is not enabled. >> It may not worthy to define consume for debug only.? How about replace >> ?unknown? with ?unsupported?? And parse the extension id to literal >> name if the name is known? >> >> Xuelei >> >>> On Jan 4, 2020, at 3:19 PM, Jamil Nimeh >>> wrote: >>> >>> Hi Xuelei, I backed out my change and went solely with the approach >>> you suggested below.? It works in that it allows the handshake to >>> proceed.? I notice these debug log messages though during consumption >>> of the CR message from the server: >>> >>> javax.net.ssl|DEBUG|01|main|2020-01-04 15:02:26.636 >>> PST|SSLExtensions.java:135|Ignore unknown or unsupported extension ( >>> "unknown extension (5)": { >>> >>> } >>> ... >>> javax.net.ssl|DEBUG|01|main|2020-01-04 15:02:26.656 >>> PST|CertificateRequest.java:926|Consuming CertificateRequest >>> handshake message ( >>> "CertificateRequest": { >>> ?? "certificate_request_context": "", >>> ?? "extensions": [ >>> ???? "unknown extension (5)": { >>> >>> ???? }, >>> ???? "unknown extension (18)": { >>> >>> ???? }, >>> ???? "signature_algorithms (13)": { >>> ?????? "signature schemes": [rsa_pss_rsae_sha256, >>> ecdsa_secp256r1_sha256, ed25519, rsa_pss_rsae_sha384, >>> rsa_pss_rsae_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, >>> rsa_pkcs1_sha512, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, >>> rsa_pkcs1_sha1, ecdsa_sha1] >>> ???? }, >>> ???? "unknown extension (47)": { >>> ?????? 0000: 00 29 00 27 30 25 31 10?? 30 0E 06 03 55 04 0A 0C >>> .).'0%1.0...U... >>> ?????? 0010: 07 54 65 73 74 50 4B 49?? 31 11 30 0F 06 03 55 04 >>> .TestPKI1.0...U. >>> ?????? 0020: 03 0C 08 54 65 73 74 52?? 6F 6F 74 >>> ...TestRoot >>> ???? } >>> ?? ] >>> } >>> ) >>> >>> In the debug logs, it seems like we shouldn't call a status_request >>> extension an "unknown extension" because we know what it is and can >>> parse it.? Having the entry in SSLExtension for CR_STATUS_REQUEST and >>> a simple do-nothing consumer gets rid of the status_request/unknown >>> messages and has it render in the printing of the CR message properly. >>> >>> While we're talking about the debug logs we have other extensions >>> that we know about and have entries in SSLExtension, but they have no >>> per-message registration.? You can see in the CR above that 18 >>> (signed_certificate_timestamp) and 47 (certificate_authorities) are >>> extensions that we were aware of enough to put basic entries in >>> SSLExtension for, but just didn't put full consumer/producer support >>> in there. >>> >>> It might be nice to use the display approach that we have for an >>> unsupported extension for those extensions we at least know about, >>> but rather than say "unknown extension" at the start of the printing >>> at least give the name.? Let me see if I can make that work without >>> it being too invasive. >>> >>> --Jamil >>> >>>> On 1/4/20 9:27 AM, Xuelei Fan wrote: >>>> CertStatusExtension.java >>>> ------------------------ >>>> 1239???????????? // The consuming happens in server side only. >>>> typo? server -> client >>>> >>>> It wold be nice to add a debug log that this extension get ignored. >>>> But may not need to define this consumer as it is not supported. >>>> >>>> SSLExtension.java >>>> ----------------- >>>> As this fix does not implement this feature yet, is it possible to >>>> just define it without the on-load consumer? >>>> >>>> Otherwise, it looks fine to me. >>>> >>>> BTW, this issue reminders me a common problem: if an extension is >>>> supported in a handshake message, we need to know all other >>>> handshake messages that could use the extension, and define an >>>> SSLExtension enum for them.? Otherwise, a similar issue could >>>> happen.? I think it would be challenge to know that in practice. >>>> >>>> So I was just wondering, could we just release the check in the >>>> SSLExtensions.java implementation (from line 71 to 95)?? If the >>>> extension for the specific handshake type is not defined, just >>>> ignore it, except for ServerHello?? I think the behavior complies to >>>> the TLS 1.3 protocol. >>>> >>>> if (SSLExtension.isConsumable(extId) && >>>> ???? SSLExtension.valueOf(handshakeType, extId) == null) { >>>> ???? ... >>>> -?? } else { >>>> +?? } else if (handshakeType == SSLHandshake.SERVER_HELLO) { >>>> ???????? throw hm.handshakeContext.conContext.fatal( >>>> ?????????????? Alert.UNSUPPORTED_EXTENSION, >>>> ?????????????? "extension (" + extId + >>>> ?????????????? ") should not be presented in " + handshakeType.name); >>>> +?? } else { >>>> +?????? isSupported = false; >>>> +?????? // debug log to ignore unknown extension for handshakeType >>>> ???? } >>>> } >>>> >>>> Xuelei >>>> >>>>> On 1/3/2020 10:06 AM, Jamil Nimeh wrote: >>>>> Hi All, the golang folks have been running into an issue where our >>>>> JSSE client treats the status_request extension in a >>>>> CertificateRequest message from a golang server as an unknown >>>>> extension and alerts.? This quick fix will allow the client to read >>>>> and accept the extension and proceed.? I believe you need golang >>>>> 1.13.x to see this take place. >>>>> >>>>> This fix does not implement client-side OCSP stapling.? That will >>>>> be an RFE for another day. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236039 >>>>> >>>>> Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8236039/webrev.01/ >>>>> >>>>> --Jamil >>>>> From jamil.j.nimeh at oracle.com Sun Jan 5 22:20:09 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Sun, 5 Jan 2020 14:20:09 -0800 Subject: RFR JDK-8236039: JSSE Client does not accept status_request extension in CertificateRequest messages for TLS 1.3 In-Reply-To: References: <739aa89f-c4dc-898d-4459-0d1efe2359aa@oracle.com> <2004fc2d-0ea5-a3c2-cd1c-4ccdb66a7cfc@oracle.com> Message-ID: <95eb5b0e-50d2-7055-9fe3-c7424cb5a950@oracle.com> Hi Xuelei, et al., I have a new version of the webrev here: https://cr.openjdk.java.net/~jnimeh/reviews/8236039/webrev.02 I thought a little more about what you said about consumers and tried looking at the logging both with and without the CR consumer in place.? With your changes to the SSLExtensions constructor, combined with the new SSLExtension.nameOf(int), I think we can not have the consumer and the resulting logs look good.? You still get a warning when processing a CR status_request, but now an "unknown or unsupported" message that identifies "status_request (5)" makes more sense.? The status_request extension is identified by name now but unsupported in the CR message which is accurate, but no consumer overhead at all, debug or not.? Best of both worlds. When we get to doing the client-side OCSP stapling feature, then we'll need server side producers and client-side consumers.? But all that fun is for a later date. Thanks, --Jamil On 1/4/20 6:41 PM, Xuelei Fan wrote: > It's a good idea to me to have a SSLExtension.nameOf(int) method. > > Thanks, > Xuelei > > On 1/4/2020 3:53 PM, Jamil Nimeh wrote: >> Let me throw out another idea.? I think the actual parsing only >> happens in the consumer if you call the spec constructor.? You could >> have a consumer registered that simply returns null.? That avoids the >> extra unknown/unsupported log message that we don't need and you >> don't have the cost of actually parsing the extension.? It should >> just skip over it. The only performance hit you take is the actual >> call into one additional method.? That shouldn't have a major >> performance impact. >> >> Just to see how it would work, I created SSLExtension.nameOf(int) >> which takes the extension ID and returns a name or "unknown >> extension".? I did that because I didn't want to mess with >> valueOf(SSLHandshake, int) since there's other logic depending on >> that returning null for extensions we don't support. >> >> The result was that the unsupported-but-known extensions have their >> names presented, which is a nice thing for those looking at the log. >> >> --Jamil >> >> On 1/4/20 3:35 PM, Xuelei Fan wrote: >>> We may not want to parse the extension if the debug is not >>> enabled.?? It may not worthy to define consume for debug only.? How >>> about replace ?unknown? with ?unsupported?? And parse the extension >>> id to literal name if the name is known? >>> >>> Xuelei >>> >>>> On Jan 4, 2020, at 3:19 PM, Jamil Nimeh >>>> wrote: >>>> >>>> Hi Xuelei, I backed out my change and went solely with the approach >>>> you suggested below.? It works in that it allows the handshake to >>>> proceed.? I notice these debug log messages though during >>>> consumption of the CR message from the server: >>>> >>>> javax.net.ssl|DEBUG|01|main|2020-01-04 15:02:26.636 >>>> PST|SSLExtensions.java:135|Ignore unknown or unsupported extension ( >>>> "unknown extension (5)": { >>>> >>>> } >>>> ... >>>> javax.net.ssl|DEBUG|01|main|2020-01-04 15:02:26.656 >>>> PST|CertificateRequest.java:926|Consuming CertificateRequest >>>> handshake message ( >>>> "CertificateRequest": { >>>> ?? "certificate_request_context": "", >>>> ?? "extensions": [ >>>> ???? "unknown extension (5)": { >>>> >>>> ???? }, >>>> ???? "unknown extension (18)": { >>>> >>>> ???? }, >>>> ???? "signature_algorithms (13)": { >>>> ?????? "signature schemes": [rsa_pss_rsae_sha256, >>>> ecdsa_secp256r1_sha256, ed25519, rsa_pss_rsae_sha384, >>>> rsa_pss_rsae_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, >>>> rsa_pkcs1_sha512, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, >>>> rsa_pkcs1_sha1, ecdsa_sha1] >>>> ???? }, >>>> ???? "unknown extension (47)": { >>>> ?????? 0000: 00 29 00 27 30 25 31 10?? 30 0E 06 03 55 04 0A 0C? >>>> .).'0%1.0...U... >>>> ?????? 0010: 07 54 65 73 74 50 4B 49?? 31 11 30 0F 06 03 55 04? >>>> .TestPKI1.0...U. >>>> ?????? 0020: 03 0C 08 54 65 73 74 52?? 6F 6F 74???????????????? >>>> ...TestRoot >>>> ???? } >>>> ?? ] >>>> } >>>> ) >>>> >>>> In the debug logs, it seems like we shouldn't call a status_request >>>> extension an "unknown extension" because we know what it is and can >>>> parse it.? Having the entry in SSLExtension for CR_STATUS_REQUEST >>>> and a simple do-nothing consumer gets rid of the >>>> status_request/unknown messages and has it render in the printing >>>> of the CR message properly. >>>> >>>> While we're talking about the debug logs we have other extensions >>>> that we know about and have entries in SSLExtension, but they have >>>> no per-message registration. You can see in the CR above that 18 >>>> (signed_certificate_timestamp) and 47 (certificate_authorities) are >>>> extensions that we were aware of enough to put basic entries in >>>> SSLExtension for, but just didn't put full consumer/producer >>>> support in there. >>>> >>>> It might be nice to use the display approach that we have for an >>>> unsupported extension for those extensions we at least know about, >>>> but rather than say "unknown extension" at the start of the >>>> printing at least give the name.? Let me see if I can make that >>>> work without it being too invasive. >>>> >>>> --Jamil >>>> >>>>> On 1/4/20 9:27 AM, Xuelei Fan wrote: >>>>> CertStatusExtension.java >>>>> ------------------------ >>>>> 1239???????????? // The consuming happens in server side only. >>>>> typo? server -> client >>>>> >>>>> It wold be nice to add a debug log that this extension get >>>>> ignored.? But may not need to define this consumer as it is not >>>>> supported. >>>>> >>>>> SSLExtension.java >>>>> ----------------- >>>>> As this fix does not implement this feature yet, is it possible to >>>>> just define it without the on-load consumer? >>>>> >>>>> Otherwise, it looks fine to me. >>>>> >>>>> BTW, this issue reminders me a common problem: if an extension is >>>>> supported in a handshake message, we need to know all other >>>>> handshake messages that could use the extension, and define an >>>>> SSLExtension enum for them. Otherwise, a similar issue could >>>>> happen.? I think it would be challenge to know that in practice. >>>>> >>>>> So I was just wondering, could we just release the check in the >>>>> SSLExtensions.java implementation (from line 71 to 95)?? If the >>>>> extension for the specific handshake type is not defined, just >>>>> ignore it, except for ServerHello?? I think the behavior complies >>>>> to the TLS 1.3 protocol. >>>>> >>>>> if (SSLExtension.isConsumable(extId) && >>>>> ???? SSLExtension.valueOf(handshakeType, extId) == null) { >>>>> ???? ... >>>>> -?? } else { >>>>> +?? } else if (handshakeType == SSLHandshake.SERVER_HELLO) { >>>>> ???????? throw hm.handshakeContext.conContext.fatal( >>>>> ?????????????? Alert.UNSUPPORTED_EXTENSION, >>>>> ?????????????? "extension (" + extId + >>>>> ?????????????? ") should not be presented in " + handshakeType.name); >>>>> +?? } else { >>>>> +?????? isSupported = false; >>>>> +?????? // debug log to ignore unknown extension for handshakeType >>>>> ???? } >>>>> } >>>>> >>>>> Xuelei >>>>> >>>>>> On 1/3/2020 10:06 AM, Jamil Nimeh wrote: >>>>>> Hi All, the golang folks have been running into an issue where >>>>>> our JSSE client treats the status_request extension in a >>>>>> CertificateRequest message from a golang server as an unknown >>>>>> extension and alerts.? This quick fix will allow the client to >>>>>> read and accept the extension and proceed.? I believe you need >>>>>> golang 1.13.x to see this take place. >>>>>> >>>>>> This fix does not implement client-side OCSP stapling. That will >>>>>> be an RFE for another day. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236039 >>>>>> >>>>>> Webrev: >>>>>> https://cr.openjdk.java.net/~jnimeh/reviews/8236039/webrev.01/ >>>>>> >>>>>> --Jamil >>>>>> From xuelei.fan at oracle.com Mon Jan 6 02:45:03 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 5 Jan 2020 18:45:03 -0800 Subject: RFR JDK-8236039: JSSE Client does not accept status_request extension in CertificateRequest messages for TLS 1.3 In-Reply-To: <95eb5b0e-50d2-7055-9fe3-c7424cb5a950@oracle.com> References: <739aa89f-c4dc-898d-4459-0d1efe2359aa@oracle.com> <2004fc2d-0ea5-a3c2-cd1c-4ccdb66a7cfc@oracle.com> <95eb5b0e-50d2-7055-9fe3-c7424cb5a950@oracle.com> Message-ID: <1c5a68a4-2647-d9e0-3478-5db1d30264c6@oracle.com> Hi Jamil, Thanks for the new update, which looks pretty good to me. If have something (like SSLLogger.debug()) for line 96 could mitigate your worries about the debug log? SSLExtensions.java: - 96 // debug log to ignore unknown extension for handshakeType + if (SSLLogger.isOn && ...) { + SSLLogger.debug("Ignore unknown or unsupported extension (" + + SSLExtension.nameOf(extId) + ") in " + + SSLHandshake.nameOf(handshakeType)); + } Thanks, Xuelei On 1/5/2020 2:20 PM, Jamil Nimeh wrote: > Hi Xuelei, et al., > > I have a new version of the webrev here: > > https://cr.openjdk.java.net/~jnimeh/reviews/8236039/webrev.02 > > I thought a little more about what you said about consumers and tried > looking at the logging both with and without the CR consumer in place. > With your changes to the SSLExtensions constructor, combined with the > new SSLExtension.nameOf(int), I think we can not have the consumer and > the resulting logs look good.? You still get a warning when processing a > CR status_request, but now an "unknown or unsupported" message that > identifies "status_request (5)" makes more sense.? The status_request > extension is identified by name now but unsupported in the CR message > which is accurate, but no consumer overhead at all, debug or not.? Best > of both worlds. > > When we get to doing the client-side OCSP stapling feature, then we'll > need server side producers and client-side consumers.? But all that fun > is for a later date. > > Thanks, > --Jamil > > > On 1/4/20 6:41 PM, Xuelei Fan wrote: >> It's a good idea to me to have a SSLExtension.nameOf(int) method. >> >> Thanks, >> Xuelei >> >> On 1/4/2020 3:53 PM, Jamil Nimeh wrote: >>> Let me throw out another idea.? I think the actual parsing only >>> happens in the consumer if you call the spec constructor.? You could >>> have a consumer registered that simply returns null.? That avoids the >>> extra unknown/unsupported log message that we don't need and you >>> don't have the cost of actually parsing the extension.? It should >>> just skip over it. The only performance hit you take is the actual >>> call into one additional method.? That shouldn't have a major >>> performance impact. >>> >>> Just to see how it would work, I created SSLExtension.nameOf(int) >>> which takes the extension ID and returns a name or "unknown >>> extension".? I did that because I didn't want to mess with >>> valueOf(SSLHandshake, int) since there's other logic depending on >>> that returning null for extensions we don't support. >>> >>> The result was that the unsupported-but-known extensions have their >>> names presented, which is a nice thing for those looking at the log. >>> >>> --Jamil >>> >>> On 1/4/20 3:35 PM, Xuelei Fan wrote: >>>> We may not want to parse the extension if the debug is not >>>> enabled.?? It may not worthy to define consume for debug only.? How >>>> about replace ?unknown? with ?unsupported?? And parse the extension >>>> id to literal name if the name is known? >>>> >>>> Xuelei >>>> >>>>> On Jan 4, 2020, at 3:19 PM, Jamil Nimeh >>>>> wrote: >>>>> >>>>> Hi Xuelei, I backed out my change and went solely with the approach >>>>> you suggested below.? It works in that it allows the handshake to >>>>> proceed.? I notice these debug log messages though during >>>>> consumption of the CR message from the server: >>>>> >>>>> javax.net.ssl|DEBUG|01|main|2020-01-04 15:02:26.636 >>>>> PST|SSLExtensions.java:135|Ignore unknown or unsupported extension ( >>>>> "unknown extension (5)": { >>>>> >>>>> } >>>>> ... >>>>> javax.net.ssl|DEBUG|01|main|2020-01-04 15:02:26.656 >>>>> PST|CertificateRequest.java:926|Consuming CertificateRequest >>>>> handshake message ( >>>>> "CertificateRequest": { >>>>> ?? "certificate_request_context": "", >>>>> ?? "extensions": [ >>>>> ???? "unknown extension (5)": { >>>>> >>>>> ???? }, >>>>> ???? "unknown extension (18)": { >>>>> >>>>> ???? }, >>>>> ???? "signature_algorithms (13)": { >>>>> ?????? "signature schemes": [rsa_pss_rsae_sha256, >>>>> ecdsa_secp256r1_sha256, ed25519, rsa_pss_rsae_sha384, >>>>> rsa_pss_rsae_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, >>>>> rsa_pkcs1_sha512, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, >>>>> rsa_pkcs1_sha1, ecdsa_sha1] >>>>> ???? }, >>>>> ???? "unknown extension (47)": { >>>>> ?????? 0000: 00 29 00 27 30 25 31 10?? 30 0E 06 03 55 04 0A 0C >>>>> .).'0%1.0...U... >>>>> ?????? 0010: 07 54 65 73 74 50 4B 49?? 31 11 30 0F 06 03 55 04 >>>>> .TestPKI1.0...U. >>>>> ?????? 0020: 03 0C 08 54 65 73 74 52?? 6F 6F 74 ...TestRoot >>>>> ???? } >>>>> ?? ] >>>>> } >>>>> ) >>>>> >>>>> In the debug logs, it seems like we shouldn't call a status_request >>>>> extension an "unknown extension" because we know what it is and can >>>>> parse it.? Having the entry in SSLExtension for CR_STATUS_REQUEST >>>>> and a simple do-nothing consumer gets rid of the >>>>> status_request/unknown messages and has it render in the printing >>>>> of the CR message properly. >>>>> >>>>> While we're talking about the debug logs we have other extensions >>>>> that we know about and have entries in SSLExtension, but they have >>>>> no per-message registration. You can see in the CR above that 18 >>>>> (signed_certificate_timestamp) and 47 (certificate_authorities) are >>>>> extensions that we were aware of enough to put basic entries in >>>>> SSLExtension for, but just didn't put full consumer/producer >>>>> support in there. >>>>> >>>>> It might be nice to use the display approach that we have for an >>>>> unsupported extension for those extensions we at least know about, >>>>> but rather than say "unknown extension" at the start of the >>>>> printing at least give the name.? Let me see if I can make that >>>>> work without it being too invasive. >>>>> >>>>> --Jamil >>>>> >>>>>> On 1/4/20 9:27 AM, Xuelei Fan wrote: >>>>>> CertStatusExtension.java >>>>>> ------------------------ >>>>>> 1239???????????? // The consuming happens in server side only. >>>>>> typo? server -> client >>>>>> >>>>>> It wold be nice to add a debug log that this extension get >>>>>> ignored.? But may not need to define this consumer as it is not >>>>>> supported. >>>>>> >>>>>> SSLExtension.java >>>>>> ----------------- >>>>>> As this fix does not implement this feature yet, is it possible to >>>>>> just define it without the on-load consumer? >>>>>> >>>>>> Otherwise, it looks fine to me. >>>>>> >>>>>> BTW, this issue reminders me a common problem: if an extension is >>>>>> supported in a handshake message, we need to know all other >>>>>> handshake messages that could use the extension, and define an >>>>>> SSLExtension enum for them. Otherwise, a similar issue could >>>>>> happen.? I think it would be challenge to know that in practice. >>>>>> >>>>>> So I was just wondering, could we just release the check in the >>>>>> SSLExtensions.java implementation (from line 71 to 95)?? If the >>>>>> extension for the specific handshake type is not defined, just >>>>>> ignore it, except for ServerHello?? I think the behavior complies >>>>>> to the TLS 1.3 protocol. >>>>>> >>>>>> if (SSLExtension.isConsumable(extId) && >>>>>> ???? SSLExtension.valueOf(handshakeType, extId) == null) { >>>>>> ???? ... >>>>>> -?? } else { >>>>>> +?? } else if (handshakeType == SSLHandshake.SERVER_HELLO) { >>>>>> ???????? throw hm.handshakeContext.conContext.fatal( >>>>>> ?????????????? Alert.UNSUPPORTED_EXTENSION, >>>>>> ?????????????? "extension (" + extId + >>>>>> ?????????????? ") should not be presented in " + handshakeType.name); >>>>>> +?? } else { >>>>>> +?????? isSupported = false; >>>>>> +?????? // debug log to ignore unknown extension for handshakeType >>>>>> ???? } >>>>>> } >>>>>> >>>>>> Xuelei >>>>>> >>>>>>> On 1/3/2020 10:06 AM, Jamil Nimeh wrote: >>>>>>> Hi All, the golang folks have been running into an issue where >>>>>>> our JSSE client treats the status_request extension in a >>>>>>> CertificateRequest message from a golang server as an unknown >>>>>>> extension and alerts.? This quick fix will allow the client to >>>>>>> read and accept the extension and proceed.? I believe you need >>>>>>> golang 1.13.x to see this take place. >>>>>>> >>>>>>> This fix does not implement client-side OCSP stapling. That will >>>>>>> be an RFE for another day. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236039 >>>>>>> >>>>>>> Webrev: >>>>>>> https://cr.openjdk.java.net/~jnimeh/reviews/8236039/webrev.01/ >>>>>>> >>>>>>> --Jamil >>>>>>> From jamil.j.nimeh at oracle.com Mon Jan 6 05:01:37 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Sun, 5 Jan 2020 21:01:37 -0800 Subject: RFR JDK-8236039: JSSE Client does not accept status_request extension in CertificateRequest messages for TLS 1.3 In-Reply-To: <1c5a68a4-2647-d9e0-3478-5db1d30264c6@oracle.com> References: <739aa89f-c4dc-898d-4459-0d1efe2359aa@oracle.com> <2004fc2d-0ea5-a3c2-cd1c-4ccdb66a7cfc@oracle.com> <95eb5b0e-50d2-7055-9fe3-c7424cb5a950@oracle.com> <1c5a68a4-2647-d9e0-3478-5db1d30264c6@oracle.com> Message-ID: <12230565-5505-8529-e9e5-e64c4199bc30@oracle.com> I don't think we need it.? We're already getting a similar message as things stand now.? The existing message doesn't correlate the extension with the message, but you can figure out which message is being processed by looking at where it falls in the trace. I'll push this as-is.? Thanks for the review and the improvements to the overall fix. --Jamil On 1/5/2020 6:45 PM, Xuelei Fan wrote: > Hi Jamil, > > Thanks for the new update, which looks pretty good to me. > > If have something (like SSLLogger.debug()) for line 96 could mitigate > your worries about the debug log? > > SSLExtensions.java: > -?? 96 // debug log to ignore unknown extension for handshakeType > + if (SSLLogger.isOn && ...) { > +??? SSLLogger.debug("Ignore unknown or unsupported extension (" + > +??????? SSLExtension.nameOf(extId) + ") in " + > +??????? SSLHandshake.nameOf(handshakeType)); > + } > > Thanks, > Xuelei > > On 1/5/2020 2:20 PM, Jamil Nimeh wrote: >> Hi Xuelei, et al., >> >> I have a new version of the webrev here: >> >> https://cr.openjdk.java.net/~jnimeh/reviews/8236039/webrev.02 >> >> I thought a little more about what you said about consumers and tried >> looking at the logging both with and without the CR consumer in >> place. With your changes to the SSLExtensions constructor, combined >> with the new SSLExtension.nameOf(int), I think we can not have the >> consumer and the resulting logs look good.? You still get a warning >> when processing a CR status_request, but now an "unknown or >> unsupported" message that identifies "status_request (5)" makes more >> sense.? The status_request extension is identified by name now but >> unsupported in the CR message which is accurate, but no consumer >> overhead at all, debug or not.? Best of both worlds. >> >> When we get to doing the client-side OCSP stapling feature, then >> we'll need server side producers and client-side consumers.? But all >> that fun is for a later date. >> >> Thanks, >> --Jamil >> >> >> On 1/4/20 6:41 PM, Xuelei Fan wrote: >>> It's a good idea to me to have a SSLExtension.nameOf(int) method. >>> >>> Thanks, >>> Xuelei >>> >>> On 1/4/2020 3:53 PM, Jamil Nimeh wrote: >>>> Let me throw out another idea.? I think the actual parsing only >>>> happens in the consumer if you call the spec constructor.? You >>>> could have a consumer registered that simply returns null.? That >>>> avoids the extra unknown/unsupported log message that we don't need >>>> and you don't have the cost of actually parsing the extension.? It >>>> should just skip over it. The only performance hit you take is the >>>> actual call into one additional method.? That shouldn't have a >>>> major performance impact. >>>> >>>> Just to see how it would work, I created SSLExtension.nameOf(int) >>>> which takes the extension ID and returns a name or "unknown >>>> extension".? I did that because I didn't want to mess with >>>> valueOf(SSLHandshake, int) since there's other logic depending on >>>> that returning null for extensions we don't support. >>>> >>>> The result was that the unsupported-but-known extensions have their >>>> names presented, which is a nice thing for those looking at the log. >>>> >>>> --Jamil >>>> >>>> On 1/4/20 3:35 PM, Xuelei Fan wrote: >>>>> We may not want to parse the extension if the debug is not >>>>> enabled.?? It may not worthy to define consume for debug only.? >>>>> How about replace ?unknown? with ?unsupported?? And parse the >>>>> extension id to literal name if the name is known? >>>>> >>>>> Xuelei >>>>> >>>>>> On Jan 4, 2020, at 3:19 PM, Jamil Nimeh >>>>>> wrote: >>>>>> >>>>>> Hi Xuelei, I backed out my change and went solely with the >>>>>> approach you suggested below.? It works in that it allows the >>>>>> handshake to proceed.? I notice these debug log messages though >>>>>> during consumption of the CR message from the server: >>>>>> >>>>>> javax.net.ssl|DEBUG|01|main|2020-01-04 15:02:26.636 >>>>>> PST|SSLExtensions.java:135|Ignore unknown or unsupported extension ( >>>>>> "unknown extension (5)": { >>>>>> >>>>>> } >>>>>> ... >>>>>> javax.net.ssl|DEBUG|01|main|2020-01-04 15:02:26.656 >>>>>> PST|CertificateRequest.java:926|Consuming CertificateRequest >>>>>> handshake message ( >>>>>> "CertificateRequest": { >>>>>> ?? "certificate_request_context": "", >>>>>> ?? "extensions": [ >>>>>> ???? "unknown extension (5)": { >>>>>> >>>>>> ???? }, >>>>>> ???? "unknown extension (18)": { >>>>>> >>>>>> ???? }, >>>>>> ???? "signature_algorithms (13)": { >>>>>> ?????? "signature schemes": [rsa_pss_rsae_sha256, >>>>>> ecdsa_secp256r1_sha256, ed25519, rsa_pss_rsae_sha384, >>>>>> rsa_pss_rsae_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, >>>>>> rsa_pkcs1_sha512, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, >>>>>> rsa_pkcs1_sha1, ecdsa_sha1] >>>>>> ???? }, >>>>>> ???? "unknown extension (47)": { >>>>>> ?????? 0000: 00 29 00 27 30 25 31 10?? 30 0E 06 03 55 04 0A 0C >>>>>> .).'0%1.0...U... >>>>>> ?????? 0010: 07 54 65 73 74 50 4B 49?? 31 11 30 0F 06 03 55 04 >>>>>> .TestPKI1.0...U. >>>>>> ?????? 0020: 03 0C 08 54 65 73 74 52?? 6F 6F 74 ...TestRoot >>>>>> ???? } >>>>>> ?? ] >>>>>> } >>>>>> ) >>>>>> >>>>>> In the debug logs, it seems like we shouldn't call a >>>>>> status_request extension an "unknown extension" because we know >>>>>> what it is and can parse it.? Having the entry in SSLExtension >>>>>> for CR_STATUS_REQUEST and a simple do-nothing consumer gets rid >>>>>> of the status_request/unknown messages and has it render in the >>>>>> printing of the CR message properly. >>>>>> >>>>>> While we're talking about the debug logs we have other extensions >>>>>> that we know about and have entries in SSLExtension, but they >>>>>> have no per-message registration. You can see in the CR above >>>>>> that 18 (signed_certificate_timestamp) and 47 >>>>>> (certificate_authorities) are extensions that we were aware of >>>>>> enough to put basic entries in SSLExtension for, but just didn't >>>>>> put full consumer/producer support in there. >>>>>> >>>>>> It might be nice to use the display approach that we have for an >>>>>> unsupported extension for those extensions we at least know >>>>>> about, but rather than say "unknown extension" at the start of >>>>>> the printing at least give the name.? Let me see if I can make >>>>>> that work without it being too invasive. >>>>>> >>>>>> --Jamil >>>>>> >>>>>>> On 1/4/20 9:27 AM, Xuelei Fan wrote: >>>>>>> CertStatusExtension.java >>>>>>> ------------------------ >>>>>>> 1239???????????? // The consuming happens in server side only. >>>>>>> typo? server -> client >>>>>>> >>>>>>> It wold be nice to add a debug log that this extension get >>>>>>> ignored.? But may not need to define this consumer as it is not >>>>>>> supported. >>>>>>> >>>>>>> SSLExtension.java >>>>>>> ----------------- >>>>>>> As this fix does not implement this feature yet, is it possible >>>>>>> to just define it without the on-load consumer? >>>>>>> >>>>>>> Otherwise, it looks fine to me. >>>>>>> >>>>>>> BTW, this issue reminders me a common problem: if an extension >>>>>>> is supported in a handshake message, we need to know all other >>>>>>> handshake messages that could use the extension, and define an >>>>>>> SSLExtension enum for them. Otherwise, a similar issue could >>>>>>> happen.? I think it would be challenge to know that in practice. >>>>>>> >>>>>>> So I was just wondering, could we just release the check in the >>>>>>> SSLExtensions.java implementation (from line 71 to 95)?? If the >>>>>>> extension for the specific handshake type is not defined, just >>>>>>> ignore it, except for ServerHello?? I think the behavior >>>>>>> complies to the TLS 1.3 protocol. >>>>>>> >>>>>>> if (SSLExtension.isConsumable(extId) && >>>>>>> ???? SSLExtension.valueOf(handshakeType, extId) == null) { >>>>>>> ???? ... >>>>>>> -?? } else { >>>>>>> +?? } else if (handshakeType == SSLHandshake.SERVER_HELLO) { >>>>>>> ???????? throw hm.handshakeContext.conContext.fatal( >>>>>>> ?????????????? Alert.UNSUPPORTED_EXTENSION, >>>>>>> ?????????????? "extension (" + extId + >>>>>>> ?????????????? ") should not be presented in " + >>>>>>> handshakeType.name); >>>>>>> +?? } else { >>>>>>> +?????? isSupported = false; >>>>>>> +?????? // debug log to ignore unknown extension for handshakeType >>>>>>> ???? } >>>>>>> } >>>>>>> >>>>>>> Xuelei >>>>>>> >>>>>>>> On 1/3/2020 10:06 AM, Jamil Nimeh wrote: >>>>>>>> Hi All, the golang folks have been running into an issue where >>>>>>>> our JSSE client treats the status_request extension in a >>>>>>>> CertificateRequest message from a golang server as an unknown >>>>>>>> extension and alerts.? This quick fix will allow the client to >>>>>>>> read and accept the extension and proceed.? I believe you need >>>>>>>> golang 1.13.x to see this take place. >>>>>>>> >>>>>>>> This fix does not implement client-side OCSP stapling. That >>>>>>>> will be an RFE for another day. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236039 >>>>>>>> >>>>>>>> Webrev: >>>>>>>> https://cr.openjdk.java.net/~jnimeh/reviews/8236039/webrev.01/ >>>>>>>> >>>>>>>> --Jamil >>>>>>>> From chris.hegarty at oracle.com Mon Jan 6 16:38:38 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 6 Jan 2020 16:38:38 +0000 Subject: Reading from a closed socket: different behavior between Linux and other operating systems In-Reply-To: References: <3a035a1c-53ed-18c2-e8d9-bd42ed263366@oracle.com> Message-ID: I agree with David, this is an expected difference between the socket layers on different operating systems. The different behaviours are acceptable implementations on said operating systems. Unfortunately, this results in different behaviour of the Java socket (and TCP socket channel) APIs, when running on different platforms (as you are observing). I am not suggesting that you do this, but if the intention is that the server issues a forceful / abortive close, then ( at least in the minimal repo case ) one could: // force RST clientChannel.setOption(StandardSocketOptions.SO_LINGER, 0); I read over the Lucene issue that you sited; it appears that the higher-level problem you are encountering is how/when to issue an HTTP retry request when there is a socket or perceived SSL exception. And how the SSLSocketImpl handles the difference between the above socket layer behaviours. SSLSocket aggregates both the network socket operations and SSL protocol implementation, which makes it more difficult to discern where the underlying issue is coming from, than say, if one was to use SocketChannel along with SSLEngine. However, I would expect that any SSLException that has a SocketException as its cause could be considered as a "network problem" - as described by the SocketException message. The wrapping SSLException in such a case should provide additional SSL protocol specific information to help with diagnosis, e.g. the current protocol state. I'm sure that this is not the answer that you were looking for, but maybe you can consider it when making a decision on whether this can be fixed in the HTTP Client that you are using. -Chris. > On 3 Jan 2020, at 13:53, David Lloyd wrote: > > This is, AFAICT, expected based on the differences between the socket layers of the various operating systems involved and their handling of closed sockets. If you write a similar test program in C using OS specific APIs, I believe you will see similar results. I don't think this is a problem with the JDK, nor is it likely to be something that can be fixed in the JDK (since the error reported by the OS is, as far as I know, unlikely to be universally sufficient to extrapolate the exact cause of failure). -------------- next part -------------- An HTML attachment was scrubbed... URL: From simone.bordet at gmail.com Tue Jan 7 08:34:13 2020 From: simone.bordet at gmail.com (Simone Bordet) Date: Tue, 7 Jan 2020 09:34:13 +0100 Subject: Reading from a closed socket: different behavior between Linux and other operating systems In-Reply-To: References: <3a035a1c-53ed-18c2-e8d9-bd42ed263366@oracle.com> Message-ID: Hi, On Mon, Jan 6, 2020 at 5:39 PM Chris Hegarty wrote: > // force RST > clientChannel.setOption(StandardSocketOptions.SO_LINGER, 0); Just want to point out that when the channel/socket is set in non-blocking mode, SO_LINGER is either not supported or gives undefined behavior or throws (on Windows). -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From archana.nogriya at uk.ibm.com Tue Jan 7 13:39:16 2020 From: archana.nogriya at uk.ibm.com (Archana Nogriya) Date: Tue, 7 Jan 2020 13:39:16 +0000 Subject: [14] RFR JDK-8229243 "SunPKCS11-Solaris provider tests failing on Solaris 11.4" Message-ID: Hi, We have noticed that, src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11gcm2.h has been added couple of month back, and in new copyright added with GPLV2 but there is no mention of Classpath exception. Since this code is part of release and distributed please can I request you to add Classpath exception in the copyrights. http://mail.openjdk.java.net/pipermail/security-dev/2019-October/020758.html bug: https://bugs.openjdk.java.net/browse/JDK-8229243 Webrev: http://cr.openjdk.java.net/~valeriep/8229243/webrev.00/ Many Thanks & Regards Archana Nogriya Java Runtimes Development and Project Manager IBM Hursley IBM United Kingdom Ltd internet email: archana.nogriya 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 dawid.weiss at gmail.com Tue Jan 7 08:19:23 2020 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Tue, 7 Jan 2020 09:19:23 +0100 Subject: Reading from a closed socket: different behavior between Linux and other operating systems In-Reply-To: References: <3a035a1c-53ed-18c2-e8d9-bd42ed263366@oracle.com> Message-ID: Thank you for your feedback. I can understand how this behavior can be considered platform-dependent but it's still a bit surprising that it shows consistent behavior on everything except Linux... (we originally thought it's Windows to be blamed here). For the SSL layer I implemented a workaround Chris suggested. Dawid On Mon, Jan 6, 2020 at 5:38 PM Chris Hegarty wrote: > > I agree with David, this is an expected difference between the socket > layers on different operating systems. The different behaviours are > acceptable implementations on said operating systems. Unfortunately, > this results in different behaviour of the Java socket (and TCP socket > channel) APIs, when running on different platforms (as you are > observing). > > I am not suggesting that you do this, but if the intention is that the > server issues a forceful / abortive close, then ( at least in the > minimal repo case ) one could: > > // force RST > clientChannel.setOption(StandardSocketOptions.SO_LINGER, 0); > > I read over the Lucene issue that you sited; it appears that the > higher-level problem you are encountering is how/when to issue an HTTP > retry request when there is a socket or perceived SSL exception. And how > the SSLSocketImpl handles the difference between the above socket layer > behaviours. > > SSLSocket aggregates both the network socket operations and SSL protocol > implementation, which makes it more difficult to discern where the > underlying issue is coming from, than say, if one was to use > SocketChannel along with SSLEngine. However, I would expect that any > SSLException that has a SocketException as its cause could be considered > as a "network problem" - as described by the SocketException message. > The wrapping SSLException in such a case should provide additional > SSL protocol specific information to help with diagnosis, e.g. the > current protocol state. > > I'm sure that this is not the answer that you were looking for, but > maybe you can consider it when making a decision on whether this can be > fixed in the HTTP Client that you are using. > > -Chris. > > On 3 Jan 2020, at 13:53, David Lloyd wrote: > > This is, AFAICT, expected based on the differences between the socket layers of the various operating systems involved and their handling of closed sockets. If you write a similar test program in C using OS specific APIs, I believe you will see similar results. I don't think this is a problem with the JDK, nor is it likely to be something that can be fixed in the JDK (since the error reported by the OS is, as far as I know, unlikely to be universally sufficient to extrapolate the exact cause of failure). > > From job at kimmeringer.de Tue Jan 7 17:34:04 2020 From: job at kimmeringer.de (Lothar Kimmeringer) Date: Tue, 7 Jan 2020 18:34:04 +0100 Subject: Reading from a closed socket: different behavior between Linux and other operating systems In-Reply-To: References: <3a035a1c-53ed-18c2-e8d9-bd42ed263366@oracle.com> Message-ID: Am 07.01.2020 um 09:19 schrieb Dawid Weiss: > I can understand how this behavior can be considered > platform-dependent but it's still a bit surprising that it shows > consistent behavior on everything except Linux... (we originally > thought it's Windows to be blamed here). Not the only one. Open, close and open again a ServerSocket for the same port in a short time (i.e. less than one minute) and you will get bind exceptions on Linux where other systems happily work. Cheers, Lothar From anthony.scarpino at oracle.com Tue Jan 7 19:39:28 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 7 Jan 2020 11:39:28 -0800 Subject: RFR[14] 8236098:AlgorithmConstraints:permits method not throwing IAEx when primitives are empty Message-ID: <462ad0dc-10d1-a7b1-6e1b-b538838ea3e3@oracle.com> Hi, I need a code review for a JCK issue where the AlgorithmConstraints spec says that permits() with a null or empty primitives throws an IllegalArgumentsException. The code currently allows no primitive and continues with the check. Additionally, there was a needed change to JSSE SeverHello that was sending a null primitives. https://cr.openjdk.java.net/~ascarpino/8236098/webrev/ Tony From anthony.scarpino at oracle.com Tue Jan 7 19:40:38 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 7 Jan 2020 11:40:38 -0800 Subject: RFR[14] 8236098:AlgorithmConstraints:permits method not throwing IAEx when primitives are empty In-Reply-To: <462ad0dc-10d1-a7b1-6e1b-b538838ea3e3@oracle.com> References: <462ad0dc-10d1-a7b1-6e1b-b538838ea3e3@oracle.com> Message-ID: FYI, there is no test included because the JCK test already exists. On 1/7/20 11:39 AM, Anthony Scarpino wrote: > Hi, > > I need a code review for a JCK issue where the AlgorithmConstraints spec > says that permits() with a null or empty primitives throws an > IllegalArgumentsException.? The code currently allows no primitive and > continues with the check.? Additionally, there was a needed change to > JSSE SeverHello that was sending a null primitives. > > https://cr.openjdk.java.net/~ascarpino/8236098/webrev/ > > Tony From xuelei.fan at oracle.com Tue Jan 7 20:52:35 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 7 Jan 2020 12:52:35 -0800 Subject: RFR[14] 8236098:AlgorithmConstraints:permits method not throwing IAEx when primitives are empty In-Reply-To: References: <462ad0dc-10d1-a7b1-6e1b-b538838ea3e3@oracle.com> Message-ID: <5c7809a6-2749-c349-77f2-9fa345922195@oracle.com> Looks fine to me. Thanks, Xuelei On 1/7/2020 11:40 AM, Anthony Scarpino wrote: > FYI, there is no test included because the JCK test already exists. > > On 1/7/20 11:39 AM, Anthony Scarpino wrote: >> Hi, >> >> I need a code review for a JCK issue where the AlgorithmConstraints >> spec says that permits() with a null or empty primitives throws an >> IllegalArgumentsException.? The code currently allows no primitive and >> continues with the check.? Additionally, there was a needed change to >> JSSE SeverHello that was sending a null primitives. >> >> https://cr.openjdk.java.net/~ascarpino/8236098/webrev/ >> >> Tony From archana.nogriya at uk.ibm.com Wed Jan 8 11:47:23 2020 From: archana.nogriya at uk.ibm.com (Archana Nogriya) Date: Wed, 8 Jan 2020 11:47:23 +0000 Subject: [14] RFR JDK-8229243 "SunPKCS11-Solaris provider tests failing on Solaris 11.4" - Copyrights issue GPLV2 with no classpath exception Message-ID: Hi, We have noticed that, src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11gcm2.h has been added couple of month back, and in new copyright added with GPLV2 but there is no mention of Classpath exception. Since this code is part of release and distributed please can I request you to add Classpath exception in the copyrights. http://mail.openjdk.java.net/pipermail/security-dev/2019-October/020758.html bug: https://bugs.openjdk.java.net/browse/JDK-8229243 Webrev: http://cr.openjdk.java.net/~valeriep/8229243/webrev.00/ Many Thanks & Regards Archana Nogriya Java Runtimes Development and Project Manager IBM Hursley IBM United Kingdom Ltd internet email: archana.nogriya 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 1983-01-06 at gmx.net Thu Jan 9 22:44:16 2020 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Thu, 9 Jan 2020 23:44:16 +0100 Subject: [14] RFR JDK-8229243 "SunPKCS11-Solaris provider tests failing on Solaris 11.4" In-Reply-To: References: Message-ID: Am 2020-01-07 um 14:39 schrieb Archana Nogriya: > Hi, > > We have noticed that, > src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11gcm2.h has been > added couple of month back, and in new copyright added with GPLV2 but > there is no mention of Classpath exception. > > Since this code is part of release and distributed please can I request > you to add Classpath exception in the copyrights. > > http://mail.openjdk.java.net/pipermail/security-dev/2019-October/020758.html > > bug: https://bugs.openjdk.java.net/browse/JDK-8229243 > Webrev: http://cr.openjdk.java.net/~valeriep/8229243/webrev.00/ It is an antipattern to throw IAE on null. An NPE is appropriate here. See also Objects class for this. From valerie.peng at oracle.com Fri Jan 10 00:12:06 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 9 Jan 2020 16:12:06 -0800 Subject: [14] RFR JDK-8229243 "SunPKCS11-Solaris provider tests failing on Solaris 11.4" In-Reply-To: References: Message-ID: <1ed8c8fa-e2a4-a249-8a8a-035716a9b844@oracle.com> Thanks for the report, I will file a bug and update the copyright accordingly. Regards, Valerie On 1/7/2020 5:39 AM, Archana Nogriya wrote: > Hi, > > We have noticed that, > src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11gcm2.h > has > been added couple of month back, and in new copyright added with GPLV2 > but there is no mention of Classpath exception. > > Since this code is part of release and distributed please can I > request you to add Classpath exception in the copyrights. > > _http://mail.openjdk.java.net/pipermail/security-dev/2019-October/020758.html_ > > > /bug: //_https://bugs.openjdk.java.net/browse/JDK-8229243_// > Webrev: //_http://cr.openjdk.java.net/~valeriep/8229243/webrev.00/_/ > > > > > > Many Thanks & Regards > Archana Nogriya > Java Runtimes Development and Project Manager > IBM Hursley > IBM United Kingdom Ltd > internet email: archana.nogriya 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 valerie.peng at oracle.com Fri Jan 10 00:37:26 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 9 Jan 2020 16:37:26 -0800 Subject: [14] RFR: 8236897: Fix the copyright header for pkcs11gcm2.h Message-ID: <6f7fd3c9-983c-66b0-4470-9978eb407165@oracle.com> Can someone help with this trivial review? Just a copyright update with Classpath exception. Bug: https://bugs.openjdk.java.net/browse/JDK-8236897 (Doc only w/ noreg-doc label added.) Webrev: http://cr.openjdk.java.net/~valeriep/8236897/webrev.00/ Thanks, Valerie From weijun.wang at oracle.com Fri Jan 10 00:53:45 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 10 Jan 2020 08:53:45 +0800 Subject: [14] RFR: 8236897: Fix the copyright header for pkcs11gcm2.h In-Reply-To: <6f7fd3c9-983c-66b0-4470-9978eb407165@oracle.com> References: <6f7fd3c9-983c-66b0-4470-9978eb407165@oracle.com> Message-ID: The change looks fine. Thanks, Max > On Jan 10, 2020, at 8:37 AM, Valerie Peng wrote: > > > Can someone help with this trivial review? Just a copyright update with Classpath exception. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8236897 (Doc only w/ noreg-doc label added.) > > Webrev: http://cr.openjdk.java.net/~valeriep/8236897/webrev.00/ > > Thanks, > > Valerie > From valerie.peng at oracle.com Sat Jan 11 00:29:41 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 10 Jan 2020 16:29:41 -0800 Subject: [15] RFR 8216012: Infinite loop in RSA KeyPairGenerator In-Reply-To: <1a312490-6f9a-9dc8-d5b3-8764623328e4@oracle.com> References: <1a312490-6f9a-9dc8-d5b3-8764623328e4@oracle.com> Message-ID: <42e3ebe5-96ac-9c0f-fe18-f61292370cae@oracle.com> Hi Masanori Yano, Your fix looks fine, I just made some minor update to the regression test, e.g. add more debugging output, removing unnecessary code and cases, etc. I put your initial contribution at http://cr.openjdk.java.net/~valeriep/8216012/webrev.00 I made some update and latest fix is at http://cr.openjdk.java.net/~valeriep/8216012/webrev.01 Can you please take a look and let me know if you are ok with webrev.01? If all are well, I will proceed to integrate it into JDK15. Thanks, Valerie On 12/2/2019 4:40 PM, Valerie Peng wrote: > Hi Masanori Yano, > > I can help sponsoring this fix. However, as it's a P4, it may be > targeted to 15 depending on the available cycles. > > Are you a contributor for OpenJDK? > > If not, please see http://openjdk.java.net/contribute/ for the process. > > Thanks, > Valerie > On 10/8/2019 8:10 PM, yano-masanori at fujitsu.com wrote: >> Hello. >> >> I would like to contribute for JDK-8216012. >> >> The cause of this problem is RSAKeyPairGenerator that doesn't check >> the public exponent even though the algorithm of rsa key generation >> can use only odd exponent number. >> >> To generate a KeyPair, the RSAKeyPairGenerator finds two random primes >> P and Q, and calculate Phi = (P - 1) * (Q - 1). If Phi is not relative >> prime to exponent, RSAKeyPairGenerator retry from the first. >> >> The value of Phi must be an even number because P and Q are odd numbers. >> If exponent is an even number, the greatest common divisor cannot >> be 1 because one of common divisors is 2 which is bigger than 1. >> Therefore, generateKeyPair() method of RSAKeyPairGenerator cannot exit >> the retrying loop. >> >> To solve this problem, I propose to check whether the public exponent >> is even number. >> >> Please sponsor the following change. >> >> diff --git >> a/src/java.base/share/classes/sun/security/rsa/RSAKeyPairGenerator.java >> b/src/java.base/share/classes/sun/security/rsa/RSAKeyPairGenerator.java >> --- >> a/src/java.base/share/classes/sun/security/rsa/RSAKeyPairGenerator.java >> +++ >> b/src/java.base/share/classes/sun/security/rsa/RSAKeyPairGenerator.java >> @@ -96,6 +96,10 @@ >> ????????????????? throw new InvalidAlgorithmParameterException >> ????????????????????????? ("Public exponent must be 3 or larger"); >> ????????????? } >> +??????????? if (!tmpPublicExponent.testBit(0)) { >> +??????????????? throw new InvalidAlgorithmParameterException >> +??????????????????????? ("Public exponent must be an odd number"); >> +??????????? } >> ????????????? if (tmpPublicExponent.bitLength() > tmpKeySize) { >> ????????????????? throw new InvalidAlgorithmParameterException >> ????????????????????????? ("Public exponent must be smaller than key >> size"); >> diff --git >> a/test/jdk/sun/security/rsa/TestKeyPairGeneratorExponent.java >> b/test/jdk/sun/security/rsa/TestKeyPairGeneratorExponent.java >> new file mode 100644 >> --- /dev/null >> +++ b/test/jdk/sun/security/rsa/TestKeyPairGeneratorExponent.java >> @@ -0,0 +1,65 @@ >> +import java.math.BigInteger; >> + >> +import java.security.*; >> +import java.security.interfaces.*; >> +import java.security.spec.*; >> + >> +/** >> + * @test >> + * @bug 8216012 >> + * @summary Tests the RSA public key exponent for KeyPairGenerator >> + * @run main/timeout=60 TestKeyPairGeneratorExponent >> + */ >> +public class TestKeyPairGeneratorExponent { >> +??? private static int keyLen = 512; >> + >> +??? private static BigInteger[] validExponents = new BigInteger[] { >> +??????? RSAKeyGenParameterSpec.F0, >> +??????? RSAKeyGenParameterSpec.F4, >> +??????? // Since 512-bit exponent is larger than? modulus, fails in >> RSAPublicKeyImpl.checkExponentRange(). >> +??????? BigInteger.ONE.shiftLeft(keyLen - 1).subtract(BigInteger.ONE) >> +??? }; >> + >> +??? private static BigInteger[] invalidExponents = new BigInteger[] { >> +??????? BigInteger.valueOf(-1), >> +??????? BigInteger.ZERO, >> +??????? BigInteger.ONE, >> +??????? // 8216012: An even number causes infinite loop. >> +??????? BigInteger.valueOf(4), >> +??????? BigInteger.ONE.shiftLeft(keyLen) >> +??? }; >> + >> +??? public static void testValidExponents(KeyPairGenerator kpg, >> BigInteger exponent) { >> +??????? try { >> +??????????? kpg.initialize(new RSAKeyGenParameterSpec(keyLen, >> exponent)); >> +??????????? kpg.generateKeyPair(); >> +??????? } catch(InvalidAlgorithmParameterException iape){ >> +??????????? throw new RuntimeException("Unexpected Exception: " + >> iape); >> +??????? } >> +??? } >> + >> +??? public static void testInvalidExponents(KeyPairGenerator kpg, >> BigInteger exponent) { >> +??????? try { >> +??????????? kpg.initialize(new RSAKeyGenParameterSpec(keyLen, >> exponent)); >> +??????????? kpg.generateKeyPair(); >> +??????????? throw new RuntimeException("Expected >> InvalidAlgorithmParameterException was not thrown."); >> +??????? } catch(InvalidAlgorithmParameterException iape){ >> +??????????? // Expected InvalidAlgorithmParameterException was >> thrown.OK >> +??????? } >> +??? } >> + >> +??? public static void main(String[] args) throws Exception { >> +??????? Provider provider = Security.getProvider("SunRsaSign"); >> +??????? KeyPairGenerator kpg; >> + >> +??????? for(BigInteger validExponent : validExponents) { >> +??????????? kpg = KeyPairGenerator.getInstance("RSA", provider); >> +??????????? testValidExponents(kpg, validExponent); >> +??????? } >> + >> +??????? for(BigInteger invalidExponent : invalidExponents) { >> +??????????? kpg = KeyPairGenerator.getInstance("RSA", provider); >> +??????????? testInvalidExponents(kpg, invalidExponent); >> +??????? } >> +??? } >> +} >> >> Regards, >> Masanori Yano From sean.coffey at oracle.com Mon Jan 13 10:28:18 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 13 Jan 2020 10:28:18 +0000 Subject: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent() In-Reply-To: References: Message-ID: some off line comments suggested that I could move the jar initialization checks to the EventHelper class. With that in place, the EventHelper utility class should never initialize the logging framework early during jar initialization. http://cr.openjdk.java.net/~coffeys/webrev.8234466.v4/webrev/ regards, Sean. On 16/12/2019 14:15, Se?n Coffey wrote: > The recent crypto event logging mechanism (JDK-8148188) has introduced > a regression whereby the System Logger may be invoked too early in the > bootstrap phase. This causes issue when JarFile objects are locked by > JarFile verifier initialization code. The logging work records an X509 > Certificate which is used during the jar file > verification/initialization phase and hence leads to an early > System.Logger call. > > One thread invokes the initialization of the Logger framework via > ServiceLoader and waits to lock a JarFile in use via another thread. > Unfortunately that other thread is also waiting for the System Logger > to initialize. For now, I think we can avoid the early Logger > initialization via use of a ThreadLocal. I've tried reproducing the > reported issue through manual and automated tests but to no avail. > I've added a new ServiceLoader test which has concurrent threads. One > is loading providers and another is initializing JarFile verifiers. > Hope it helps improve code coverage for the future. > > JBS record: https://bugs.openjdk.java.net/browse/JDK-8234466 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8234466/webrev/ > From daniel.fuchs at oracle.com Mon Jan 13 13:14:43 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 13 Jan 2020 13:14:43 +0000 Subject: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent() In-Reply-To: References: Message-ID: <71307cd4-5a3e-e558-1a70-c735cf14331e@oracle.com> On 13/01/2020 10:28, Se?n Coffey wrote: > some off line comments suggested that I could move the jar > initialization checks to the EventHelper class. With that in place, the > EventHelper utility class should never initialize the logging framework > early during jar initialization. > > http://cr.openjdk.java.net/~coffeys/webrev.8234466.v4/webrev/ Looks good to me Se?n. Probably safer than the other alternatives. 46 private static boolean loggingSecurity; that should be volatile too. best regard, -- daniel > > regards, > Sean. > > On 16/12/2019 14:15, Se?n Coffey wrote: >> The recent crypto event logging mechanism (JDK-8148188) has introduced >> a regression whereby the System Logger may be invoked too early in the >> bootstrap phase. This causes issue when JarFile objects are locked by >> JarFile verifier initialization code. The logging work records an X509 >> Certificate which is used during the jar file >> verification/initialization phase and hence leads to an early >> System.Logger call. >> >> One thread invokes the initialization of the Logger framework via >> ServiceLoader and waits to lock a JarFile in use via another thread. >> Unfortunately that other thread is also waiting for the System Logger >> to initialize. For now, I think we can avoid the early Logger >> initialization via use of a ThreadLocal. I've tried reproducing the >> reported issue through manual and automated tests but to no avail. >> I've added a new ServiceLoader test which has concurrent threads. One >> is loading providers and another is initializing JarFile verifiers. >> Hope it helps improve code coverage for the future. >> >> JBS record: https://bugs.openjdk.java.net/browse/JDK-8234466 >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8234466/webrev/ >> From chris.hegarty at oracle.com Mon Jan 13 14:06:22 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 13 Jan 2020 14:06:22 +0000 Subject: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent() In-Reply-To: <71307cd4-5a3e-e558-1a70-c735cf14331e@oracle.com> References: <71307cd4-5a3e-e558-1a70-c735cf14331e@oracle.com> Message-ID: <299806F4-A7DA-41DB-8CD8-D227F820ECFE@oracle.com> > On 13 Jan 2020, at 13:14, Daniel Fuchs wrote: > > On 13/01/2020 10:28, Se?n Coffey wrote: >> some off line comments suggested that I could move the jar initialization checks to the EventHelper class. With that in place, the EventHelper utility class should never initialize the logging framework early during jar initialization. >> http://cr.openjdk.java.net/~coffeys/webrev.8234466.v4/webrev/ > > Looks good to me Se?n. Probably safer than the other alternatives. +1 I?m going to ask, since I cannot find the answer myself. Why are some securityLogger::log invocations guarded with isLoggingSecurity, and others not? With this change shouldn?t all invocations be guarded, since it is isLoggingSecurity that assigns securityLogger a value? -Chris From daniel.fuchs at oracle.com Mon Jan 13 14:38:43 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 13 Jan 2020 14:38:43 +0000 Subject: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent() In-Reply-To: <299806F4-A7DA-41DB-8CD8-D227F820ECFE@oracle.com> References: <71307cd4-5a3e-e558-1a70-c735cf14331e@oracle.com> <299806F4-A7DA-41DB-8CD8-D227F820ECFE@oracle.com> Message-ID: <6f5ccf9f-f138-1d76-24dc-68115166f36a@oracle.com> On 13/01/2020 14:06, Chris Hegarty wrote: > I?m going to ask, since I cannot find the answer myself. Why are some securityLogger::log invocations guarded with isLoggingSecurity, and others not? With this change shouldn?t all invocations be guarded, since it is isLoggingSecurity that assigns securityLogger a value? Argh! Well spotted chris! -- daniel From sean.coffey at oracle.com Mon Jan 13 17:19:48 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 13 Jan 2020 17:19:48 +0000 Subject: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent() In-Reply-To: <6f5ccf9f-f138-1d76-24dc-68115166f36a@oracle.com> References: <71307cd4-5a3e-e558-1a70-c735cf14331e@oracle.com> <299806F4-A7DA-41DB-8CD8-D227F820ECFE@oracle.com> <6f5ccf9f-f138-1d76-24dc-68115166f36a@oracle.com> Message-ID: Thanks for the reviews. All callers of EventHelper log methods are ensuring that isLoggingSecurity() is true before proceeding. I've added an assert null check in the 4 logger methods to ensure expectations are in place. http://cr.openjdk.java.net/~coffeys/webrev.8234466.v5/webrev/ Hope this helps, Sean. On 13/01/2020 14:38, Daniel Fuchs wrote: > On 13/01/2020 14:06, Chris Hegarty wrote: >> I?m going to ask, since I cannot find the answer myself. Why are some >> securityLogger::log invocations guarded with isLoggingSecurity, and >> others not? With this change shouldn?t all invocations be guarded, >> since it is isLoggingSecurity that assigns securityLogger a value? > > Argh! Well spotted chris! > > -- daniel From chris.hegarty at oracle.com Mon Jan 13 17:21:03 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 13 Jan 2020 17:21:03 +0000 Subject: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent() In-Reply-To: References: <71307cd4-5a3e-e558-1a70-c735cf14331e@oracle.com> <299806F4-A7DA-41DB-8CD8-D227F820ECFE@oracle.com> <6f5ccf9f-f138-1d76-24dc-68115166f36a@oracle.com> Message-ID: <2D1BAE15-0A47-43D5-87C5-14C80A974B86@oracle.com> > On 13 Jan 2020, at 17:19, Se?n Coffey wrote: > > Thanks for the reviews. All callers of EventHelper log methods are ensuring that isLoggingSecurity() is true before proceeding. I've added an assert null check in the 4 logger methods to ensure expectations are in place. > > http://cr.openjdk.java.net/~coffeys/webrev.8234466.v5/webrev/ Thanks. LGTM. -Chris. From daniel.fuchs at oracle.com Mon Jan 13 17:42:57 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 13 Jan 2020 17:42:57 +0000 Subject: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent() In-Reply-To: <2D1BAE15-0A47-43D5-87C5-14C80A974B86@oracle.com> References: <71307cd4-5a3e-e558-1a70-c735cf14331e@oracle.com> <299806F4-A7DA-41DB-8CD8-D227F820ECFE@oracle.com> <6f5ccf9f-f138-1d76-24dc-68115166f36a@oracle.com> <2D1BAE15-0A47-43D5-87C5-14C80A974B86@oracle.com> Message-ID: <78428501-7395-3a50-1d7a-6c1f84acc1c1@oracle.com> On 13/01/2020 17:21, Chris Hegarty wrote: >> On 13 Jan 2020, at 17:19, Se?n Coffey wrote: >> >> Thanks for the reviews. All callers of EventHelper log methods are ensuring that isLoggingSecurity() is true before proceeding. I've added an assert null check in the 4 logger methods to ensure expectations are in place. >> >> http://cr.openjdk.java.net/~coffeys/webrev.8234466.v5/webrev/ > Thanks. LGTM. > Likewise. Thanks Se?n! best regards, -- daniel From Alan.Bateman at oracle.com Mon Jan 13 18:50:28 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 Jan 2020 18:50:28 +0000 Subject: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent() In-Reply-To: References: Message-ID: <43190e76-8028-3419-b07c-58e8cd6aeb50@oracle.com> On 13/01/2020 10:28, Se?n Coffey wrote: > some off line comments suggested that I could move the jar > initialization checks to the EventHelper class. With that in place, > the EventHelper utility class should never initialize the logging > framework early during jar initialization. > > http://cr.openjdk.java.net/~coffeys/webrev.8234466.v4/webrev/ Thanks for the update. JAR file verification is tricky and important not to attempt to run arbitrary code while doing that, esp. anything that might need to load a class or resource from the class path. So I think the approach (in v5) looks okay.? A minor nit in JarFile is that it should be "static final".? Also you might want to replace or change the @summary in both tests to make it clearer that the tests attempt to trigger class loading from the class loader during JAR file verification. -Alan. From sean.coffey at oracle.com Mon Jan 13 21:18:19 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 13 Jan 2020 21:18:19 +0000 Subject: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent() In-Reply-To: <43190e76-8028-3419-b07c-58e8cd6aeb50@oracle.com> References: <43190e76-8028-3419-b07c-58e8cd6aeb50@oracle.com> Message-ID: Thanks Alan. Updates made and changes pushed. regards, Sean. On 13/01/2020 18:50, Alan Bateman wrote: > On 13/01/2020 10:28, Se?n Coffey wrote: >> some off line comments suggested that I could move the jar >> initialization checks to the EventHelper class. With that in place, >> the EventHelper utility class should never initialize the logging >> framework early during jar initialization. >> >> http://cr.openjdk.java.net/~coffeys/webrev.8234466.v4/webrev/ > Thanks for the update. JAR file verification is tricky and important > not to attempt to run arbitrary code while doing that, esp. anything > that might need to load a class or resource from the class path. So I > think the approach (in v5) looks okay.? A minor nit in JarFile is that > it should be "static final".? Also you might want to replace or change > the @summary in both tests to make it clearer that the tests attempt > to trigger class loading from the class loader during JAR file > verification. > > -Alan. From igor.ignatyev at oracle.com Tue Jan 14 17:03:38 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 14 Jan 2020 09:03:38 -0800 Subject: RFR(S): 8236111 : narrow allowSmartActionArgs disabling In-Reply-To: <916e0375-abba-9945-b845-0fd4198513f0@oracle.com> References: <423ea31a-ebf8-4cba-72a4-6fbb934f7789@oracle.com> <0BA46866-3DEA-44BF-B87C-2B59B84196C9@oracle.com> <916e0375-abba-9945-b845-0fd4198513f0@oracle.com> Message-ID: Joe and Roger, thank you for your reviews. security-libs guys, could you please take a look? Thanks, -- Igor > On Jan 2, 2020, at 12:58 PM, Roger Riggs wrote: > > The core lib changes look ok. > > Roger > On Jan 2, 2020, at 1:26 PM, Joe Darcy wrote: > > The removal of the existing TEST.properties files look fine. > > Please also solicit feedback from the security libs team as their area is affected. > > Roger, FYI the serial filter tests are updated as part of this changeset. > > Cheers, > > -Joe > > On 12/23/2019 8:13 PM, Igor Ignatyev wrote: >> Thanks David. >> >> core-libs folks, could you please review jdk part of this patch? >> >> Thanks, >> -- Igor >> >>> On Dec 23, 2019, at 1:33 PM, David Holmes wrote: >>> >>> Hi Igor, >>> >>> Hotspot changes seem fine. Can't comment on jdk tests. >>> >>> Thanks, >>> David >>> >>> On 24/12/2019 6:42 am, Igor Ignatyev wrote: >>>> ping? >>>>> On Dec 17, 2019, at 11:30 AM, Igor Ignatyev wrote: >>>>> >>>>> http://cr.openjdk.java.net/~iignatyev/8236111/webrev.00/ >>>>>> 31 lines changed: 20 ins; 11 del; 0 mod; >>>>> Hi all, >>>>> >>>>> could you please review this small patch which enables allowSmartActionArgs in hotspot and jdk test suites and disables them in a small number of test directories? the patch also removes TEST.properties files which enabled allowSmartActionArgs as they aren't needed anymore. >>>>> >>>>> from JBS: >>>>>> currently, allowSmartActionArgs is disabled for the whole hotspot and jdk test suites and enabled just in few places. this makes it a bit harder for people to use smart action arguments in these test suites as they have to not to forget to enable them. and given in all the other test suites, smart action arguments are enabled, it can be confusing and frustrating. >>>>> >>>>> testing: tier1-5 >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8236111 >>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8236111/webrev.00/ >>>>> >>>>> Thanks, >>>>> -- Igor From anthony.scarpino at oracle.com Tue Jan 14 19:21:24 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 14 Jan 2020 11:21:24 -0800 Subject: RFR[14]: Release notes for weak Named Curve disabling Message-ID: <2a44087b-0086-e607-8f5c-8b386c319b01@oracle.com> I need a review of the release notes for adding named curves to the disabledAlgorithms properties. https://bugs.openjdk.java.net/browse/JDK-8236730 thanks Tony From bradford.wetmore at oracle.com Tue Jan 14 19:33:46 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 14 Jan 2020 11:33:46 -0800 Subject: RFR(14) 8236957: Obvious typo in java/security/spec/RSAMultiPrimePrivateCrtKeySpec.java Message-ID: <645c8e9c-497a-63ac-b9f1-a01e38fc1a0e@oracle.com> A simple one character fix, the modulus n should have been listed, not q. https://bugs.openjdk.java.net/browse/JDK-8236957 http://cr.openjdk.java.net/~wetmore/8236957/webrev.00/ Thanks, Brad From anthony.scarpino at oracle.com Tue Jan 14 19:38:12 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 14 Jan 2020 11:38:12 -0800 Subject: RFR(14) 8236957: Obvious typo in java/security/spec/RSAMultiPrimePrivateCrtKeySpec.java In-Reply-To: <645c8e9c-497a-63ac-b9f1-a01e38fc1a0e@oracle.com> References: <645c8e9c-497a-63ac-b9f1-a01e38fc1a0e@oracle.com> Message-ID: <3952538e-646b-19c5-fca0-52e628ff6f7a@oracle.com> On 1/14/20 11:33 AM, Bradford Wetmore wrote: > A simple one character fix, the modulus n should have been listed, not q. > > https://bugs.openjdk.java.net/browse/JDK-8236957 > http://cr.openjdk.java.net/~wetmore/8236957/webrev.00/ > > Thanks, > > Brad Looks good. Tony From sean.mullan at oracle.com Tue Jan 14 22:17:48 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 14 Jan 2020 17:17:48 -0500 Subject: RFR(S): 8236111 : narrow allowSmartActionArgs disabling In-Reply-To: References: <423ea31a-ebf8-4cba-72a4-6fbb934f7789@oracle.com> <0BA46866-3DEA-44BF-B87C-2B59B84196C9@oracle.com> <916e0375-abba-9945-b845-0fd4198513f0@oracle.com> Message-ID: <9ac57907-90cf-936e-07c3-c14082a1bd35@oracle.com> dropping core-libs-dev and hotspot-dev On 1/14/20 12:03 PM, Igor Ignatyev wrote: > Joe and Roger, thank you for your reviews. > > security-libs guys, could you please take a look? Sure, but what is allowSmartActionArgs? I'm assuming this is a jtreg feature but I have not heard of it before. Thanks, Sean > > Thanks, > -- Igor > >> On Jan 2, 2020, at 12:58 PM, Roger Riggs wrote: >> >> The core lib changes look ok. >> >> Roger > >> On Jan 2, 2020, at 1:26 PM, Joe Darcy wrote: >> >> The removal of the existing TEST.properties files look fine. >> >> Please also solicit feedback from the security libs team as their area is affected. >> >> Roger, FYI the serial filter tests are updated as part of this changeset. >> >> Cheers, >> >> -Joe >> >> On 12/23/2019 8:13 PM, Igor Ignatyev wrote: >>> Thanks David. >>> >>> core-libs folks, could you please review jdk part of this patch? >>> >>> Thanks, >>> -- Igor >>> >>>> On Dec 23, 2019, at 1:33 PM, David Holmes wrote: >>>> >>>> Hi Igor, >>>> >>>> Hotspot changes seem fine. Can't comment on jdk tests. >>>> >>>> Thanks, >>>> David >>>> >>>> On 24/12/2019 6:42 am, Igor Ignatyev wrote: >>>>> ping? >>>>>> On Dec 17, 2019, at 11:30 AM, Igor Ignatyev wrote: >>>>>> >>>>>> http://cr.openjdk.java.net/~iignatyev/8236111/webrev.00/ >>>>>>> 31 lines changed: 20 ins; 11 del; 0 mod; >>>>>> Hi all, >>>>>> >>>>>> could you please review this small patch which enables allowSmartActionArgs in hotspot and jdk test suites and disables them in a small number of test directories? the patch also removes TEST.properties files which enabled allowSmartActionArgs as they aren't needed anymore. >>>>>> >>>>>> from JBS: >>>>>>> currently, allowSmartActionArgs is disabled for the whole hotspot and jdk test suites and enabled just in few places. this makes it a bit harder for people to use smart action arguments in these test suites as they have to not to forget to enable them. and given in all the other test suites, smart action arguments are enabled, it can be confusing and frustrating. >>>>>> >>>>>> testing: tier1-5 >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8236111 >>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8236111/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> -- Igor > From igor.ignatyev at oracle.com Tue Jan 14 22:29:08 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 14 Jan 2020 14:29:08 -0800 Subject: RFR(S): 8236111 : narrow allowSmartActionArgs disabling In-Reply-To: <9ac57907-90cf-936e-07c3-c14082a1bd35@oracle.com> References: <423ea31a-ebf8-4cba-72a4-6fbb934f7789@oracle.com> <0BA46866-3DEA-44BF-B87C-2B59B84196C9@oracle.com> <916e0375-abba-9945-b845-0fd4198513f0@oracle.com> <9ac57907-90cf-936e-07c3-c14082a1bd35@oracle.com> Message-ID: <050B548D-D1CD-4AD9-83B2-5A4CFEA4DE6D@oracle.com> Hi Sean, allowSmartActionArgs has been added quite recently to jtreg by CODETOOLS-7902352[1], it is a jtreg feature which replaces ${X} in jtreg actions (such as @run) with the value of X where X is either a "test" system property[2] or a name from @requires context[3]. [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902352 [2] https://hg.openjdk.java.net/code-tools/jtreg/raw-file/90e9eef3d433/src/share/doc/javatest/regtest/tag-spec.html#testvars [3] https://hg.openjdk.java.net/code-tools/jtreg/raw-file/90e9eef3d433/src/share/doc/javatest/regtest/tag-spec.html#requires_names Thanks, -- Igor > On Jan 14, 2020, at 2:17 PM, Sean Mullan wrote: > > dropping core-libs-dev and hotspot-dev > > On 1/14/20 12:03 PM, Igor Ignatyev wrote: >> Joe and Roger, thank you for your reviews. >> security-libs guys, could you please take a look? > > Sure, but what is allowSmartActionArgs? I'm assuming this is a jtreg feature but I have not heard of it before. > > Thanks, > Sean > > >> Thanks, >> -- Igor >>> On Jan 2, 2020, at 12:58 PM, Roger Riggs wrote: >>> >>> The core lib changes look ok. >>> >>> Roger >>> On Jan 2, 2020, at 1:26 PM, Joe Darcy wrote: >>> >>> The removal of the existing TEST.properties files look fine. >>> >>> Please also solicit feedback from the security libs team as their area is affected. >>> >>> Roger, FYI the serial filter tests are updated as part of this changeset. >>> >>> Cheers, >>> >>> -Joe >>> >>> On 12/23/2019 8:13 PM, Igor Ignatyev wrote: >>>> Thanks David. >>>> >>>> core-libs folks, could you please review jdk part of this patch? >>>> >>>> Thanks, >>>> -- Igor >>>> >>>>> On Dec 23, 2019, at 1:33 PM, David Holmes wrote: >>>>> >>>>> Hi Igor, >>>>> >>>>> Hotspot changes seem fine. Can't comment on jdk tests. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 24/12/2019 6:42 am, Igor Ignatyev wrote: >>>>>> ping? >>>>>>> On Dec 17, 2019, at 11:30 AM, Igor Ignatyev wrote: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~iignatyev/8236111/webrev.00/ >>>>>>>> 31 lines changed: 20 ins; 11 del; 0 mod; >>>>>>> Hi all, >>>>>>> >>>>>>> could you please review this small patch which enables allowSmartActionArgs in hotspot and jdk test suites and disables them in a small number of test directories? the patch also removes TEST.properties files which enabled allowSmartActionArgs as they aren't needed anymore. >>>>>>> >>>>>>> from JBS: >>>>>>>> currently, allowSmartActionArgs is disabled for the whole hotspot and jdk test suites and enabled just in few places. this makes it a bit harder for people to use smart action arguments in these test suites as they have to not to forget to enable them. and given in all the other test suites, smart action arguments are enabled, it can be confusing and frustrating. >>>>>>> >>>>>>> testing: tier1-5 >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8236111 >>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8236111/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> -- Igor From joe.darcy at oracle.com Tue Jan 14 22:54:02 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 14 Jan 2020 14:54:02 -0800 Subject: RFR(S): 8236111 : narrow allowSmartActionArgs disabling In-Reply-To: <050B548D-D1CD-4AD9-83B2-5A4CFEA4DE6D@oracle.com> References: <423ea31a-ebf8-4cba-72a4-6fbb934f7789@oracle.com> <0BA46866-3DEA-44BF-B87C-2B59B84196C9@oracle.com> <916e0375-abba-9945-b845-0fd4198513f0@oracle.com> <9ac57907-90cf-936e-07c3-c14082a1bd35@oracle.com> <050B548D-D1CD-4AD9-83B2-5A4CFEA4DE6D@oracle.com> Message-ID: <592a336c-b8e8-9142-f640-16b586715fbd@oracle.com> PS Some additional context, the "smart action args" feature is being commonly used is that regression tests for preview features can say ??? --enable-preview -source {$jdk.version} without needing to be updated explicitly for each release. HTH, -Joe On 1/14/2020 2:29 PM, Igor Ignatyev wrote: > Hi Sean, > > allowSmartActionArgs has been added quite recently to jtreg by CODETOOLS-7902352[1], it is a jtreg feature which replaces ${X} in jtreg actions (such as @run) with the value of X where X is either a "test" system property[2] or a name from @requires context[3]. > > [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902352 > [2] https://hg.openjdk.java.net/code-tools/jtreg/raw-file/90e9eef3d433/src/share/doc/javatest/regtest/tag-spec.html#testvars > [3] https://hg.openjdk.java.net/code-tools/jtreg/raw-file/90e9eef3d433/src/share/doc/javatest/regtest/tag-spec.html#requires_names > > Thanks, > -- Igor > > >> On Jan 14, 2020, at 2:17 PM, Sean Mullan wrote: >> >> dropping core-libs-dev and hotspot-dev >> >> On 1/14/20 12:03 PM, Igor Ignatyev wrote: >>> Joe and Roger, thank you for your reviews. >>> security-libs guys, could you please take a look? >> Sure, but what is allowSmartActionArgs? I'm assuming this is a jtreg feature but I have not heard of it before. >> >> Thanks, >> Sean >> >> >>> Thanks, >>> -- Igor >>>> On Jan 2, 2020, at 12:58 PM, Roger Riggs wrote: >>>> >>>> The core lib changes look ok. >>>> >>>> Roger >>>> On Jan 2, 2020, at 1:26 PM, Joe Darcy wrote: >>>> >>>> The removal of the existing TEST.properties files look fine. >>>> >>>> Please also solicit feedback from the security libs team as their area is affected. >>>> >>>> Roger, FYI the serial filter tests are updated as part of this changeset. >>>> >>>> Cheers, >>>> >>>> -Joe >>>> >>>> On 12/23/2019 8:13 PM, Igor Ignatyev wrote: >>>>> Thanks David. >>>>> >>>>> core-libs folks, could you please review jdk part of this patch? >>>>> >>>>> Thanks, >>>>> -- Igor >>>>> >>>>>> On Dec 23, 2019, at 1:33 PM, David Holmes wrote: >>>>>> >>>>>> Hi Igor, >>>>>> >>>>>> Hotspot changes seem fine. Can't comment on jdk tests. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 24/12/2019 6:42 am, Igor Ignatyev wrote: >>>>>>> ping? >>>>>>>> On Dec 17, 2019, at 11:30 AM, Igor Ignatyev wrote: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~iignatyev/8236111/webrev.00/ >>>>>>>>> 31 lines changed: 20 ins; 11 del; 0 mod; >>>>>>>> Hi all, >>>>>>>> >>>>>>>> could you please review this small patch which enables allowSmartActionArgs in hotspot and jdk test suites and disables them in a small number of test directories? the patch also removes TEST.properties files which enabled allowSmartActionArgs as they aren't needed anymore. >>>>>>>> >>>>>>>> from JBS: >>>>>>>>> currently, allowSmartActionArgs is disabled for the whole hotspot and jdk test suites and enabled just in few places. this makes it a bit harder for people to use smart action arguments in these test suites as they have to not to forget to enable them. and given in all the other test suites, smart action arguments are enabled, it can be confusing and frustrating. >>>>>>>> testing: tier1-5 >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8236111 >>>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8236111/webrev.00/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> -- Igor From sean.mullan at oracle.com Wed Jan 15 00:25:46 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 14 Jan 2020 19:25:46 -0500 Subject: RFR(S): 8236111 : narrow allowSmartActionArgs disabling In-Reply-To: <592a336c-b8e8-9142-f640-16b586715fbd@oracle.com> References: <423ea31a-ebf8-4cba-72a4-6fbb934f7789@oracle.com> <0BA46866-3DEA-44BF-B87C-2B59B84196C9@oracle.com> <916e0375-abba-9945-b845-0fd4198513f0@oracle.com> <9ac57907-90cf-936e-07c3-c14082a1bd35@oracle.com> <050B548D-D1CD-4AD9-83B2-5A4CFEA4DE6D@oracle.com> <592a336c-b8e8-9142-f640-16b586715fbd@oracle.com> Message-ID: <664a360b-2dc2-40c1-f5bb-0c5549a2b1c6@oracle.com> Ok, thanks for the additional info - the changes look fine to me. --Sean On 1/14/20 5:54 PM, Joe Darcy wrote: > PS Some additional context, the "smart action args" feature is being > commonly used is that regression tests for preview features can say > > ??? --enable-preview -source {$jdk.version} > > without needing to be updated explicitly for each release. > > HTH, > > -Joe > > On 1/14/2020 2:29 PM, Igor Ignatyev wrote: >> Hi Sean, >> >> allowSmartActionArgs has been added quite recently to jtreg by >> CODETOOLS-7902352[1], it is a jtreg feature which replaces ${X} in >> jtreg actions (such as @run) with the value of X where X is either a >> "test" system property[2] or a name from @requires context[3]. >> >> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902352 >> [2] >> https://hg.openjdk.java.net/code-tools/jtreg/raw-file/90e9eef3d433/src/share/doc/javatest/regtest/tag-spec.html#testvars >> >> [3] >> https://hg.openjdk.java.net/code-tools/jtreg/raw-file/90e9eef3d433/src/share/doc/javatest/regtest/tag-spec.html#requires_names >> >> >> Thanks, >> -- Igor >> >> >>> On Jan 14, 2020, at 2:17 PM, Sean Mullan wrote: >>> >>> dropping core-libs-dev and hotspot-dev >>> >>> On 1/14/20 12:03 PM, Igor Ignatyev wrote: >>>> Joe and Roger, thank you for your reviews. >>>> security-libs guys, could you please take a look? >>> Sure, but what is allowSmartActionArgs? I'm assuming this is a jtreg >>> feature but I have not heard of it before. >>> >>> Thanks, >>> Sean >>> >>> >>>> Thanks, >>>> -- Igor >>>>> On Jan 2, 2020, at 12:58 PM, Roger Riggs >>>>> wrote: >>>>> >>>>> The core lib changes look ok. >>>>> >>>>> Roger >>>>> On Jan 2, 2020, at 1:26 PM, Joe Darcy wrote: >>>>> >>>>> The removal of the existing TEST.properties files look fine. >>>>> >>>>> Please also solicit feedback from the security libs team as their >>>>> area is affected. >>>>> >>>>> Roger, FYI the serial filter tests are updated as part of this >>>>> changeset. >>>>> >>>>> Cheers, >>>>> >>>>> -Joe >>>>> >>>>> On 12/23/2019 8:13 PM, Igor Ignatyev wrote: >>>>>> Thanks David. >>>>>> >>>>>> core-libs folks, could you please review jdk part of this patch? >>>>>> >>>>>> Thanks, >>>>>> -- Igor >>>>>> >>>>>>> On Dec 23, 2019, at 1:33 PM, David Holmes >>>>>>> wrote: >>>>>>> >>>>>>> Hi Igor, >>>>>>> >>>>>>> Hotspot changes seem fine. Can't comment on jdk tests. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 24/12/2019 6:42 am, Igor Ignatyev wrote: >>>>>>>> ping? >>>>>>>>> On Dec 17, 2019, at 11:30 AM, Igor Ignatyev >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~iignatyev/8236111/webrev.00/ >>>>>>>>>> 31 lines changed: 20 ins; 11 del; 0 mod; >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> could you please review this small patch which enables >>>>>>>>> allowSmartActionArgs in hotspot and jdk test suites and >>>>>>>>> disables them in a small number of test directories? the patch >>>>>>>>> also removes TEST.properties files which enabled >>>>>>>>> allowSmartActionArgs as they aren't needed anymore. >>>>>>>>> >>>>>>>>> from JBS: >>>>>>>>>> currently, allowSmartActionArgs is disabled for the whole >>>>>>>>>> hotspot and jdk test suites and enabled just in few places. >>>>>>>>>> this makes it a bit harder for people to use smart action >>>>>>>>>> arguments in these test suites as they have to not to forget >>>>>>>>>> to enable them. and given in all the other test suites, smart >>>>>>>>>> action arguments are enabled, it can be confusing and >>>>>>>>>> frustrating. >>>>>>>>> testing: tier1-5 >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8236111 >>>>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8236111/webrev.00/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> -- Igor From sean.mullan at oracle.com Wed Jan 15 16:07:22 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 15 Jan 2020 11:07:22 -0500 Subject: RFR[14]: Release notes for weak Named Curve disabling In-Reply-To: <2a44087b-0086-e607-8f5c-8b386c319b01@oracle.com> References: <2a44087b-0086-e607-8f5c-8b386c319b01@oracle.com> Message-ID: This looks fine. The only suggestion I would make is to change: "With over 50 named curves available" to "With 47 weak named curves to be disabled" which I think is a little more clear/related to this issue. When I initially read that, I mistakenly thought over 50 curves were being disabled, although I figured out what you were saying is that those are all of the supported curves... --Sean On 1/14/20 2:21 PM, Anthony Scarpino wrote: > I need a review of the release notes for adding named curves to the > disabledAlgorithms properties. > > https://bugs.openjdk.java.net/browse/JDK-8236730 > > thanks > > Tony From valerie.peng at oracle.com Wed Jan 15 19:54:04 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 15 Jan 2020 11:54:04 -0800 Subject: [15] RFR 8216012: Infinite loop in RSA KeyPairGenerator In-Reply-To: References: <1a312490-6f9a-9dc8-d5b3-8764623328e4@oracle.com> <42e3ebe5-96ac-9c0f-fe18-f61292370cae@oracle.com> Message-ID: Will do, thanks for the confirmation~ Valerie On 1/15/2020 12:08 AM, yano-masanori at fujitsu.com wrote: > Hi Valerie, > > Thank you for updating my test. It looks fine to me. > Please start to integrate it into JDK15. > > Regards, > Masanori Yano > >> -----Original Message----- >> From: Valerie Peng >> Sent: Saturday, January 11, 2020 9:30 AM >> To: security-dev at openjdk.java.net; yano-masanori at fujitsu.com >> Subject: [15] RFR 8216012: Infinite loop in RSA KeyPairGenerator >> >> Hi Masanori Yano, >> >> Your fix looks fine, I just made some minor update to the regression test, e.g. >> add more debugging output, removing unnecessary code and cases, etc. >> >> I put your initial contribution at >> http://cr.openjdk.java.net/~valeriep/8216012/webrev.00 >> >> I made some update and latest fix is at >> http://cr.openjdk.java.net/~valeriep/8216012/webrev.01 >> >> Can you please take a look and let me know if you are ok with webrev.01? >> If all are well, I will proceed to integrate it into JDK15. >> >> Thanks, >> >> Valerie >> >> On 12/2/2019 4:40 PM, Valerie Peng wrote: >>> Hi Masanori Yano, >>> >>> I can help sponsoring this fix. However, as it's a P4, it may be >>> targeted to 15 depending on the available cycles. >>> >>> Are you a contributor for OpenJDK? >>> >>> If not, please see http://openjdk.java.net/contribute/ for the process. >>> >>> Thanks, >>> Valerie >>> On 10/8/2019 8:10 PM, yano-masanori at fujitsu.com wrote: >>>> Hello. >>>> >>>> I would like to contribute for JDK-8216012. >>>> >>>> The cause of this problem is RSAKeyPairGenerator that doesn't check >>>> the public exponent even though the algorithm of rsa key generation >>>> can use only odd exponent number. >>>> >>>> To generate a KeyPair, the RSAKeyPairGenerator finds two random >>>> primes P and Q, and calculate Phi = (P - 1) * (Q - 1). If Phi is not >>>> relative prime to exponent, RSAKeyPairGenerator retry from the first. >>>> >>>> The value of Phi must be an even number because P and Q are odd >> numbers. >>>> If exponent is an even number, the greatest common divisor cannot be >>>> 1 because one of common divisors is 2 which is bigger than 1. >>>> Therefore, generateKeyPair() method of RSAKeyPairGenerator cannot >>>> exit the retrying loop. >>>> >>>> To solve this problem, I propose to check whether the public exponent >>>> is even number. >>>> >>>> Please sponsor the following change. >>>> >>>> diff --git >>>> a/src/java.base/share/classes/sun/security/rsa/RSAKeyPairGenerator.ja >>>> va >>>> b/src/java.base/share/classes/sun/security/rsa/RSAKeyPairGenerator.ja >>>> va >>>> --- >>>> a/src/java.base/share/classes/sun/security/rsa/RSAKeyPairGenerator.ja >>>> va >>>> +++ >>>> b/src/java.base/share/classes/sun/security/rsa/RSAKeyPairGenerator.ja >>>> va >>>> @@ -96,6 +96,10 @@ >>>> ????????????????? throw new InvalidAlgorithmParameterException >>>> ????????????????????????? ("Public exponent must be 3 or larger"); >>>> ????????????? } >>>> +??????????? if (!tmpPublicExponent.testBit(0)) { >>>> +??????????????? throw new InvalidAlgorithmParameterException >>>> +??????????????????????? ("Public exponent must be an odd >> number"); >>>> +??????????? } >>>> ????????????? if (tmpPublicExponent.bitLength() > tmpKeySize) { >>>> ????????????????? throw new InvalidAlgorithmParameterException >>>> ????????????????????????? ("Public exponent must be smaller than >> key >>>> size"); diff --git >>>> a/test/jdk/sun/security/rsa/TestKeyPairGeneratorExponent.java >>>> b/test/jdk/sun/security/rsa/TestKeyPairGeneratorExponent.java >>>> new file mode 100644 >>>> --- /dev/null >>>> +++ b/test/jdk/sun/security/rsa/TestKeyPairGeneratorExponent.java >>>> @@ -0,0 +1,65 @@ >>>> +import java.math.BigInteger; >>>> + >>>> +import java.security.*; >>>> +import java.security.interfaces.*; >>>> +import java.security.spec.*; >>>> + >>>> +/** >>>> + * @test >>>> + * @bug 8216012 >>>> + * @summary Tests the RSA public key exponent for KeyPairGenerator >>>> + * @run main/timeout=60 TestKeyPairGeneratorExponent */ public >>>> +class TestKeyPairGeneratorExponent { >>>> +??? private static int keyLen = 512; >>>> + >>>> +??? private static BigInteger[] validExponents = new BigInteger[] { >>>> +??????? RSAKeyGenParameterSpec.F0, >>>> +??????? RSAKeyGenParameterSpec.F4, >>>> +??????? // Since 512-bit exponent is larger than? modulus, fails in >>>> RSAPublicKeyImpl.checkExponentRange(). >>>> +??????? BigInteger.ONE.shiftLeft(keyLen - >>>> +1).subtract(BigInteger.ONE) >>>> +??? }; >>>> + >>>> +??? private static BigInteger[] invalidExponents = new BigInteger[] >>>> +{ >>>> +??????? BigInteger.valueOf(-1), >>>> +??????? BigInteger.ZERO, >>>> +??????? BigInteger.ONE, >>>> +??????? // 8216012: An even number causes infinite loop. >>>> +??????? BigInteger.valueOf(4), >>>> +??????? BigInteger.ONE.shiftLeft(keyLen) >>>> +??? }; >>>> + >>>> +??? public static void testValidExponents(KeyPairGenerator kpg, >>>> BigInteger exponent) { >>>> +??????? try { >>>> +??????????? kpg.initialize(new RSAKeyGenParameterSpec(keyLen, >>>> exponent)); >>>> +??????????? kpg.generateKeyPair(); >>>> +??????? } catch(InvalidAlgorithmParameterException iape){ >>>> +??????????? throw new RuntimeException("Unexpected Exception: " >> + >>>> iape); >>>> +??????? } >>>> +??? } >>>> + >>>> +??? public static void testInvalidExponents(KeyPairGenerator kpg, >>>> BigInteger exponent) { >>>> +??????? try { >>>> +??????????? kpg.initialize(new RSAKeyGenParameterSpec(keyLen, >>>> exponent)); >>>> +??????????? kpg.generateKeyPair(); >>>> +??????????? throw new RuntimeException("Expected >>>> InvalidAlgorithmParameterException was not thrown."); >>>> +??????? } catch(InvalidAlgorithmParameterException iape){ >>>> +??????????? // Expected InvalidAlgorithmParameterException was >>>> thrown.OK >>>> +??????? } >>>> +??? } >>>> + >>>> +??? public static void main(String[] args) throws Exception { >>>> +??????? Provider provider = Security.getProvider("SunRsaSign"); >>>> +??????? KeyPairGenerator kpg; >>>> + >>>> +??????? for(BigInteger validExponent : validExponents) { >>>> +??????????? kpg = KeyPairGenerator.getInstance("RSA", provider); >>>> +??????????? testValidExponents(kpg, validExponent); >>>> +??????? } >>>> + >>>> +??????? for(BigInteger invalidExponent : invalidExponents) { >>>> +??????????? kpg = KeyPairGenerator.getInstance("RSA", provider); >>>> +??????????? testInvalidExponents(kpg, invalidExponent); >>>> +??????? } >>>> +??? } >>>> +} >>>> >>>> Regards, >>>> Masanori Yano From yano-masanori at fujitsu.com Wed Jan 15 08:08:29 2020 From: yano-masanori at fujitsu.com (yano-masanori at fujitsu.com) Date: Wed, 15 Jan 2020 08:08:29 +0000 Subject: [15] RFR 8216012: Infinite loop in RSA KeyPairGenerator In-Reply-To: <42e3ebe5-96ac-9c0f-fe18-f61292370cae@oracle.com> References: <1a312490-6f9a-9dc8-d5b3-8764623328e4@oracle.com> <42e3ebe5-96ac-9c0f-fe18-f61292370cae@oracle.com> Message-ID: Hi Valerie, Thank you for updating my test. It looks fine to me. Please start to integrate it into JDK15. Regards, Masanori Yano > -----Original Message----- > From: Valerie Peng > Sent: Saturday, January 11, 2020 9:30 AM > To: security-dev at openjdk.java.net; yano-masanori at fujitsu.com > Subject: [15] RFR 8216012: Infinite loop in RSA KeyPairGenerator > > Hi Masanori Yano, > > Your fix looks fine, I just made some minor update to the regression test, e.g. > add more debugging output, removing unnecessary code and cases, etc. > > I put your initial contribution at > http://cr.openjdk.java.net/~valeriep/8216012/webrev.00 > > I made some update and latest fix is at > http://cr.openjdk.java.net/~valeriep/8216012/webrev.01 > > Can you please take a look and let me know if you are ok with webrev.01? > If all are well, I will proceed to integrate it into JDK15. > > Thanks, > > Valerie > > On 12/2/2019 4:40 PM, Valerie Peng wrote: > > Hi Masanori Yano, > > > > I can help sponsoring this fix. However, as it's a P4, it may be > > targeted to 15 depending on the available cycles. > > > > Are you a contributor for OpenJDK? > > > > If not, please see http://openjdk.java.net/contribute/ for the process. > > > > Thanks, > > Valerie > > On 10/8/2019 8:10 PM, yano-masanori at fujitsu.com wrote: > >> Hello. > >> > >> I would like to contribute for JDK-8216012. > >> > >> The cause of this problem is RSAKeyPairGenerator that doesn't check > >> the public exponent even though the algorithm of rsa key generation > >> can use only odd exponent number. > >> > >> To generate a KeyPair, the RSAKeyPairGenerator finds two random > >> primes P and Q, and calculate Phi = (P - 1) * (Q - 1). If Phi is not > >> relative prime to exponent, RSAKeyPairGenerator retry from the first. > >> > >> The value of Phi must be an even number because P and Q are odd > numbers. > >> If exponent is an even number, the greatest common divisor cannot be > >> 1 because one of common divisors is 2 which is bigger than 1. > >> Therefore, generateKeyPair() method of RSAKeyPairGenerator cannot > >> exit the retrying loop. > >> > >> To solve this problem, I propose to check whether the public exponent > >> is even number. > >> > >> Please sponsor the following change. > >> > >> diff --git > >> a/src/java.base/share/classes/sun/security/rsa/RSAKeyPairGenerator.ja > >> va > >> b/src/java.base/share/classes/sun/security/rsa/RSAKeyPairGenerator.ja > >> va > >> --- > >> a/src/java.base/share/classes/sun/security/rsa/RSAKeyPairGenerator.ja > >> va > >> +++ > >> b/src/java.base/share/classes/sun/security/rsa/RSAKeyPairGenerator.ja > >> va > >> @@ -96,6 +96,10 @@ > >> ????????????????? throw new InvalidAlgorithmParameterException > >> ????????????????????????? ("Public exponent must be 3 or larger"); > >> ????????????? } > >> +??????????? if (!tmpPublicExponent.testBit(0)) { > >> +??????????????? throw new InvalidAlgorithmParameterException > >> +??????????????????????? ("Public exponent must be an odd > number"); > >> +??????????? } > >> ????????????? if (tmpPublicExponent.bitLength() > tmpKeySize) { > >> ????????????????? throw new InvalidAlgorithmParameterException > >> ????????????????????????? ("Public exponent must be smaller than > key > >> size"); diff --git > >> a/test/jdk/sun/security/rsa/TestKeyPairGeneratorExponent.java > >> b/test/jdk/sun/security/rsa/TestKeyPairGeneratorExponent.java > >> new file mode 100644 > >> --- /dev/null > >> +++ b/test/jdk/sun/security/rsa/TestKeyPairGeneratorExponent.java > >> @@ -0,0 +1,65 @@ > >> +import java.math.BigInteger; > >> + > >> +import java.security.*; > >> +import java.security.interfaces.*; > >> +import java.security.spec.*; > >> + > >> +/** > >> + * @test > >> + * @bug 8216012 > >> + * @summary Tests the RSA public key exponent for KeyPairGenerator > >> + * @run main/timeout=60 TestKeyPairGeneratorExponent */ public > >> +class TestKeyPairGeneratorExponent { > >> +??? private static int keyLen = 512; > >> + > >> +??? private static BigInteger[] validExponents = new BigInteger[] { > >> +??????? RSAKeyGenParameterSpec.F0, > >> +??????? RSAKeyGenParameterSpec.F4, > >> +??????? // Since 512-bit exponent is larger than? modulus, fails in > >> RSAPublicKeyImpl.checkExponentRange(). > >> +??????? BigInteger.ONE.shiftLeft(keyLen - > >> +1).subtract(BigInteger.ONE) > >> +??? }; > >> + > >> +??? private static BigInteger[] invalidExponents = new BigInteger[] > >> +{ > >> +??????? BigInteger.valueOf(-1), > >> +??????? BigInteger.ZERO, > >> +??????? BigInteger.ONE, > >> +??????? // 8216012: An even number causes infinite loop. > >> +??????? BigInteger.valueOf(4), > >> +??????? BigInteger.ONE.shiftLeft(keyLen) > >> +??? }; > >> + > >> +??? public static void testValidExponents(KeyPairGenerator kpg, > >> BigInteger exponent) { > >> +??????? try { > >> +??????????? kpg.initialize(new RSAKeyGenParameterSpec(keyLen, > >> exponent)); > >> +??????????? kpg.generateKeyPair(); > >> +??????? } catch(InvalidAlgorithmParameterException iape){ > >> +??????????? throw new RuntimeException("Unexpected Exception: " > + > >> iape); > >> +??????? } > >> +??? } > >> + > >> +??? public static void testInvalidExponents(KeyPairGenerator kpg, > >> BigInteger exponent) { > >> +??????? try { > >> +??????????? kpg.initialize(new RSAKeyGenParameterSpec(keyLen, > >> exponent)); > >> +??????????? kpg.generateKeyPair(); > >> +??????????? throw new RuntimeException("Expected > >> InvalidAlgorithmParameterException was not thrown."); > >> +??????? } catch(InvalidAlgorithmParameterException iape){ > >> +??????????? // Expected InvalidAlgorithmParameterException was > >> thrown.OK > >> +??????? } > >> +??? } > >> + > >> +??? public static void main(String[] args) throws Exception { > >> +??????? Provider provider = Security.getProvider("SunRsaSign"); > >> +??????? KeyPairGenerator kpg; > >> + > >> +??????? for(BigInteger validExponent : validExponents) { > >> +??????????? kpg = KeyPairGenerator.getInstance("RSA", provider); > >> +??????????? testValidExponents(kpg, validExponent); > >> +??????? } > >> + > >> +??????? for(BigInteger invalidExponent : invalidExponents) { > >> +??????????? kpg = KeyPairGenerator.getInstance("RSA", provider); > >> +??????????? testInvalidExponents(kpg, invalidExponent); > >> +??????? } > >> +??? } > >> +} > >> > >> Regards, > >> Masanori Yano From ecki at zusammenkunft.net Thu Jan 16 10:32:23 2020 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 16 Jan 2020 10:32:23 +0000 Subject: LDAP Channel Binding Message-ID: Hello, Some updates: Microsoft moved their automatic update of the LDAP policies in Windows Server updates to March 2020 (but still recommend to activate it earlier). And I did some tests: when you turn on the mandatory LDAP Signing, then simple binds or Digest-md5 binds over LDAP are rejected by NTDS. Both work over ldaps: (Implicite TLS, did not check STARTTLS). DIGEST-MD5 without TLS is also possible, but you have to request qop=auth-int. (Sidenode AD will reject digest-md5 with Auth-int over TLS). I did not Test GSSAPI or SPNEGO yet. The mandatory LDAP channel binding does not seem to make a problem/change. I suspect it only applies to Kerberos or NTLM which I still need to test. Gruss Bernd PS: testcode https://gist.github.com/ecki/cdd7a14575b7dca10da8d362974731a0 -- http://bernd.eckenfels.net On Wed, Dec 18, 2019 at 4:17 AM +0100, > wrote: Hello, Microsoft just released an Security Advisory, announcing that upcoming Windows Server Versions will turn on mandatory TLS Channel Binding (or signing) on LDAP Servers. They also remind Administrators to install the KB patch and turn it on. Do you have experiences with this, will Java (8) work with the setting of "mandatory is supported" (1) and/or "mandatory" (2) for this key, and if not what is the plan here? https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023 https://support.microsoft.com/en-us/help/4034879/how-to-add-the-ldapenforcechannelbinding-registry-entry Gruss Bernd -- http://bernd.eckenfels.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Fri Jan 17 10:59:42 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 17 Jan 2020 10:59:42 +0000 Subject: RFR: 8218021: jarsigner strips the execute permission when signing a .zip file Message-ID: Hi, Looking to introduce some JDK private functionality which will help preserve internal zip file attribute permissions when jarsigner is run on a zip file. Some of the logic is taken from the recent work carried out in this area for zipfs API. https://bugs.openjdk.java.net/browse/JDK-8218021 http://cr.openjdk.java.net/~coffeys/webrev.8218021/webrev/ regards, Sean. From 1983-01-06 at gmx.net Fri Jan 17 11:10:53 2020 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Fri, 17 Jan 2020 12:10:53 +0100 Subject: RFR: 8218021: jarsigner strips the execute permission when signing a .zip file In-Reply-To: References: Message-ID: <595ecc7e-7b63-9d4d-2548-f1d31b179687@gmx.net> Am 2020-01-17 um 11:59 schrieb Se?n Coffey: > Hi, > > Looking to introduce some JDK private functionality which will help > preserve internal zip file attribute permissions when jarsigner is run > on a zip file. Some of the logic is taken from the recent work carried > out in this area for zipfs API. > > https://bugs.openjdk.java.net/browse/JDK-8218021 > http://cr.openjdk.java.net/~coffeys/webrev.8218021/webrev/ Make sure that the following idiom also works on tr_TR or alike: > if (this.name.toLowerCase().endsWith(ZIP_FILE_EXT) From sean.coffey at oracle.com Fri Jan 17 13:07:21 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 17 Jan 2020 13:07:21 +0000 Subject: RFR: 8218021: jarsigner strips the execute permission when signing a .zip file In-Reply-To: <567aa080d022617cb45d188c7472fa60fd3317db.camel@paratix.ch> References: <567aa080d022617cb45d188c7472fa60fd3317db.camel@paratix.ch> Message-ID: <79146371-82a6-ea63-4f5a-5e9c3a719495@oracle.com> Hi Philipp, On 17/01/2020 12:40, Philipp Kunz wrote: > Hi Sean, > > Nice patch. I wonder why permissions should be preserved only in zip > files. Jar files also are zip files, according to the jar file specs, > and hence, shouldn't jar files benefit of preserving permissions, too? Thanks for your comments. The jar tool has never been interested in the posix permissions fields for the individual entries. Such a change could yield more interoperability issues. Such a change would also need much more consideration The zip tool on the other hand has always populated this field and I think the case at hand is unique here (preserving attributes already created by non-java tools) > > The file name extension is most often zip for zip files and jar for jar > files but is that really a safe assumption? I would not expect it > always. Removing Yes, I didn't see any easy way to distinguish a zip file from a jar file without being more invasive and scanning file attributes for that file. I could take that approach if it's deemed necessary. regards, Sean. > >> if (zf.getName().toLowerCase().endsWith(".zip")) { > along with similar code in ZipFile would avoid discussing that question > and the test would not have to check that files with another name > extension than zip don't preserve permissions. > > Philipp > > > On Fri, 2020-01-17 at 10:59 +0000, Se?n Coffey wrote: >> Hi, >> >> Looking to introduce some JDK private functionality which will help >> preserve internal zip file attribute permissions when jarsigner is >> run >> on a zip file. Some of the logic is taken from the recent work >> carried >> out in this area for zipfs API. >> >> https://bugs.openjdk.java.net/browse/JDK-8218021 >> http://cr.openjdk.java.net/~coffeys/webrev.8218021/webrev/ >> >> regards, >> Sean. >> >> From matthias.baesken at sap.com Fri Jan 17 13:09:58 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 17 Jan 2020 13:09:58 +0000 Subject: jtreg test security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java instabilities Message-ID: Hello, I wonder if you have some input regarding the following issue. I noticed a couple of instabilities (in jdk13 and higher) in the test security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java . The test sometimes fails when validating the "validity interval" of OCSP responses : Example output is like : certpath: OCSP response validity interval is from Wed Dec 04 01:05:27 CET 2019 certpath: Checking validity of OCSP response on: Wed Dec 04 01:39:15 CET 2019 <--------- default interval is system time "on" machine +/- 15 minutes , this is seen as valid by OpenJDK ... java.lang.RuntimeException: TEST FAILED: couldn't determine EE certificate status at ValidatePathWithParams.validate(ValidatePathWithParams.java:177) at LuxTrustCA.main(LuxTrustCA.java:186) 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:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:832) stdout contains : Received exception: java.security.cert.CertPathValidatorException: Response is unreliable: its validity interval is out-of-date So our system time "on" machine ( 01:39:15 CET 2019 +/- 15 minutes ) does not contain the time from OCSP response ( 01:05:27 CET 2019) . Reason is unclear , of course the time on the test machine could be wrong but we see the issue on multiple machines and when looking into the system times of the machines they look fine . Maybe the time info from the OCSP response is wrong , at least it looks like this is the issue here . Have you seen similar issues (also in other tests dealing with OCSP response validity checks) ? Do you think that increasing the acceptance interval e.g. by setting it to -Dcom.sun.security.ocsp.clockSkew=9000000 in security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java would be okay ? ( I'd like to add a little bit more tracing too so that in case of such errors it is easier to understand the issue ) Best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From philipp.kunz at paratix.ch Fri Jan 17 12:40:46 2020 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Fri, 17 Jan 2020 13:40:46 +0100 Subject: RFR: 8218021: jarsigner strips the execute permission when signing a .zip file In-Reply-To: References: Message-ID: <567aa080d022617cb45d188c7472fa60fd3317db.camel@paratix.ch> Hi Sean, Nice patch. I wonder why permissions should be preserved only in zip files. Jar files also are zip files, according to the jar file specs, and hence, shouldn't jar files benefit of preserving permissions, too? The file name extension is most often zip for zip files and jar for jar files but is that really a safe assumption? I would not expect it always. Removing > if (zf.getName().toLowerCase().endsWith(".zip")) { along with similar code in ZipFile would avoid discussing that question and the test would not have to check that files with another name extension than zip don't preserve permissions. Philipp On Fri, 2020-01-17 at 10:59 +0000, Se?n Coffey wrote: > Hi, > > Looking to introduce some JDK private functionality which will help > preserve internal zip file attribute permissions when jarsigner is > run > on a zip file. Some of the logic is taken from the recent work > carried > out in this area for zipfs API. > > https://bugs.openjdk.java.net/browse/JDK-8218021 > http://cr.openjdk.java.net/~coffeys/webrev.8218021/webrev/ > > regards, > Sean. > > From lance.andersen at oracle.com Fri Jan 17 20:23:51 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 17 Jan 2020 15:23:51 -0500 Subject: RFR: 8218021: jarsigner strips the execute permission when signing a .zip file In-Reply-To: References: Message-ID: HI Sean, I think the change looks reasonable and I would keep it focused on its current intent for zip files given the problem you were addressing. The test also looks reasonable. Did you give any consideration to throwing a SkippedException if posixAttributes are not supported? Also remember to update your copyright year prior to pushing? Best Lance > On Jan 17, 2020, at 5:59 AM, Se?n Coffey wrote: > > Hi, > > Looking to introduce some JDK private functionality which will help preserve internal zip file attribute permissions when jarsigner is run on a zip file. Some of the logic is taken from the recent work carried out in this area for zipfs API. > > https://bugs.openjdk.java.net/browse/JDK-8218021 > http://cr.openjdk.java.net/~coffeys/webrev.8218021/webrev/ > > regards, > Sean. > > 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 1983-01-06 at gmx.net Sat Jan 18 20:39:08 2020 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Sat, 18 Jan 2020 21:39:08 +0100 Subject: LDAP Channel Binding In-Reply-To: References: Message-ID: <6a60ed26-962a-918f-08df-b9ed5315d4bc@gmx.net> Am 2020-01-16 um 11:32 schrieb Bernd Eckenfels: > Hello, > > Some updates: > > Microsoft moved their automatic update of the LDAP policies in Windows Server updates to March 2020 (but still recommend to activate it earlier). > > And I did some tests: when you turn on the mandatory LDAP Signing, then simple binds or Digest-md5 binds over LDAP are rejected by NTDS. Both work over ldaps: (Implicite TLS, did not check STARTTLS). DIGEST-MD5 without TLS is also possible, but you have to request qop=auth-int. (Sidenode AD will reject digest-md5 with Auth-int over TLS). I did not Test GSSAPI or SPNEGO yet. > > The mandatory LDAP channel binding does not seem to make a problem/change. I suspect it only applies to Kerberos or NTLM which I still need to test. That is confusing because: https://bugs.openjdk.java.net/browse/JDK-6491070 I am excited to see your GSSAPI mech results. You cannot test SPENGO because the Java SASL factory does not suppor the GSS-SPNEGO SASL mech. > PS: testcode https://gist.github.com/ecki/cdd7a14575b7dca10da8d362974731a0 You code looks wrong. Retrieving data from RootDSE does not require a successful bind. It will work anonymously. You need to go down the tree. Look at ldapsearch(1), if you don't provide -Y GSSAPI, it will perform a simple search for supportedSASLMechanisms and pick the best one it supports. This is the same as obtaining the root naming contexts, this can be done anonymously too. Michael From ecki at zusammenkunft.net Sun Jan 19 07:03:05 2020 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sun, 19 Jan 2020 07:03:05 +0000 Subject: LDAP Channel Binding In-Reply-To: References: , <6a60ed26-962a-918f-08df-b9ed5315d4bc@gmx.net>, Message-ID: Hello, The getattribute is not needed for the test, the new signing policy server setting will abort already at the bind call with an exception. But yes, you can also use other searches to be sure. They did not fail with simple bind inside TLS even with mandatory channel binding. You said it is confusing, but the bug you mentioned is only a valid feature request, it does not talk about failing binds. I would assume that Kerberos needs the binding token and the others not. Unfortunatelly the doc from Microsoft is quite incomplete and confusing. So has anybody seeing failing TLS binds yet and if so, in which condition? It is also not clear why AD proposes the auth. quality of protection from digest-md5 if it is configured to reject it. So if somebody can get Microsoft to look into this and provide details, that would be great. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: Michael Osipov <1983-01-06 at gmx.net> Gesendet: Saturday, January 18, 2020 9:39:08 PM An: Bernd Eckenfels ; security-dev at openjdk.java.net Betreff: Re: LDAP Channel Binding Am 2020-01-16 um 11:32 schrieb Bernd Eckenfels: > Hello, > > Some updates: > > Microsoft moved their automatic update of the LDAP policies in Windows Server updates to March 2020 (but still recommend to activate it earlier). > > And I did some tests: when you turn on the mandatory LDAP Signing, then simple binds or Digest-md5 binds over LDAP are rejected by NTDS. Both work over ldaps: (Implicite TLS, did not check STARTTLS). DIGEST-MD5 without TLS is also possible, but you have to request qop=auth-int. (Sidenode AD will reject digest-md5 with Auth-int over TLS). I did not Test GSSAPI or SPNEGO yet. > > The mandatory LDAP channel binding does not seem to make a problem/change. I suspect it only applies to Kerberos or NTLM which I still need to test. That is confusing because: https://bugs.openjdk.java.net/browse/JDK-6491070 I am excited to see your GSSAPI mech results. You cannot test SPENGO because the Java SASL factory does not suppor the GSS-SPNEGO SASL mech. > PS: testcode https://gist.github.com/ecki/cdd7a14575b7dca10da8d362974731a0 You code looks wrong. Retrieving data from RootDSE does not require a successful bind. It will work anonymously. You need to go down the tree. Look at ldapsearch(1), if you don't provide -Y GSSAPI, it will perform a simple search for supportedSASLMechanisms and pick the best one it supports. This is the same as obtaining the root naming contexts, this can be done anonymously too. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1983-01-06 at gmx.net Sun Jan 19 10:15:57 2020 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Sun, 19 Jan 2020 11:15:57 +0100 Subject: LDAP Channel Binding In-Reply-To: References: <6a60ed26-962a-918f-08df-b9ed5315d4bc@gmx.net> Message-ID: <4b76bb2a-ced9-ba6f-5e08-62d2df3e9b2c@gmx.net> Am 2020-01-19 um 08:02 schrieb Bernd Eckenfels: > You said it is confusing, but the bug you mentioned is only a valid > feature request, it does not talk about failing binds. I would assume > that Kerberos needs the binding token and the others not. > Unfortunatelly the doc from Microsoft is quite incomplete and > confusing. The problem is that JSSE Sun Impl documentation does not even mention TLS channel binding. To make things worse, I agree with you, Microsoft's documentation is horrible. It does not say whether we are talking about GSS-API channel binding or TLS channel biding. The best I have comeup with is https://github.com/WinRb/rubyntlm/issues/27 https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2008/dd639324(v=vs.90)?redirectedfrom=MSDN > So has anybody seeing failing TLS binds yet and if so, in which > condition? Yes, see https://stackoverflow.com/q/59756206/696632 What I can say is tht in our company auth-int has been mandatatory for several months now and my Java code always used auth-conf with GSSAPI mech w/o any flaws. > It is also not clear why AD proposes the auth. quality of protection > from digest-md5 if it is configured to reject it. So if somebody can > get Microsoft to look into this and provide details, that would be > great. > > Gruss Bernd > > > -- http://bernd.eckenfels.net ________________________________ Von: > Michael Osipov <1983-01-06 at gmx.net> Gesendet: Saturday, January 18, > 2020 9:39:08 PM An: Bernd Eckenfels ; > security-dev at openjdk.java.net > Betreff: Re: LDAP Channel Binding > > Am 2020-01-16 um 11:32 schrieb Bernd Eckenfels: >> Hello, >> >> Some updates: >> >> Microsoft moved their automatic update of the LDAP policies in >> Windows Server updates to March 2020 (but still recommend to >> activate it earlier). >> >> And I did some tests: when you turn on the mandatory LDAP Signing, >> then simple binds or Digest-md5 binds over LDAP are rejected by >> NTDS. Both work over ldaps: (Implicite TLS, did not check >> STARTTLS). DIGEST-MD5 without TLS is also possible, but you have to >> request qop=auth-int. (Sidenode AD will reject digest-md5 with >> Auth-int over TLS). I did not Test GSSAPI or SPNEGO yet. >> >> The mandatory LDAP channel binding does not seem to make a >> problem/change. I suspect it only applies to Kerberos or NTLM which >> I still need to test. > > That is confusing because: > https://bugs.openjdk.java.net/browse/JDK-6491070 > > I am excited to see your GSSAPI mech results. You cannot test SPENGO > because the Java SASL factory does not suppor the GSS-SPNEGO SASL > mech. > >> PS: testcode >> https://gist.github.com/ecki/cdd7a14575b7dca10da8d362974731a0 > > You code looks wrong. Retrieving data from RootDSE does not require > a successful bind. It will work anonymously. You need to go down the > tree. > > Look at ldapsearch(1), if you don't provide -Y GSSAPI, it will > perform a simple search for supportedSASLMechanisms and pick the best > one it supports. This is the same as obtaining the root naming > contexts, this can be done anonymously too. > > Michael > From sean.coffey at oracle.com Mon Jan 20 15:42:47 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 20 Jan 2020 15:42:47 +0000 Subject: RFR: 8218021: jarsigner strips the execute permission when signing a .zip file In-Reply-To: References: <567aa080d022617cb45d188c7472fa60fd3317db.camel@paratix.ch> <79146371-82a6-ea63-4f5a-5e9c3a719495@oracle.com> Message-ID: <41864c0e-fa66-047f-be66-a2dd1d94d463@oracle.com> Hi Philipp, thanks for the reply .. comments inline On 19/01/20 16:09, Philipp Kunz wrote: > Hi Sean, > > I figure that distinguishing zips and jars is ambiguous in a certain > way. After having signed a zip, it contains a manifest and is also a > jar file according to the specs. That would mean we would end up with > two kinds of jar files, those with permissions and those without, > depending on the file name extension of the files. That a tool named > jarsigner is successfully applied to a file is for me convincing enough > to consider that file a jar file or jarsigned would reject it however > it name ends. Yes, both zip and jar files enjoy the same format. jar files being created predominantly with the java based API/tools. > > Now when signing jar files (namely those with zip file name extension > but depending on the further discussion not necessary limited to those) > with permissions, I wonder if those permissions should also be subject > of the signature. I would consider a change of an executable flag for > example a change of the signed file just the same as a changed byte of > contents. The way jarsigner works now, loosing the permissions, we know > at least that the files contained in signed jars have certain > permission flags (none or defaults) immediately after having signed > them even though later manipulation would not be detected and, hence, > cannot be trusted even with a valid signature. historically, jar tool never recorded these permissions. As such, it should make no difference to how jarsigner operates on such files. The original report highlights the loss of data on files created with the zip utility. It think it's reasonable for jarsigner to preserve attributes in such a case. > > Far as I understand the current situation, jars and zips could be told > from one another only before signing depending on the presence or > absence of a manifest. After signing, however, a manifest is always > there. Looking at it that way, the "much more consideration" you > mention would have to take place now, wouldn't it? I'm not sure if there's much change in this area post fix. The classic jar tool doesn't add or read the file attributes at hand. The name check was useful to prevent any unintended behavioural changes in this area. > > I also wonder why the "if (filename.endsWith(".zip"))" piece of code > does not occur only in JarSigner. Why is it in ZipFile, too? One such > kind of if statement should have been enough, at first glance. There > may be a good and convincing explanation but I don't see it just like > that. On the other hand, having this if condition duplicated into > ZipFile looks like it could have an undesired side-effect elsewhere. I > also kind of miss another test case to make sure permission flags > continue to be disregarded for "non-zip" jar files. fair point. I should be able to remove this code. I can also improve the test case. > > And the comment of Michael Osipov is really frightening. Did you know > that i and I are two different characters in turkish both of which have > yet other capital/small counterparts? At that point maybe discussing > the file name extension distinction could easily become lengthier than > a discussion about consequences of supporting permissions for all jar > files. frightening ?? Yes, I've worked on such issues before. Thanks to Michael for pointing that out. I should be able to do a comparison using Locale.ROOT > > You mention "the case, at hand is unique here" and that made to occur > to me that if there is maybe only one person affected that he or she > could work around it more easily than changing the jdk. Is it really > important for most others? And is it really a bug at all? > > Another idea to work around compatibility issues would be to introduce > a flag for jarsigner, for example -p like with tar. Yet another idea > could be to refire the jar file specs and jar and jarsigner tools docs > accordingly. Let me have a think about this. A new flag in jarsigner may help. regards, Sean. > > Regards, > Philipp > > > On Fri, 2020-01-17 at 13:07 +0000, Se?n Coffey wrote: >> Hi Philipp, >> >> On 17/01/2020 12:40, Philipp Kunz wrote: >>> Hi Sean, >>> >>> Nice patch. I wonder why permissions should be preserved only in >>> zip >>> files. Jar files also are zip files, according to the jar file >>> specs, >>> and hence, shouldn't jar files benefit of preserving permissions, >>> too? >> Thanks for your comments. The jar tool has never been interested in >> the >> posix >> permissions fields for the individual entries. Such a change could >> yield >> more >> interoperability issues. Such a change would also need much more >> consideration >> >> The zip tool on the other hand has always populated this field and I >> think the case >> at hand is unique here (preserving attributes already created by >> non-java tools) >>> The file name extension is most often zip for zip files and jar for >>> jar >>> files but is that really a safe assumption? I would not expect it >>> always. Removing >> Yes, I didn't see any easy way to distinguish a zip file from a jar >> file >> without being >> more invasive and scanning file attributes for that file. I could >> take >> that approach >> if it's deemed necessary. >> >> regards, >> Sean. >>>> if (zf.getName().toLowerCase().endsWith(".zip")) { >>> along with similar code in ZipFile would avoid discussing that >>> question >>> and the test would not have to check that files with another name >>> extension than zip don't preserve permissions. >>> >>> Philipp >>> >>> >>> On Fri, 2020-01-17 at 10:59 +0000, Se?n Coffey wrote: >>>> Hi, >>>> >>>> Looking to introduce some JDK private functionality which will >>>> help >>>> preserve internal zip file attribute permissions when jarsigner >>>> is >>>> run >>>> on a zip file. Some of the logic is taken from the recent work >>>> carried >>>> out in this area for zipfs API. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8218021 >>>> http://cr.openjdk.java.net/~coffeys/webrev.8218021/webrev/ >>>> >>>> regards, >>>> Sean. >>>> >>>> From mbalao at redhat.com Mon Jan 20 19:16:57 2020 From: mbalao at redhat.com (Martin Balao) Date: Mon, 20 Jan 2020 16:16:57 -0300 Subject: SunPKCS11's Secmod and external modules in FIPS mode In-Reply-To: <54c3b155-5f71-11d9-f8e3-74a416263ff4@redhat.com> References: <54c3b155-5f71-11d9-f8e3-74a416263ff4@redhat.com> Message-ID: Ping. Any hint about this? Thanks, Martin.- On 12/20/19 10:03 PM, Martin Balao wrote: > Hello, > > SunPKCS11's Secmod in OpenJDK does not allow modules other than the NSS > Software Token to be configured in FIPS mode [1]. To give some context, > NSS represents modules internally with a structure called "struct > SECMODModuleStr" and the "fips" variable you see in [1] is the "isFIPS" > member of the module structure [2]. isFIPS is initialized by NSS to > false for all modules [3] but if the module spec string has a "FIPS" > flag, it may be turned to true [4]. Newer NSS versions (since bug > 1531267 [5] [6]) may set isFIPS to true for all modules when > /proc/sys/crypto/fips_enabled is 1 in Linux systems. As a result, as > soon as the system is in FIPS mode and the NSSDB has more than the NSS > Software Token module in it, OpenJDK refuses to initialize the SunPKCS11 > provider. You can see a real case with pk11-kit-trust as the external > module in RH1780335 [7]. > > This behavior has been the same since the very beginning of OpenJDK > (revision 2), and I couldn't find much information about it. There might > be a commit message previous to that. > > I'm trying to understand the rationale behind it and see what would be > the implications of removing the check (note: couldn't notice anything > in my quick test by removing it). > > Can someone give me a hint? > > Thanks, > Martin.- > > -- > [1] - > https://hg.openjdk.java.net/jdk/jdk/file/59ddac265649/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Secmod.java#l417 > [2] - > https://github.com/nss-dev/nss/blob/c1ff439ca931f53c318e7381636ed5889b3d66f1/lib/pk11wrap/secmodt.h#L49 > [3] - > https://github.com/nss-dev/nss/blob/a141cd68ece76118aebf8033c06d46a3692b55fe/lib/pk11wrap/pk11pars.c#L49 > [4] - > https://github.com/nss-dev/nss/blob/a141cd68ece76118aebf8033c06d46a3692b55fe/lib/pk11wrap/pk11pars.c#L819 > [5] - https://bugzilla.mozilla.org/show_bug.cgi?id=1531267 > [6] - https://hg.mozilla.org/projects/nss/rev/536fd7c9db5a > [7] - https://bugzilla.redhat.com/show_bug.cgi?id=1780335 > From ecki at zusammenkunft.net Mon Jan 20 20:07:14 2020 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 20 Jan 2020 20:07:14 +0000 Subject: LDAP Channel Binding In-Reply-To: <4b76bb2a-ced9-ba6f-5e08-62d2df3e9b2c@gmx.net> References: <6a60ed26-962a-918f-08df-b9ed5315d4bc@gmx.net> , <4b76bb2a-ced9-ba6f-5e08-62d2df3e9b2c@gmx.net> Message-ID: Hello, Ok, so I have tested the GSSAPI method with a non-native (endured, non delegated) Kerberos login and it works with and without TLS no matter if channel binding is enforced or not. (GSS without TLS fails as expected with auth when request signing is required). So this either means the enforcing does not work on Windows Server 2019 or the enforcing is not for TLS binding in GSSAPI handshakes. I will publish the traces later. BTW1 when using GSS with TLS and requesting Auth-int and/or auth-conf the MS DS will actually terminate the connection with a "wrong parameter" error (on the server side event log) and close the socket with no proper error. BTW2 i tested anonymous binds, it rejects RootDSE queries in my case. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: Michael Osipov <1983-01-06 at gmx.net> Gesendet: Sonntag, Januar 19, 2020 11:15 AM An: Bernd Eckenfels Cc: security-dev at openjdk.java.net Betreff: Re: LDAP Channel Binding Am 2020-01-19 um 08:02 schrieb Bernd Eckenfels: > You said it is confusing, but the bug you mentioned is only a valid > feature request, it does not talk about failing binds. I would assume > that Kerberos needs the binding token and the others not. > Unfortunatelly the doc from Microsoft is quite incomplete and > confusing. The problem is that JSSE Sun Impl documentation does not even mention TLS channel binding. To make things worse, I agree with you, Microsoft's documentation is horrible. It does not say whether we are talking about GSS-API channel binding or TLS channel biding. The best I have comeup with is https://github.com/WinRb/rubyntlm/issues/27 https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2008/dd639324(v=vs.90)?redirectedfrom=MSDN > So has anybody seeing failing TLS binds yet and if so, in which > condition? Yes, see https://stackoverflow.com/q/59756206/696632 What I can say is tht in our company auth-int has been mandatatory for several months now and my Java code always used auth-conf with GSSAPI mech w/o any flaws. > It is also not clear why AD proposes the auth. quality of protection > from digest-md5 if it is configured to reject it. So if somebody can > get Microsoft to look into this and provide details, that would be > great. > > Gruss Bernd > > > -- http://bernd.eckenfels.net ________________________________ Von: > Michael Osipov <1983-01-06 at gmx.net> Gesendet: Saturday, January 18, > 2020 9:39:08 PM An: Bernd Eckenfels ; > security-dev at openjdk.java.net > Betreff: Re: LDAP Channel Binding > > Am 2020-01-16 um 11:32 schrieb Bernd Eckenfels: >> Hello, >> >> Some updates: >> >> Microsoft moved their automatic update of the LDAP policies in >> Windows Server updates to March 2020 (but still recommend to >> activate it earlier). >> >> And I did some tests: when you turn on the mandatory LDAP Signing, >> then simple binds or Digest-md5 binds over LDAP are rejected by >> NTDS. Both work over ldaps: (Implicite TLS, did not check >> STARTTLS). DIGEST-MD5 without TLS is also possible, but you have to >> request qop=auth-int. (Sidenode AD will reject digest-md5 with >> Auth-int over TLS). I did not Test GSSAPI or SPNEGO yet. >> >> The mandatory LDAP channel binding does not seem to make a >> problem/change. I suspect it only applies to Kerberos or NTLM which >> I still need to test. > > That is confusing because: > https://bugs.openjdk.java.net/browse/JDK-6491070 > > I am excited to see your GSSAPI mech results. You cannot test SPENGO > because the Java SASL factory does not suppor the GSS-SPNEGO SASL > mech. > >> PS: testcode >> https://gist.github.com/ecki/cdd7a14575b7dca10da8d362974731a0 > > You code looks wrong. Retrieving data from RootDSE does not require > a successful bind. It will work anonymously. You need to go down the > tree. > > Look at ldapsearch(1), if you don't provide -Y GSSAPI, it will > perform a simple search for supportedSASLMechanisms and pick the best > one it supports. This is the same as obtaining the root naming > contexts, this can be done anonymously too. > > Michael > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Jan 21 13:49:06 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 Jan 2020 13:49:06 +0000 Subject: RFR: 8218021: jarsigner strips the execute permission when signing a .zip file In-Reply-To: References: Message-ID: On 17/01/2020 10:59, Se?n Coffey wrote: > Hi, > > Looking to introduce some JDK private functionality which will help > preserve internal zip file attribute permissions when jarsigner is run > on a zip file. Some of the logic is taken from the recent work carried > out in this area for zipfs API. > > https://bugs.openjdk.java.net/browse/JDK-8218021 > http://cr.openjdk.java.net/~coffeys/webrev.8218021/webrev/ The jarsigner tool is for signing JAR files so it does look strange that it only preserves the permissions when signing a zip file.? So I think I agree with the other comments that that part of the proposal should be examined again. If you don't special case then the concerns about the toLowerCase() usage go away too. The bigger issue with the proposal is that the signing doesn't cover the information in the extended extra blocks so they can be tampered with.? I think we need to heard from security-dev on this point. One option might be to emit a warning when there are permissions. Another is a jarsigner option to opt-in to preserve the permissions. -Alan From ecki at zusammenkunft.net Tue Jan 21 16:57:13 2020 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 21 Jan 2020 16:57:13 +0000 Subject: LDAP Channel Binding In-Reply-To: <4b76bb2a-ced9-ba6f-5e08-62d2df3e9b2c@gmx.net> References: <6a60ed26-962a-918f-08df-b9ed5315d4bc@gmx.net> , <4b76bb2a-ced9-ba6f-5e08-62d2df3e9b2c@gmx.net> Message-ID: Hello, I have now repeated the tests with LdapEnforceChannelBinding=2 and I could see the rejection with error code 80090346 for GSSAPI and DIGEST-MD5 with TLS. The simple bind with TLS and the GSSAPI or DIGEST-MD5 without TLS but with auth-int/conf all work with signing and binding required (I.e after Microsoft charged defaults in March) (Which makes the TLS binding a bit useless, but we should still think about supporting it.) Jgss seems to already allow to set it, so only JSSE needs to provide an api for sasl/jndi. Gru? Bernd -- https://Bernd.eckenfels.net ________________________________ Von: Michael Osipov <1983-01-06 at gmx.net> Gesendet: Sonntag, Januar 19, 2020 11:15 AM An: Bernd Eckenfels Cc: security-dev at openjdk.java.net Betreff: Re: LDAP Channel Binding Am 2020-01-19 um 08:02 schrieb Bernd Eckenfels: > You said it is confusing, but the bug you mentioned is only a valid > feature request, it does not talk about failing binds. I would assume > that Kerberos needs the binding token and the others not. > Unfortunatelly the doc from Microsoft is quite incomplete and > confusing. The problem is that JSSE Sun Impl documentation does not even mention TLS channel binding. To make things worse, I agree with you, Microsoft's documentation is horrible. It does not say whether we are talking about GSS-API channel binding or TLS channel biding. The best I have comeup with is https://github.com/WinRb/rubyntlm/issues/27 https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2008/dd639324(v=vs.90)?redirectedfrom=MSDN > So has anybody seeing failing TLS binds yet and if so, in which > condition? Yes, see https://stackoverflow.com/q/59756206/696632 What I can say is tht in our company auth-int has been mandatatory for several months now and my Java code always used auth-conf with GSSAPI mech w/o any flaws. > It is also not clear why AD proposes the auth. quality of protection > from digest-md5 if it is configured to reject it. So if somebody can > get Microsoft to look into this and provide details, that would be > great. > > Gruss Bernd > > > -- http://bernd.eckenfels.net ________________________________ Von: > Michael Osipov <1983-01-06 at gmx.net> Gesendet: Saturday, January 18, > 2020 9:39:08 PM An: Bernd Eckenfels ; > security-dev at openjdk.java.net > Betreff: Re: LDAP Channel Binding > > Am 2020-01-16 um 11:32 schrieb Bernd Eckenfels: >> Hello, >> >> Some updates: >> >> Microsoft moved their automatic update of the LDAP policies in >> Windows Server updates to March 2020 (but still recommend to >> activate it earlier). >> >> And I did some tests: when you turn on the mandatory LDAP Signing, >> then simple binds or Digest-md5 binds over LDAP are rejected by >> NTDS. Both work over ldaps: (Implicite TLS, did not check >> STARTTLS). DIGEST-MD5 without TLS is also possible, but you have to >> request qop=auth-int. (Sidenode AD will reject digest-md5 with >> Auth-int over TLS). I did not Test GSSAPI or SPNEGO yet. >> >> The mandatory LDAP channel binding does not seem to make a >> problem/change. I suspect it only applies to Kerberos or NTLM which >> I still need to test. > > That is confusing because: > https://bugs.openjdk.java.net/browse/JDK-6491070 > > I am excited to see your GSSAPI mech results. You cannot test SPENGO > because the Java SASL factory does not suppor the GSS-SPNEGO SASL > mech. > >> PS: testcode >> https://gist.github.com/ecki/cdd7a14575b7dca10da8d362974731a0 > > You code looks wrong. Retrieving data from RootDSE does not require > a successful bind. It will work anonymously. You need to go down the > tree. > > Look at ldapsearch(1), if you don't provide -Y GSSAPI, it will > perform a simple search for supportedSASLMechanisms and pick the best > one it supports. This is the same as obtaining the root naming > contexts, this can be done anonymously too. > > Michael > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Tue Jan 21 20:47:40 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 21 Jan 2020 15:47:40 -0500 Subject: SunPKCS11's Secmod and external modules in FIPS mode In-Reply-To: References: <54c3b155-5f71-11d9-f8e3-74a416263ff4@redhat.com> Message-ID: Hi Martin, I asked around but no-one can quite recall why the fips variable was set this way. Our best guess is that it was set this way as we did not have any tests for this use case. I don't have any issue with changing this. However, is there a way you could provide some tests (ex: on linux) to make sure it is working as expected? Thanks, Sean On 1/20/20 2:16 PM, Martin Balao wrote: > Ping. Any hint about this? > > Thanks, > Martin.- > > On 12/20/19 10:03 PM, Martin Balao wrote: >> Hello, >> >> SunPKCS11's Secmod in OpenJDK does not allow modules other than the NSS >> Software Token to be configured in FIPS mode [1]. To give some context, >> NSS represents modules internally with a structure called "struct >> SECMODModuleStr" and the "fips" variable you see in [1] is the "isFIPS" >> member of the module structure [2]. isFIPS is initialized by NSS to >> false for all modules [3] but if the module spec string has a "FIPS" >> flag, it may be turned to true [4]. Newer NSS versions (since bug >> 1531267 [5] [6]) may set isFIPS to true for all modules when >> /proc/sys/crypto/fips_enabled is 1 in Linux systems. As a result, as >> soon as the system is in FIPS mode and the NSSDB has more than the NSS >> Software Token module in it, OpenJDK refuses to initialize the SunPKCS11 >> provider. You can see a real case with pk11-kit-trust as the external >> module in RH1780335 [7]. >> >> This behavior has been the same since the very beginning of OpenJDK >> (revision 2), and I couldn't find much information about it. There might >> be a commit message previous to that. >> >> I'm trying to understand the rationale behind it and see what would be >> the implications of removing the check (note: couldn't notice anything >> in my quick test by removing it). >> >> Can someone give me a hint? >> >> Thanks, >> Martin.- >> >> -- >> [1] - >> https://hg.openjdk.java.net/jdk/jdk/file/59ddac265649/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Secmod.java#l417 >> [2] - >> https://github.com/nss-dev/nss/blob/c1ff439ca931f53c318e7381636ed5889b3d66f1/lib/pk11wrap/secmodt.h#L49 >> [3] - >> https://github.com/nss-dev/nss/blob/a141cd68ece76118aebf8033c06d46a3692b55fe/lib/pk11wrap/pk11pars.c#L49 >> [4] - >> https://github.com/nss-dev/nss/blob/a141cd68ece76118aebf8033c06d46a3692b55fe/lib/pk11wrap/pk11pars.c#L819 >> [5] - https://bugzilla.mozilla.org/show_bug.cgi?id=1531267 >> [6] - https://hg.mozilla.org/projects/nss/rev/536fd7c9db5a >> [7] - https://bugzilla.redhat.com/show_bug.cgi?id=1780335 >> > From 1983-01-06 at gmx.net Tue Jan 21 22:22:28 2020 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Tue, 21 Jan 2020 23:22:28 +0100 Subject: LDAP Channel Binding In-Reply-To: References: <6a60ed26-962a-918f-08df-b9ed5315d4bc@gmx.net> <4b76bb2a-ced9-ba6f-5e08-62d2df3e9b2c@gmx.net> Message-ID: Am 2020-01-20 um 21:07 schrieb Bernd Eckenfels: > Hello, > > Ok, so I have tested the GSSAPI method with a non-native (endured, > non delegated) Kerberos login and it works with and without TLS no > matter if channel binding is enforced or not. (GSS without TLS fails > as expected with auth when request signing is required). > > So this either means the enforcing does not work on Windows Server > 2019 or the enforcing is not for TLS binding in GSSAPI handshakes. Can you double check that this really is enabled? > I will publish the traces later. Please provide them. > BTW1 when using GSS with TLS and requesting Auth-int and/or auth-conf > the MS DS will actually terminate the connection with a "wrong > parameter" error (on the server side event log) and close the socket > with no proper error. This is correct. Active Directory does not support auth-int or auth-conf over a TLS channel. > BTW2 i tested anonymous binds, it rejects RootDSE queries in my > case. You need to stick to the base scope (same level). > -- http://bernd.eckenfels.net ________________________________ Von: > Michael Osipov <1983-01-06 at gmx.net> Gesendet: Sonntag, Januar 19, > 2020 11:15 AM An: Bernd Eckenfels Cc: security-dev at openjdk.java.net > Betreff: Re: LDAP Channel Binding > > Am 2020-01-19 um 08:02 schrieb Bernd Eckenfels: >> You said it is confusing, but the bug you mentioned is only a >> valid feature request, it does not talk about failing binds. I >> would assume that Kerberos needs the binding token and the others >> not. Unfortunatelly the doc from Microsoft is quite incomplete and >> confusing. > > The problem is that JSSE Sun Impl documentation does not even > mention TLS channel binding. To make things worse, I agree with you, > Microsoft's documentation is horrible. It does not say whether we are > talking about GSS-API channel binding or TLS channel biding. > > The best I have comeup with is > https://github.com/WinRb/rubyntlm/issues/27 > https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2008/dd639324(v=vs.90)?redirectedfrom=MSDN > > >> So has anybody seeing failing TLS binds yet and if so, in which >> condition? > > Yes, see https://stackoverflow.com/q/59756206/696632 > > What I can say is tht in our company auth-int has been mandatatory > for several months now and my Java code always used auth-conf with > GSSAPI mech w/o any flaws. > >> It is also not clear why AD proposes the auth. quality of >> protection from digest-md5 if it is configured to reject it. So if >> somebody can get Microsoft to look into this and provide details, >> that would be great. >> >> Gruss Bernd >> >> >> -- http://bernd.eckenfels.net ________________________________ >> Von: Michael Osipov <1983-01-06 at gmx.net> Gesendet: Saturday, >> January 18, 2020 9:39:08 PM An: Bernd Eckenfels >> ; security-dev at openjdk.java.net >> Betreff: Re: LDAP Channel Binding >> >> Am 2020-01-16 um 11:32 schrieb Bernd Eckenfels: >>> Hello, >>> >>> Some updates: >>> >>> Microsoft moved their automatic update of the LDAP policies in >>> Windows Server updates to March 2020 (but still recommend to >>> activate it earlier). >>> >>> And I did some tests: when you turn on the mandatory LDAP >>> Signing, then simple binds or Digest-md5 binds over LDAP are >>> rejected by NTDS. Both work over ldaps: (Implicite TLS, did not >>> check STARTTLS). DIGEST-MD5 without TLS is also possible, but you >>> have to request qop=auth-int. (Sidenode AD will reject digest-md5 >>> with Auth-int over TLS). I did not Test GSSAPI or SPNEGO yet. >>> >>> The mandatory LDAP channel binding does not seem to make a >>> problem/change. I suspect it only applies to Kerberos or NTLM >>> which I still need to test. >> >> That is confusing because: >> https://bugs.openjdk.java.net/browse/JDK-6491070 >> >> I am excited to see your GSSAPI mech results. You cannot test >> SPENGO because the Java SASL factory does not suppor the GSS-SPNEGO >> SASL mech. >> >>> PS: testcode >>> https://gist.github.com/ecki/cdd7a14575b7dca10da8d362974731a0 >> >> You code looks wrong. Retrieving data from RootDSE does not >> require a successful bind. It will work anonymously. You need to go >> down the tree. >> >> Look at ldapsearch(1), if you don't provide -Y GSSAPI, it will >> perform a simple search for supportedSASLMechanisms and pick the >> best one it supports. This is the same as obtaining the root >> naming contexts, this can be done anonymously too. >> >> Michael >> > > From 1983-01-06 at gmx.net Tue Jan 21 22:31:23 2020 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Tue, 21 Jan 2020 23:31:23 +0100 Subject: LDAP Channel Binding In-Reply-To: References: <6a60ed26-962a-918f-08df-b9ed5315d4bc@gmx.net> <4b76bb2a-ced9-ba6f-5e08-62d2df3e9b2c@gmx.net> Message-ID: <3f09c638-1115-e765-a6f1-44b8be562f1d@gmx.net> Am 2020-01-21 um 17:57 schrieb Bernd Eckenfels: > Hello, > > I have now repeated the tests with LdapEnforceChannelBinding=2 and I > could see the rejection with error code 80090346 for GSSAPI and > DIGEST-MD5 with TLS. > > The simple bind with TLS and the GSSAPI or DIGEST-MD5 without TLS but > with auth-int/conf all work with signing and binding required (I.e > after Microsoft charged defaults in March) > > (Which makes the TLS binding a bit useless, but we should still think > about supporting it.) > > Jgss seems to already allow to set it, so only JSSE needs to provide > an api for sasl/jndi. How? I am confused! The Kerberos SaslClient does not use/set GSS channel bindings. I don't see any in com.sun.security.sasl.gsskerb. The implication of LDAP channel binding is not to rely on mech binding, but on the outer channel (TLS) binding. > ________________________________ Von: Michael Osipov > <1983-01-06 at gmx.net> Gesendet: Sonntag, Januar 19, 2020 11:15 AM An: > Bernd Eckenfels Cc: security-dev at openjdk.java.net Betreff: Re: LDAP > Channel Binding > > Am 2020-01-19 um 08:02 schrieb Bernd Eckenfels: >> You said it is confusing, but the bug you mentioned is only a >> valid feature request, it does not talk about failing binds. I >> would assume that Kerberos needs the binding token and the others >> not. Unfortunatelly the doc from Microsoft is quite incomplete and >> confusing. > > The problem is that JSSE Sun Impl documentation does not even > mention TLS channel binding. To make things worse, I agree with you, > Microsoft's documentation is horrible. It does not say whether we are > talking about GSS-API channel binding or TLS channel biding. > > The best I have comeup with is > https://github.com/WinRb/rubyntlm/issues/27 > https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2008/dd639324(v=vs.90)?redirectedfrom=MSDN > > >> So has anybody seeing failing TLS binds yet and if so, in which >> condition? > > Yes, see https://stackoverflow.com/q/59756206/696632 > > What I can say is tht in our company auth-int has been mandatatory > for several months now and my Java code always used auth-conf with > GSSAPI mech w/o any flaws. > >> It is also not clear why AD proposes the auth. quality of >> protection from digest-md5 if it is configured to reject it. So if >> somebody can get Microsoft to look into this and provide details, >> that would be great. >> >> Gruss Bernd >> >> >> -- http://bernd.eckenfels.net ________________________________ >> Von: Michael Osipov <1983-01-06 at gmx.net> Gesendet: Saturday, >> January 18, 2020 9:39:08 PM An: Bernd Eckenfels >> ; security-dev at openjdk.java.net >> Betreff: Re: LDAP Channel Binding >> >> Am 2020-01-16 um 11:32 schrieb Bernd Eckenfels: >>> Hello, >>> >>> Some updates: >>> >>> Microsoft moved their automatic update of the LDAP policies in >>> Windows Server updates to March 2020 (but still recommend to >>> activate it earlier). >>> >>> And I did some tests: when you turn on the mandatory LDAP >>> Signing, then simple binds or Digest-md5 binds over LDAP are >>> rejected by NTDS. Both work over ldaps: (Implicite TLS, did not >>> check STARTTLS). DIGEST-MD5 without TLS is also possible, but you >>> have to request qop=auth-int. (Sidenode AD will reject digest-md5 >>> with Auth-int over TLS). I did not Test GSSAPI or SPNEGO yet. >>> >>> The mandatory LDAP channel binding does not seem to make a >>> problem/change. I suspect it only applies to Kerberos or NTLM >>> which I still need to test. >> >> That is confusing because: >> https://bugs.openjdk.java.net/browse/JDK-6491070 >> >> I am excited to see your GSSAPI mech results. You cannot test >> SPENGO because the Java SASL factory does not suppor the GSS-SPNEGO >> SASL mech. >> >>> PS: testcode >>> https://gist.github.com/ecki/cdd7a14575b7dca10da8d362974731a0 >> >> You code looks wrong. Retrieving data from RootDSE does not >> require a successful bind. It will work anonymously. You need to go >> down the tree. >> >> Look at ldapsearch(1), if you don't provide -Y GSSAPI, it will >> perform a simple search for supportedSASLMechanisms and pick the >> best one it supports. This is the same as obtaining the root >> naming contexts, this can be done anonymously too. >> >> Michael >> > > From weijun.wang at oracle.com Wed Jan 22 07:40:41 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 22 Jan 2020 15:40:41 +0800 Subject: Microsoft LDAP Channel Binding In-Reply-To: References: Message-ID: <078776CE-C096-47FA-A834-BDBAF4D44F7E@oracle.com> > On Dec 18, 2019, at 9:14 PM, Michael Osipov <1983-01-06 at gmx.net> wrote: > > ... > A few issues must be addressed first: > * Java's SASL GSSAPI mech has a bug which will make all default installations fail. > I have reported this years ago and this must be immediately fixed [3]. > ... > [3] https://bugs.openjdk.java.net/browse/JDK-8160818 My current plan is to update the default value of SERVER_AUTH: "false" if only "auth" is requested, and "true" if one of "auth-int" or "auth-conf" is requested. I'll see what compatibility impact there would be for other actions. Thanks, Max From 1983-01-06 at gmx.net Wed Jan 22 08:21:00 2020 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Wed, 22 Jan 2020 09:21:00 +0100 Subject: Microsoft LDAP Channel Binding In-Reply-To: <078776CE-C096-47FA-A834-BDBAF4D44F7E@oracle.com> References: <078776CE-C096-47FA-A834-BDBAF4D44F7E@oracle.com> Message-ID: <62340af7-e442-aca6-5a41-f569be691ce6@gmx.net> Am 2020-01-22 um 08:40 schrieb Weijun Wang: > > >> On Dec 18, 2019, at 9:14 PM, Michael Osipov <1983-01-06 at gmx.net> wrote: >> >> ... > >> A few issues must be addressed first: >> * Java's SASL GSSAPI mech has a bug which will make all default installations fail. >> I have reported this years ago and this must be immediately fixed [3]. >> > ... >> [3] https://bugs.openjdk.java.net/browse/JDK-8160818 > > My current plan is to update the default value of SERVER_AUTH: "false" if only "auth" is requested, and "true" if one of "auth-int" or "auth-conf" is requested. I'll see what compatibility impact there would be for other actions. Max, when you are on it, please take recent changes in Cyrus SASL into account. A compatiblity with Cyrus SASL is crucial here. The dicussion in question is: https://github.com/cyrusimap/cyrus-sasl/issues/419 Especially this block: https://github.com/cyrusimap/cyrus-sasl/blob/master/plugins/gssapi.c#L1762-L1778 Java should match here. Michael From weijun.wang at oracle.com Wed Jan 22 09:14:28 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 22 Jan 2020 17:14:28 +0800 Subject: Microsoft LDAP Channel Binding In-Reply-To: <62340af7-e442-aca6-5a41-f569be691ce6@gmx.net> References: <078776CE-C096-47FA-A834-BDBAF4D44F7E@oracle.com> <62340af7-e442-aca6-5a41-f569be691ce6@gmx.net> Message-ID: <3D274C76-CC7A-4EB1-AED8-BC8BF7B2FD19@oracle.com> > On Jan 22, 2020, at 4:21 PM, Michael Osipov <1983-01-06 at gmx.net> wrote: > > Am 2020-01-22 um 08:40 schrieb Weijun Wang: >> >> >>> On Dec 18, 2019, at 9:14 PM, Michael Osipov <1983-01-06 at gmx.net> wrote: >>> >>> ... >> >>> A few issues must be addressed first: >>> * Java's SASL GSSAPI mech has a bug which will make all default installations fail. >>> I have reported this years ago and this must be immediately fixed [3]. >>> >> ... >>> [3] https://bugs.openjdk.java.net/browse/JDK-8160818 >> >> My current plan is to update the default value of SERVER_AUTH: "false" if only "auth" is requested, and "true" if one of "auth-int" or "auth-conf" is requested. I'll see what compatibility impact there would be for other actions. > > Max, > > when you are on it, please take recent changes in Cyrus SASL into > account. A compatiblity with Cyrus SASL is crucial here. > > The dicussion in question is: > https://github.com/cyrusimap/cyrus-sasl/issues/419 What is the major point in this thread? In fact, I think the old code in https://github.com/cyrusimap/cyrus-sasl/commit/e41cfb986c1b1935770de554872247453fdbb079 looks correct. GSS_C_MUTUAL_FLAG | GSS_C_SEQUENCE_FLAG should only be set when there is a security layer. Is the if check wrong? --Max > > Especially this block: > https://github.com/cyrusimap/cyrus-sasl/blob/master/plugins/gssapi.c#L1762-L1778 > Java should match here. > > Michael From 1983-01-06 at gmx.net Wed Jan 22 09:45:18 2020 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Wed, 22 Jan 2020 10:45:18 +0100 Subject: Microsoft LDAP Channel Binding In-Reply-To: <3D274C76-CC7A-4EB1-AED8-BC8BF7B2FD19@oracle.com> References: <078776CE-C096-47FA-A834-BDBAF4D44F7E@oracle.com> <62340af7-e442-aca6-5a41-f569be691ce6@gmx.net> <3D274C76-CC7A-4EB1-AED8-BC8BF7B2FD19@oracle.com> Message-ID: Am 2020-01-22 um 10:14 schrieb Weijun Wang: > > >> On Jan 22, 2020, at 4:21 PM, Michael Osipov <1983-01-06 at gmx.net> wrote: >> >> Am 2020-01-22 um 08:40 schrieb Weijun Wang: >>> >>> >>>> On Dec 18, 2019, at 9:14 PM, Michael Osipov <1983-01-06 at gmx.net> wrote: >>>> >>>> ... >>> >>>> A few issues must be addressed first: >>>> * Java's SASL GSSAPI mech has a bug which will make all default installations fail. >>>> I have reported this years ago and this must be immediately fixed [3]. >>>> >>> ... >>>> [3] https://bugs.openjdk.java.net/browse/JDK-8160818 >>> >>> My current plan is to update the default value of SERVER_AUTH: "false" if only "auth" is requested, and "true" if one of "auth-int" or "auth-conf" is requested. I'll see what compatibility impact there would be for other actions. >> >> Max, >> >> when you are on it, please take recent changes in Cyrus SASL into >> account. A compatiblity with Cyrus SASL is crucial here. >> >> The dicussion in question is: >> https://github.com/cyrusimap/cyrus-sasl/issues/419 > > What is the major point in this thread? In fact, I think the old code in https://github.com/cyrusimap/cyrus-sasl/commit/e41cfb986c1b1935770de554872247453fdbb079 looks correct. GSS_C_MUTUAL_FLAG | GSS_C_SEQUENCE_FLAG should only be set when there is a security layer. Is the if check wrong? While the old code is a verbatim implementation of the RFC by A. Melnikov, recent changes by Ken Murchison interprete the RFC in context of an external SSF. One need ony set auth-int of the external layer does not guarantee auth-int and so on. See my discussion with Quanah Gibson-Mount about this. The fundamental difference is that the Java GSSAPI mech does not take external SSF into account and cannot decide whether auth-int of auth-conf should be applied or not. Logically, it makes no sense to apply auth-inf/-conf if the external layer (e.g., TLS) already provides this. Michael From sean.mullan at oracle.com Thu Jan 23 20:45:56 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 23 Jan 2020 15:45:56 -0500 Subject: jtreg test security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java instabilities In-Reply-To: References: Message-ID: <9901d8ad-383f-441b-2c09-50076cd411d9@oracle.com> An HTML attachment was scrubbed... URL: From mbalao at redhat.com Thu Jan 23 22:11:41 2020 From: mbalao at redhat.com (Martin Balao) Date: Thu, 23 Jan 2020 19:11:41 -0300 Subject: SunPKCS11's Secmod and external modules in FIPS mode In-Reply-To: References: <54c3b155-5f71-11d9-f8e3-74a416263ff4@redhat.com> Message-ID: Hi Sean, On 1/21/20 5:47 PM, Sean Mullan wrote: > > I asked around but no-one can quite recall why the fips variable was set > this way. Our best guess is that it was set this way as we did not have > any tests for this use case. > > I don't have any issue with changing this. However, is there a way you > could provide some tests (ex: on linux) to make sure it is working as > expected? > Thanks for having a look at this. I'll propose a change and either an automated reproducer or manual steps to verify on Linux. Kind regards, Martin.- From matthias.baesken at sap.com Fri Jan 24 08:40:02 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 24 Jan 2020 08:40:02 +0000 Subject: jtreg test security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java instabilities In-Reply-To: <9901d8ad-383f-441b-2c09-50076cd411d9@oracle.com> References: <9901d8ad-383f-441b-2c09-50076cd411d9@oracle.com> Message-ID: Hi Sean, thanks for looking into it . >However, there is no nextUpdate field set, which means there should be always newer information available. So while the 5 minute delay may not be a huge issue, the fact that they are returning cached responses, >looks like a problem to me.This could be the underlying problem, in that they are not generating fresh OCSPResponses. I will contact LuxTrust and see if we can get some information from them. Can we exclude the test until the issue is resolved ? We see such failures very often . Best regards, Matthias From: Sean Mullan Sent: Donnerstag, 23. Januar 2020 21:46 To: Baesken, Matthias ; security-dev at openjdk.java.net Subject: Re: jtreg test security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java instabilities On 1/17/20 8:09 AM, Baesken, Matthias wrote: Hello, I wonder if you have some input regarding the following issue. I noticed a couple of instabilities (in jdk13 and higher) in the test security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java . The test sometimes fails when validating the "validity interval" of OCSP responses : Example output is like : certpath: OCSP response validity interval is from Wed Dec 04 01:05:27 CET 2019 certpath: Checking validity of OCSP response on: Wed Dec 04 01:39:15 CET 2019 <--------- default interval is system time "on" machine +/- 15 minutes , this is seen as valid by OpenJDK ... java.lang.RuntimeException: TEST FAILED: couldn't determine EE certificate status at ValidatePathWithParams.validate(ValidatePathWithParams.java:177) at LuxTrustCA.main(LuxTrustCA.java:186) 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:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:832) stdout contains : Received exception: java.security.cert.CertPathValidatorException: Response is unreliable: its validity interval is out-of-date So our system time "on" machine ( 01:39:15 CET 2019 +/- 15 minutes ) does not contain the time from OCSP response ( 01:05:27 CET 2019) . Reason is unclear , of course the time on the test machine could be wrong but we see the issue on multiple machines and when looking into the system times of the machines they look fine . Maybe the time info from the OCSP response is wrong , at least it looks like this is the issue here . Have you seen similar issues (also in other tests dealing with OCSP response validity checks) ? Yes, I can confirm we have seen this at least once before. There is a bug filed for it, but it is currently marked Confidential because it has some internal information in it. Can you send me the whole log file or at least more of it which shows the info below? Do you think that increasing the acceptance interval e.g. by setting it to -Dcom.sun.security.ocsp.clockSkew=9000000 in security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java would be okay ? ( I'd like to add a little bit more tracing too so that in case of such errors it is easier to understand the issue ) No that would be too much skew. If there is an issue with the time on the OCSP Responder, that is a more serious issue which this property might mask. I just ran this test myself locally. I noticed that one of the OCSP Responders appears to be returning pre-produced OCSPResponses: certpath: connecting to OCSP service at: http://qca.ocsp.luxtrust.lu certpath: OCSP response status: SUCCESSFUL certpath: OCSP response type: basic certpath: Responder ID: byKey: AFC136FF2B78DC9F78E0100F2ABC24DDBD6F12B6 certpath: OCSP response produced at: Thu Jan 23 15:23:08 EST 2020 certpath: OCSP number of SingleResponses: 1 certpath: thisUpdate: Thu Jan 23 15:18:13 EST 2020 However, there is no nextUpdate field set, which means there should be always newer information available. So while the 5 minute delay may not be a huge issue, the fact that they are returning cached responses, looks like a problem to me. This could be the underlying problem, in that they are not generating fresh OCSPResponses. I will contact LuxTrust and see if we can get some information from them. Thanks, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Jan 24 20:11:05 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 24 Jan 2020 15:11:05 -0500 Subject: jtreg test security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java instabilities In-Reply-To: References: <9901d8ad-383f-441b-2c09-50076cd411d9@oracle.com> Message-ID: On 1/24/20 3:40 AM, Baesken, Matthias wrote: > Hi Sean, thanks for looking into it . > >>However, there is no nextUpdate field set, which means there should be always newer information available. So while the 5 minute delay may not be a huge issue, the fact that they are returning cached responses, > >>looks like a problem to me.This could be the underlying problem, in that they are not generating fresh OCSPResponses. I will contact LuxTrust and see if we can get some information from them. > > Can we exclude? the test? until? the issue is resolved ? Ok, that is fine with me. Thanks, Sean > > We see such failures very often . > > Best regards, Matthias > > *From:*Sean Mullan > *Sent:* Donnerstag, 23. Januar 2020 21:46 > *To:* Baesken, Matthias ; > security-dev at openjdk.java.net > *Subject:* Re: jtreg test > security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java > instabilities > > On 1/17/20 8:09 AM, Baesken, Matthias wrote: > > Hello,?? I wonder if you have some input regarding the following issue. > > I noticed a couple? of instabilities ?(in jdk13 and ?higher)? in > the?? test > security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java > . > > The test sometimes fails? when validating the ?validity interval? > of? OCSP responses : > > Example output is like : > > certpath: OCSP response validity interval is from Wed Dec 04 > *01:05:27 CET 2019* > > certpath: Checking validity of OCSP response on: Wed Dec 04 > *01:39:15 CET 2019* *<---------? default ?interval? is system time > ?on? machine ?+/- 15 minutes? , this is seen as valid by OpenJDK* > > ? ? > > java.lang.RuntimeException: TEST FAILED: couldn't determine EE > certificate status > > ??????????????? at > ValidatePathWithParams.validate(ValidatePathWithParams.java:177) > > ??????????????? at LuxTrustCA.main(LuxTrustCA.java:186) > > ??????????????? 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:564) > > ??????????????? at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > > ??????????????? at java.base/java.lang.Thread.run(Thread.java:832) > > stdout contains : > > Received exception: java.security.cert.CertPathValidatorException: > *Response is unreliable: its validity interval is out-of-date* > > So our *?system time ?on? machine?? ( 01:39:15 CET 2019* *??+/- 15 > minutes? ) *does not contain?? the time?? from? OCSP response*? ( > 01:05:27 CET 2019) .* > > Reason is? unclear , of course?? the time?? on the? test machine > could be wrong? but we see the issue on multiple machines? and ?when > looking? into the system times of the machines they look fine . > > Maybe the time? info? from the OCSP response? is wrong ,? at least > it looks like? this is the issue here . > > Have you seen similar issues? (also in other tests dealing with OCSP > response validity checks) ? > > Yes, I can confirm we have seen this at least once before. There is a > bug filed for it, but it is currently marked Confidential because it has > some internal information in it. > > Can you send me the whole log file or at least more of it which shows > the info below? > > Do you think that ?increasing the? acceptance interval? e.g.? by > setting ?it? to ???-Dcom.sun.security.ocsp.clockSkew=9000000??? in > ?security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java would be okay ? > > ( I?d like to add a little? bit more tracing too so that in case of > such errors? it is easier to understand? the issue ) > > No that would be too much skew. If there is an issue with the time on > the OCSP Responder, that is a more serious issue which this property > might mask. > > I just ran this test myself locally. I noticed that one of the OCSP > Responders appears to be returning pre-produced OCSPResponses: > > certpath: connecting to OCSP service at: http://qca.ocsp.luxtrust.lu > certpath: OCSP response status: SUCCESSFUL > certpath: OCSP response type: basic > certpath: Responder ID: byKey: AFC136FF2B78DC9F78E0100F2ABC24DDBD6F12B6 > certpath: OCSP response produced at: Thu Jan 23 15:23:08 EST 2020 > certpath: OCSP number of SingleResponses: 1 > certpath: thisUpdate: Thu Jan 23 15:18:13 EST 2020 > > However, there is no nextUpdate field set, which means there should be > always newer information available. So while the 5 minute delay may not > be a huge issue, the fact that they are returning cached responses, > looks like a problem to me. > > This could be the underlying problem, in that they are not generating > fresh OCSPResponses. I will contact LuxTrust and see if we can get some > information from them. > > Thanks, > > Sean > From valerie.peng at oracle.com Fri Jan 24 22:01:33 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 24 Jan 2020 14:01:33 -0800 Subject: [15] RFR 8236512: PKCS11 Connection closed after Cipher.doFinal and NoPadding Message-ID: Hi, Can someone help reviewing this? This can only be reproduced with 3rd party HSM vendor, so there is no new regression test. To address this, I removed the killSession() calls from PKCS11 Cipher, Mac, Signature services and reverted to old behavior of finishing off the current operation as a way of resetting the current object. Also fixed one place missing the reset() call and another one with redundant reset() call so the key id counting matches up. Bug: https://bugs.openjdk.java.net/browse/JDK-8236512 Webrev: http://cr.openjdk.java.net/~valeriep/8236512/webrev.00/ Mach5 run is clean. Thanks, Valerie From matthias.baesken at sap.com Mon Jan 27 09:25:03 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 27 Jan 2020 09:25:03 +0000 Subject: RFR [XS]: 8237869: exclude jtreg test security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java because of instabilities - was : RE: jtreg test security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java Message-ID: Hello, please review the exclusion of jtreg test security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8237869 http://cr.openjdk.java.net/~mbaesken/webrevs/8237869.0/ Thanks, Matthias > -----Original Message----- > From: Sean Mullan > Sent: Freitag, 24. Januar 2020 21:11 > To: Baesken, Matthias ; security- > dev at openjdk.java.net > Subject: Re: jtreg test > security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA. > java instabilities > > On 1/24/20 3:40 AM, Baesken, Matthias wrote: > > Hi Sean, thanks for looking into it . > > > >>However, there is no nextUpdate field set, which means there should be > always newer information available. So while the 5 minute delay may not be > a huge issue, the fact that they are returning cached responses, > > > >>looks like a problem to me.This could be the underlying problem, in that > they are not generating fresh OCSPResponses. I will contact LuxTrust and see > if we can get some information from them. > > > > Can we exclude? the test? until? the issue is resolved ? > > Ok, that is fine with me. > From christoph.langer at sap.com Mon Jan 27 13:41:59 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 27 Jan 2020 13:41:59 +0000 Subject: [CAUTION] RFR [XS]: 8237869: exclude jtreg test security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java because of instabilities - was : RE: jtreg test security/infra/java/security/cert/CertPathValidator/certification/LuxTrus Message-ID: Hi Matthias, the entry in ProblemList.txt can't refer to 8237869, which is the bug that you're using to submit the exclusion. It must refer to the item that shall resolve the underlying issue which probably is Oracle's private bug that Sean referred to. @Sean: In the interest of backportability, I'd ask you to either open up the internal bug and supply its id. If that isn't possible, could you please create a new public item and have your internal bug refer to it? Thanks Christoph > -----Original Message----- > From: security-dev On Behalf Of > Baesken, Matthias > Sent: Montag, 27. Januar 2020 10:25 > To: Sean Mullan ; security- > dev at openjdk.java.net > Subject: [CAUTION] RFR [XS]: 8237869: exclude jtreg test > security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA. > java because of instabilities - was : RE: jtreg test > security/infra/java/security/cert/CertPathValidator/certification/LuxTrust... > > Hello, please review the exclusion of jtreg test > security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA. > java . > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8237869 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8237869.0/ > > Thanks, Matthias > > > > -----Original Message----- > > From: Sean Mullan > > Sent: Freitag, 24. Januar 2020 21:11 > > To: Baesken, Matthias ; security- > > dev at openjdk.java.net > > Subject: Re: jtreg test > > > security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA. > > java instabilities > > > > On 1/24/20 3:40 AM, Baesken, Matthias wrote: > > > Hi Sean, thanks for looking into it . > > > > > >>However, there is no nextUpdate field set, which means there should > be > > always newer information available. So while the 5 minute delay may not > be > > a huge issue, the fact that they are returning cached responses, > > > > > >>looks like a problem to me.This could be the underlying problem, in that > > they are not generating fresh OCSPResponses. I will contact LuxTrust and > see > > if we can get some information from them. > > > > > > Can we exclude? the test? until? the issue is resolved ? > > > > Ok, that is fine with me. > > From sean.mullan at oracle.com Mon Jan 27 15:29:19 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 27 Jan 2020 10:29:19 -0500 Subject: [CAUTION] RFR [XS]: 8237869: exclude jtreg test security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java because of instabilities - was : RE: jtreg test security/infra/java/security/cert/CertPathValidator/certification/LuxTrus In-Reply-To: References: Message-ID: On 1/27/20 8:41 AM, Langer, Christoph wrote: > Hi Matthias, > > the entry in ProblemList.txt can't refer to 8237869, which is the bug that you're using to submit the exclusion. It must refer to the item that shall resolve the underlying issue which probably is Oracle's private bug that Sean referred to. Right. > > @Sean: In the interest of backportability, I'd ask you to either open up the internal bug and supply its id. If that isn't possible, could you please create a new public item and have your internal bug refer to it? I can't open it up because it contains internal network addresses. Even if I scrub them out, I believe you could still see them in the History. I would suggest that Matthias open a new public bug to track this issue using the information in the Description of JDK-8237869, and I will then mark 8237869 as a duplicate. You can assign that bug to me for now. Most likely it is an issue that LuxTrust has to fix on their end, and once that is fixed we can simply remove it from the ProblemList. Thanks, Sean > > Thanks > Christoph > > >> -----Original Message----- >> From: security-dev On Behalf Of >> Baesken, Matthias >> Sent: Montag, 27. Januar 2020 10:25 >> To: Sean Mullan ; security- >> dev at openjdk.java.net >> Subject: [CAUTION] RFR [XS]: 8237869: exclude jtreg test >> security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA. >> java because of instabilities - was : RE: jtreg test >> security/infra/java/security/cert/CertPathValidator/certification/LuxTrust... >> >> Hello, please review the exclusion of jtreg test >> security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA. >> java . >> >> Bug/webrev : >> >> https://bugs.openjdk.java.net/browse/JDK-8237869 >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8237869.0/ >> >> Thanks, Matthias >> >> >>> -----Original Message----- >>> From: Sean Mullan >>> Sent: Freitag, 24. Januar 2020 21:11 >>> To: Baesken, Matthias ; security- >>> dev at openjdk.java.net >>> Subject: Re: jtreg test >>> >> security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA. >>> java instabilities >>> >>> On 1/24/20 3:40 AM, Baesken, Matthias wrote: >>>> Hi Sean, thanks for looking into it . >>>> >>>>> However, there is no nextUpdate field set, which means there should >> be >>> always newer information available. So while the 5 minute delay may not >> be >>> a huge issue, the fact that they are returning cached responses, >>>> >>>>> looks like a problem to me.This could be the underlying problem, in that >>> they are not generating fresh OCSPResponses. I will contact LuxTrust and >> see >>> if we can get some information from them. >>>> >>>> Can we exclude? the test? until? the issue is resolved ? >>> >>> Ok, that is fine with me. >>> > From sean.mullan at oracle.com Mon Jan 27 15:31:37 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 27 Jan 2020 10:31:37 -0500 Subject: [CAUTION] RFR [XS]: 8237869: exclude jtreg test security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java because of instabilities - was : RE: jtreg test security/infra/java/security/cert/CertPathValidator/certification/LuxTrus In-Reply-To: References: Message-ID: <5440fbf8-4fdd-6f2a-01e0-c7eeaca959a2@oracle.com> On 1/27/20 10:29 AM, Sean Mullan wrote: > On 1/27/20 8:41 AM, Langer, Christoph wrote: >> Hi Matthias, >> >> the entry in ProblemList.txt can't refer to 8237869, which is the bug >> that you're using to submit the exclusion. It must refer to the item >> that shall resolve the underlying issue which probably is Oracle's >> private bug that Sean referred to. > Right. > >> >> @Sean: In the interest of backportability, I'd ask you to either open >> up the internal bug and supply its id. If that isn't possible, could >> you please create a new public item and have your internal bug refer >> to it? > > I can't open it up because it contains internal network addresses. Even > if I scrub them out, I believe you could still see them in the History. > > I would suggest that Matthias open a new public bug to track this issue > using the information in the Description of JDK-8237869, and I will then > mark 8237869 as a duplicate. Sorry, I meant to say I will mark the internal bug as a duplicate. --Sean > You can assign that bug to me for now. Most > likely it is an issue that LuxTrust has to fix on their end, and once > that is fixed we can simply remove it from the ProblemList. > > Thanks, > Sean > >> >> Thanks >> Christoph >> >> >>> -----Original Message----- >>> From: security-dev On Behalf Of >>> Baesken, Matthias >>> Sent: Montag, 27. Januar 2020 10:25 >>> To: Sean Mullan ; security- >>> dev at openjdk.java.net >>> Subject: [CAUTION] RFR [XS]: 8237869: exclude jtreg test >>> security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA. >>> >>> java because of instabilities - was : RE: jtreg test >>> security/infra/java/security/cert/CertPathValidator/certification/LuxTrust... >>> >>> >>> Hello, please review the exclusion of? jtreg test >>> security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA. >>> >>> java? . >>> >>> Bug/webrev : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8237869 >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8237869.0/ >>> >>> Thanks, Matthias >>> >>> >>>> -----Original Message----- >>>> From: Sean Mullan >>>> Sent: Freitag, 24. Januar 2020 21:11 >>>> To: Baesken, Matthias ; security- >>>> dev at openjdk.java.net >>>> Subject: Re: jtreg test >>>> >>> security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA. >>> >>>> java instabilities >>>> >>>> On 1/24/20 3:40 AM, Baesken, Matthias wrote: >>>>> Hi Sean, thanks for looking into it . >>>>> >>>>>> However, there is no nextUpdate field set, which means there should >>> be >>>> always newer information available. So while the 5 minute delay may not >>> be >>>> a huge issue, the fact that they are returning cached responses, >>>>> >>>>>> looks like a problem to me.This could be the underlying problem, >>>>>> in that >>>> they are not generating fresh OCSPResponses. I will contact LuxTrust >>>> and >>> see >>>> if we can get some information from them. >>>>> >>>>> Can we exclude? the test? until? the issue is resolved ? >>>> >>>> Ok, that is fine with me. >>>> >> From matthias.baesken at sap.com Mon Jan 27 16:10:50 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 27 Jan 2020 16:10:50 +0000 Subject: [CAUTION] RFR [XS]: 8237869: exclude jtreg test security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java because of instabilities - was : RE: jtreg test security/infra/java/security/cert/CertPathValidator/certification/LuxTrus In-Reply-To: References: Message-ID: Hi, new webrev , now with the other bugid : http://cr.openjdk.java.net/~mbaesken/webrevs/8237869.1/ ... and new issue to track the LuxTrust instabilities : https://bugs.openjdk.java.net/browse/JDK-8237888 security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java fails when checking validity interval Best regards, Matthias > > On 1/27/20 8:41 AM, Langer, Christoph wrote: > > Hi Matthias, > > > > the entry in ProblemList.txt can't refer to 8237869, which is the bug that > you're using to submit the exclusion. It must refer to the item that shall > resolve the underlying issue which probably is Oracle's private bug that Sean > referred to. > Right. > > > > > @Sean: In the interest of backportability, I'd ask you to either open up the > internal bug and supply its id. If that isn't possible, could you please create a > new public item and have your internal bug refer to it? > > I can't open it up because it contains internal network addresses. Even > if I scrub them out, I believe you could still see them in the History. > > I would suggest that Matthias open a new public bug to track this issue > using the information in the Description of JDK-8237869, and I will then > mark 8237869 as a duplicate. You can assign that bug to me for now. Most > likely it is an issue that LuxTrust has to fix on their end, and once > that is fixed we can simply remove it from the ProblemList. > > Thanks, From sean.mullan at oracle.com Mon Jan 27 16:13:10 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 27 Jan 2020 11:13:10 -0500 Subject: [CAUTION] RFR [XS]: 8237869: exclude jtreg test security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java because of instabilities - was : RE: jtreg test security/infra/java/security/cert/CertPathValidator/certification/LuxTrus In-Reply-To: References: Message-ID: <8b9420df-9e86-81de-49b3-62b581e3e6a6@oracle.com> Looks fine to me. --Sean On 1/27/20 11:10 AM, Baesken, Matthias wrote: > Hi, new webrev , now with the other bugid : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8237869.1/ > > > > ... and new issue to track the LuxTrust instabilities : > > https://bugs.openjdk.java.net/browse/JDK-8237888 > security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java fails when checking validity interval > > > Best regards, Matthias > > >> On 1/27/20 8:41 AM, Langer, Christoph wrote: >>> Hi Matthias, >>> >>> the entry in ProblemList.txt can't refer to 8237869, which is the bug that >> you're using to submit the exclusion. It must refer to the item that shall >> resolve the underlying issue which probably is Oracle's private bug that Sean >> referred to. >> Right. >> >>> @Sean: In the interest of backportability, I'd ask you to either open up the >> internal bug and supply its id. If that isn't possible, could you please create a >> new public item and have your internal bug refer to it? >> >> I can't open it up because it contains internal network addresses. Even >> if I scrub them out, I believe you could still see them in the History. >> >> I would suggest that Matthias open a new public bug to track this issue >> using the information in the Description of JDK-8237869, and I will then >> mark 8237869 as a duplicate. You can assign that bug to me for now. Most >> likely it is an issue that LuxTrust has to fix on their end, and once >> that is fixed we can simply remove it from the ProblemList. >> >> Thanks, From christoph.langer at sap.com Mon Jan 27 16:18:03 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 27 Jan 2020 16:18:03 +0000 Subject: [CAUTION] RFR [XS]: 8237869: exclude jtreg test security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java because of instabilities - was : RE: jtreg test security/infra/java/security/cert/CertPathValidator/certification/LuxTrus In-Reply-To: <8b9420df-9e86-81de-49b3-62b581e3e6a6@oracle.com> References: <8b9420df-9e86-81de-49b3-62b581e3e6a6@oracle.com> Message-ID: +1 I converted JDK-8237869 to be a subtask of JDK-8237888. @Sean: I couldn't assign it to you but I assume you'll pick it yourself and add do the necessary updates. Thanks. Best regards Christoph > -----Original Message----- > From: Sean Mullan > Sent: Montag, 27. Januar 2020 17:13 > To: Baesken, Matthias ; Langer, Christoph > ; security-dev at openjdk.java.net > Subject: Re: [CAUTION] RFR [XS]: 8237869: exclude jtreg test > security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA. > java because of instabilities - was : RE: jtreg test > security/infra/java/security/cert/CertPathValidator/certification/LuxTrus > > Looks fine to me. > > --Sean > > On 1/27/20 11:10 AM, Baesken, Matthias wrote: > > Hi, new webrev , now with the other bugid : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8237869.1/ > > > > > > > > ... and new issue to track the LuxTrust instabilities : > > > > https://bugs.openjdk.java.net/browse/JDK-8237888 > > > security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA. > java fails when checking validity interval > > > > > > Best regards, Matthias > > > > > >> On 1/27/20 8:41 AM, Langer, Christoph wrote: > >>> Hi Matthias, > >>> > >>> the entry in ProblemList.txt can't refer to 8237869, which is the bug that > >> you're using to submit the exclusion. It must refer to the item that shall > >> resolve the underlying issue which probably is Oracle's private bug that > Sean > >> referred to. > >> Right. > >> > >>> @Sean: In the interest of backportability, I'd ask you to either open up > the > >> internal bug and supply its id. If that isn't possible, could you please create > a > >> new public item and have your internal bug refer to it? > >> > >> I can't open it up because it contains internal network addresses. Even > >> if I scrub them out, I believe you could still see them in the History. > >> > >> I would suggest that Matthias open a new public bug to track this issue > >> using the information in the Description of JDK-8237869, and I will then > >> mark 8237869 as a duplicate. You can assign that bug to me for now. Most > >> likely it is an issue that LuxTrust has to fix on their end, and once > >> that is fixed we can simply remove it from the ProblemList. > >> > >> Thanks, From matthias.baesken at sap.com Tue Jan 28 13:18:31 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 28 Jan 2020 13:18:31 +0000 Subject: RFR: 8237962: give better error output for invalid OCSP response intervals in CertPathValidator checks Message-ID: Hello, please review this small change . While working on https://bugs.openjdk.java.net/browse/JDK-8237869 and https://bugs.openjdk.java.net/browse/JDK-8237888 I noticed that the error output in case of invalid OCSP response intervals could be improved a bit. Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8237962 http://cr.openjdk.java.net/~mbaesken/webrevs/8237962.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Tue Jan 28 15:45:59 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 28 Jan 2020 10:45:59 -0500 Subject: RFR: 8237962: give better error output for invalid OCSP response intervals in CertPathValidator checks In-Reply-To: References: Message-ID: Hi Matthias, On 1/28/20 8:18 AM, Baesken, Matthias wrote: > Hello, please review this small change . > > While working on > https://bugs.openjdk.java.net/browse/JDK-8237869 > and > https://bugs.openjdk.java.net/browse/JDK-8237888 > I noticed that the error output in case of invalid OCSP response > intervals? could be improved a bit. > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8237962 This should be an Enhancement, and not a Bug. You should also add an appropriate noreg label (maybe noreg-trivial). > http://cr.openjdk.java.net/~mbaesken/webrevs/8237962.0/ Please try to keep the lines within 80 characters to be consistent with the rest of the file. It seems you could combine lines 602 and 604. I would also tweak the wording a bit, ex: debug.println("Checking validity of OCSP response on " + new Date(now) + " with allowed interval between " + nowMinusSkew + " and " + nowPlusSkew); Lines 615 through 625 should only be executed if debug is enabled. They should be in an "if (debug != null)" block. Also, if we were going to add this, I would probably restructure this entire block of code so you avoid code duplication. But, I actually don't think these extra debugging statements are necessary. There is enough information in lines 600-605 to know exactly why the validity check failed. My general opinion on debugging logging is to give enough information to help diagnose errors, but don't give too much extraneous information. --Sean > > Thanks, Matthias > From bradford.wetmore at oracle.com Tue Jan 28 21:00:28 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 28 Jan 2020 13:00:28 -0800 Subject: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 Message-ID: <616a4a6e-931c-33f3-be4b-b17a67e73707@oracle.com> Good morning/afternoon/evening/night, As announced on jdk8u-dev[1], there is a Maintenance Release in progress for Java SE 8 (i.e. JSR 337) [2] to include two security features important for TLS 1.3: 1. Application-Layer Protocol Negotiation (ALPN) [3][4] 2. RSA Signature Scheme with Appendix: Probabilistic Signature Scheme (RSASSA-PSS) [5][6] As mentioned in [1], if it wasn't too much work then we would like to contribute the changes required by this MR to the next appropriate OpenJDK 8 release, most likely 8u252. Now that the MR3 balloting successfully concluded last night, I'd like to make that happen, and move the code into review. The code is essentially what was reviewed for 8u41[7][8] and internally for what we expect to be in Oracle's 8u251 JDK, except the code in this review is based on the current JDK 8u workspace. We also included code to allow the Windows platform to use PSS natively. The specific bugs/backports (requested by the JDK8u maintainers) follow: ALPN: ===== 8230977: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension (Java SE 8) 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension 8170282: Enable ALPN parameters to be supplied during the TLS handshake 8145849: ALPN: getHandshakeApplicationProtocol() always return null 8158978: ALPN not working when values are set directly on a SSLServerSocket 8171443: (spec) An ALPN callback function may also ignore ALPN RSASSA-PSS: =========== 8230978: Add support for RSASSA-PSS Signature algorithm (Java SE 8) 8175029: StackOverflowError in X509CRL and X509Certificate.verify(PublicKey, Provider) 8146293: Add support for RSASSA-PSS Signature algorithm 8205445: Add RSASSA-PSS Signature support to SunMSCAPI 8205720: KeyFactory#getKeySpec and translateKey throws NullPointerException with Invalid key 8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized 8213009: Refactoring existing SunMSCAPI classes 8213010: Supporting keys created with certmgr.exe 8214096: sun.security.util.SignatureUtil passes null parameter, so JCE validation fails 8215694: keytool cannot generate RSASSA-PSS certificates 8221407: Windows 32bit build error in libsunmscapi/security.cpp 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange 8223003: SunMSCAPI keys are not cleaned up 8223063: Support CNG RSA keys 8225745: NoSuchAlgorithmException exception for SHA256withECDSA with RSASSA-PSS support 8225180: SignedObject with invalid Key not throwing the InvalidKeyException in Windows 8236470: Deal with ECDSA using ecdsa-with-SHA2 plus hash algorithm as AlgorithmId Reviewed-by: valeriep, weijun, coffeys, pkoppula Here are the reviews: 1. ALPN: http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/ALPN 2. RSASSA-PSS: http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS Most of these changes are direct copies of the changesets applied in JDK 9+, but adjusted for JDK 8u. Also, truncated MessageDigests (i.e. SHA-512/224, SHA-512/256) were added to the SUN Provider to support the corresponding truncated RSASSA-PSS Signatures. Thanks, Brad [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010573.html [2] https://www.jcp.org/en/jsr/detail?id=337 [3] https://bugs.openjdk.java.net/browse/JDK-8230977 [4] https://bugs.openjdk.java.net/browse/JDK-8233417 [5] https://bugs.openjdk.java.net/browse/JDK-8230978 [6] https://bugs.openjdk.java.net/browse/JDK-8233418 [7] https://mail.openjdk.java.net/pipermail/security-dev/2019-November/020900.html [8] http://hg.openjdk.java.net/jdk8u/jdk8u41/ From gnu.andrew at redhat.com Wed Jan 29 07:14:22 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 29 Jan 2020 07:14:22 +0000 Subject: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 In-Reply-To: <616a4a6e-931c-33f3-be4b-b17a67e73707@oracle.com> References: <616a4a6e-931c-33f3-be4b-b17a67e73707@oracle.com> Message-ID: On 28/01/2020 21:00, Bradford Wetmore wrote: > Good morning/afternoon/evening/night, > > As announced on jdk8u-dev[1], there is a Maintenance Release in progress > for Java SE 8 (i.e. JSR 337) [2] to include two security features > important for TLS 1.3: > > 1.? Application-Layer Protocol Negotiation (ALPN) [3][4] > 2.? RSA Signature Scheme with Appendix: Probabilistic Signature Scheme > (RSASSA-PSS) [5][6] > > As mentioned in [1], if it wasn't too much work then we would like to > contribute the changes required by this MR to the next appropriate > OpenJDK 8 release, most likely 8u252. > > Now that the MR3 balloting successfully concluded last night, I'd like > to make that happen, and move the code into review. > > The code is essentially what was reviewed for 8u41[7][8] and internally > for what we expect to be in Oracle's 8u251 JDK, except the code in this > review is based on the current JDK 8u workspace.? We also included code > to allow the Windows platform to use PSS natively. > > The specific bugs/backports (requested by the JDK8u maintainers) follow: > > ALPN: > ===== > 8230977: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation > Extension (Java SE 8) > 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation > Extension > 8170282: Enable ALPN parameters to be supplied during the TLS handshake > 8145849: ALPN: getHandshakeApplicationProtocol() always return null > 8158978: ALPN not working when values are set directly on a SSLServerSocket > 8171443: (spec) An ALPN callback function may also ignore ALPN > > RSASSA-PSS: > =========== > 8230978: Add support for RSASSA-PSS Signature algorithm (Java SE 8) > 8175029: StackOverflowError in X509CRL and > X509Certificate.verify(PublicKey, Provider) > 8146293: Add support for RSASSA-PSS Signature algorithm > 8205445: Add RSASSA-PSS Signature support to SunMSCAPI > 8205720: KeyFactory#getKeySpec and translateKey throws > NullPointerException with Invalid key > 8206171: Signature#getParameters for RSASSA-PSS throws ProviderException > when not initialized > 8213009: Refactoring existing SunMSCAPI classes > 8213010: Supporting keys created with certmgr.exe > 8214096: sun.security.util.SignatureUtil passes null parameter, so JCE > validation fails > 8215694: keytool cannot generate RSASSA-PSS certificates > 8221407: Windows 32bit build error in libsunmscapi/security.cpp > 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange > 8223003: SunMSCAPI keys are not cleaned up > 8223063: Support CNG RSA keys > 8225745: NoSuchAlgorithmException exception for SHA256withECDSA with > RSASSA-PSS support > 8225180: SignedObject with invalid Key not throwing the > InvalidKeyException in Windows > 8236470: Deal with ECDSA using ecdsa-with-SHA2 plus hash algorithm as > AlgorithmId > Reviewed-by: valeriep, weijun, coffeys, pkoppula > > Here are the reviews: > > 1.? ALPN: > ???? http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/ALPN > > 2.? RSASSA-PSS: > ???? http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS > > Most of these changes are direct copies of the changesets applied > in JDK 9+, but adjusted for JDK 8u. > > Also, truncated MessageDigests (i.e. SHA-512/224, SHA-512/256) were > added to the SUN Provider to support the corresponding truncated > RSASSA-PSS Signatures. > > Thanks, > > Brad > > [1] > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010573.html > [2] https://www.jcp.org/en/jsr/detail?id=337 > [3] https://bugs.openjdk.java.net/browse/JDK-8230977 > [4] https://bugs.openjdk.java.net/browse/JDK-8233417 > [5] https://bugs.openjdk.java.net/browse/JDK-8230978 > [6] https://bugs.openjdk.java.net/browse/JDK-8233418 > [7] > https://mail.openjdk.java.net/pipermail/security-dev/2019-November/020900.html > > [8] http://hg.openjdk.java.net/jdk8u/jdk8u41/ > > Thanks for posting these. I'll look over them in detail tomorrow and compare with the 9+ changesets listed. It would have been preferable to handle each backport individually, but I appreciate that it's more expedient to handle them in bulk when porting from 8u41. Thanks again, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From matthias.baesken at sap.com Wed Jan 29 09:20:48 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 29 Jan 2020 09:20:48 +0000 Subject: RFR: 8237962: give better error output for invalid OCSP response intervals in CertPathValidator checks Message-ID: Hi Sean, new webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8237962.1/ Best Regards, Matthias > > Message: 2 > Date: Tue, 28 Jan 2020 10:45:59 -0500 > From: Sean Mullan > To: security-dev at openjdk.java.net > Subject: Re: RFR: 8237962: give better error output for invalid OCSP > response intervals in CertPathValidator checks > Message-ID: > Content-Type: text/plain; charset=windows-1252; format=flowed > > Hi Matthias, > > On 1/28/20 8:18 AM, Baesken, Matthias wrote: > > Hello, please review this small change . > > > > While working on > > https://bugs.openjdk.java.net/browse/JDK-8237869 > > and > > https://bugs.openjdk.java.net/browse/JDK-8237888 > > I noticed that the error output in case of invalid OCSP response > > intervals? could be improved a bit. > > > > Bug/webrev : > > > https://bugs.openjdk.java.net/browse/JDK-8237962 > > This should be an Enhancement, and not a Bug. You should also add an > appropriate noreg label (maybe noreg-trivial). > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8237962.0/ > > Please try to keep the lines within 80 characters to be consistent with > the rest of the file. > > It seems you could combine lines 602 and 604. I would also tweak the > wording a bit, ex: > > debug.println("Checking validity of OCSP response on " + > new Date(now) + " with allowed interval between " + > nowMinusSkew + " and " + nowPlusSkew); > > Lines 615 through 625 should only be executed if debug is enabled. They > should be in an "if (debug != null)" block. Also, if we were going to > add this, I would probably restructure this entire block of code so you > avoid code duplication. > > But, I actually don't think these extra debugging statements are > necessary. There is enough information in lines 600-605 to know exactly > why the validity check failed. My general opinion on debugging logging > is to give enough information to help diagnose errors, but don't give > too much extraneous information. > > --Sean > From matthias.baesken at sap.com Wed Jan 29 12:18:38 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 29 Jan 2020 12:18:38 +0000 Subject: 8238157: security/infra/java/security/cert/CertPathValidator/certification/AmazonCA.java tests failures because of revocation date Message-ID: Hello, recently we see (cross platform) sometimes failures in the jtreg test security/infra/java/security/cert/CertPathValidator/certification/AmazonCA.java . The failures look like this : java.lang.RuntimeException: TEST FAILED: unexpected revocation date at ValidatePathWithParams.validate(ValidatePathWithParams.java:206) at AmazonCA_3.runTest(AmazonCA.java:444) at AmazonCA.main(AmazonCA.java:66) 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:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:834) or java.lang.RuntimeException: TEST FAILED: unexpected revocation date at ValidatePathWithParams.validate(ValidatePathWithParams.java:209) at AmazonCA_1.runTest(AmazonCA.java:189) at AmazonCA.main(AmazonCA.java:64) 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:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:832) looking at the logfiles we see small differences between expected and currently found revocation date : Certificate revocation date:Tue Jan 29 00:35:55 CET 2019 Expected revocation date:Tue Jan 29 00:35:56 CET 2019 This seems to cause the trouble . I opened https://bugs.openjdk.java.net/browse/JDK-8238157 for this - do you think it is an issue on Amazon side ? Best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Jan 29 15:55:09 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 29 Jan 2020 10:55:09 -0500 Subject: RFR: 8237962: give better error output for invalid OCSP response intervals in CertPathValidator checks In-Reply-To: References: Message-ID: Looks good. Thanks, Sean On 1/29/20 4:20 AM, Baesken, Matthias wrote: > > Hi Sean, new webrev : > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8237962.1/ > > > Best Regards, Matthias > > >> >> Message: 2 >> Date: Tue, 28 Jan 2020 10:45:59 -0500 >> From: Sean Mullan >> To: security-dev at openjdk.java.net >> Subject: Re: RFR: 8237962: give better error output for invalid OCSP >> response intervals in CertPathValidator checks >> Message-ID: >> Content-Type: text/plain; charset=windows-1252; format=flowed >> >> Hi Matthias, >> >> On 1/28/20 8:18 AM, Baesken, Matthias wrote: >>> Hello, please review this small change . >>> >>> While working on >>> https://bugs.openjdk.java.net/browse/JDK-8237869 >>> and >>> https://bugs.openjdk.java.net/browse/JDK-8237888 >>> I noticed that the error output in case of invalid OCSP response >>> intervals? could be improved a bit. >>> >>> Bug/webrev : >>>> https://bugs.openjdk.java.net/browse/JDK-8237962 >> >> This should be an Enhancement, and not a Bug. You should also add an >> appropriate noreg label (maybe noreg-trivial). >> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8237962.0/ >> >> Please try to keep the lines within 80 characters to be consistent with >> the rest of the file. >> >> It seems you could combine lines 602 and 604. I would also tweak the >> wording a bit, ex: >> >> debug.println("Checking validity of OCSP response on " + >> new Date(now) + " with allowed interval between " + >> nowMinusSkew + " and " + nowPlusSkew); >> >> Lines 615 through 625 should only be executed if debug is enabled. They >> should be in an "if (debug != null)" block. Also, if we were going to >> add this, I would probably restructure this entire block of code so you >> avoid code duplication. >> >> But, I actually don't think these extra debugging statements are >> necessary. There is enough information in lines 600-605 to know exactly >> why the validity check failed. My general opinion on debugging logging >> is to give enough information to help diagnose errors, but don't give >> too much extraneous information. >> >> --Sean >> > From sean.mullan at oracle.com Wed Jan 29 16:16:20 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 29 Jan 2020 11:16:20 -0500 Subject: 8238157: security/infra/java/security/cert/CertPathValidator/certification/AmazonCA.java tests failures because of revocation date In-Reply-To: References: Message-ID: On 1/29/20 7:18 AM, Baesken, Matthias wrote: > > Hello, recently we see (cross platform)? sometimes failures in the > jtreg test > security/infra/java/security/cert/CertPathValidator/certification/AmazonCA.java > . > Is it intermittent or consistent? Also do you see it with CRLs or OCSP? It could be an issue with Amazon's CA. Perhaps the revocation date in the CRL and OCSP response is off by one second. It would be useful if you could debug a bit more into this. Thanks, Sean > The? failures look like this : > > java.lang.RuntimeException: TEST FAILED: unexpected revocation date > > ??????????????? at > ValidatePathWithParams.validate(ValidatePathWithParams.java:206) > > ??????????????? at AmazonCA_3.runTest(AmazonCA.java:444) > > ??????????????? at AmazonCA.main(AmazonCA.java:66) > > ??????????????? 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:566) > > ??????????????? at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > > ??????????????? at java.base/java.lang.Thread.run(Thread.java:834) > > ? or > > java.lang.RuntimeException: TEST FAILED: unexpected revocation date > > ??????????????? at > ValidatePathWithParams.validate(ValidatePathWithParams.java:209) > > ??????????????? at AmazonCA_1.runTest(AmazonCA.java:189) > > ??????????????? at AmazonCA.main(AmazonCA.java:64) > > ??????????????? 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:564) > > ??????????????? at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > > ??????????????? at java.base/java.lang.Thread.run(Thread.java:832) > > looking at the logfiles we see small differences between expected and > currently found revocation date : > > Certificate revocation date:Tue Jan 29 00:35:55 CET 2019 > > Expected revocation date:Tue Jan 29 00:35:56 CET 2019 > > This seems to? cause the trouble . > > I opened > > https://bugs.openjdk.java.net/browse/JDK-8238157 > > for this ? do you think it is an issue on Amazon side ? > > Best regards, Matthias > From eric.caspole at oracle.com Wed Jan 29 20:55:50 2020 From: eric.caspole at oracle.com (eric.caspole at oracle.com) Date: Wed, 29 Jan 2020 15:55:50 -0500 Subject: RFR (XS): 8238189 Cleanups to AES crypto micros Message-ID: <4529a790-4746-420b-40d7-f8c1f66b7c4a@oracle.com> Hi everyone, Get I get reviews on this small change to the AESBench crypto micro, which puts all the algorithms into the small set for convenience of testing compiler intrinsics etc. JBS: https://bugs.openjdk.java.net/browse/JDK-8238189 Webrev: http://cr.openjdk.java.net/~ecaspole/JDK-8238189/01/webrev/ Thanks, Eric From xuelei.fan at oracle.com Wed Jan 29 22:32:12 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 29 Jan 2020 14:32:12 -0800 Subject: RFR (XS): 8238189 Cleanups to AES crypto micros In-Reply-To: <4529a790-4746-420b-40d7-f8c1f66b7c4a@oracle.com> References: <4529a790-4746-420b-40d7-f8c1f66b7c4a@oracle.com> Message-ID: <34832123-df13-1609-38a4-b44d36955de7@oracle.com> It looks good to me. Thanks, Xuelei On 1/29/2020 12:55 PM, eric.caspole at oracle.com wrote: > Hi everyone, > Get I get reviews on this small change to the AESBench crypto micro, > which puts all the algorithms into the small set for convenience of > testing compiler intrinsics etc. > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8238189 > > Webrev: > http://cr.openjdk.java.net/~ecaspole/JDK-8238189/01/webrev/ > > Thanks, > Eric From matthias.baesken at sap.com Thu Jan 30 08:24:33 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 30 Jan 2020 08:24:33 +0000 Subject: RFR: 8237962: give better error output for invalid OCSP response intervals in CertPathValidator checks In-Reply-To: References: Message-ID: Thanks, may I have a second review ? Best regards, Matthias > Looks good. > > Thanks, > Sean > > On 1/29/20 4:20 AM, Baesken, Matthias wrote: > > > > Hi Sean, new webrev : > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8237962.1/ > > > > > > Best Regards, Matthias > > From matthias.baesken at sap.com Thu Jan 30 08:34:51 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 30 Jan 2020 08:34:51 +0000 Subject: 8238157: security/infra/java/security/cert/CertPathValidator/certification/AmazonCA.java tests failures because of revocation date In-Reply-To: References: Message-ID: Hello Sean, it is intermittent (we see it ~ 1-2 times per week in our tests ). > Also do you see it with CRLs or OCSP? I think it is OCSP, at least the log says OCSP a lot of times ?? ! > Perhaps the revocation date in > the CRL and OCSP response is off by one second Yeah, looks like this ! Best regards, Matthias > > On 1/29/20 7:18 AM, Baesken, Matthias wrote: > > > > Hello, recently we see (cross platform)? sometimes failures in the > > jtreg test > > > security/infra/java/security/cert/CertPathValidator/certification/AmazonCA. > java > > . > > > > Is it intermittent or consistent? Also do you see it with CRLs or OCSP? > > It could be an issue with Amazon's CA. Perhaps the revocation date in > the CRL and OCSP response is off by one second. It would be useful if > you could debug a bit more into this. > > Thanks, > > Sean > From christoph.langer at sap.com Thu Jan 30 10:52:43 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 30 Jan 2020 10:52:43 +0000 Subject: RFR: 8237962: give better error output for invalid OCSP response intervals in CertPathValidator checks In-Reply-To: References: Message-ID: Hi Matthias, I'm wondering whether we should add cpve as cause of the RuntimeException in test/jdk/security/infra/java/security/cert/CertPathValidator/certification/ValidatePathWithParams.java, line 177, instead of printing it out explicitly? Like: throw new RuntimeException( "TEST FAILED: couldn't determine EE certificate status", cvpe); Best regards Christoph > -----Original Message----- > From: Baesken, Matthias > Sent: Donnerstag, 30. Januar 2020 09:25 > To: Sean Mullan ; security- > dev at openjdk.java.net > Cc: Langer, Christoph > Subject: RE: RFR: 8237962: give better error output for invalid OCSP response > intervals in CertPathValidator checks > > Thanks, may I have a second review ? > > Best regards, Matthias > > > > > Looks good. > > > > Thanks, > > Sean > > > > On 1/29/20 4:20 AM, Baesken, Matthias wrote: > > > > > > Hi Sean, new webrev : > > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8237962.1/ > > > > > > > > > Best Regards, Matthias > > > From barath.pg67 at gmail.com Thu Jan 30 11:43:28 2020 From: barath.pg67 at gmail.com (BHARATH P G) Date: Thu, 30 Jan 2020 17:13:28 +0530 Subject: Regarding OpenJDK bug#JDK-8211787 Message-ID: Hi, The bug JDK-8211787 has been resolved by changing the test case timeout from 5000 to 25000 ms. Could someone please explain what changed in jdk to increase the socket timeout of a test case which was working fine in 8 but with 12? Thanks, Bharath -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Thu Jan 30 13:27:56 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 30 Jan 2020 13:27:56 +0000 Subject: RFR: 8237962: give better error output for invalid OCSP response intervals in CertPathValidator checks In-Reply-To: References: Message-ID: Hi Christoph, that sounds like a good idea . New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8237962.3/ Thanks, Matthias > Hi Matthias, > > I'm wondering whether we should add cpve as cause of the > RuntimeException in > test/jdk/security/infra/java/security/cert/CertPathValidator/certification/Val > idatePathWithParams.java, line 177, instead of printing it out explicitly? > > Like: > throw new RuntimeException( > "TEST FAILED: couldn't determine EE certificate status", cvpe); > > Best regards > Christoph > > > -----Original Message----- > > From: Baesken, Matthias > > Sent: Donnerstag, 30. Januar 2020 09:25 > > To: Sean Mullan ; security- > > dev at openjdk.java.net > > Cc: Langer, Christoph > > Subject: RE: RFR: 8237962: give better error output for invalid OCSP > response > > intervals in CertPathValidator checks > > > > Thanks, may I have a second review ? > > > > Best regards, Matthias > > > > > > > > > Looks good. > > > > > > Thanks, > > > Sean > > > > > > On 1/29/20 4:20 AM, Baesken, Matthias wrote: > > > > > > > > Hi Sean, new webrev : > > > > > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8237962.1/ > > > > > > > > > > > > Best Regards, Matthias > > > > From sean.mullan at oracle.com Thu Jan 30 19:18:31 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 30 Jan 2020 14:18:31 -0500 Subject: [15] RFR: 8191395: policy.allowSystemProperty and policy.expandProperties also apply to JAAS configurations Message-ID: <30c2ed46-52ac-613d-dcaa-bcf166e5b295@oracle.com> Please review this small change to the documentation of these two security properties. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191395/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8191395 Thanks, Sean From mbalao at redhat.com Fri Jan 31 00:23:26 2020 From: mbalao at redhat.com (Martin Balao) Date: Thu, 30 Jan 2020 21:23:26 -0300 Subject: RFR 8238264: Exception thrown when setting javax.net.ssl.keyStoreType = PKCS11 Message-ID: Hi, I'd like to have a review for 8238264 [1]. Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8238264/8238264.webrev.00/ Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8238264 From weijun.wang at oracle.com Fri Jan 31 00:27:19 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 31 Jan 2020 08:27:19 +0800 Subject: [15] RFR: 8191395: policy.allowSystemProperty and policy.expandProperties also apply to JAAS configurations In-Reply-To: <30c2ed46-52ac-613d-dcaa-bcf166e5b295@oracle.com> References: <30c2ed46-52ac-613d-dcaa-bcf166e5b295@oracle.com> Message-ID: <387D67EA-1C90-4658-95E3-F58B425CEA86@oracle.com> Looks fine. Does this require a CSR? Thanks, Max > On Jan 31, 2020, at 3:18 AM, Sean Mullan wrote: > > Please review this small change to the documentation of these two security properties. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191395/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8191395 > > Thanks, > Sean From sean.mullan at oracle.com Fri Jan 31 15:42:12 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 31 Jan 2020 10:42:12 -0500 Subject: [15] RFR: 8191395: policy.allowSystemProperty and policy.expandProperties also apply to JAAS configurations In-Reply-To: <387D67EA-1C90-4658-95E3-F58B425CEA86@oracle.com> References: <30c2ed46-52ac-613d-dcaa-bcf166e5b295@oracle.com> <387D67EA-1C90-4658-95E3-F58B425CEA86@oracle.com> Message-ID: On 1/30/20 7:27 PM, Weijun Wang wrote: > Looks fine. Does this require a CSR? Hmm, I was on the fence about that. ConfigFile already mentions policy.allowSystemProperty in the class description [1], so I think in this case, we are just improving the documentation. I can't find any JAAS reference to policy.expandProperties though. I suppose we should file one then since this would be the first time it is documented. Let me draft up a CSR and reply back later. --Sean [1] https://download.java.net/java/early_access/jdk14/docs/api/jdk.security.auth/com/sun/security/auth/login/ConfigFile.html > > Thanks, > Max > >> On Jan 31, 2020, at 3:18 AM, Sean Mullan wrote: >> >> Please review this small change to the documentation of these two security properties. >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191395/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8191395 >> >> Thanks, >> Sean >